MS Office for OSX? Why not for Unix as Well?

technode asks: "Apple has released OSX, which appears to be an amalgam of NetBSD, and NexTStep, and other stuff. There is, or will be, undoubtedly, a 'native mode' office suite for OSX. If there is an Office suite for OSX, then why not for other Unixes? To do it once requires solving the basic problem of mapping Office onto the Unix/X-windows API. Once you have that piece, it seems like the only thing preventing a Linux MS Office Suite is MS desire to preserve their OS market share. Technically, this begins to seem a little bit like using one's market share in the applications business to protect one's market share in the OS business, which would, on the face of it, seem to be an anti-trust no-no. What gives?" Most people don't seem to understand that "native-mode" OSX isn't necessarily Unix compatible. Macs have had their own GUI toolbox for a long time, and I would assume that if Office does show for OSX, that it would be an easy port to other Unicies. This doesn't even go into the horrendous track record with regards to security that Microsoft has garnered, especially over the past few years. Does Unix really need Office at this point? Update: 12/29 1pm EDT by C :The wording above is incorrect. To clarify: an OS X version of Office would not be an easy port to Unix. Sorry for the miswording, there.

Comments

Re:In this case, it wouldn't work.

[Gid1]

*sigh*

Well, looks like you're not getting it either. (I'm a Mac OS X and UNIX programmer, and I have done NEXTSTEP programming too.)

1. Carbon is native. Cocoa is too. Classic isn't.

2. Carbon and Cocoa aren't languages, as you stated. They're APIs.

3. There are Objective C extensions to GCC, which is what you probably use when you allegedly develop MOSX code. Thus, the fact that Cocoa is written in Obj-C is not a problem for UNIX porting.

4. Cocoa would be far easier to port than Carbon, since the bulk of it (OpenSTEP) is already kinda ported in the form of GNUStep. (Cocoa is informally NEXTSTEP 5, IIRC, and the GNUStep team try to track changes in Cocoa, IIRC) One of the big missing bits is the whole Aqua/"Display PDF" layer, which contains some very proprietary work. However, the basic "event based model classes" you describe are identical.

5. Failing all that, IIRC, there already is a Mac OS (Classic) API for UNIX, or something like it. AFAICR, Adobe used it to produce their IRIX version of Photoshop. I'm not sure about that, though. It would defeat the whole point though, as they'd have to branch from the classic Mac OS Office.

For future reference for the dumb !"$%$£ that asked the original question, it's much easier to think that Mac OS X *contains* a standard UNIX rather than *is* a standard UNIX. Therefore, it's pretty easy to port UNIX stuff to MOSX, but not necessarily the other way round.

Mac GUI and APIs

[booch]

Let me see if I can help straigthen things out here. I'll start with the GUI itself, then move on to the APIs used to build GUI apps.

Most UNIX-like systems use an X11 server to draw graphics on the screen. MacOS X does not use X11; instead it uses Quartz, a Display PDF server, derived from NeXT's Display PostScript server. (The GNUstep project is working on a DPS/Quartz server running on top of X11.)

X11 and Quartz only provide basic drawing capabilities. They don't provide widgets such as menus, toolbars, scrollbars, etc. So a widget toolkit API is layered on top of the drawing functionality. In X11, common widget sets are KDE/Qt, GNOME/GTK, and Xt/Motif. Most of these APIs try to shield the programmer from having to access any of the low-level rendering calls. There are versions of Qt that can run without X11 -- the front end and back end are completely de-coupled.

MacOS X provides 2 different APIs for GUIs: Carbon and Cocoa. Cocoa is basically the NeXTSTEP/OpenSTEP API adapted for use within MacOS. It contains most of the old NeXT stuff, plus some functionality from MacOS 9. It is accessed via Objective-C. (The GNUstep folks are attempting to emulate most of Cocoa.) Carbon is basically the old MacOS 9 API in C adapted to use Quartz and the other lower-level functionality of MacOS X.

No Offense....

[jmenezes]

But you managed to be wrong on every point.

Is it an Application? Yes.
Does it run native on MacOSX? Yes.
well, almost.
On that you are absolutely right.

Is MacOSX a Unix OS? Yes.
Somewhat.
MacOSX is based on a BSD/Mach Kernel. But that doesnt make it Unix. The Unix compatibility is more of a one-way street than anything else. Lemme hit a few more of your points, and I'll explain:

Carbon Applications are every bit as Unix as Cocoa.
True, but not in the way you meant. Cocoa has _NOTHING_ to do with Unix, and neither does carbon.

Carbon is not some thin wrapper Apple devised to help developers port.
somewhat true. Carbon is almost the entire MacOS toolbox, as its been since the begining. Apple took the existing toolbox, weeded out the APIs that wouldnt work under OSX (the ones with direct hardware access, for example) and added a few new oens, and called that carbon. Its a completely integrated API set for MacOSX, not just a wrapper.
This aided in porting current applications to MAcOSX without having to do a major re-write.

In fact some aspects of Cocoa, under the OO level, are implemented using Carbon API calls.
wrong. Cocoa was pretty much done LONG before the idea of carbon came around. originally, there was going to be a "classic" compatibility layer, much like there is now, and then from there developers would have to completrely re-write their applications in objective-c or java for cocoa (yellow box, as it was known then). After much developer discontent, they decided to add carbon, which sits NEXT to cocoa, not underneath it. In fact, with MacOSX server 1, there was no carbon compatibility layer, or a classic layer for that matter. just BSD and yellow-box.

They use terminology like a Terminal window "letting you talking directly to the Unix kernel". This is crap, the shell is just another program. They mystify Unix and make it sound harder than it really is.
I agree, it could be taken as confusing. but with terminal programs, you can simply port most *nix applications and have them run in the terminal without a problem.
The problem only arises if you try to use a GUI, under which case you would have to use quartz...
which has _NOTHING_ to do with x11 or gnome or kde or anything like that.

In short, unless it is running in the classic environment (they all run as one application), it is a Unix Application.
BZZZZZZT.
nope.
its a Unix application as much as OfficeXP is a VAX/XMS application (NT having some of its roots in VMS, Win32 having its roots in NT)

Now, getting to what I was saying earlier, Unix compatibility ios a one-way street with MacOSX. it is based on a Mach/BSD kernel, and can run a good deal of bsd/unix programs with a simple re-compile or some minor code tweaking....
But theres a lot more to OSX then the BSD layer.
On top of that, is the Carbon and Cocoa APIs, which run on top of the BSD layer. THESE are what the native applications are written to, the higher-level APIs. and then there is the Quartz graphics layer, which is the GUI for OSX.
Any Native MacOSX application, therefore, isnt written to the BSD layer, but to the cocoa and carbon layer that sits atop it.
Apple could port (with significant effort, no doubt) the upper layers of MacOSX to run on the NT kernel, but that wouldnt make the applications any more Win32 then it would make them BSD or VAX for that matter.
this is evolution, and its only working one way.
Humans arent gonna evolve into apes (although its arguable that a fair amount have the brain capacity of apes....), and in somewhat the same way, OSX applications arent gonna evolve into Unix applications.
they can be re-written, but not simply evolve into them.