OpenStep is a defunct object-oriented application programming interface (API) specification for a legacy object-oriented operating system, with the basic goal of offering a NeXTSTEP-like environment on non-NeXTSTEP operating systems.OpenStep was principally developed by NeXT with Sun Microsystems, to allow advanced application development on Sun's operating systems, specifically Solaris.
![](/uploads/1/2/6/6/126600938/867631154.png)
![Openstep Openstep](http://www.roard.com/docs/lmf1.article/shot2.png)
Images and articles about Solaris OpenStep are all over the net, so to sum it up, NeXT and Sun joined forces to get Solaris off of CDE and use NeXT's desktop UI, and more importantly, its OPENSTEP framework to create cross platform applications. Sun moved focus to Java instead of OPENSTEP and kept the CDE desktop.Over a decade later, the Retro community brought Solaris OpenStep back called!I haven't actually tried it but the screenshot shows that the beautiful Sun Microsystems logo is replaced with a shrunken OPENSTEP logo like to what you see on the OPENSTEP Box or CD Cover:So because of the removal of Sun logos, I don't want to use Lubu OpenMagic.I want to use the original Solaris OpenStep. Winworldpc doesn't have it (yet) so I tried looking for it and found this:I tried using it, but when I try to uncompress them with their.sh script, it would fail. I also tried to uncompress each file manually but it would not uncompress. If anyone else knows where we can find a copy of Solaris OpenStep, or if anyone knows if this copy on nextcomputers.org actually can work, please reply! After deep diving into the matrix, I did some reading and discovered these.gz files are not.gz files at all.
I validated that with the following command:$ file SUNWOosUc.cpio.bin.gz SUNWOosUc.cpio.bin.gz: ASCII cpio archive (SVR4 with no CRC)Its no wonder these files would not gunzip! They aren't gzipped in the first place! Why would the archiver even do that? Renaming.cpio to.cpio.bin.gz.I honestly haven't heard of a.cpio file before. Googling I found the following:Next, I opened unbundle.gzip.sh and made the following change to the script on line 66 and added line 67:## these files are not really gzipped.
They are actually.cpio files in disguise. (cd $INSTALLPATH; gzcat $CURRENTDIR/$LIST cpio -icdm)(cd $INSTALLPATH; cpio -idv. Thanks robobox.But I have a change of heart.As neat as this looks, this version I got from nextcomputers.org is incomplete without Interface Builder or Project Builder. Its basically more of a sample of the UI, but no means to make appsAlso, the OpenStep Terminal app is broken.
Launching it does nothing.I guess you can think of this OpenStep 1.0 desktop environment for Solaris is some kind of trial version, or a user only version. It would be interesting to see if OpenStep apps with fat binaries would run in this thing though, but as it is right now, its too barebones for me.Looking at LuBu OpenMagic (enhanced Solaris OpenStep 1.1 sparc) seems to have alot more apps built in.
But even that doesn't have Interface Builder or Project Builder as far as I know from looking atWould be nice to purchase on ebay some official boxed / CD release if that even exists. I believe it was a real product for sale from what I've read in archived articles. Would be interesing to see how does the CD, Box, etc look like. Or maybe it was an online only purchase.
Would be interesting to know that part of history.However I guess it really depends on what you want.For users who want to use OpenStep within CDE this is perfect 'User Environment' to test a fat binary compiled from some some other OpenStep system. All they need to do is simply minimize that CDE control panel so that it doesn't get in the way of the OpenStep Dock.Fyi, I never explained how I got this working.
I actually mirrored the manual install steps that did and it also works for this earlier version of OpenStep 1.0 with the caveat that you need to manually start it up within CDE with:$ sh /usr/openstep/bin/openstepAnd thats a wrap. Whoever is interested in following these steps described in this thread, good luck!
Tar xzvf icecast-2.3.2.tar.gzcd icecast-2.3.2sh./configure -without-python -disable-dependency-trackingmakesudo make install.Status: Needs to be installed on Windows,Linux and other Unixen except forMacOS X,OpenStep/ NeXTStepsystems.At the moment, the portaudio Subversion repository version is theonly version that works on MinGW and soMKPerformSndMIDIportaudio uses the upcomingV19 release. Either fetch the Subversionsnapshot, or using Subversion, checkoutthe portaudio version 19 development branch. OnLinux/ BSD/ SGIetc do. MusicKit Install locations PlatformFrameworks install locationApplications install locationOpenStep 4.2 (m68k,ix86)/LocalLibrary/Frameworks/LocalAppsMacOS X-Server V1.0-1.2/Local/Library/Frameworks/Local/AppsMacOS X/Library/Frameworks/ApplicationsGNUStep (on Unixen)/usr/GNUstep/Local/Library/Frameworks/usr/GNUstep/Local/ApplicationsGNUStep (on Windows)C:GNUstepLocalLibraryFrameworksC:GNUstepLocalApplicationsCommand line tools and manual pages will install into the /usr/local hierarchy onUnix type machines, specifically /usr/local/bin. Locations for command lineWindows tools have yet to be determined.If you are the system administrator for a NFS shared network, youprobably want to choose a local directory which can be exported andcreate symbolic links into that directory on the networked machines.Alternatively, if you have a single server that exports /Local. and /usr/local, simply install the packagethere and you're done. On GNUstep systems, make is responsible forbuilding the MusicKit sources.
From the top level of the source tree, executing makeshould build Frameworks, Examples and Applications. Note that the applications and tools built maydiffer from the MacOS X set due to missingGNUmakefile definitions, but we aim to produce thesame files on all platforms.At the time of writing, GNUstep isn't able to buildframeworks which depend on earlier built frameworks automatically. This requiresinstalling each MusicKit framework individually, in order, in a similar fashion to the frameworksof GNUstep themselves. Also, the environment variables required byGNUstep for building must be defined while having rootpermissions in order to install. This is achieved with the following commands. On MacOS X, to benefit from theXcode IDE (the IDE, pluszero-linking), make will just run the xcodebuildcommand line tool which does the actual building using theMusicKit.xcodeproj project. If configuredetermined some libraries were unavailable, they will be omitted from theCONFIGUREDLIBS variable passed on the command line whenxcodebuild is run by make.
Since xcodebuildinstall builds and then installs, the sudo make installsuffices, typing a preceding make is not actually necessary.The MusicKit project can also be built within theXcode IDE GUI. However configure must berun before building with Xcode, in order to configure headers toselectively compile sources based on library availability. Inaddition, the default configuration is to assume if theXcode GUI is being used,then the MusicKit is being developed, not just installed and that alllibraries have been installed. If all of the libraries are notavailable, the build setting CONFIGUREDLIBS must be changed for theSndKit to remove those libraries which are not installed. In practice,the user must manually modify CONFIGUREDLIBS build setting in theSndKit target to match the setting in Makefile.To build on MacOS 10.6, currently the MusicKit and SndKit frameworks must be built for thei386 32 bit architecture. This requires the supporting libraries to also be built as i386binaries.
Assuming the support libraries are built with an i386 architecture binary,configure needs to be instructed to test the library linking with thei386 architecture, using the -arch flag. If necessary, compile and install an appropriateMIDI driver.To compile the MacOS X-Server V1.2 ZilogSCC MIDI driver, some headerfiles are missing. You can get them from theDarwin distribution of theSoundKit, copy them from aNeXTStep 3.3/ OpenStep4.2 system, or as a convience, they are made availablefor.MacOS X Developer release includes source for a genericUSB MIDI driver at/Developer/Examples/CoreAudio/MIDI/SampleUSBDriver.There is also a driver binary for the MIDIMan MIDISPORTâ„¢ USB interfaces forMacOS X available for download from and othervendors may well have drivers available for their hardware. The documentation for the MusicKit and SndKit are now authored in SGML format. This is thenrendered to HTML, PDF,Apple HelpViewer and potentiallyother formats. In order to convert the documentation to these usual output formats, toolssuch as, need to beinstalled in addition to DocBook itself. The configure command willcheck for these tools.
The make command will attempt to build andinstall as much of the documentation as possible based on which tools have beeninstalled. This is invoked.
![](/uploads/1/2/6/6/126600938/867631154.png)