Honoring the Ways of the Original Macintosh
My PowerBook 180, still going strong
I really loved the classic Macintoshes and their user experiences. They played such a huge part in forming our ideas of what software could be. The SE/30, the IIci, and the PowerBook 180 running System 6 and 7 were particularly great, each for different reasons. My very first laptop was a PowerBook 180 running 7.1, and it was a phenomenal computer for its time.
Those early Motorola 680x0 Macs were the perfect example of the original Macintosh experience, and if you take some time to dig in and examine the how’s and why's, you start to see there are a ton of ideas that can still help us write great software today.
It’s a bit like honoring your Elders. They hold some important truths that can help us all live our best lives, if we just take the time to listen. Some times (maybe a lot of times) those old ideas can show us what not to do, too, and that’s just as valuable.
The original Macintosh product brochure
The first time I saw a Macintosh in person was when a computer store in my small home town set up a table out in the middle of the mall with a single Mac 128K running MacPaint. From those brief two or three minutes I was able to spend taking my turn amongst the crowd, painting and dragging pixels, listening to that 400K disk drive hum and purr, my path in life became perfectly clear.
Unfortunately, I never got the chance to develop any “real” classic Macintosh software back then. That is, writing actual Pascal or C code to create commercial Macintosh products. The original Macintosh was so different from anything that anyone had ever programmed before that the information and tools for developing it turned out to be a challenge to get your hands on and learn.
The Passage to Vietnam CD-ROM I helped develop for Rick Smolan (each screen carefully “dithered” to 256 colors because that’s all you had to work with!)
Instead, like many others, the original Macintosh software I did get to create was multimedia CD-ROM and educational software titles written in Macromedia Director. I loved that, of course, and had a great early career of working on some great projects, but I never stopped itching to write actual Macintosh software.
By the time I did start to understand the tools and tricks to unlocking the Macintosh’s Toolbox, Apple had been making some pretty big business blunders. Windows began winning the “computer wars,” and soon we all had to move on to building web and internet applications in things like ASP, JSP and PHP to make a living—often working on noisy, clunky Windows machines that just didn’t have the same spirit the Macintosh did.
Thankfully Apple survived, and we can all work on Macs again, if we choose to. Even better, writing native Mac (and iOS and iPadOS and watchOS) software has become so much more approachable, now, with Xcode, Swift and now SwiftUI.
Today’s macOS is a whole different beast, though, than the original Macintosh experience was, with entirely more advanced development tools, APIs, and philosophies. It’s all really great, don’t get me wrong. It’s just not as quaint as it once was. So lately, I’ve been wanting to look back, again, and remember what it was like to write classic Macintosh software. To honor my Elders, you might say.
Late one night, I downloaded the Mini vMac emulator, a disk image with System 7.1, another image with THINK Pascal, and dove back in…
All of the THINK Pascal source code created for this post is available on GitHub to download and run for yourself. Instructions are provided in the GitHub repo README.md.
Building a Classic Macintosh Starter App
The About window in my starter project.
One of the biggest hurdles for creating a classic Macintosh application from scratch was the amount of boilerplate startup code you had to write just to get an app up and running. The Macintosh Toolbox didn’t help you with that, as much as you expected it might.
If you wanted to create a well-structured, well-behaved app that followed all of Apple’s guidelines, you needed to get a ton of your own starter code in place just to start monitoring and handling user events properly, allowing windows to be dragged around (that’s right, windows didn’t have any drag functionality built in), supporting resizable windows, adding menus that could become enabled or disabled correctly whenever the user did things, etc., etc., etc.
This was a big reason why so many early Macintosh applications felt so clunky. Everyone was still trying to figure all of this stuff out.
Developers had to manually add the system’s Desk Accessory items to their Apple menu, and had to write code to launch those accessories when they were selected. The system didn’t do this for you.
Believe it or not, you even had to write code to populate the Apple menu with the system’s Desk Accessories, and then write more code to launch them if the user selected one of the accessories from the menu. It still amazes me the Toolbox didn’t do that for you.
All of this was a big speed bump to get over, especially for a new and aspiring Macintosh programmer. I often wondered if Apple had provided us all a better starter app back then, with all of that boilerplate code in place and written in a way Apple had wanted it to be written, just how many aspiring developers like me could have been able to go on and create more great applications for the original Macintosh. For me, I think it would have made all the difference.
With that in mind, I figured this would be a perfect project for me to remember what programming the Macintosh was like thirty years ago—creating a starter project with all of that important, boilerplate code in place, written in the best possible way I knew how, to help kickstart a well-behaved, old-school, event-driven Macintosh application.
This meant it would need to have things like…
The amount of code infrastructure needed to get a well-behaved classic app started.
A standard menu bar in place with File, Edit, Format and Window menus, and code showing how to enable and disable items based on actions taken by the user.
A working Apple menu that provides a standard “About This App…” option and access to all of the Desk Accessories installed in the System.
A basic “Settings…” option that shows how user preferences could be implemented (and saved) for a classic Macintosh app.
A Font sub-menu that shows how to implement hierarchical menus, and how to populate a menu with a list of all the current fonts installed in the System.
Code to help manage an app’s windows, included support for palette windows that remain open, on top of all other windows (the original Macintosh Toolbox didn’t support these types of windows).
An actual example of a tool palette window, and how to provide selectable tools.
Starter document window support, including an example of how to implement “dirty” documents that have changes, asking the the user if they want to save those changes before the window closes or the app quits.
An example of a central, “Main Window” that stays open for the life of the app, that can be presented full screen, and that triggers the app to quit if the window is closed.
How to hide the menu bar for full-screen apps (Apple didn’t make this easy, as they felt the menu bar was core to the user experience, and should always be available).
An example of how to do proper shut-down procedures for when the app quits, including asking to save any changes to documents.
A custom “Debug Console” to help log messages to the screen while the app is running. Okay, this is technically not essential, and has nothing to do with creating a classic Macintosh app, but it’s something I’ve added to all of my professional apps over the years, and I found it helpful getting this starter code to work, too.
The Best of the Classic Macintosh Experience
Today’s macOS is a brilliant example of a modern, stable, well-designed, feature-rich computer operating system, and it’s a joy to use for every-day work. (Also: an absolute wonder that Apple was ever able to pull it off.)
System 7’s more open System Folder, its clean, thoughtful application of color, and features like easy-to-configure Sharing were wonderful enhancements to the already solid System 6.0.8 user experience.
In my humble opinion, though, both System 6.0.8 and System 7.1 were the perfect manifestations of Apple’s original ideals. System 6.0.8 because it had finally become a quintessential implementation of the old black and white classic interface. And System 7.1 because it was a brilliant, well-thought-out application of color and functional polish applied to that original, classic design.
All of the versions prior to System 6.0.8 still hadn’t fully lived up to Apple’s original promise of what a stable Macintosh interface could be. And everything after 7.1 became a kludgy, bloated mess of ill-conceived, poorly-implemented features that Apple tacked on to try and keep the world happy while they scrambled to figure out their transition to today’s modern macOS.
Moley Russell’s Wart
On top, System 7.1’s Balloon Help menu (perfectly rendered in color and black and white) compared to the flawed System 7.5 Apple Guide icon that replaced it. The lightbulb concept didn’t read well, and notice the lack of a clean black and white version.
Moley Russell’s Wart
System 7.5 and 7.5.5 were pretty nice, too. They both added useful features. Apple messed it up, though, with the tiniest of details. The icon for the 7.5 Apple Guide menu (which replaced the beautifully simple Balloon Help menu from System 7) broke their own Interface Guidelines in a pretty high-profile way. (If curious, take a look at page 263 in their 1992 version of Macintosh Human Interface Guidelines for how it fell short.) The new icon stood out like Moley Russell's Wart, and it was the first crack in the veneer for what was about to come next.
So, for me, it was both System 6.0.8 and System 7.1 that had fully delivered on all of Apple’s original Macintosh User Interface design ideas in perfect form. I can (almost) imagine that Jef Raskin, Bill Atkinson, Andy Hertzfeld, and Susan Kare had been smiling proudly at us while we used them.
For that reason, I targeted only those two versions of the classic System software for my starter-app project, using them as my inspiration for how I wrote the code.
Pascal, the Mac’s Original Language
Some typical Pascal startup code for a classic Macintosh application.
I had the choice of writing the starter-app code in C or Pascal. If I were building an actual Macintosh application that I was intending to maintain and sell today, I would choose C or even C++. Back when Apple was first creating the Macintosh, however, the only environment the engineers had available to them was the Lisa and its development tools to write the Mac’s system software with. Those tools included a 68000 Assembler and the Lisa Pascal compiler.
That meant the original Macintosh Toolbox was written in Assembly Language and Lisa Pascal, and all of the Toolbox’s APIs have a Pascal calling signature. You could almost say Pascal was the Mac’s first language.
In order to get the full experience of writing a classic Macintosh application, again, I chose Pascal to write the code in, just to keep things fun.
Finding the Key to Open the Macintosh Toolbox
Writing software for the original Macintosh was not simple. Or I should say figuring out how to write software for the original Macintosh was not simple. Its earth-shifting UI concepts were entirely new, its APIs and data constructs were bewildering, and there was no Internet or Stack Overflow to reach out to. There were, however, some classic books that eventually got published. I found old copies of these, in particular, to help me with this starter-app project…
One of the very best books to ease yourself into classic Macintosh programming.
“Macintosh Pascal Programming Primer: Inside the Toolbox Using THINK Pascal” by Dave Mark and Cartwright Reed. This is an excellent (and gentle) introduction to writing Macintosh software for beginners, with Pascal code examples to start you on your journey.
Stephen Chernicoff’s four-volume set, “Macintosh Revealed,” provides a much deeper dive into writing old-school Macintosh software. All four volumes are useful, but volumes 1 and 2 cover the essentials.
“Inside Macintosh”, Apple’s definitive documentation. Not a light read, but it is the ultimate and complete reference. Go with the revamped 1992 to 1994 version, not the original set, which are available in PDF format.
The “Macintosh Human Interface Guideline” is a fun (and definitive) read about designing classic Macintosh software, with some great principles that are still relevant today.
Giving the User Control
Scotty and the Macintosh. Star Trek IV: The Voyage Home
It seems like such an ingrained (and obvious) idea now, but one of the biggest tectonic shifts that the Macintosh helped bring to the world was this idea that the user should always get to decide what they did next.
Instead of forcing the user through some series of (often confusing) programmer-defined steps, menus, and modes the way software had traditionally been written, the Macintosh wanted us to always wait and see what the user would do, and then act on that accordingly.
The heart of every classic Macintosh application is its event loop, where it sits quietly waiting for the user to take action.
This new event-driven approach meant that your app sat quietly waiting for the user to do something. Then, when a user event did occur, you looked at what type of event it was (mouse movement, menu selected, buttons clicked, windows dragged or resized, disks inserted, etc., etc.) and your code would branch off and do whatever was appropriate for that event.
This entirely new idea (back then) was at the very heart of providing the Macintosh user experience.
“Cooperating” in the Good and the Bad
Famously, the original Macintosh wasn’t a true multitasking system. Instead, it used a cooperative model, relying on application developers to play nice. Each cycle through your event-loop, you “cooperated” by voluntarily handing over a slice of your app’s time to the System so that it could let any other applications running alongside yours have some processing time too.
The Apple software engineers made this cooperation easy. You handed over your slice of time whenever you called the Toolbox function to get your next event:
WaitNextEvent(everyEvent, theEvent, 60, anEmptyMouseMoveRgn);The integer you passed in the third parameter (60 in this case) was how many ticks you were willing to “sleep” while the System gave other applications a chance to run.
Usually, that worked out okay. Most applications behaved, because of how easy Apple had made it. But because you were all running on the same thread, if one of the other apps did something bad and crashed, you all came crashing down with it!
A Puppet Show of Smoke and Mirrors
One of the other fundamental things you had to wrap your head around, writing classic Macintosh software, was that the original Macintosh Toolbox and User Interface was not a real, component-based, object-oriented system like we are used to, today. The APIs were all functional based. Pascal procedures and functions, in fact. No “window” or “menu” or “scroll bar” components existed for us to interact with. There were only rudimentary Pascal data records with information about what a window or a menu or a scroll bar might be, which you then passed around to Toolbox procedures and functions to make things happen.
Most of the time, the “things you made happen” came down to using QuickDraw to draw shapes and patterns on the screen to give the illusion of a User Interface.
Using QuickDraw to Pull All the Strings
Behind the scenes, QuickDraw was your primary tool for presenting your app’s UI. And what a tool it was. QuickDraw was this AMAZING collection of 68000 machine code routines that gave you a full suite of functions, procedures, and data structures to draw your UI with. And it was fast. really, REALLY fast.
An interesting note about MacPaint: the drawing window couldn't be moved, even though it had a title and drag bar. Maybe Bill Atkinson forgot to add his call to DragWindow? Or maybe there were other reasons why.
In fact, if you look at MacPaint, it’s really nothing more than a slick demo of QuickDraw, written by the very same guy who wrote the QuickDraw code, all packaged up as one of the first Macintosh applications.
As a developer who really loves to write POCs for my own work, I like to imagine how Bill Atkinson had been writing MacPaint at the same time he was working on the QuickDraw APIs to flush out all the kinks and bugs in the Mac’s drawing library.
Everything about providing a Macintosh user experience came down to writing code that used QuickDraw’s brilliance to pull the strings. As long as you paid attention to every little detail, and made sure all your geometry calculations were pixel-perfect, your interface would look great and render fast.
The grow-box was only an illusion of window control that you had draw, yourself, along with all your other window content.
A window’s resize box, for example, wasn’t an actual UI component that knew how to resize a window. It was a QuickDraw illusion of a UI component that you had to draw, yourself, whenever your windows updated…
DrawGrowIcon(theWindow);Then you had to pay attention to when the user clicked and dragged in that area of the window, and begin tracking the resize yourself, taking the new size record returned to you and resizing the window with more of your own code…
newSize := GrowWindow(theWindow, theEvent.where, theRectLimit);
SizeWindow(theWindow, LoWord(newSize), HiWord(newSize), TRUE);
InvalRect(theWindow^.portRect);Teaching a Window How to Move
The same smoke-and-mirror illusions were true for windows. If you wanted your users to be able to move your app’s windows around on the screen (and what respectable app didn’t) you had to implement the code to do that yourself. I’ll let that sink in for a minute. Classic Macintosh windows didn’t know how to move on their own.
Basically, whenever you detected the user had clicked their mouse in the title bar of a window, you had to call a Toolbox function to start the window moving:
DragWindow(theWindow, theEvent.where, screenBits.bounds);This function would help you move the window in a standard, Macintosh way, which meant a gray outline would appear and follow the user’s mouse movements until they let go of the mouse, and then this function would move the window to where that gray outline finished, along with bringing the window to the front of all the other windows.
Floating palette windows were not supported, so you had to write your own customized window management and drawing code to have them in your app.
For my starter-app, though, I wanted it to provide palette window support. Palette windows remain on top of all other windows providing quick access to their content at all times, but the Toolbox didn’t directly support this kind of window. That meant I had to write specialized code and do my own dragging of a gray outline whenever the user tried to move a window, and then either bring it to the top, if it was a palette window being moved, or behind any open palette windows if it was any other type of window. This required implementing a special type of data record to keep track of what type a window was that was being dragged, along with some special logic for ordering the windows properly once the window had moved.
Luckily, QuickDraw did provide a function for dragging a gray outline around the screen that helped make this custom window dragging functionality possible:
theDragResult := DragGrayRgn(theWindowOutlineRgn, thePoint, theLimitRect, theSafeRect, 0, nil);Take a look at the DragAppWindow procedure in AppScreen.p to get an idea of how I implemented this. A lot of code was needed to support palette windows, and it may not be 100% perfect in my implementation, but it’s close, and tool palettes were so central to most editing apps, it seemed important (and fun) to try and include it.
Keeping Menus Up-To-Date
The “Save” menu item should only be enabled when the document in the top window has changes to be saved. This becomes a visual indicator to the user to let them know if their changes have been saved or not.
The Macintosh’s menu bar was (and still is, in today’s modern macOS) a key part of providing a consistent, predictable interface for the user. Apple’s User Interface Guidelines asks us to disable any menus and menu items in the menu bar that are not appropriate for the user at any given moment. For example, the “Save” item in the “File” menu should typically only be enabled if a selected document window is open, and only if un-saved changes had been made to it.
Or, if your app provides a “Window” menu, as another example, it should always be up-to-date, whenever the user pulls the menu down to view it, listing only the current windows that are open.
And typically, the “Edit” menu should be disabled entirely, if there is nothing appropriate to be edited at the moment.
This behavior of keeping menus constantly updated in context could get complicated, and examples of how to do it correctly were never documented very well, so I wanted my starter code to provided an example of how an app might go about it. The logic I wrote would need to evolve and expand more if real features were ever added to the app. But initially, the starter code includes examples of…
Disabling the “Edit” and “Format” menus if no document window is selected.
Keeping the “Save” and “Save As...” menu items disabled until a document is selected.
Only enabling the “Save” item if the selected document has changes.
Enabling the “Close” menu item if there are any closable windows selected (not just document windows). The “Close” item should let you close any closable window. That means the item would be disabled if a palette window was selected, since palette windows should not be closable by normal means (see the last bullet item below).
Keeping the “Window” menu updated with current windows, grouping document windows separately from the built-in app windows (i.e. About, Settings, etc.)
Providing a menu item in the “Window” menu that lets the user hide and show the Tool Palette window, and updating that menu item’s title with “Hide” or “Show” depending on whether the Tool Palette was currently visible or not.
You can look at the UpdateMenusBeforeOpening and UpdateMenuAfterEvents procedures in AppMenuBar.p for the code that is doing most of this.
Handling “Dirty” Documents
Clicking in the starter-app’s document windows draws random, inverted circles in it, and marks the document “dirty.”
An important behavior of a well-behaved document-based app is that it should prompt the user to save any changes to documents before closing it or quitting the app. This is an idea the Macintosh introduced to us forty years ago, and is still a part of modern app behavior today. (Although, with today’s fast processors and silent mass storage, we should all be saving changes automatically for our users at this point—a behavior Jef Raskin had originally wanted for the Macintosh, but floppy disks were too noisy and slow back then to be saving all the time.)
A handle to a AppWindowInfo record is attached to every document window, and the “hasChanged” flag is set whenever the document needs saving.
The starter-app includes some simple code that will draw random inverted circles in a document window if you click in it, simulating the editing of the document. This will mark the document “dirty” (i.e. having unsaved changes) by setting a “hasChanged” flag that is within its AppWindowInfo record (which is attached to the document window via its refCon field). This flag will get checked for any document window whenever an attempt is made to close it—either by the user, or as part of the shut-down process when the app quits.
The refCon field, which is part of the WindowRecord (a built-in record type that is maintained by the Macintosh Toolbox for every window), was a common way to attach data to a Macintosh window. It is a long integer property that can hold a Pointer or a Handle to some other record describing the window in more detail.
In the case of the app starter, the window’s refCon field is used to point to a custom AppWindowInfo record (defined in the AppDefines.p file) which has an AppWindowKind property (an enum value that can be basic, document, or palette) and, in the case of “document” windows, whether or not it has changes to be save (the “hasChanged” boolean). This type of record is normally expanded in a real app with additional fields to hold other details about the window, like the document’s actual data, for example.
The main code and logic for all of this can be found in the MouseDownInAppDocumentWindow procedure and the CloseAppDocumentWindow function in AppDocumentWindow.p.
Supporting User Preferences and App Settings
Another important part of a good user experience (then and now) is letting the user set their preferences for how the app should behave. Providing this feature requires providing some UI in the app to control those settings, and then saving them in a file somewhere that the app can load each time it runs.
The saved preferences/settings data is saved in the System Folder.
Before System 7, most Macintosh applications would save their user preference files within the root of the current System Folder. This worked pretty well, but it added clutter to the System Folder. So for System 7, Apple introduced a “Preferences” folder located inside the System Folder, and encouraged developers to save their preferences in there.
You then had to write code to detect if your application was running in System 6, in which case you would fall back and save your settings in the old location, or System 7, where you would use new System 7 APIs to find the “Preferences” folder and save them there.
To keep things simple for supporting both System 6 and System 7, the code in my starter app follows the old tradition of always saving the settings file in the top level System Folder, regardless of what system the app is running in.
Notice the name of the saved settings file (“STRtSettings”)? The idea behind the starter code is that it can be used to create a real Macintosh application, so the code is set to name the settings file with a prefix of the app’s BNDL identifier (for the starter app, it’s been set to ‘STRt’), and then adding “Settings” to the end of it. That way the settings from the starter app won’t override the settings for a real app, assuming the real app has been given its own BNDL identifier. Which all apps must do.
The BNDL identifier is defined and set in the AppDefines.p file.
Look at the LoadAppSettings and SaveAppSettings procedures in AppSettings.p for more details how the settings are save, and the “Toggle…” procedures in that same source file for how they are used by the UI.
Hiding the Menu Bar And Going Full Screen
Clicking the zoom box of the “Main Window” switches it to fullscreen mode.
Another feature I wanted to include in the starter-app (mainly so I could remember how it had once been done) was to provide a “Main Window” for apps that need a primary window for user interaction, and to allow it to go full screen. This type of window usually opens when the app starts, stays open during the life of the app, and (depending on the app) causes the app to quit if it’s closed. Games are a good example of apps that often need a full-screen main window. Interactive, multimedia CD-ROM titles are another.
The “Main Window” in fullscreen mode, with the menu bar hidden.
To go full screen in a classic Macintosh application, you had to write special code to hide the menu bar. This wasn’t something Apple typically wanted you to do, because the menu bar was designed to be a primary, dependable part of the user interface, always available whenever the user needed it. So Apple didn’t make it easy, nor did they document the procedure. Luckily, Apple insiders like Scott Knaster were around to show us the way.
Take a look at EnterFullScreenMode and ExitFullScreenMode in AppScreen.p for the code, and ZoomAppAppMainWindow in AppMainWindow.p for the code that’s called when the Zoom box is clicked.
The “Start Full Screen” option becomes disabled if the “Has a Main Window” setting is turned off.
The starter app lets you disable the main window in “Settings…” Notice that the “Start Full Screen” settings option becomes disabled if you turn off the main window setting. This simple idea of disabling UI controls, like this, based on the settings of other UI controls, is a common part of UI behavior we still implement today, and another example of a guideline that Apple had helped establish all those years ago.
Adding a Debug Console
Finally, for almost every app I have ever helped build in my career, I’ve added some kind of special tooling, early on, to help build and test it. Often, I’ll add a hidden panel somewhere in the app, for example, that developers and QA testers can open with a special gesture to help configure app state in ways that are time-consuming to accomplish under normal use of the app. Or, as is the case with this starter app, I added additional ways to log information for debugging.
A built-in “Debug Console” to help log variables and other app state while the app is running.
THINK Pascal had some really brilliant debugging tools (some of the best for its time) including a console to log to. But I found it could get in your way, sometimes, because of how it could alter your QuickDraw state, and then wouldn’t restore it properly for you.
So for this starter app, I built in a simple logging console I could print out variables, etc. in to help me get the starter code working. It can either be opened by clicking the “Show Debug Console” checkbox I added to the “About” window, or by calling one of the “Debug” procedures from somewhere within your code, which will open the console if it had not been opened, already. Take a look at AppDebugConsole.p for the few logging procedures that I added, and how the console log works.
What the Starter App Leaves Out
The starter-app implements most of the fundamental behavior a classic Macintosh needs to get started, but there are other basic things a real application would still need to do.
For example, the starter code populates the “Font” sub-menu with the currently installed fonts in the System (see InitAppFontMenu in AppFontMenu.p), but it doesn’t do anything when a font is selected by the user. Most apps would store that selection somewhere, and use it as the default font for when any new text creation and editing was done in the app. The same goes for the items in the “Style” sub-menu.
Also, a small side note. There had been some interesting user-experience debates, back in the day, over whether or not the “Font” menu should hold a top-tier position in the menu bar, instead of being a sub-menu of a “Format” menu, for example. That probably is a better user experience, as it gives people quicker access to their fonts. I added it as a submenu to help show how hierarchical menus got implemented.
The “Edit” menu would also need to get fully flushed out. Right now, the starter code only enables or disables it, depending on whether or not a document window is selected. A real app would need to actually implement all of the functionality for when each item in the menu is selected, depending on the context of what elements were currently selected in the app. It would also need to be enabled properly for Desk Accessories, especially in System 6, which is a whole other can of worms I didn’t get into for this project.
Finally, as you can imagine, document support is often the biggest and most complicated part of any document-based app, especially a classic Macintosh app. The rudimentary document window support provided in the starter app doesn’t let you actually save, load, or even edit real document data. It only prompts you to save, if it detects changes had been made (i.e. clicking the mouse in the document window). Plus, document data storage is usually very specific to the type of document the app creates, so the starter-app does not attempt to include any real document support beyond the minimal code needed to get started.
Quality Time with the Elders
It was a lot of fun revisiting some of the challenges of programming the original Macintosh. It had been such a strange and rewarding system to develop for, and one that has given us so many of the values and ideals we still hold true today.
You can download the THINK Pascal source code here, if you’d like to experiment with it yourself.
All of the THINK Pascal source code created for this post is available on GitHub to download and run for yourself. Instructions are provided in the GitHub repo README.md.
And yeah, I suppose I do feel a bit like I’ve paid respects to our ancient elders, now. Maybe they’ll look favorably upon me, one day, when I arrive at the gates of that Infinite Loop in the sky.