Comment by protomyth

14 years ago

Technically, all of the display code (Quartz) was not part of NeXTSTEP. NeXTSTEP used Adobe Display Postscript which cost too much and had too many licensing restrictions to be used on OS X. Also, all the code imported from Mac OS would beed to be converted.

These are all layers on top of the lower-level OS, which is the only part that would need to be ported; and it was already ported.

Quartz is basically "Display PDF" instead of "Display PostScript" with the architectural difference being that DPS was client-server, with bits of PostScript being interpreted on the fly; while Quartz got rid of the round trips between client and server, merging everything into one faster, monolithic layer. I recommend you look at the PS and then the PDF specs, they are about 90% identical.

The code imported from MacOS also ran in a separate "box" on top of the lower-level details.

Really the best case I can make for my argument is to point out the similarity between NeXTStep's IOKit drivers and the OSX IOKit drivers. That is the part, that really DOES interface with the guts of the system.

  • Quartz was written new for OS X and didn't use any of the code from Display Postscript. The licensing fee for DPS was cost prohibitive for Apple and NeXT/Apple did not own the code. I am well aware of the PDF and PS specs (I have programmed in PS for a while). It should be noted that PS and PDF have diverged and PS looks to be no longer updating.

    I think you discount the complexity of Carbon a little bit.

    NeXTStep's IOKit uses Objective-C and the OSX uses a cut spec version of C++. Driver code is not compatible.

    • I've never really done a whole lot of lower level programming but IIRC 68K/PowerPC was big endian and I believe that a lot of Carbon was pretty stubborn about that.

      Also I don't know how much Altivec code would have needed to be ported to SSE (if any).