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]

Being "just a newer release of OpenStep" doesn't mean it is somehow suddenly easy to reimplement the whole API.

Actually it looks like the Zaurus thing is mostly a port of GNUstep, so it's not even entirely new stuff.

Ah, I am glad to hear that. I've seen the myStep project before, whilst browsing ZSI and such, and wondered why the hell they would start over again from scatch. Mostly though, I doubted the project would get far if they were doing that. Even if they're porting GNUstep, it seems that they won't get that far- Zaurus projects have a habit of not being finished.

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?

[Bob Davis, Retired]

Openstep is a public standard. Anyone can feel free to implement it for themselves. Cocoa is based on Openstep, and is in fact mostly compatible with it.

Re:cocoa apps?

[Jayfar]

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.

Re:cocoa apps?

[Anonymous Coward]

It's a moot point since Photoshop won't run on a Zaurus ;)

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!

Re:How about an OS X Sync solution!?

[aperezbios]

My latest, yet-to-be-released project, PortabilityKit, solves this problem. It bridges the gap between GNUstep and OS X, when it comes to Cocoa classes at least. Carbon is a beast of its own, and Apple does not condone its' use for new projects.

*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.

Afraid not...

[Anonymous Coward]

Preference panes, menu extras, the Finder, and Cocoa (not OpenStep, but Cocoa) are all Apple technologies.

Perhaps you should RTFA next time.

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

If they can do this ...

[Sonic McTails]

Why not make an API and some glue code so Aqua apps can be compiled on other platforms without problems. I could make SomeRandomProgram compeletely with Carbon (which is pure C/C++), and then take that same code, link against a glue-API, and have the same program work in X11. The same idea could be done with binaries, although only NetBSD has any Mach-O support ...

Re:If they can do this ...

[Anonymous Coward]

To clarify, mySTEP is a GnuSTEP-based implementation of OpenSTEP, an earlier version of what is now referred to as "Cocoa" (during the Rhapsody days, this was the "Yellow Box"), which is a very high-level API that has various language interfaces to objectiveC (Apple's preferred language; an object-oriented C dialect with Smalltalk-alike enhancements), Java, Ruby, Python, etc.

Cocoa applications are in most cases GUI apps as most of Cocoa's overhead is targeted for that direction. On Mac OS X, Cocoa interfaces with Quartz, the DisplayPDF-based, OpenGL-enhanced WindowServer that sits right under Aqua. With GnuSTEP, X11 is used. I don't know how it works with mySTEP.

But Quartz is not open source and there is no reason for that to change. Therefore, a lot of reverse engineering will probably be needed for cross-developing Aqua applications. I also fail to see the point: right now, Cocoa apps don't *really* work well under GnuSTEP; it still seems to have a long way to go. Even then, I don't think they have it implemented for Win32 yet.

As to binaries, I don't see at all how that would work.

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:If they can do this ...

[Tar-Palantir]

I stand corrected. Isn't QT for Win missing bits though? You yourself said it's lightweight. Does it include, say, the File Manager? CoreFoundation? Resources? Sorry for my misinformation... I've never had much experience with QT.

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.

Re:If they can do this ...

[slashdotbs]

If they can do this, how come I can't get MAME to run on my Zaurus SL-5600? This is (to me, at least) much more important. Seriously, if anyone has a 5600 and has MAME working, please share. As for running Mac OSX apps, one can only speculate how slooowly they would work.

PortabilityKit?

[Xystance]

From what you describe, PortabilityKit will allow anything programmed for OpenStep/GNUStep to also work for OS X. Is there a program that allows Zaurus firmware 3.10 syncing to a system running a GNUStep/OpenStep environment or program built on GNUStep that I don't know about? :)

Again...

[Anonymous Coward]

It doesn't look like you bothered to RTFA article.

He specifically mentions Mac OS X applications, and talks about updating the implementation of OpenStep (which is open source) to be compatible with Cocoa (which is not).

This is not exactly complicated, guy. RTFA.

Re:Again...

[FredFnord]

> He specifically mentions Mac OS X applications.

He specifically mentions recompiling MacOS X applications for use with the palmtop. Don't work unless they are recompiled. So the ONLY thing at issue is Cocoa. You can't run native MacOS X applications on the handheld; different processor, and trust me, he's not doing processor emulation.

> ...and talks about updating the implementation of OpenStep (which is open source)
> to be compatible with Cocoa (which is not).

Let's distinguish the OpenStep API from the GnuStep implementation, shall we? GNUStep is a 'free' (as in gnus) implementation of the 'open' OpenStep API. You can't copyright or patent an API.

Even given that, though, I'd agree with you if they were reverse-engineering the entire API from scratch. But when the changes are like 3% of the damn API base, give it up! Reverse-engineering the hundred or so class-pieces of the Cocoa APIs that have changed since GNUStep was implemented isn't even INTERESTING, let alone offensive.

-fred