I really don't claim to be a Pilot Programming guru, but I would like to give some pointers to people starting out. I was somewhat confused and intimidated by the state of the art of programming the Pilot on the PC platform when I first looked into it, so I know there must be other people who need a jump start.
I would first point out that I personally have over 20 years of programming experience on all sorts of computers. I say this not to toot my own horn, but to emphasize that programming the Pilot is not for the novice programmer. The tools I used, gcc, Pilrc, and Copilot, are oriented toward people who have already worked with C/C++ and Unix. If you don't already know something about these languages, how makefiles work, linking, and debugging, I would suggest you start out with something easier. Take a class or read a book about programming and try programming your PC with a good learning language and environment, such as Visual C++ or Visual Basic.
So if you are up to the gcc challenge, start by looking at Darrin Massena's Pilot Development Page. He has a lot of good material there. Darrin Massena also runs a newsgroup on programming, and the link is on his page. You can also look at the PalmOS Development page. There is also Wademan's FAQ.
Use the instructions in Wademan's FAQ to download the gcc package and unpack it. It comes with Emacs , the king of all editors. This is a port for Win32 and works well. You can also use Bill Gates' WordPad (save your file as plain text) or any other text editor. Snoop around the example program directory. The most important files are the makefile (Makefile), the source file (hello-world.c), and the resource file (hello-world.rcp). Hopefully you know what a makefile is. It tells the computer how to build your program and automatically does what is necessary based on what you have changed recently. The source code files are what you would expect, except in the Pilot world there is a "PilotMain", not "main". The resource file is written in a language unique to Pilrc. If you download the Pilrc separately, it has documentation. You can try putting your name as the title by changing the resource file, for example.
To start making your own program, make a new directory and copy the example program files into it. Rename files and edit away. From here, it is really up to your skill and imagination. I spent a lot of time downloading other people's programs with source code and reverse engineering them. Try your program on the Copilot at regular intervals. The Copilot is a marvelous tool, and I find it amazing how closely it behaves to the real Pilot. If your program crashes, try reversing your edits back to where it worked before. (Remember Dave's First Rule of Software: SAVE SAVE SAVE!) You can also put in FrmCustomAlert() calls to display data or stop the program at key places. If you are really skilled, you can try using the debugger in the Copilot. It is assembly code level, though, so you have to figure out where your program symbols are somehow. :-( I haven't really looked into it, but the CodeWarrior is available for the PC now and I would imagine it has a C debugger. If you have access to Linux gcc you can get a lot of the logic and flow of your program working on the PC platform before trying it on the Pilot. I did this with Rally 1000.Your program runs a lot like one on a PC, but you must remember some important differences. When a user starts up another app during your program, you must react to it. This is the "appStopEvent" event in your main loop. When you see this, you must clean up and terminate. If you don't want your program to restart from scratch the next time, you must save status information. Since there is no disk drive on a PalmPilot (not yet :-) ) you must use a database or the preferences system. I don't know anything about databases. Preferences work off the "PrefGetAppPreferences" and "PrefSetAppPreferences" calls. These changed in version 2.0, so you should read up on them. I put all my program's information into a structure and saved the whole block. When coming up you just read the prefs back into the same structure.
A trick I learned to make the program behave better was to set up an initial loop in the program which waits for the "frmOpenEvent" event. If you try to do any graphics operations before receiving this event, your program my hang or act strangely.
One pitfall I hit was that gcc does not process global arrays with aggregate initializers, i.e. char names[] = {"foo", "bar" };. I had to write a global initialization routine to loop through and initialize the arrays. I read in the newsgroup that this can be overcome, but I didn't look into it any further.
I found the FrmCustomAlert particularly useful. You define a dialog resource with a string in it with the characters "^1", "^2", and "^3" in it. Then you call FrmCustomAlert with 1-3 string arguments. The string arguments get put into the places where you put the carat markers. This way you can put up variable messages.
String handling in gcc is kind of primitive. In version 1.0 of the PalmPilot firmware, you had just the basic copying and concatenation, StrCopy and StrCat. There are also calls to put words and ints into strings, such as StrIToA. I found StrIToA did not work with negative integers, however. In version 2.0 of the PalmPilot firmware they added a "sprintf" type of capability, but if you rely on it, your program will not run under 1.0.
Good luck programming the world's premier PDA!
Updated 24 January 1998.