Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Linux As we all know, Mac OS X has support for what is called 'fat binaries'. These are binaries that can carry code for for instance multiple architectures - in the case of the Mac, PowerPC and x86. Ryan Gordon was working on an implementation of fat binaries for Linux - but due to the conduct of the Linux maintainers, Gordon has halted the effort.
Permalink for comment 393230
To read all comments associated with this story, please click here.
by tyrione on Fri 6th Nov 2009 12:43 UTC in reply to "RE[2]: TYPO"
Member since:

"Quad FAT from NeXTSTEP: m68 NeXTStation, x86, SPARC 5/10, HP PA-RISC 712/60 & 712/80i Gecko systems.

Win32 too, if you used the Yellowbox stuff. But they were still separate executables with in the .app folder hierarchy, right? Mac OS 7 up till 9 also had FAT binaries, and these included 68000 and PowerPC code in the same executable "file" via code resources.

Yellowbox: That was mach-o, Portable Distributed Objects [PDO], orb, and other parts of Openstep to have the Openstep for NT development environment, on top of Windows. There was the the D'OLE [Distributed Object Link and Embed] idea when EOF 2 and WinNT 3.51 was out ala Openstep Enterprise.

The FAT binaries were specific to the entire OS. Yes, similar to Mac's but from a different view of the computer model.

The original NeXT FAT solution was designed around the Network model; and as has been stated in other sites, you store a single copy [up to 4 architectures on a NeXTSTEP or later Openstep version of the OS (NS3.3 binaries ran under Openstep 4.x): Inspector would list the architectures available and gray out all but your CPU architecture] across the Network [NFS/NIS managed NetInfo master servers] which being as there was no Carbon all applications were either NS3.0 - NS3.3 [non-Openstep apps] or NS3.3-OS4.2 [accessible to Openstep]--all relying on the NeXT APIs now known as Cocoa.

NeXTStep and Openstep /NextLibrary included all architecture libraries for you to leverage and your build environment was set up so that you could then recompile your code for each specific architecture while ultimately making local libs specific for each architecture dylibs upon demand.

If your machine was SPARC the SPARC NeXT libraries were linked against the executable along with the local libraries of SPARC for that application. Ditto for the other ones. All distributed object code was shared with NeXT PDO.

Each system copy of the OS installed was either custom for the client deployed via images, individually installed [your choice of localization to include or not besides your native language] to name but to install options. Third party apps had a clean understanding of where the help system was, the /NextLibrary, /NextApps, /NetworkApps, /LocalApps, etc were for and stuck to them.

Corporations built site licensing levels and they would keep track of how many network copies were running simultaneously.

Normally, PPDs were installed by default, unlike now with on-demand.

WIth a clean standard set of APIs applications were very lean and the business logic specific to the application was included in the bundle/.app folder, including the usual localization plists, etc.

The documentation was in RTFD before it was later moved to HTML. NeXT RTFD was nice.

NeXT Corporate's network was accessible from around the globe and everyone had the mandatory ~/Public folder.

Network branches were by Country and then by State/Region/Province, etc.

A lot of customizations specific to NeXT Corporate were never released that made a large network system a joy to work under. I was only ever a single ~username short cut away to quickly move to that branch of the network in Workspace Manager to give and copy info staff needed from one another, outside of custom database driven applications.

NeXTMail was a must. I'm still waiting to see a demo just once where Steve and people around the World demonstrate an OS X Server Network and show group collaboration. The iChat video between Paris and San Fran is not impressive.

on and on and on.

Edited 2009-11-06 12:47 UTC

Reply Parent Score: 3