[Openmcl-devel] Questions about porting an MCL app from Classic Mac

[mikel evins]

On Jun 6, 2019, at 12:17 PM, Thej <thej at shaw.ca> wrote:
> 
> I found a very interesting old MCL project online and I was wondering what would be required to “port” it to Clozure CL?

It's a tall order. We had some public discussions about fifteen years ago about something along those lines, and I think the eventual consensus was that it would be easier to write a new one.

It's been a long time, and I was never really an expert on Sk8's internals, but here are some issues that occur to me:

- Build system

  Sk8 is from long before the wide adoption of asdf, and uses its own idiosyncratic build system. Based on previous experience converting from homegrown build systems to asdf, I wouldn't expect this part to really be hard, but I would expect it to be tedious and time-consuming.

- MCL-isms

  Sk8 was not intended or designed to be portable across implementations. Idiosyncracies of Macintosh Common Lisp are scattered through it comprehensively. The init file for building contains references to variables that are meaningless outside MCL, and constructs user-interface elements that rely on MCL's tight integration with the pre-OSX Macintosh Toolbox and Systems 6, 7, 8, and 9. You'll have to find all of that stuff and replace it.

- low-level magic

  Sk8 uses MCL's built-in assembler to do things like customize MacOS (6, 7, 8, and 9) window definitions, and interoperate with HyperCard XCMD resources. You have to do something or other with all of that stuff. The funny-looking windows that Sk8 used in its UI--intended to be easily visually distinguished from the UI you're building with it--are custom WDEF resources written in this way. You can't really port that stuff practically; you'd need to either replace or discard all of it.

- Sk8Script

  Sk8Script, the Hypertalk-like scripting language built into Sk8, is basically a full implementation of AppleScript in Lisp (I think Ruben said it was the first complete implementation). It relies on low-level details of AppleEvents in Mac OS 9 and earlier, if I remember right. Getting that to work right on current macOS might be pretty fiddly. Getting it to work anywhere else is probably not worth the effort. You'd probably want to rip it out, and then figure out how to staunch the resulting bleeding.

- SourceServer

  This was a Lisp implementation of an interface to Apple's Projector source-control system. There's probably no reason for anyoneto care about it anymore, but it's part of the Sk8 sources, and there are references to it scattered around the code. Again, you'd probably want to rip it out and then go looking for things to fix.

- MCL for SK8

  The MCL used to build SK8 was not, strictly speaking, an official MCL release. It was patched to support SK8 by altering bits of the low-level support for things like AppleEvents, foreign Booleans, MCL kernel support for Mac OS dialog boxes, QuickDraw rendering, data structures, foreign pointers, MacOS resource files, and some other stuff. You'd basically need to find everywhere that all of these patches were used or assumed and either rip that stuff out or implement some kind of substitute for it. That would be a bear of a task, all by itself.

Once all of that is done, you can address the multistep, layered build process that constructs MacFrames andSK8 on top of the resulting Lisp.

Fifteen years ago, Ruben himself suggested that it would be saner and more useful to start over, using the old SK8 as a sort of runnable specification, and inventing something newer and, one might hope, even better.