More OpenStep History

It looks like this OpenStep history is popular based on the number of hits my blog got for an earlier post this week. Of course it helps that it was syndicated on OSNews.Com (thanks Eugenia)! So here's a bit more.

Mach Stuff: As you probably know, the NeXT operating system was based on BSD and Mach (same as the Mac OS X release (code-named Darwin) currently is. Solaris is nowadays based on System V Release 4 (as opposed to the earlier days when our O/S was BSD based). As we started to try to get the NextStep applications running on Solaris (which was at about version 2.5.1 in those days), we had several porting issues. The usual BSD -> SVR4 API issues which are easy to fixup. On top of that there were places in the NextStep API's and the NextStep applications where Mach specific API's were used.

Whenever the NextStep API's used such specific Mach variables or calls, then, for the OpenStep API's, we needed to remove them and generalise so that there was a chance that it would work on all the platforms that OpenStep was to run on.

But on top of that, some applications still made Mach API calls, and this had to be dealt with. Mark Anenberg wrote a small library that emulated the calls that we still needed. I forget exactly what they were.

There was only one Mach book around at the time (as far as I remember), called Programming Under Mach and this was the bible for trying to understand how each of these routines worked. The book didn't always have the material we needed, so we had to work closely with the O/S folks at NeXT. Luckily this included some of the people that originally created Mach at CMU.

As the applications were ported, they either used this emulation library, or where possible, the code was adjusted to do the equivalent in a more native Solaris way.

Purify support: One of the things we wanted to do was make sure that our version of OpenStep was performant. That it didn't leak memory, or use uninitialised variables or incorrectly accessed variables. The usual stuff that memory checking software can look for. At the time in 1994-5 though, one of the best packages around for doing this was Purify from Pure Software (now IBM Rational).

Trouble was, Purify didn't grok the shared objects that our compilers generated from the compiled Objective-C code. Stan Lanning at Purify did the work needed to fix this. This helped us to really improve the quality of our port. As far as I know, this Objective-C support has been in their product ever since.

[Technorati Tag: OpenStep]

[Technorati Tag: Computer History]

( Aug 13 2004, 08:19:39 AM PDT ) [Listen] Permalink