Linked by Thom Holwerda on Mon 19th Apr 2010 10:08 UTC
Apple "I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the Mac OS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it's safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS."
Thread beginning with comment 419839
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by bogomipz
by saso on Tue 20th Apr 2010 08:10 UTC in reply to "RE: Comment by bogomipz"
saso
Member since:
2007-04-18

I would contest that the API rewrite had at its primary goals a goal to 'trim' the API down because the devices couldn't handle it. It's not too long ago that I was running OPENSTEP 4.2 on a 200MHz Pentium with 64MB of RAM (recommended were at least 32MB, minimum 8MB). It ran well, as snappy as any modern OS, and all that despite the fact that it ran a "slow" microkernel with drivers written in "slow" Objective-C and the whole graphics layer being a "slow" Display PostScript client-server architecture.

Reply Parent Score: 1

JonathanBThompson Member since:
2006-05-26

OPENSTEP is an implementation of NeXTStep, and OSX Cocoa and the frameworks is a hopped-up superset of NeXTStep, combined with the fact that Cocoa uses a compositing GUI and APIs to handle that. On top of that, another major difference is this: desktop/workstation/server systems optimistically allocate RAM, meaning they go on the assumption that not all of it will actually be used, but a process is told they've got some amount they asked for, even if it isn't really there, combined with it being backed up by swap, and that optimistic allocation combined with running with swap combined with the fact that the iPhoneOS is a composited GUI (OPENSTEP/NeXTStep is not, IIRC: definitely not NeXTStep, as such things didn't exist in release then, if anywhere) and iPhoneOS likely overall has a larger API than OPENSTEP for all it does, well, you combine all that and realize Apple put a lot of stuff into a relatively small system. I haven't tried modern versions of Windows, or of Linux, but when you turn off swap (for those that allow you to do so) things go splat rather readily, even without a composited GUI that eats up memory like there's no tomorrow. A phone OS needs to run more an embedded system: only promise what's actually there, and can't rely on paging. Yes, iPhoneOS has mmap, but, seriously, would you want to be constantly updating flash memory, both for speed as well as flash wear? Using mmap is most likely valuable for read-only data.

Reply Parent Score: 2

RE[4]: Comment by bogomipz
by saso on Tue 20th Apr 2010 17:58 in reply to "RE[3]: Comment by bogomipz"
saso Member since:
2007-04-18

OPENSTEP isn't an implementation, it's a full OS with an implementation of the OpenStep spec, as well as all the old NeXT APIs (old pre-OpenStep APIs, DriverKit, MusicKit, whateverKit), plus the full Unix goodness (manpages, BSD Unix APIs, etc.). However, there's little meaning in arguing which platform has more libraries (in terms of binary volume), because that's not what I meant to say. I meant to emphasize that the reason the iPhone OS APIs were redesigned and rewritten most likely has little to do with fitting the APIs on a "small" device, as compared with a 1996 computer, the iPhone's performance is stellar. If it were just that, Apple could just as well have dumped half of Cocoa (AppKit part) and created a subset with just a few classes and features added for multi-touch and window handling on small-screen devices. My suspicion is that they tried that, and concluded that the it was just way too hard to do, as the design logic in AppKit is quite big-screen-WIMP centric.

Reply Parent Score: 2