Slashdot Mirror
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.
Under OS X, the GUI is not an X server. It's a lot more advanced than X, which has its pros and cons.
For example, it supports transparency natively, and z-coordinates. But it isn't network-transparent out of the box.
In any case, yes, you could to Office on *nix if you were to port Cocoa or Carbon to the platform of choice, but i don't see Apple doing that anytime soon.
IE for Solaris is based on a partial port of win32 to solaris--with this you could theoretically port office for win32 to Solaris and therefore *nix.
Anyway, don't confuse OS X with a Real Unix with Real X Windows. Support for X on OSX is a third-party effort at best.
How many times do we have to have this discussion? OSX has BSD and Nextstep roots. It also has classic mac roots. This API, known as carbon is an updating of the classical Mac APIs. This API is what MS is using to bring Office to OSX. I've heard rumors that MS is developing the next version of Office in Cocoa, (the NextStep derivative API), this version could in theory be run on GNUStep, but this rumor is unlikely to actually be true.
Although internally OS X is a UNIX, the GUI toolkit that it uses, Cocoa is not X11, and has nothing to do with it. Most of the low-level jobs are done using PostScript, and the high-level APIs are in Objective C.
Because of that, Cocoa is even further from Linux than native Windows APIs. The closest thing to Cocoa on Linux is Qt, but they still have such substancial differences that easy porting is not an option.
Cocoa which is the old NEXT api upgraded and tweeked to MacOSX. It can be used from object C and java.
Apple wasn't getting super good feedback from developers about porting all there apps to Cocoa so apple under pressure released....
The Carbon api, which is a bit like the old mac os (I think like 80-90% the same). This allowed companies to rewrite existing apps for OS-X easily.
These are the 2 native api layers for OSx. Older apps (mac os 7-8-9) still run in a compatability mode.
Oreilly has an article on Carbon/Cocoa that is quite good.
Microsoft is using Carbon for there port..So not as super easy to port.. But then again they just might not want to port it....
Linux/BSD's security track record is no better than Microsoft's. The things we have going for us:
- source code, so we can spot and fix bugs faster
- non-homogeniety (I didn't worry much about the overflows in PINE, since with all the jillions of architectures and versions it was extremely unlikely that someone would create an exploit or worm specifically for my version and machine.)
But we all have the same factors working against us:
- Writing software in inappropriately low-level languages (C/C++), where security holes are possible because the language makes it easy for programmers to make mistakes which can lead to exploits
- Writing software in or supporting scripting languages (perl, VBS) which make it easy to write broken CGI/etc. scripts on unix or easy to write worms on Windows. (Actually, now that perl is standard-issue on unix systems, it would seem that a cross-platform scripted worm would be relatively simple to pull off.)
- Ad-hoc (if even) code-review procedures. My favorite example is the MD5 Crypt code in PAM (a very important module for security!!) -- it's clear to me that nobody ever read this code before making it standard. Take a look.