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.
I was one of the beta testers for Office X. They've fixed many bugs since Office 2001 under Mac OS 9 and cleaned up the interface in Entourage. However, don't look for a full *nix port any time soon.
What MS Has done is comply with Apple's new API to the OS. Office X is NOT a UNIX application, it's still a Mac Application. All the code is Mac PowerPC code and uses Apple's "Carbon" and maybe some "Coco" code (but I'm not positive on the last one). It works well, it's fast and it's developed by a real Mac programming team as opposed to the abismal ports of Word 6 for example.
The truth of the matter is, Apple needs MS and MS Needs Apple (whether or not they want to admit it). I do not think that MS will be porting Office X to other *nixes any time in the future.
-- DuckWing
- Bloat. MS Office defies the basic principles of UNIX. It will
probably need to run as root and make our systems unstable. Do we need
this?
- No freedom. This is a step in the wrong direction for those of us who
prefer to use 'cvs update' instead of service packs to update our systems.
- Monopoly leveraging. Microsoft will undoubtedly engineer their
.Net
"features" into new versions of Office. Don't be surprised if you, as a
UNIX user, will need a Passport account just to run Word.
- Monopoly extension. Why would anyone work on improving Koffice,
StarOffice, or LaTeX if MS Office exists on the UNIX platform? The
competitors would start out at a huge disadvantage and know there's no
place in the market for them.
Now, on the plus side:- User friendliness. MS Office provides a seamless transition for
lusers who have grown up with Windows and don't know anything else.
- World domination. Anything that helps us replace inferior desktop OSs is a good thing,
evolution-wise and principle-wise.
- Hackability. UNIX is a far superior platform for hackers because of
the wide array of debugging tools available, so it will make reverse
engineers' jobs easier.
It is obvious that the cons outweigh the pros here by sheer numbers. But given the recent strides made by the Koffice team, it will only be a matter of time before their product is superior to MS Office in every respect.-Uncle
All personal preferences of bloat, security, blah blah blah aside, I believe the primary reason that MS isn't very interested in MSOffice on the Linux desktop is because of product licensing control.
It's far too easy (in MS's view) for software to be copied under Linux. As a class of users, Apple users tend to be "more honest" about paying for their software. Windows users are questions in a non-business environment (heh, but a number of businesses also, really). But with XP, there will be more control over product licensing.
With Linux, they lose all this, or it becomes far harder to maintain. Also consider this issue: Cost of support for MS. With all the different distros available, I tend to think they mind find the cost of support under Linux as not yet being tolerable.
Linux has it's own version of "DLL Hell" in the libraries. With a MS product, it's *generally* pretty safe to force an upgrade of a MS DLL with a new MS DLL. But what about libraries they have no control over? The only way around that is to replicate the seemingly near 500MB of libraries. And then people complain about bloat!
I'm no big MS business model fan, but I find some of their products (Outlook not included) quite usable. I run Linux, OSX, Debian, FreeBSD, NT4, and Win2K here in my shop. I still use Windows/MSOffice for business work, because I have yet to find anything as good as MSOffice for Linux. Sad, but true, from MY perspective. Anyways, in some respects, they're in a lose-lose situation. They can't control the libraries, etc, and when they load their own, people will whine that it takes a full gig to install MSOffice. What's a company to do? Not bother, that's what.
--John
As has been repeated many times here, what Unix really needs is:
...), Microsoft would have to cooperate in the construction of this program in some way.
1] A standard for office file formats
2] A capable standalone import/export program between this format and MS office formats.
The OpenOffice file format looks pretty good to me, but I understand why there could be reluctance among the many other office projects to ditch their ideas (though I think they should anyway).
Having the conversion program be standalone would allow all competing interfaces to the standard file to coexist nicely with each other. My fantasy is that in the final settlement with somebody (US states, EU,
Dara
One of OS X's gifts to the world, however, is the end of the reign X Window on UNIX. The GUI environment under OS X is Aqua. Anyone writing for the Mac writes their GUI as an Aqua GUI (Java apps are Aqua). You cannot easily port an Aqua app to the X Window System.
*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.
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.
Software sucks. Open Source sucks less.
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.
Stop over-analyzing your analizations
It's plum ironic that you read all about Linux, BSD, Solaris, hacking, personal freedoms, and all other sorts of stuff on Slashdot, and yet no one ever seems to be able to get it right, or care to try very hard, when it comes to the Mac OS or Mac OS X. Even the initial post didn't seem to me to have looked very hard to see if there IS a Mac OS X version of Office.
I wrote the MacNN article which sparked this thread last year, and saw a complete and total lack of understanding in most of the following posts. The tone of the followups expressed a lack of understanding on Apple's part for using BSD and not Linux - that Apple is not savvy enough to be in business, etc. This thread has reinforced that most dotters don't really understand what Mac OS X IS.
-++-
Mac OS X is NOT Unix. Mac OS X is NOT *NIX, or Linux. The architecture of Mac OS X is focused on leveraging the Mach kernel to provide services, do VM, handle threads, and more. Then, the tools on top of that are crafted to the Mach kernel, such as all applications being a Mach thread, and networking through BSD sockets. There is no compatibility layer which speaks Mach, there is only Mach.
Perhaps the work to change this would not revolutionize the field of Computer Science, but there is no true reason for Apple to switch, and having application *NIX personalities is a feature almost no "Mac" user would ever care about.
Quartz is not X11. X11 is a protocol, Quartz is an API. The better analogy would be Quartz and KDE - both of which feed a display engine, and provide widgets and graphical tools. Without getting into a side by side comparison, which you choose is going to be a matter of choice as to which you like better.
But, Microsoft worked hard to leverage the Quartz API for many of the features in Office - graph generation being the primary target, so a good amount of work would have to be done to reengineer major parts of the display engine just to get around these sections.
Consider further, if you will, how hard it has proven to be for most programming firms to take a Win32 application to the Mac using the Mac Toolbox (aka Classic) or even Carbon, much less fine-tuning it's graphics for the platform. The more impressive quick translation applications for Mac OS X have been written in Cocoa, the framework that has evolved from the NextSTEP/OPENSTEP frameworks/APIs, and Cocoa isn't even close to being link Carbon.
With the Mac Office codebase written in Carbon/Classic, it would take quite a while for any porting to take place, and in such time, I am confidant a newer version of Office would have already been released...
-++-
I'm not saying Slashdot should become, overnight, more Mac OS X conscious, but really...no one would spare the whip on someone who said Linux and Windows were the same since they are both operating systems...