Re: porting apps from NextStep to Cocoa
Re: porting apps from NextStep to Cocoa
- Subject: Re: porting apps from NextStep to Cocoa
- From: Karl Kraft <email@hidden>
- Date: Mon, 6 Jan 2003 11:22:43 -0600
It all depends on how large and complex the app is, and what features
it needs. Does it have libraries, or is it a single monolithic app?
Cocoa is neither a superset nor subset of NextStep, so not everything
in one is available in the other. In addition the industry has changed
since then, so items that didn't make sense under NextStep are
no-brainers under Cocoa.
I am just finishing up porting a medium (74 KLOC) app to Cocoa that
started on NextStep. Part of the project (Non-GUI) was converted to
OpenStep, and then moved to GNUstep. The rest was waiting for a viable
GUI alternative. It was decided that OSX finally fit the bill.
Here are some random thoughts.
1) There is a whole set of issues related to deployment, network, user
retraining etc. We changed how we deploy the software, how users login,
and tons of other stuff. Cocoa has better integration with lots of
technologies, like using Windows file shares, or grabbing stuff via
HTTP. We had resources like color lists and fonts that we had to deal
with. We pulled out some code and replaced it with OpenSource
alternatives. We moved all the various file formats to XML property
lists instead of the mish-mosh that existsed before.
2) OpenStep would run NextStep binaries, but couldn't compile NextStep
source. (well not easily, although you could copy the Next development
tools over to Openstep, hoark up the makefiles something horrible and
make it work, but it's very painful). So you need to convert all at
once, not a class at a time.
3) You can convert Nextstep source to OpenStep source by running it
through a series of scripts using the tops tool. Tops is available on
OSX, but the scripts aren't, You should be able to copy them from an
Openstep box, convert the source, and do the whole thing on OSX.
4) The Conversion. Here is where things get tough. The project I did
was converted on OpenStep first (Client Issue). OpenStep is a dead
platform, and the tools are broken, with no fix possible, so that was
frustrating. On the other hand we were able to have the same code
running on OpenStep and OSX at the same time, with only a few ifdefs
for drawing code, and until they choose OSX, the possibility remained
of moving the code from OpenStep to somewhere else. If I had to do it
again, I would port directly from NextStep to OSX.
4a) The conversion scripts do 80-95% of the job depending on how much
experience you have with them, and how well you know both platforms.
retain/release/autorelease/NSString didn't exist on NextStep. The
conversion script throws little #warnings and #errors all over the
place to alert you to things that couldn't be done automatically. I
seem to recall that after running all seven conversions( it's a multi
step process), we had something like 400 hard errors, and 2000
warnings. Most of which were the same thing repeated over and over.
The method was to pick one "class" of warnings, and solve it. Solving
would produce more warnings. Here are some examples from the scripts:
replace "NX_PLAINSTYLE" with "NSBorderlessWindowMask"
replace "NX_TITLEDSTYLE" with "NSTitledWindowMask"
And the errors are from things like this:
replacemethod "placeWindow:" with same
error "WindowConversion: 'placeWindow:' is obsolete. Convert to
'setFrame:display:'"
4b) You have to decide how deep of a conversion you want to do. We
had a lot of stuff that converted from NSString to cString and back and
forth a few dozen times. Worked very hard to exorcise the code of any
c-strings. The conversion made lines like this:
NSString *myString = [NSString stringWithCString:[[NSString
stringWithFormat:@"%d",x] cString]];
fprintf(stderr,"Value=%s",[myString cString]);
4c) Some NeXTSTEP classes don't exists in OpenStep. Storage is one
that comes to mind. You either need to write a replacement (not hard),
or convert those structs into objects. (I did Storage when I converted
Xox to OpenStep, and objects for my more recent project)
4d) What do you want to re-architect and what to throw out? The
report system for the project used Draw and the method it used for Fax
covers to generate reports. None of that is there in Cocoa, so we
replaced all of that with ReportMill. We replaced all of the printing
stuff with a new architecture so that we could generate postscript
without converting out of PDF.
4e) The conversion introduced bugs, and it helped us find some that had
existed for years, But could never be debugged successfully under
NeXTSTEP. Be good with the debugger.
5) Nibs. The conversion script will convert the objects, but all of
the Nibs need to be cleaned by hand. Button sizes and everything else
has changed. The menu layout has changed. Biggest weird menu thing was
Quit is in the top level and doesn't show in the menu bar, so when we
first started on OSX, we had no way to quit. Also have to pull all the
images out of the nibs and put them into the project.
6) Project Builder - To import the project, you need to import the
Nextstep project file to openstep, and then the openstep project to
OSX. And then you won't like the result. Toss the old project, and
make a new one from scratch, besides which the project layout is much
freer under OSX.
7) Libraries need to be made into frameworks. Dozens of workarounds
can be pulled out.
On Monday, January 6, 2003, at 09:59 AM, Robert Baruch wrote:
Can anyone comment on the level of effort required to port a legacy
application from NextStep to Cocoa? Has anyone does this? I would very
much like to hear about your experiences.
Thanks,
Rob
_______________________________________________
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.
_______________________________________________
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.