|
Roger's Code Workshop: Part 1
Atari
ST/TT/Falcon programming
Hello and welcome to Roger's Code Workshop. My name is Roger Burrows and I've been programming on Atari 680x0 machines since around 1990.
This is the first instalment of (I hope) a regular column in MyAtari, on any and all topics related to programming on the Atari. The editors have given me a free hand, so I intend to discuss things of general interest as well as the "techie" stuff.
Graphical User Interface (GUI) Libraries (1)
One of the best things about the introduction of the Atari ST was the built-in GUI. From a programmer's point of view, the GUI is managed by calling parts of the operating system to do things like open a window, display text
and so forth. However, although everything you absolutely need is there, it
takes a lot of extra code and care to achieve some things that seem straightforward from the outside, like managing multiple windows.
And every time you develop a program, you need (more or less) the same additional code.
Because programmers are lazy, they prefer
to write code only once and to have someone else write it anyway. For these reasons, GUI libraries are
useful. They provide functions beyond those offered by the basic Atari AES/VDI calls and are generally well tested, since they have been used in multiple programs.
When Anodyne Software was looking around for a GUI library to use when developing CD writing software, we had the following requirements:
documentation in English or French, simple to use, available for both Pure C and Lattice C (or easily portable), and source code available. We ended up with a library called Windform, developed in France. Next time I'll let you know whether we made the right decision.
Programming as a game
Over the years, I've bought and played quite a few computer games, but I never seem to spend as much time on them as I do on my TT, writing code. This could be because I need to get a life, but my current theory is that programming is the best game of all. The machine sits there, capable of
doing all kinds of amazing things, just waiting for the right commands. A bit like the original Adventure, except that there is no predetermined solution,
you can do anything you can think of.
Like many games, where you're just "that close" to breaking your points record or reaching the next level, in programming you're always "that close" to fixing the last bug, or writing the best editor, or whatever. Both situations provide the incentive to keep going where some (more sensible?) person might just give up.
Of course, there are those who think that playing games is a poor substitute for experiencing real life, so perhaps spending much of my time on a substitute for a substitute for real life isn't a lot to boast about...
Coda
If you have any questions about programming, or suggestions for topics you'd like me to cover, please let me know. If you have code that doesn't
work (or does work but you don't know why!), let me know and I'll try to help. If it's of general interest, I'll include it in this column.
codeworkshop@anodynesoftware.com.
|
