News: (May 2000) There is a patch to make Think Pascal 4.5 compatible with newer versions of MacOS! And this time it works! See "How do I get it" below.
Contents:
Introduction
This page is written in order to help you get started with Think Pascal 4.5, the newest version of Think Pascal, freely downloadable off the net. The fact that you can download the complete compiler for free means that we have a complete free development system for the Mac!
Note, however, that it is provided as an unofficial update. You can get no support whatsoever for it from Symantec! Version 4.5d4 was made by Rich Siegel (of BBEdit fame), who was in the past responsible for the official updates of Think Pascal. We should be thankful to both Rich for making the update and for Symantec for providing it. Both make no money from it. Let's make a note in the "good reputation" column!
About the author
I, Ingemar Ragnemalm, have no official status with Symantec and Think Pascal, but am basically just a long-time satisfied user. I have developed large amounts of code with Think Pascal, and I believe that I know both Mac programming and Think Pascal pretty well. Still, I don't claim that I know everything about either of them.
I started programming the Mac with Borland's Turbo Pascal, and switched to Think C since that's what everybody recommended, and I needed something a bit more professional than Turbo, something that could handle more than one source file at a time.
One day, a friend had an old Pascal program that he wanted to run on the Mac. For some reason, I tried Think Pascal when doing it. Actually, I think the reason was that TransSkel was made for Think rather than Turbo. And, I was astonished to see how easy it was! Think Pascal nailed my errors far quicker than any of the other systems I knew, and I used the debugger efficiently almost without being aware of it. I gave it a few more shots, and was hooked. I converted the C code I was working on to Pascal, and saw how development speed was multiplied. Today, that old code is known as Sprite Animation Toolkit.
I was amazed, and I still am. Part of it was that Pascal is a more forgiving language than C, and also nicer to use with the Mac toolbox, but an equal part was the qualities of Think Pascal as a development system.
What is Think Pascal?
Think Pascal is an excellent development system for the Macintosh. It was released by Think Technologies in 1986 as Lightspeed Pascal. Think Technologies was bought by Symantec, and the name was changed to Think Pascal. The last official update came 1992, and the product was officially discontinued in 1997.
Lightspeed Pascal was a fantastic development system, significantly better than its cousin Lightspeed C (Think C). It is surprising that it didn't get more attention. There are some reasons, one that Pascal is often considered to be "just" an educational language, an impression that perhaps was exaggerated by its close relation to MacPascal, an interpreter that definitely is only for educational use.
But, Lightspeed/Think Pascal is so much more!
- It is a good compiler, generating good, fast 68k code.
- The editor auto-formats the code, which keeps it clean and readable, saving you the time to do it.
- It has a fantastic debugger with powerful features that no other development system has. Learn the debugger, it is fantastic! (See further below.)
It has some drawbacks, namely:
- You can't turn off auto-formatting.
- It can not generate PPC native code, only 68k code.
- Careless port-setting can create problems that will make the program break when compiled to disk, but work in the debugger.
- You can not compile C code, assembler or any other language.
All these problems have their solutions:
- You edit non-Pascal files with a separate text editor, like BBEdit or SimpleText.
- You develop your program in Think Pascal, and when you need a PPC native version, you make the necessary changes to make it compile in CodeWarrior too. Don't switch to CodeWarrior, just make your code work with both and have the best of both worlds!
- The debugger vs stand-alone problem never, absolutely never happens to me, so it seems like it is a beginner problem. I believe the problem is port setting, but I'll try to add more info when I can. (See further the section Doh! Why doesn't my program work?.)
- If you need to link C code with your Think Pascal program, you need to compile it to a library with Think C.
How do I get it?
Download Think Pascal 4.5d4 from Symantec.
Download a better set of interfaces from my archive.
Download the Think Pascal 4.5d4->4.5a1 patch. This is necessary to use Think Pascal on MacOS verisons 8.5 and up, and adds some other improvements as well.
No, you can't use the interface files that come with the compiler. They are buggy, and also tedious to use, with lots of unnecessary "uses". The modified version may not be perfect, but it works a lot better.
Setting it up
Decompress THINK Pascal 4.5d4.sit, Ingemar's UPI for TP 4.5d4.cpt and Pascal 4.5a1 Update.sit by dropping them on Stuffit Expander. (Keep the archives in case you want to go back.) The result is three folders, one named THINK Pascal 4.5d4, one named THINK Pascal 4.5d4 Folder and a third named Pascal Update. The first contains my modified UPI,the other Think Pascal and the original UPI, with subfolders named THINK Pascal 4.5d4 and THINKPas Univ Hdr 2.1, and the third is the update.
Now we must clean up this mess.
Move the contents of THINK Pascal 4.5d4 (my modified interfaces) into THINK Pascal 4.5d4 Folder:THINK Pascal 4.5d4 - that is, move my interfaces to the folder where the compiler is located. Trash the empty THINK Pascal 4.5d4 folder.
Open THINKPas Univ Hdr 2.1. Move Runtime.lib and the folder Libraries into the folder where the compiler is. Take THINK Pascal 4.5d4 out of THINK Pascal 4.5d4 Folder, and trash THINK Pascal 4.5d4 Folder (now containing only THINKPas Univ Hdr 2.1).
Move Interface.Lib from the update frolder to the Think Pascal 4.5 folder. Trash Interface.o. (There was another Interface.Lib in the Univ Hdr folder, but that should be trashed by now.)
Run THINK Pascal 4.5d4 -> 4.5a1 to update the Think Pascal 4.5 application.
To clean up the Think Pascal 4.5 folder, you may want to put away the doc files. If you kept the archives, why not trash them? There is some useful information in them, though.
You should now have a folder with the following files and folders:
- Interface.Lib (was Interface.o when you got it, but you have renamed it)
- Interfaces (contains my modified files)
- Libraries (from the Univ Hdr folder)
- Runtime.Lib (ditto)
- THINK Pascal 4.5 (that is, TP 4.5a1)
The resulting folder should something like this:
Rename the folder to THINK Pascal 4.5a1, just to make it tell the truth. OK, now you have a complete development system ready to use!
You need two more things to make it complete: you need a resource editor and a reference to the Mac toolbox!
ResEdit is the only choice for resource editor if you have an extremely low budget. Resorceror may be of interest the day your budget is better.
Finally, how about the documentation to the Mac toolbox? Inside Macintosh is the original text on the subject. If you haven't done so already, I suggest you get a copy of Apple's Inside Macintosh documentation. You can download it from Apple. There is a lot of documentation so I suggest looking at the Overview first to give you an idea of what other documentation volumes might be worthwhile for your needs.
An alternative that is easier to use is Think Reference, which was made by Symantec but is published by MacTech these days. Commercial, a bit too C-centric, but easy to use.
An old shareware solution is Inside Mac DA. It only covers up to Inside Mac 4, so it is older than Color QuickDraw, but still small, fast and pretty useful as a reference to the most important parts. A more modern solution that you can also get off the net is ObiWan by Peter Lewis. It is shareware, $10.
Getting started
Think Pascal is a fairly intuitive development system, where you can learn a lot by just trial and error. Open dialogs, change settings, try menu commands, and not least, run and modify demo programs!
Now, how about starting out with the simplest program of all, "Hello world". Do the following:
Create a new project. Check "instant project" if you want a main program file created for you. Replace the line
{ Insert your program code here }
by
ShowText;WriteLn('Hello world!');
Hit cmd-R (Run) to compile and run. No problem!
Now, how about the "real Mac" version of Hello world? It is longer, but not too bad:
program Test;{Variables:}varw: WindowPtr; {A window to draw in}r: Rect; {The bounding box of the window}begin{Create the window}SetRect(r, 50, 50, 200, 100);w := NewWindow(nil, r, '', true, plainDBox, WindowPtr(-1), false, 0);{Make it the current drawing port}SetPort(w);{Draw a string!}MoveTo(5, 20);DrawString('Hello world!');{Wait for a mouse-click, then stop.}while not Button do;end.
All the parameters to NewWindow are a bit confusing, but you will usually read windows from resources, which is easier.
I have no intention of providing a complete manual here, but here are some notes on things that are not entirely intuitive:
- You must have a project file to compile anything. You can't just open a source file and compile it. The project file describes what source and library files the compiler should use. All files that should be used must be added to the project file/window.
- The four letters DNVR listed with each file in the project
window enable/disable the following features:
- D: Debug, lets you step, set breakpoints etc in the unit.
- N: Macsbug names.
- V: Overflow checking.
- R: Range checking.
- N: Macsbug names.
Disable DVR for maximum speed, enable them for maximum safety. I believe N only affects the size. Debugging with range and overflow checking on can be a lot easier than without them!
- D: Debug, lets you step, set breakpoints etc in the unit.
- Use the procedures ShowDrawing and ShowText to show the Text and Drawing windows from the program.
- You don't use Drawing and Text in "real" programs, but they are quite useful for quick test hacks.
- The "Run options" dialog is very important! There, you can select a resource file to use, and to copy into the application when building to disk, and there you set the memory partition and stack size. Note that the memory partition when building to disk is not set there, but by a "SIZE" resource.
Having fun with the debugger
Have you tried the debugger yet? You don't really need to know all of it to start working, but there is a lot of potential there, not all of it obvious. It consists of at least four parts: the editor windows, Lightsbug, Instant and Observe.
The Lightsbug window may seem a bit cluttered. The most useful part is the variable list, but the other parts are worth exploring. You can click-and-drag variables to the icons down the left side to access some special features.
The top three icons swich between variable view, register view and heap view. You will mostly use the variable view, although the other two are in no way useless! Then follows these: Magnifying glass, File cabinet, Eye Folder, Pencil icon, Groucho icon and Trash icon. All are explained if you click on them!
The bottom part of the window shows the memory as raw hex numbers. That is occasionally useful, but when you don't use it, you can hide it by dragging the separating line downwards.
Don't forget the other parts of the debugger! Lightsbug is just one of them. The innocent-looking Observe and Instant are extremely powerful and useful, and the editor windows, where you single-step and set breakpoints, is perhaps the most vital one.
Note, however, that power should be used with a little care. Be careful with putting expressions in Observe that use pointers or handles that may become invalid, or expressions that allocate memory!
Here are some specific non-obvious debugger features:
- You must check "stops in" to be able to set breakpoints. You set breakpoints by clicking "stop signs" in the left side of the editor window.
- When debugging, the little icon in the upper right corner can be clicked to stop execution at any time. Command-shift-period has the same effect.
- You can get more than one Lightsbug window! Try cmd-shift-L!
- Observe will re-evaluate all expressions typed in it if you select Observe from the Debug menu.
- The contents of Observe and Instant isn't saved when you quit, but if you have much and interesting contents in it, you can save manually from the file menu. The same holds for Instant.
Doh! Why doesn't my program work?
There are a few pitfalls, problems that you can run into after a while.
- You sometimes get error messages about "segment too large". If you do, click the pyramid icon in the project window to switch to "segment view". There, you can drag files between segments. Generally speaking, try to keep you segments below 32k!
- The debugging gear in Think Pascal is not interrupt-safe, so if you have any VBL tasks, Time Manager tasks, Device Manager or file system callback routines, put a {$Push} {$D-} before the routine's definition, and a {$Pop} after it.
- It's pretty much impossible to debug Drag Manager tracking routines inside of Think Pascal, because of the games that the Drag Manager plays. (Don't bother trying; your machine will lock up solidly.) You'll need to debug them using Macsbug. You can debug Drag Manager receive handlers, however.
- It's tricky to debug Apple Event code inside of Think Pascal, because when you send Think Pascal to the background, the user program gets suspended and won't respond to Apple Events. However, if you can assemble a test harness so that your program sends Apple Events to itself, or your test harness can send events to your program from another machine, Think Pascal will pass any events that it receives on to the running program.
There is one infamous problem that you should be aware of: When you build a program to disk, and it doesn't work. This can leave a beginner rather stumped and frustrated. Well, don't be. The likely problems are the following:
- Careless port-setting. Inside Think Pascal, the port is set to "Drawing" by default. When running stand-alone, that default is no longer valid, so you must make sure that you SetPort to some valid window.
- Think Pascal initializes the Toolbox automatically. If you do that yourself too, you may get problems. You should either disable Think's initialization by {$I-}, or let Think do the initializations for you.
- If you give your program plenty of memory in Run options..., but don't include a SIZE resource with some comparable memory setting, then your program may run out of memory when running stand-alone.
- Finally, there is one problem that all development system has. If you write outside arrays, or follow invalid pointers, you will get unpredictable errors, errors that will change whenever your program changes. Pascal's range checking can help you find some problems, but invalid pointers, you must look out for yourself. Check if NewPtr/NewHandle/GetResource and similar calls return nil before using the result. When disposing data, set the disposed pointer/handle to nil.
Finally, if the compiler is crashing on you for no apparent reason: Are you using MacOS 8.5 or newer? Are you still using 4.5d4 (or older) or have you applied the update mentioned above? If not, do it!
Learning the Pascal language
I will not teach you Pascal here. To learn the language, you can just buy a textbook. There is also some resources on the net. A pretty nice, although not Mac-specific, on-line course is available here. Note that there are some bugs in the links, with mixing "htm" and "htlm" extensions incorrectly, but you will figure it out. There is also a link to another Pascal course at Pascal Central.
Apart from learning the Pascal language, Mac programming require some specific knowledge. Reference material like Inside Mac, Think Reference or ObiWan holds the information, but they don't teach Mac programming. But, there is a way, and it is free: the book Macintosh Pascal. That book, and its demos, deal with CodeWarrior, but the differences are not too big.
Using Think 4.0.2 demos with 4.5a1
Now you should go out and get some demos! Here are some places to get them:
My source-code archive (also by ftp).
Pascal Central, truly worth the name with links to most net resources of interest for a Pascal programmer. In particular, check its source-code section.
Peter Lewis has made a large bunch of reusable modules available. (All newer code there is for CodeWarrior, but that isn't too hard to adapt.)
Water's Edge Software has the Tools Plus library, which supports Think Pascal.
Leo Possajennikov has made a number of small freeware games available with Think Pascal source-code.
Want to play music in your TP application? Try Zerius Sound System by Cody DW Jones, the only MOD player that comes with Pascal interfaces in the standard package &endash; and it is also the best MOD playing lib I've found!
Almost any Pascal source for the Mac is of interest for you. There is one little problem though: there are almost no demos that are written for TP 4.5a1! You will find demos for TP 4.0.2, and for CodeWarrior, and for both, and perhaps some for Turbo Pascal for the Mac or MPW Pascal. You will need to make some changes to make it work.
It will be easiest with TP 4.0.2 demos. Let's get a simple one and make the necessary changes!
A very simple animation demo I wrote is MicroAnimationDemo. It demonstrates sprite animation, and is about as simple as it gets. The link above is to a version that works with TP 4.0.2 and CodeWarrior. To see how I adapted it to TP 4.5a1, click here.
Some demos will work with no changes at all. Such demos include Info, OneTest, On the edge and MemoryGame. Generally speaking, most code that doesn't require any interface units (except the auto-included ones) will run without changes.
The demo KbdLts required a few changes. Types.p had to be added to the project and to the "uses". Some changes in DeskBus.p also messed it up a little, so I had to hack that.
When I modified the interfaces, there was one problem that I couldn't solve to 100%, and that was the changed defintion of "Pattern". Painted Black is a program that required some changes to reflect that problem.
Here are some modified demos:
Using Sprite Animation Toolkit from 4.5a1
Sprite Animation Toolkit, my game making library, is a package that should be of interest for hobby game programmers, especially using Think Pascal. The standard distribution supports only TP 4.0.2, and most demos require some changes to work with TP 4.5a1. In order to make it easier for 4.5a1 users to get started, I have put together a package with SAT 2.5.0 and a couple of demos, all tested with TP 4.5d4 with the modified interfaces. (It is not yet tested with 4.5a1.)
OK, so what's so great with the debugger?
Anyone who speaks for Think Pascal is bound to mention the debugger in more or less enthusiastic terms.
So, what about it? Isn't it just another source-level debugger?
No, it isn't. Like all other source-level debuggers, you can set breakpoints, single-step though the code, inspect variables, and evaluate simple expressions... but that's where the competitors stop.
Here's a quick comparison of features:
Breakpoints and single-stepping:
Think Pascal: Everything is done in the editor windows. This means no unnecessary windows to clutter your screen, and you can set the breakpoints before you compile and run!
Think C and CodeWarrior up to CW Pro 2: You must first compile and run. Then the debugger stops, and you can then navigate to the places you want breakpoints. Extra windows, harder to navigate, and compile-and-debug takes much longer!
CW Pro 3 is better than older CW in this respect. You set breakpoints in the editor windows, but you still single-step in a separate debugger window. Well, it is getting there.
Viewing variables:
Think Pascal: All variables accessible in the current context are listed in the Lightsbug window(s).
Think C: Old versions: no variable list available. In Symantec C++ v8, it finally got variable lists. I don't know if those give the full set of variables or just a subset.
CodeWarrior: Only a subset of the accessible variables are shown.
All three can change the value of shown variables.
Expressions:
Think Pascal: Any expression that is valid in the code is evaluated, including constants and function calls. (This is the Observe window.)
Think C: Fairly complex expressions can be evaluated. Function calls can be evaluated, but the feature is off by default.
CodeWarrior: Only very simple expressions can be evaluated. Constants and function calls are not allowed. On the positive side, expressions can be used for conditional breakpoints, but that would only be useful if the expressions were not so limited.
Type-and-execute ("Instant"):
Think Pascal: Any code that is valid in the code can be typed in and executed while the program is halted.
Think C and CodeWarrior: Don't have it and will never get it.
Well, that's what I think is the most important differences. Think Pascal wins every comparison with a wide margin! (Anyone who disagrees, please tell me so, but not without solid arguments.) If only the C users realized what they are missing, perhaps we would see as good debuggers in the future, but as it is now, Think is the top of the line. Spread the word and the future might get brighter.
If nothing else, take a little time learning what you can do with it. It is well worth it.
Acknowledgements and final words
Thanks to Rich Siegel, Gale Paeper and all others who have suggested additions and corrections! Some parts of the text is quotes from you. And thanks to Symantec for making this possible.
I'm sure CodeWarrior fans aren't too amused by the comparison in the previous section. Let me stress that I am not anti-CodeWarrior in any way. I have it, use it, like much of it, but keep wishing for a better debugger for it. As I've said before, the best development system I've been able to come up with is a combination of Think Pascal and CodeWarrior. With TP 4.5a1, it is even easier than before to use the same code with both compilers!
I belive that this page will be a positive thing for all involved:
- Beginners get a zero-budget, easy to use, powerful system to start with, using a language that is close to english, and with decent amounts of source-code on the net to learn from and work from.
- Symantec and Bare-Bones Software (that's Rich) get good publicity. (Now don't forget that About box, people!)
- Metrowerks gets more customers in the long run, since the TP users will want to compile PPC native code sooner or later.
- Current Mac developers might get better debuggers some day, since TP users have higher expectations on source-level debuggers, which could raise the demand for improvements.
- The Mac gets more developers, thereby the Mac users get more programs, and Apple gets more customers.
- The Wintel PC gets more competition, thereby more of the progress it still needs.
- The world gets... oh, never mind.
But... what do I get? Well, I don't know. A higher phone bill, I guess.