Porting from NeXT to OS X
Porting from NeXT to OS X
- Subject: Porting from NeXT to OS X
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 6 Jan 2003 17:44:45 -0500
On Monday, Jan 6, 2003, at 12:27 US/Eastern,
email@hidden wrote:
It sure would be cool if they did and much cooler still if they would
help us port even older NeXT Apps DIRECTLY to OSX ?
I have done this a few times. There are two main challenges:
- converting the NIB files
- converting the source
--
Converting the NIBs requires that you convert to OpenStep 4.2 as per
the porting instructions on that platform, then open/save each NIB in
IB on that platform, then move the NIBs to OS X. There may still be
some issues, but these can be taken care of by editing the object graph
as the files are loaded at one of the three or four steps in the
conversion.
--
Converting the source is a matter of using the Tops scripts from
OpenStep 4.2. It is possible to run these on OS X-- simply requires
adjusting a few paths and building a tool or two (I don't remember the
exact details and don't have the resources at hand to fill in said
details).
Out of the box, the tops scripts will not port various constructs
common to NeXT and OS 4.2 to OS X constructs-- nor will it port APIs
that were specific to OpenStep 4.2 that no longer exist on OS X. It
isn't hard-- but it is tricky (there is a big difference)-- to augment
the Tops scripts to convert or, at the least, annotate these
constructs. In one case, we were able to augment the TOPs scripts
such that it automatically converted the Display PostScript code [user
paths, in this case] into the appropriate calls to NSBezierPath.
Is this a NextStep app or an OpenStep app? Going from OpenStep to Cocoa
is significantly easier than going from NextStep to Cocoa.
They are really two completely separate problems. Enough changed
between OpenStep 4.2 and OS X that it can be very tricky to move from
OS 4.2 -> OS X, depending on the APIs used. For example, if your code
leveraged DPS heavily, moving to OS X is not straightforward (but can
be done).
Frankly, going from NeXTSTEP->OpenStep was somewhat easier in that it
was so well documented. Between OS 4.2 and OS X, there were a slew of
interim releases that resembled OS 4.2 less and less as X evolved
[remember Public Beta, anyone? or DR2?]. The NIB conversion, in
particular, is such that there is no totally straightforward way to
move from OS 4.2 to OS X-- a number of the interim releases contained
shims that died in later revisions.
--
If you would like further assistance with this, CodeFab can help. We
have lots of in-house experience with NeXTSTEP, OpenStep, OpenStep for
Solaris [Sun's implementation], and just about every version of OS X--
prerelease and otherwise-- to have ever shipped.
I don't mean for this to sound like a marketing pitch -- the port is
not completely straightforward and there are many potential pitfalls
and a tremendous number of variables. If you are porting something of
a greater magnitude than a personal project or small application,
investing in some experienced assistance would greatly smooth the
porting effort and result in a higher quality end result. Unless you
have a lot of code/nibs involved, a rewrite is likely a better answer
anyway.
For small to medium sized projects-- read Karl Kraft's most excellent
post. In one case, the project involved nearly 500kloc of ObjC with
even more C++. The NIBs tended to be very complex-- 10 to 12 thousand
objects in the NIB, in some cases, many of them from custom palettes
that had a very "interesting" design pattern.
This isn't really something Apple can afford to support, either-- doing
so would require a large amount of engineering effort to generate a
general solution for which there are a handful of projects with very
specific problems that need to be ported.
I've thought of getting some source to an old NEXTSTEP application or
two and doing a port going this route, but my only OPENSTEP machine
is a 32MB original NeXTstation with 400MB of disk. Plenty fast for
print serving, pain for software development.
If you happen to have an intel box lying around, run Virtual PC for
Windows on it and install OpenStep 4.2 or NS 3.3 on that. If you
search google for 'bbum virtual pc openstep', you should find my
writeup of how to install OS 4.2 on that system. It also wroks on VPC
for OS X, but is painfully slow-- the x86 version of VPC running under
Win98 is actually pretty spiffy fast and since you can run VPC full
screen, it completely hides Windows.
To share disks, create a disk image that is HFS (not HFS+). It can be
mounted on both OS X and OpenStep 4.2.
One point of fragility: I found that running InterfaceBuilder under
gdb would panic the kernel if I hit more than one breakpoint.
b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.