3 ms·

Thanks for the reminder that FrameMaker still has not been ported to MacOS in 2018.

tambourine_man 9y ago
Yeah, I also remember that every now and then. One of the casualties from the OS X transition.
linguae 9y ago
I'm surprised that in the history of Mac OS X (including the days of Rhapsody and Mac OS X Server 1.0), nobody wrote a Rosetta-style compatibility layer for running NeXTSTEP and OPENSTEP applications on Mac OS X, given that Cocoa is a modern version of the OpenStep API and Mac OS X's Mach-O binary format is based on the binary format used in NeXTSTEP and OPENSTEP. Now, I don't know if anyone would be interested in running 25-30 year old software on High Sierra (though it would be cool to experience native FrameMaker and WordPerfect), but a compatibility layer may have been really useful back in 2001 or 2002 when there was little native software for Mac OS X at the time. This would have given the Lighthouse Design suite of productivity tools some extra time; it's a shame they were never open sourced by Sun.
- mattl 9y ago
  Especially at the time when Jobs was complaining that nobody was signing up to make Rhapsody apps.
  - scruffyherder 9y ago
    That is when they had to dump Rhapsody, and do the whole Carbon thing, as nobody was going to write for NeXTSTEP.
- jamesmcnalley 9y ago
  You would need to emulate both a Motorola 68040 and an Intel i860, plus whatever other unusual silicon was present.
  - linguae 9y ago
    Come to think of it, the other problem with providing a NeXTSTEP/OPENSTEP binary compatibility layer is that the UI guidelines for NeXTSTEP/OPENSTEP and Mac OS are different. It's more than just the differences between NeXTSTEP's grayscale theming versus the Platinum theme used by Apple at the time. It's also the little details, down to the order of the command buttons on a dialog box. Apple is famous for its UI guidelines, especially back in the Classic Mac OS era. The problem with having NeXTSTEP and OPENSTEP applications run unmodified in Rhapsody or Mac OS X is that users would have to deal with applications designed under two sets of UI standards. This is similar to the Windows ecosystem; because Microsoft emphasizes backwards compatibility, some users could be running Windows software conforming to different UI standards based on when those software tools were written. Already Rhapsody had official support for two types of applications: applications for Mac OS running under the Classic (Blue Box) environment, and applications written using the Cocoa (Yellow Box/OpenStep) API. Large software developers such as Microsoft and Adobe balked at the prospect of having to port their large code bases to Cocoa in order to take advantage of Rhapsody's features; this is how we ended up with Carbon. Perhaps the reason we can't run Lotus Improv and FrameMaker on Macs has less to do with emulation and compatibility layers (which Apple was willing to do for 68k apps on PowerPC Macs, Classic Mac apps on PowerPC versions of Mac OS X, and PowerPC Mac OS X apps on early Intel versions of Mac OS X) and more to do with the UI differences between NeXTSTEP/OPENSTEP apps and Rhapsody/Aqua apps. Plus, NeXTSTEP and OPENSTEP had small user bases that Apple could ignore or sacrifice in favor of meeting the needs of its "native" classic Mac OS users, and I don't know if Apple itself ever billed Rhapsody and Mac OS X as successors to OPENSTEP for OPENSTEP users; if I understand correctly, Rhapsody and Mac OS X were always billed as successors to the classic Mac OS. That might have also led to the decision not to provide support for old NeXTSTEP and OPENSTEP binaries in Rhapsody and Mac OS X.
    - scruffyherder 9y ago
      After finding the source to Darwin 0.1 / 0.3 which was Rhapsody / OS X Server 1.0 and getting it to build on x86, I thought it was cool that using remote display, and chroot from a NeXTSTEP root many things would run using the Rhapsody beta UI stuff. Although the response was about nill... Nobody really cared. I started work on merging the newer BSD stuff into the 0.3 kernel but the lack of overall interest kind of demotivated me.. and I couldn't see anyone seriously caring. That and previous does such a great job with the legacy black box stuff, it'd seem full emulation was a better solution.

Yeah, I also remember that every now and then. One of the casualties from the OS X transition.

I'm surprised that in the history of Mac OS X (including the days of Rhapsody and Mac OS X Server 1.0), nobody wrote a Rosetta-style compatibility layer for running NeXTSTEP and OPENSTEP applications on Mac OS X, given that Cocoa is a modern version of the OpenStep API and Mac OS X's Mach-O binary format is based on the binary format used in NeXTSTEP and OPENSTEP. Now, I don't know if anyone would be interested in running 25-30 year old software on High Sierra (though it would be cool to experience native FrameMaker and WordPerfect), but a compatibility layer may have been really useful back in 2001 or 2002 when there was little native software for Mac OS X at the time. This would have given the Lighthouse Design suite of productivity tools some extra time; it's a shame they were never open sourced by Sun.

mattl 9y ago
Especially at the time when Jobs was complaining that nobody was signing up to make Rhapsody apps.
- scruffyherder 9y ago
  That is when they had to dump Rhapsody, and do the whole Carbon thing, as nobody was going to write for NeXTSTEP.
jamesmcnalley 9y ago
You would need to emulate both a Motorola 68040 and an Intel i860, plus whatever other unusual silicon was present.
- linguae 9y ago
  Come to think of it, the other problem with providing a NeXTSTEP/OPENSTEP binary compatibility layer is that the UI guidelines for NeXTSTEP/OPENSTEP and Mac OS are different. It's more than just the differences between NeXTSTEP's grayscale theming versus the Platinum theme used by Apple at the time. It's also the little details, down to the order of the command buttons on a dialog box. Apple is famous for its UI guidelines, especially back in the Classic Mac OS era. The problem with having NeXTSTEP and OPENSTEP applications run unmodified in Rhapsody or Mac OS X is that users would have to deal with applications designed under two sets of UI standards. This is similar to the Windows ecosystem; because Microsoft emphasizes backwards compatibility, some users could be running Windows software conforming to different UI standards based on when those software tools were written. Already Rhapsody had official support for two types of applications: applications for Mac OS running under the Classic (Blue Box) environment, and applications written using the Cocoa (Yellow Box/OpenStep) API. Large software developers such as Microsoft and Adobe balked at the prospect of having to port their large code bases to Cocoa in order to take advantage of Rhapsody's features; this is how we ended up with Carbon. Perhaps the reason we can't run Lotus Improv and FrameMaker on Macs has less to do with emulation and compatibility layers (which Apple was willing to do for 68k apps on PowerPC Macs, Classic Mac apps on PowerPC versions of Mac OS X, and PowerPC Mac OS X apps on early Intel versions of Mac OS X) and more to do with the UI differences between NeXTSTEP/OPENSTEP apps and Rhapsody/Aqua apps. Plus, NeXTSTEP and OPENSTEP had small user bases that Apple could ignore or sacrifice in favor of meeting the needs of its "native" classic Mac OS users, and I don't know if Apple itself ever billed Rhapsody and Mac OS X as successors to OPENSTEP for OPENSTEP users; if I understand correctly, Rhapsody and Mac OS X were always billed as successors to the classic Mac OS. That might have also led to the decision not to provide support for old NeXTSTEP and OPENSTEP binaries in Rhapsody and Mac OS X.
  - scruffyherder 9y ago
    After finding the source to Darwin 0.1 / 0.3 which was Rhapsody / OS X Server 1.0 and getting it to build on x86, I thought it was cool that using remote display, and chroot from a NeXTSTEP root many things would run using the Rhapsody beta UI stuff. Although the response was about nill... Nobody really cared. I started work on merging the newer BSD stuff into the 0.3 kernel but the lack of overall interest kind of demotivated me.. and I couldn't see anyone seriously caring. That and previous does such a great job with the legacy black box stuff, it'd seem full emulation was a better solution.