Mac OS X Apps on Zaurus

An anonymous reader writes "Dr. H. Nikolaus Schaller reports progress in the mySTEP project to run Mac OS X applications on the Sharp Zaurus. Though not yet ready for production, the newest release brings more maturity and features, and Dr. Schaller invites anyone interested in integrating mobile, low-cost, handheld computers with Mac OS X-based IT applications to contact the project. In particular, Dr. Schaller would like to locate someone interested in developing and contributing a new menu system (NSMenuView, NSMenuItemCell) to the project."

Comments

cocoa apps?

[cheezus]

Wouldn't that require a reverse engineered implementation of apple's APIs? Or is this just talking about a portable framework so the same apps can run on both platforms?

Personally, I'd be more intrested on being able to run OS X apps on desktop intel linux than a pda

Re:cocoa apps?

[Dr Reducto]

If you could get it to work on a PDA, how much harder could it be to get it to work on a PC?

Re:cocoa apps?

[Meowing]

Wouldn't that require a reverse engineered implementation of apple's APIs?

Well, Cocoa is really just a newer release of OpenStep, so the guts of it aren't anything altogether new or super secret. Actually it looks like the Zaurus thing is mostly a port of GNUstep, so it's not even entirely new stuff.

Personally, I'd be more intrested on being able to run OS X apps on desktop intel linux

You can sort of do that already. Obviously, you would want to avoid Mac-specific things in your program, but there should still be plenty of common ground.

Re:cocoa apps?

[Trurl's Machine]

Well, Cocoa is really just a newer release of OpenStep, so the guts of it aren't anything altogether new or super secret. Actually it looks like the Zaurus thing is mostly a port of GNUstep, so it's not even entirely new stuff.

However, Cocoa is only one of the APIs running in MacOS X. Another quite important one is Carbon, very popular among commercial developers, as it is a path of least resistance leading from MacOS 9 to MacOS X (even if it's actually a nasty kludge, not a piece of art like Cocoa). So if you hope that GNUStep can somehow provide you native Linux ports of Microsoft Office, Photoshop or Warcraft III - it's not the way, as they are all Carbon.

Re:cocoa apps?

[RevAaron]

It's more so the other way around that it's being done. It already is doable on the PC, and is being ported to the Zaurus. Not mentioned in this post, but it seems to be borrowing a lot from GNUstep, which has been very slowly working toward this goal for what seems like 10 years.

Re:cocoa apps?

[Matthias Wiesmann]

I could be wrong, but I think possibly the new Photoshop CS may be entirely Cocoa. It's the first PS that won't run under MacOS9.

I highly doubt it. The fact that a program does not run under OS 9 simply indicates that it relies on some feature that is not present under OS 9. There are many APIs in OS X that are not present in OS 9 beside cocoa: BSD, Mach, Core Graphics, Core Audio, etc. It could also be simply compiled into a Mach-O binary, and not PEF. Finally, it could be that Adobe simply does not want to support two platforms, and simply prevented the App from starting on OS 9.

Give the nature of the Photoshop, I would suspect it calls Core Graphics directly, maybe it uses the Mach API to handle memory paging (Photoshop traditionally did its own memory management). I highly doubt we will see a cocoa version of Photoshop before some time, as Photoshop build around the classic Mac OS toolbox since version 1.

Re:cocoa apps?

[Jayfar]

Further digging indicates you are probably right - no cocoa yet for PS.

Still, and off on a tangent here, it looks like I'll need to keep my PS 7 handy after I upgrade, in order to use ColorSync settings in the print driver for my HP Photosmart printer. The latest HP drivers will, at long last marginally work under MacOS 10.2.8, but only HP's inferior Colorsmart option appears in the corresponding color popup menu in the driver, when running in other than OS 9 (I can choose either under OS 9).

How about an OS X Sync solution!?

[Xystance]

As excited as this makes me, it's tough to hear. I purchased a Zaurus SL-5500 almost a year ago, and I waited... 6 months for firmware 2.38 to be syncable with anything on OS X, and even then I had to use Qtopia Desktop for everything (As opposed to Ximian Evolution or Microsoft Entourage). Then Firmware 3.10 broke sync ability. I gave up 6 months later and sold it. I would LOVE to purchase one again now that it's close to running openstep apps, however... Not without either a Microsoft Entourage or Ximian Evolution sync solution!

*sigh*

[FredFnord]

Well, uh, no.

This guy is taking the 'OpenSTEP' API set, which was opened up and published by NeXT, of which GNUStep is a legal implementation, and porting it (via GNUStep) to a handheld.

So that one can enjoy MacOS X applications on a handheld device.

Now, I'm not sure 'enjoy' is the right word, since on my 2304 x 870 screen setup (two 21" monitors) I still feel like I could use more desktop space for MacOS X. I cringe at the thought of a handheld running it. But at worst it's a solecism, not a ripping off of Apple. They published the APIs, someone else came along and made another implementation (with NeXT's blessing, if I recall correctly), and this guy is porting it to a handheld and updating it a little to be more compatible with MacOS X.

In summary: lighten up. You're sounding like the type that gives us Mac users a bad name.

-fred

Re:*sigh*

[Anonymous Coward]

NeXT & Sun created the OpenStep API from the API's of NEXTSTEP Mach (the ancestor of Mac OS X & Cocoa). There was OpenStep for Solaris, OpenStep for Windows and OPENSTEP Mach, the "reference" operating system for SPARC, HP PA-RISC, NeXT hardware (68K) and x86 (486+).

OpenStep Solaris was maintained by Sun. NeXT handled the other versions.

Re:If they can do this ...

[Tar-Palantir]

Are you aware of the incredible amount of work that would take? Carbon is a *huge* system. Even if it wasn't Mac specific (which it is, and HFS specific, and big-endian specific...) it would take a good team a long, long time to get Carbon to work multiplatform. By comparison with Carbon, Cocoa is a very small (and well designed and documented) API.

Besides which, Carbon's sort of in transition. Old APIs being phased out (thankfully!) and new ones like CoreFoundation being used in their place. CF, I believe, is partially open source.

So, in summary, the answer to your question is "because it would be infinitely more trouble than it's worth."

Re:If they can do this ...

[Chucker23N]

" Even if it wasn't Mac specific (which it is, and HFS specific, and big-endian specific...) it would take a good team a long, long time to get Carbon to work multiplatform."

Um, no, it's not. QuickTime for Windows is, and has always been, pretty much a lightweight but complete Mac OS Toolbox implementation, and Carbon is just a modernized Mac OS Toolbox. That's why iTunes for Windows was so damn easy to port - it's Carbon, and little more.

Writing an app that utilizes QuickTime is hardly different from writing an app that utilizes Carbon.

Re:Afraid not...

[FredFnord]

1) Preference panes are Apple technologes

In what way? The System Preferences panel is not really in any way different than any one of a dozen implementations of preferences for a dozen other programs. There's nothing new there. Admittedly, if it looks identical to the Apple implementation, *IDENTICAL*, then it's a bit of a rip. But nothing too exciting.

2) Menu extras are Apple technologies.

Okay. What's a Menu Extra?

3) The Finder is an Apple technology.

This specifically doesn't run the finder, it runs something vaguely similar that he's putting together himself.

Unless what you really mean is 'anything called 'The Finder' is an Apple technology.' Or 'anything that looks kind of like the Apple Finder is a rip-off,' in which case basically every OS's GUI that is even vaguely usable today is a rip-off. I explicitly include some of the better Linux GUI work.

4) Cocoa (not OpenStep, but Cocoa) is an Apple technology.

Look, here's how you create a new window in Cocoa:

NSWindow *myWindow = [[NSWindow alloc] initWithContentRect myContentRectangle
styleMask:(NSTitledWindowMask | NSClosableWindowMask)
backing:NSBackingStoreBuffered
defer:NO];

(c.f. documentation here:)
http://developer.apple.com/documentation/C ocoa/Ref erence/ApplicationKit/ObjC_classic/Classes/NSWindo w.html#//apple_ref/doc/uid/20000013/BCIBIAJJ

And here's how you create one in OpenStep:

NSWindow *myWindow = [[NSWindow alloc] initWithContentRect myContentRectangle
styleMask:(NSTitledWindowMask | NSClosableWindowMask)
backing:NSBackingStoreBuffered
defer:NO];

(c.f. documentation here:)
http://docs.sun.com/db/doc/802-2112/6i63mn 62p?q=ns window&a=view

Now, may I remind you that this is a WINDOW. In MacOS X, it's got colorful lickable widgets, it's displayed in Display PDF, it's got Quartz Extreme accelerating it (and is therefore drawn totally differently in some cases than in others.) In contrast, in Solaris OpenStep, it's displayed in X, and in Display Postscript in NeXTStep, its widgets look completely different, it has three different kinds of graphics implementations, it does different things when you click and drag in it, and just in general it behaves very differently than it does on the Mac. So this isn't some kind of 'really similar' special case. This is representative of the whole language.

Now, given that, I'm leaving you to guess how different Cocoa and NeXTStep/OpenStep actually are.

-fred

Re:If they can do this ...

[lcracker]

CoreFoundation is portable code, that's not in QT, but is statically linked into iTunes/Windows. Most, but not all, of it is open source.

I'm sure AppleSingle resources aren't a problem, whether or not they're in QT, given that we have some relatively short pure Python code that does them cross-platform, I'm sure Apple has some longer C code to do the same.