implementing Carbon

[ChristTrekker]

If one were to write one's own implementation of CarbonLib, would that be enough to run classic Mac apps natively on 68k/PPC *nix, in the same vein as WINE? Or is there more to it than that? I am certainly no expert, but it seems every classic Mac emulator relies on having a physical or ripped Mac ROM in order to access those Toolbox routines, and then translates 68k/PPC opcodes. Supplying a library for this would eliminate that necessity, correct?

 

[porter]

would that be enough to run classic Mac apps natively on 68k/PPC *nix, in the same vein as WINE?

Only if they are already Carbon applications, there never was a carbon for 68k.

classic 68k programs call trap instructions to get into the toolbox

68k CFM and PPC CFM applications call via "InterfaceLib" and other libraries.

So a 68k binary isn't going to give a damn about your CarbonLib it will just trap away and crash if there is no Mac ROM or emulator.

PPC CFM Carbon applications call the CFM CarbonLib

PPC Mach-o Carbon applications call a Mach-O CarbonLib

$ otool -L browserx
browserx:
       /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 122.0.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.12)

$ lipo -info /System/Library/Frameworks/Carbon.framework/Versions/Current/Carbon
Non-fat file: /System/Library/Frameworks/Carbon.framework/Versions/Current/Carbon is architecture: ppc

Does Carbon work natively on i386? Can somebody with an Intel mac tell us if the carbon framework has any intel implementation?

There is an architectural difference between CFM PPC and Mach-o PPC. Basically the Darwin Mach-o people stuffed up the PPC runtime model by trying to treat a RISC CPU as a CISC one. The PPC-CFM one is more correct because it originally used the AIX compiler tool set, so they did the calling conventions in a RISC efficient manner.

So in answer to your question, if you happen to have lying about a Carbon Application compiled for i386 then you could run it on any other i386 box if you implemented the CarbonLib and could load and runtime link Mach-o i386 modules.

 

[porter]

And another thing!

Prior to Carbon, all the structures were very very opaque and applications bit twiddle in GrafPort and WindowRecords themselves. Carbon tightned that all up and required accessors. So even if you had a CarbonLib, any application expecting to twiddle its own bits or use low memory variables would misbehave.

 

[porter]

I meant "were transparent". Now they are very opaque. Hope that is clear.

 

[Mike Richardson]

Does Carbon work natively on i386? Can somebody with an Intel mac tell us if the carbon framework has any intel implementation?

It does. Carbon is an integral part of the Mac OS. For example, the Finder and iTunes are both written in Carbon.

 

[ChristTrekker]

Only if they are already Carbon applications, there never was a carbon for 68k.
classic 68k programs call trap instructions to get into the toolbox

68k CFM and PPC CFM applications call via "InterfaceLib" and other libraries.

So a 68k binary isn't going to give a damn about your CarbonLib it will just trap away and crash if there is no Mac ROM or emulator.

[...]

Prior to Carbon, all the structures were very very opaque and applications bit twiddle in GrafPort and WindowRecords themselves. Carbon tightned that all up and required accessors. So even if you had a CarbonLib, any application expecting to twiddle its own bits or use low memory variables would misbehave.

So basically, it's Just Not Possible to write something that's the Macintosh equivalent to WINE (a compatibility library), because Apple made the System Software reliant on hardware-specific behavior. The only way to run Mac executables is to run the Mac OS on (real/emulated) hardware.

 

[Mike Richardson]

Only if they are already Carbon applications, there never was a carbon for 68k.
classic 68k programs call trap instructions to get into the toolbox

68k CFM and PPC CFM applications call via "InterfaceLib" and other libraries.

So a 68k binary isn't going to give a damn about your CarbonLib it will just trap away and crash if there is no Mac ROM or emulator.

[...]

Prior to Carbon, all the structures were very very opaque and applications bit twiddle in GrafPort and WindowRecords themselves. Carbon tightned that all up and required accessors. So even if you had a CarbonLib, any application expecting to twiddle its own bits or use low memory variables would misbehave.

So basically, it's Just Not Possible to write something that's the Macintosh equivalent to WINE (a compatibility library), because Apple made the System Software reliant on hardware-specific behavior. The only way to run Mac executables is to run the Mac OS on (real/emulated) hardware.

It's not impossible, but it would be very difficult. That is why the Classic environment is what it is - a full blown copy of OS 9, running in a sort of virtual machine. It was just so much easier to do it that way, I can kind of understand now.

 

[Gorgonops]

So basically, it's Just Not Possible to write something that's the Macintosh equivalent to WINE (a compatibility library), because Apple made the System Software reliant on hardware-specific behavior. The only way to run Mac executables is to run the Mac OS on (real/emulated) hardware.

It's actually been done already. Look up "Ardi Executor".

http://en.wikipedia.org/wiki/Executor_(software)

It never worked that well (allegedly) for the same reason the Wine has problems, but there it is. According to the wiki page the source code for it has been released so if you want to hack, have at it. The released Executer binaries ran on x86 so they were of course intimately linked to the syn68k CPU emulator, but in principle there's probably no reason why you couldn't substitute native execution on NetBSD m68k or the like... although since Mac software assumes it's running in privileged mode with no memory manager trapping illegal instructions might be a bear.

 

[porter]

I thought MAE was more like WINE.

http://www.aux-penelope.com/mae/

 

[Gorgonops]

I thought MAE was more like WINE.
http://www.aux-penelope.com/mae/

Judging from the screenshots MAE strikes me more like a BasiliskII-esque emulator except the toolbox ROM has been extended to support similar-to-A/UX backdoor access to the UNIX layer. (Filesystem access, clipboard import/export, etc. It also looks like it supported "commando"-type wrapping of some UNIX shell commands.)

http://web.archive.org/web/19980613012744/www.mae.apple.com/technical/3.0/White_Paper3.html

Ardi Executor was much closer to a WINE-style API emulator. MAE ran a hacked System (7.5.3 on the last version.) Executer uses neither the toolbox ROM nor a copy of the Apple system software.

(Yet another fumblefingered edit... the link to the Executer article on Wikipedia was broken and apparently I can't edit it now.

http://en.wikipedia.org/wiki/Executor_(software)

That one should work.)