This page is a wiki. Please login or create an account to begin editing.


26 posts / 0 new
Last post
Duality's picture
Online
Joined: 2014 Mar 1
Programming the Classic Mac (mid-2020 edition)

Not long ago, there was a thread on Mac Programming resources.

While I wrote a bit from the lens of a reformed Mac OS X programmer, praising the book of Cocoa Frameworks and dismissing the Old Gods of the Macintosh Toolbox as difficult, the response back then was rightly that I came across as a bit too dismissive.

Let me point out a few cool things that I've rediscovered, that might be useful for programming beautiful beige boxes.

Apple Developer Tech Support superstar Quinn "The Eskimo" Norton had an excellent Newbie Mac Programmer Hints page has a great bulleted list of pointers for starting developers.

Among them, he references Inside Macintosh, in CD-ROM and in (PDF) print form. The classic Mac Human Interface Guidelines can also be downloaded as a vintage 1992 PDF and yet another CD-ROM version.

Most interesting is that he references the Apprentice series of CD-ROMs for vintage source code. We have Apprentice volume 1 and Apprentice volume 3. There's source code for old John Calhoun games and tooling like MacBinary in the first volume, and the third has AppleScripts and HyperCard fun bits along with the usual suspects of Pascal, asm, and C(++).

Quinn's page also has some toys, sources, hacks and anti-C things that have been left largely untouched since the 90s. Worth poking around at all the tricks the fellow who made the Mac OS Internet Config tool was up to.

dogcow has been writing regularly at the Mac 512K blog relating his experiences in learning 68k assembly as he's been programming a new networking stack for super early Macs. Including a list of books you can find for stupid cheap.

Nathan Taylor, formerly of Apple, has been doing a series of Twitch streams that he's shared on YouTube for building a HyperCard RPG and recently building a HyperCard board game.

Devine Lu Linvega, organizer of the Merveilles HyperCard game jam, has been spending plenty of time with THINK Pascal 4.0.2 in Mini vMac and has been jotting down his journeys in wiki form.

Among the wiki pages; the main pascal page, the (classic B&W) Macintosh page, the HyperTalk page, and several tools he's made along the way.

They all have a common origin, in a Git repository that's dubbed the Macintosh cookbook, a growing source of THINK Pascal source codes for all the tools and experiments he's made so far.

That's a bunch of stuff. Feel free to share anything else you find useful for classic Mac programming, or steal any of these words and links for usage elsewhere.

Comments

GF's picture
GF
Offline
Joined: 2020 May 23

Thanks for sharing these valuable information!

Jatoba's picture
Offline
Joined: 2018 Apr 16

Magnificent post, Duality. I'll personally be coming back to this one a lot over time during this year and the next one.

You also had once mentioned somewhere how many different Mac communities exist or existed, each with their own niches or specializations, but also that none has yet brought together, fully documented or set up a proper "classic" Mac programming wiki. This stuck with me lately, and I'd like to slowly dedicate some time to remedy that. Seeing those chronicles from Devine Lu Linvega are very motivational. So are everyone else's programming efforts, such as Bolkonskij's website, dogcow's blog posts and Nathan Taylor's HyperCard stack creation videos.

I know a lot of old Apple Tech Notes & overall documentation address much of the Toolbox and beyond, but I'd like to write down, in my own language (as in, in my own words) all the functions that make it up, perhaps each with an usage example. That means reinventing the wheel in some ways, but doing so would be an invaluable lesson for me, and hopefully I can word it all in such a manner that any person today with as little technical background as possible can easily understand and use it.

Also, do we have somewhere a source (book or website or anything) that completely maps PPC, 68k and x86 mnemonics and/or opcodes with one another, at least to some capacity? Same for AltiVec & SSE.
I imagine that might be in QEMU's very source code, if nowhere else, but I have no idea where in it I'd search that up, or even in case it is indeed there, if it is at all in a presentable, well-organized form.
I think replicating said wiki-like effort with these would be very interesting/helpful.

Perhaps it is time to set up my own little space for that, right here.

Bolkonskij's picture
Offline
Joined: 2009 Aug 3

I agree, great post! Very helpful stuff. The problem with coding for Mac OS is not that there is no information. It is just that everything is scattered all over the web, in magazines etc.

Like right now I'm doing some coding in CodeWarrior and C. I wish there was an easy way to simply open a website and look up a certain toolbox call. But there isn't one.

So basically what I do is checking other folks code, Inside Macintosh and various sources and write my own list of documentation with all the toolbox calls and examples for later reference. Due to its incomplete and individual approach it is nothing that I'd consider sharing with the world.

But the world really needs a php.net for Mac OS Development. I feel it would really spur development - get people to start or others to return. I feel it would give me more time for what I'd actually like to do - write code.

I had plans for it, but I have too much other stuff going on - so go go go for it Jatoba! Sign up with the Garden's webspace. You've got your first bookmark Smile

Jatoba's picture
Offline
Joined: 2018 Apr 16

Via fogWraith's excellent & swift services, the (placeholder) page is up:

http://home.macintosh.garden/~jatoba/

Hope no one minds extremely rudimentary HTML for the time being. Later on I'll be Mozilla/Netscape/IE/WannaBe-focused.

I should set up some sort of form submission eventually so people individually volunteer to provide a description and a usage example for a Mac Toolbox function by themselves, too. Ideally, a fully-editable wiki could be better later on, but I may give it a try this way first.

Bolkonskij's picture
Offline
Joined: 2009 Aug 3

Very cool, Jatoba! Thumbs up from me, bookmarked. Great project idea.

Mu0n's picture
Offline
Joined: 2009 Aug 15

I recently adapted my old 'Foray into 68000' website that was made in 2004-2005, about C programming targetting pre-System 7 compact macs, to free hosting on github:

https://mu0n.github.io/ForayInto68k/index.html

I plan to add to it this summer. I've made progress at the end of last summer but haven't had time to upload new code.

I'm also spending some time learning 6502 assembly (I have a working Ben Eater 6502 breadboard computer) as well as 68k assembly, enough to do basic game protection hacking (at least that's the hope)

Bolkonskij's picture
Offline
Joined: 2009 Aug 3

I love it Mu0n! Great design, great content Smile ... the only flaw - it's hosted on github. Won't let me load the page on Mac OS. Can't open it on the machine it is supposed to be for :-/

How about moving it over to the Macintosh Garden Webhosting for free, where it'll be cherished and you can ftp in from your Mac Plus to make changes?

cbone's picture
Offline
Joined: 2011 Sep 17

Are you able to try latest web proxy I bumped into lately? This is where I gave some links and details on it and it's called WebOne. All you need is a host server for it, and I had some success accessing some sites using iCab on OS 8.1 w/it.

If it works the way I think it should work, it will give you some mileage, especially when you really want to access something that just breaks on your Mac's web browser. It's in active development and the author is very responsive to your issues, including any feature and bug fix suggestions.

Jatoba's picture
Offline
Joined: 2018 Apr 16

WebOne is cool. Though I, too, like it best when there's complete autonomy on the Mac side. For me it's like "Why do I need to turn 2 machines on to use just 1?" kinda thing. Nonetheless, I appreciate projects like WebOne. It's sometimes the 2nd best thing to have, being only behind new browsers (or older browsers updated to work better).

Bolkonskij's picture
Offline
Joined: 2009 Aug 3

Thanks for the suggestion. These proxies have been around for some time. Just beta-tested another one a couple of day ago by a certain Mac Garden member Smile While I acknowledge that it is a good idea to serve the content as e.g. a gif for older browsers, it's not really practical for me. Thus far they're slow and the functionality limited. Nothing beats a page served in plain html. These proxies might be ok for a quick glimpse on a news page but that's it.

Instead of trying to keep up with the bloatness of the modern net, I'd rather vote for a small "retro computer web" with the spirit and charme of the pioneer years. There's still so much room for creativity and new ideas that a single hobbyist afficionado could do. And that, to me, is also part of the original Macintosh spirit.

cbone's picture
Offline
Joined: 2011 Sep 17

As far as I could tell, WebOne doesn't output a graphical version of a site, it actually converts the html. The best way I could compare it works a lot like a wannabe-Wannabe web browser, but with images and some new web-browser workarounds.

I tried a proxy suggested by fogWraith that like you said, gives you a 'vnc' approach to web browsing (which is nice to 'vnc' just a webpage, which has the whole 'cool factor' to it), but WebOne doesn't do that (from my testing). Again, it's not perfect by any means, but it got me to a few places that none of my 68k browsers were able to go alone before. It works with old Windows, Android, iOS and old OS X browsers.

But, like you, I also want to just have some good old 68k-compatible websites back again Smile

Mu0n's picture
Offline
Joined: 2009 Aug 15

I never intended for this website to load on classic macs, although I see the advantage into copy pasting code directly into an environment like Symantec THINK C. However, even that developping environment is one step beyond the runtime target of Mac Plus. I wanted to use cross-platform development to fully leverage modern machines.

adespoton's picture
Offline
Joined: 2015 Feb 15

Have you tried the modern mpw yet? I gave it a quick spin-up, and it looks like it runs all the old tools, but I haven't had a chance to play around.

Plus, I went from Borland's Turbo series to Metrowerks; I never quite got into the mpw toolchain although I always admired it.

Mu0n's picture
Offline
Joined: 2009 Aug 15

The most modern mac I own is the powerbook 180. I don't even regularly run a post-7.5.5 emulator environment and my modern machine is a PC. I assume mpw is mac only? I've worked hard setting up a working dev environment for system 6 and below and the thing I hate most about the hobby is fiddling around setting a dev environment with odd options that were not intended by their devs. So many links to iron out, no documentations, it's the worst (for me).

adespoton's picture
Offline
Joined: 2015 Feb 15

MPW is Apple's Macintosh Programmer's Workshop. Following programming on a Lisa with the Pascal environment, it was the official dev environment for Apple right through until XCode.

There was a nifty little package called ToolServer that enabled Telnet access to it, which essentially give Classic Mac OS its own remote terminal. The MPW environment is pretty powerful, as it has its own scripting language, plus modules for various linkers and compilers, plus direct tie-in to the Mac debug mode, including communication with MACSBUG (the Motorola debugger).

Recently, a macOS MPW emulator has surfaced: https://github.com/ksherlock/mpw

And Paul Pratt originally created Mini vMac from the vMac source to create an accessible cross-compile MPW environment.

System 6 was during the MPW days, I think around MPW 3.

https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop

Of note is that you can use MPW to compile software for any Mac OS from System 1.0 (System file 3) in 1986 through OS X 10.1 in 2001.

taylordesign's picture
Offline
Joined: 2015 Aug 25

I've said this before in another thread but it's worth repeating: if you want to target classic Macs and modern Macs, REALbasic/Real Software/Xojo gives you a decent path. There are enough changes from the old versions of REALbasic to now that you won't be able to make one project file that covers everything, though you will be able to share code. And you'll want to start with the old version otherwise you'll be rewriting stuff that takes advantage of modern language features, stuff you wouldn't normally think of while coding (like being able to declare variables any where vs. having to declare them at the top of a function). But there's quite a bit of portability there, and insulation from Toolbox/Carbon/Cocoa unless you want to directly call an OS function through a declare.

The main drawback is that the earliest versions of REALbasic were written in the PowerPC era with a large framework relative to the time. So the RB compiler isn't the best for a fast, memory efficient 68K build. It might not even have targeted the 68000 (i.e. 512ke, Plus, SE, etc.). I would have to look up the min requirements for 1.x.

Now if you need/want to target the oldest Macs, or just want to experience classic Macintosh development in all of its glory, you'll want to look at some of the other tools from the period. I don't think anyone who is interested should be discouraged because 'Toolbox is hard.' It's not hard. It got the reputation for being hard because writing a GUI application was more work in the 80s/90s than writing a CLI application for DOS or UNIX. A CLI application must, at a minimum, deal with standard input/output. A GUI application has to have windows, menus, and an event loop.

For a modern programmer the stumbling blocks will be:
* Non-existent or less sophisticated tools for visually building your GUI, depending on the toolchain that you choose. (Though some were good even by today's standards.)
* A more hands on approach to memory management. Interaction with the OS requires pointers, handles, and function addresses even if you choose a language that otherwise takes care of memory for you.
* Less forgiving development. You can bring down the entire OS and force a restart by calling some Toolbox calls with invalid parameters.
* Memory was scarce and could become fragmented. The CPUs were snails by today's standards. And task switching was cooperative.
* There are some tasks where a modern framework will handle a ton of work for you, but what was available back then wasn't nearly as helpful.

Finally, if you want a truly unique experience, download Prograph Classic or Prograph CPX and give them a whirl some afternoon. Prograph was an iconic, data flow language which took root on Mac OS and was used to build some commercial applications in the 90s. But it withered with the OS X transition. It takes a little getting used to at first, but in the 90s I thought Prograph CPX was the most productive language/IDE I had the opportunity to work with, and I choose it for several personal projects.

Dog Cow's picture
Offline
Joined: 2009 Apr 16

Less forgiving development. You can bring down the entire OS and force a restart by calling some Toolbox calls with invalid parameters.

Oh, it's much more exciting than that! If you get a pointer wrong, or if there's a stack imbalance, you can trigger hardware accesses to the floppy controller and clobber your floppy disk...... with your source code/application on it.

And the only way to fix the floppy is to reinitialize it. You made backups, right???

I have had this happen to me on two different projects, once on each. Most recently was about 2 weeks ago. I am in the habit now of locking my disk when I test my application.

Jatoba's picture
Offline
Joined: 2018 Apr 16

I have had this happen to me on two different projects, once on each. Most recently was about 2 weeks ago. I am in the habit now of locking my disk when I test my application.

Yep, and needless to say, same goes for HDDs and whatnot... I think what can also happen is damages to the file system that don't "blow up" upfront, but may surprise you later on when you least expect it.

For that reason, my "Dev Mac" will likely remain separate from my "Everything Mac". Or, as you say, I will leave backups always!

It'd be interesting if there were Version Control tools for Mac OS... are there? I know even VB6 had some rudimentary source control utility IIRC (forgot its name), and that's current with at least Mac OS 9, but again, I have yet to come across such a Mac tool. I will use some sort of souce control where I push updates externally, one way or another.

hamburger's picture
Offline
Joined: 2020 May 9

Good thing is powermacs are less prone to corrupting hard drives or floppies because of software bugs.

68000-based macs wouldn't even trap if you accessed invalid memory because the memory layout essentially "looped" all over the address space.

68020+ macs are capable of having address errors, but it happened to me once or twice with my IIci that I corrupted my system volume because of an app that seemed to branch to a NULL or otherwise invalid pointer.

With powermacs, at least, the processor executes in unpriviledged mode most of the time, and (AFAICT?) memory-mapped I/O accesses are protected by this. Since there's no real memory protection it's pretty easy to bypass, and the 68020 emulator is an easy example, but it's still much less likely to happen by accident than on 68k.

Though, yeah, when passing pointers or handles to toolbox calls macsbug will greet you quite a few times if something's wrong. When you don't freeze on the spot that is. Laughing out loud

Jatoba's picture
Offline
Joined: 2018 Apr 16

Eventually I'd like to attempt accessing regions of memory normally reserved for device drivers ("high value" addresses), to check out some possibilities of what can and can't be done. So I'm sure I'll find ways to unwillingly corrupt things even on PPC. Tongue Trying to follow this guide, incidentally.

taylordesign's picture
Offline
Joined: 2015 Aug 25

Oh, it's much more exciting than that! If you get a pointer wrong, or if there's a stack imbalance, you can trigger hardware accesses to the floppy controller and clobber your floppy disk...... with your source code/application on it.

In all the code I wrote for classic Macs I never did this. Now I want to boot up a classic Mac and do it just to say that I have Smile

I'm sure I got lucky because I can remember crashes due to bad pointers. I just didn't happen to access an address that would have done this.

Dog Cow's picture
Offline
Joined: 2009 Apr 16

In all the code I wrote for classic Macs I never did this. Now I want to boot up a classic Mac and do it just to say that I have Smile

I'm sure I got lucky because I can remember crashes due to bad pointers. I just didn't happen to access an address that would have done this.

Did you program in assembly language, or a high-level language? I'm programming in assembly and when I say pointer I really mean an address register. Probably a lot of high-level languages and compilers make it much more difficult to produce the kind of system-destroying code that I occasionally get.

cbone's picture
Offline
Joined: 2011 Sep 17

WriteNow gave me the love for Assembly language Smile among a handful of System 7 tools I enjoyed back in the day for their speedy performance, plus small size and memory footprint.

In biology terms, the programmer is the personal trainer and the student is the program, resulting in all lean muscle versus a fluffy program filled non-essential 'burgers and fries' fed by higher languages.

Anyone try it out or use it? It wasn't the most popular, with some preferring version 3 over 4.

Jatoba's picture
Offline
Joined: 2018 Apr 16

@taylordesign Your mentions of Prograph were interesting, I decided to take a look.

Which reminded me, perhaps I have a recommendation back to you, based on that: ever seen or heard of RunTime Revolution? It is a HyperCard-compatible rich development tool, and the main competitor to SuperCard.

We got it here in the Garden, in its latest, full version (unlike its competitor SuperCard, which was requested to be removed, and now it's hard to figure out which version was even the latest one for Mac OS before OS X). Just like REALBasic and some other development tools, you have a clear """"multi-platform"""" (not enough quotation marks) upgrade path: LiveCode. (Which is relatively famous.)

m68k's picture
Offline
Joined: 2016 Dec 30

Thx for all the good stuff.