On Fri, 7 Jul 2000, William Lewis wrote:

[port-macppc added back with William Lewis's permission]

> MacOSX seems to be using the same old Mach-O format as NeXTstep. And
> the system calls are listed in <sys/syscall.h> as you might expect.
> But there are some other things to worry about:
> 
> - Kernel entry points other than syscall(). I don't know about OSX,
> but Openstep and XServer had at least one of these: the systemwide
> name/number resolver facility (lookupd, which is vaguely parallel to
> NIS/yp) used a trap other than the syscall trap to get send/receive
> rights to the daemon.

Hmmm... That would really be ARCH dependent - I'm not sure if there are
multiple standard ways to get into a powerpc kernel. I know that m68k had
A-line traps and F-line traps. I think powerpc only has one..

> - System call parameters, return values, etc. The magic numbers in
> ioctls will presumably be different. Structures filled out by system
> calls will presumably be different in places. Etc.

Right. That's what all of the syscall glue is about. :-) Check out
sys/compat to see all the other places we've done this. :-)

> - Shared libraries. Apple's shared libraries don't work the same way
> as netbsd's, afaik.  For simple command line tools, we can just ignore
> the shared-library-specific calls and try to resolve symbols against
> libc or something. But for any program that would require more than
> just a recompile to run under netbsd, there are going to be calls that
> don't map directly to anything in the netbsd world. Any program that
> uses the graphical UI would require quite a lot of functionality to be
> duplicated. But maybe we could get netbsd to use the Apple frameworks
> (which I think would be cool --- I love frameworks.)

The way NetBSD usually does this is that to run dynamically-linked
programs using the emulated OS's shared libraries.

So we wouldn't have to re-impliment anything here. You'd be using Apple's
libraries, so things would work. :-)

Note that the NetBSD foundation won't help you get these libraries
illegally. :-)

> - Daemons. Okay, most programs aren't going to talk to daemons
> directly, but the MacOSX environment, if it's anything like its
> predecessors (MacOSXServer, OPENSTEP), is supported by a lot of
> special purpose daemons, so if we figure out how to use the Apple
> frameworks we'll have to get the daemons they talk to running (or
> emulated) as well. Of course, these protocols are not documented.

Well, that's trying to get more of the system running than just the
command line tools. :-) But since you'd really be running the Apple-
distributed daemons too, so it'd work. We wouldn't need to debug the
inter-daemon protocols, just the app <-> kernel ones.

> Not an impossible goal, but I think it'd be a significant effort...

We'd start in steps.

Note also that there's the MOL project - the Mac on Linux effort. They
seem to be running a fair part of MacOS 9 that way. :-) Too bad it's
GPL'd.

Take care,

Bill