Re: Porting from Windows to Mac
Re: Porting from Windows to Mac
- Subject: Re: Porting from Windows to Mac
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 31 Oct 2008 08:32:49 -0700
On Oct 31, 2008, at 1:21 AM, Jean-Daniel Dupas wrote:
Le 30 oct. 08 à 23:49, Stefan Werner a écrit :
I would also recommend that you start over with the design of your
GUI, for
the sensibilities and design principles of Mac OS X are very
different. This
difference is exacerbated if you consider the age of MFC...
You are aware that MFC (1992) is younger than NextStep (1988)? ;-)
And if age is a criteria, we should always prefer Carbon over Posix.
Yes, but is older than the OpenStep specification (1993) that is the
true ancestor of Cocoa.
NeXTSTEP is the true ancestor of Cocoa. The NeXTSTEP APIs were quite
similar to OpenStep (of which, of course, Cocoa evolved out of).
There is relevance to Cocoa-dev here, assuming that an understanding
of history helps you.
The shift from NeXTSTEP to OpenStep was really focused on a several of
areas of change.
- The memory management model moved from a classic straight alloc /
free model -- literally, objects implemented -free and you called that
directly to tear down and deallocate the object -- to a reference
counted model using -retain/-release/-autorelease.
- Much of what had been straight C APIs were replaced with classes and
methods on said classes. User Defaults functions moved to
NSUserDefaults, for example. File management, archiving, and a
number of other fundamental subsystems were moved to Objective-C.
- NSString was added, along with NSDate and NSNumber, and the NEXTSTEP
collection classes (List and HashTable) were retired in favor of
NSDictionary, NSArray, and NSSet. List and HashTable supported non-
ObjC types, but this greatly limited their capabilities. The new
collection classes -- what you have today -- were pure object contains
and, thus, operations like archiving, KVC, etc... were enabled.
- In general, much of what had been code that every developer
seemingly needed to write over and over were captured as general
purpose, reusable, APIs.
When OpenStep was released, it contained a porting toolkit that would
run through an application's source and convert it to use the new APIs.
Trivia: Andrew Stone's Create -- www.stone.com -- is the only Cocoa
application (that I'm aware of) that has run on every single release
of Mac OS X, OpenStep, NeXTSTEP, or derivatives (including Sun's NEO)
as well as on every processor for which support shipped -- m68k, i386/
mach, i386/windows, SPARC/mach, SPARC/solaris, PA-RISC, PPC, and maybe
some I'm forgetting.
(Before joining Apple, one of my last contracts involved porting a
750,000 line Objective-C++ application from NS 3.3 to Mac OS X 10.2
[Jaguar]. It was actually quite a bit of fun and required effectively
porting to OpenStep 4.2, then Rhapsody DR1, then Mac OS X Beta, then
-- finally -- Mac OS X 10.2. By doing this, I was able to port the
rather complex NIBs, including custom palette support, from NS 3.3 to
MOSX 10.2, taking advantage of the compatibility archive support in
AppKit/IB at each stop to preserve the NIBs. Thank goodness for
Virtual PC!)
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden