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

Office X uses Aqua

[Matt Gleeson]

Office for MacOS X doesn't use X11, it uses the native OS X GUI. IIRC they are using Carbon, a transitional API from older MacOS's to OS X.

In this case, it wouldn't work.

[Gothmog]

Office v.X is what is called a "Carbon" app. It uses a subset of the old Mac APIs to work on OS X. No such API exists on any unix, so it would require rewriting the entire GUI aspect of the program to run on another UNIX.

This was Apple's way of making it easy to port apps from the "old" MacOS to OS X. You just have to make sure you are not using the parts of the old APIs that are "naughty" under OS X (directly access hardware, etc.) and you are good to go.

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.

Office X is out

[DuckWing]

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.

Nowhere near easy to port

[miahrogers]

I have a full copy of Office for OS X 10.1. I'm running it right now. It's written using Carbon an Cocoa which are distinctly Macintosh libraries. Without reimplementing those systems, which is much of what Apple has been doing for the last... 10 years, there is no way office would run on Linux/Unix.

Right now porting Office in itself to Linux probably would be just as much of an undertaking as porting it to the Mac and Mac OS X was.

I think if we see Office every for Linux, it will most likely be running on wine or one of the free .NET implementations.

Re:Nowhere near easy to port

[leandrod]

> ...Carbon an Cocoa which are distinctly Macintosh libraries

An older version of Carbon (the so-called Macintosh Toolbox) already exists, and is called Mac-on-Linux. As for Cocoa, it's GNU GPL'd POSIX implementation is GNUStep.

> porting Office [...] to Linux probably would be just as much of an undertaking as porting it to Mac

You mean, porting it *from* the Mac... Microsoft Excel, Word and PowerPoint were all created in and for the Mac, later ported to Microsoft Windows, and only after some years ported back to the Mac -- at least PowerPoint was acquired from other company, but the fact is that the original Macintosh versions worked better than today's Microsoft Windows versions and their Mac ports. In fact this was true even of Microsoft Word for DOS and OS/2 -- being simpler and better thought, it was more precise and failed less than today's versions for Microsoft Windows.

Also significantly, the most ambitious and unsatisfactory of them all is the only one created on Microsoft Windows: Microsoft Access and its Jet engine.

An analytical look at Office for UNIX

[uncle isaac]

Well, let's just take a look at the advantages and disadvantages of seeing an MS Office port to UNIX. First, the cons:

• 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

Re:An analytical look at Office for UNIX

[cperciva]

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?

I don't know... lots of people decided that they needed sendmail, but it was bloated, unstable, insecure, and needed to run as root.

Microsoft aren't the only people who produce horrible code. They might be the only people who make billions of dollars by doing so, but that's a different matter.

Cocoa != X11

[uriyan]

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.

Here is why... the story of 2 api's

[acomj]

Apple has 2 api's available for MacOSX.

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

Why *I* believe MS doesn't want MSOffice on Linux

[jcwren]

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

Maybe, but standard office file formats would do

[dara]

As has been repeated many times here, what Unix really needs is:

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, ...), Microsoft would have to cooperate in the construction of this program in some way.

Dara

OS X GUI Thankfully Nothing Like X Window System

[smack.addict]

Just because OS X is UNIX does not mean that porting GUI apps is a simple recompile. It is true for non-GUI apps. X Window apps can also easily be ported to OS X apps since you can, if you want, run a window manager on your OS X box.

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.

the question is not 'why not?' but 'why?'

[fanatic]

If you use MS apps on Linux/Unix, you're still using MS apps. You're still voting for MS with dollars. You're still endorsing MS 'extended' protocols and closed file formats.

To me, it's a non-starter. Better to have native apps that can import the files - atleast until MS uses DMCA or UCITA or some other vile thing to make that impossible, too.

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.

Re:Not Unix?

[stripes]

Carbon Applications are every bit as Unix as Cocoa

Sure, but both require a giant library of stuff to work. Oddly enough the newer lib (Cocoa) is easier to port to random Unix systems because it is more or less NeXTStep. The other lib is more or less 90% of the old MacOS API.

Sure, you can port a Carbon program to a Unix system (give the source code), as long as you implement 90% of MacOS 9 in a user level library. Of corse you could port a Carbon program to VMS, PalmOS, VM/CMS, or the ROM monitor on a SPARC if only you implement 90% of MacOS 9 for it...

Doable, but not easy.

I think this confusion is Apple's fault. 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.

Of corse they do, it makes it sound somehow cool, and also like normal Mac users will never have to learn a single thing about it (and they don't...unless they were the kind of Mac user that fiddled with ResEdit for the fun of it).

In short, unless it is running in the classic environment (they all run as one application), it is a Unix Application

Yeah, but not in the sense that it is easy to port to another Unix. I keep struggling for a good analogy, and coming up with nothing. At least nothing stunning. It's a lot like taking a PhotoShop plugin that happens to work on a Windows machine, and saying "look it runs on Windows, it's a Windows program". Sure it is. In theory it could be run without PhotoShop, in practice it's a real pain to recreate enough of PhotoShop to run PhotoShop plugins (or worse yet, actions).

So yeah, with the exception of Classic stuff that runs under OSX are Unix programs, but not always in a useful way!

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.

Mac OS X is not Linux or UNIX

[green-ant]

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

This is not going to happen.

[watanabe]

I know this won't happen because

• Tonight at a reception held in my and my wife's honor, a Microsoft Office Developer, who is friends with me and my wife, and was eating my food, and drinking my drink said "Microsoft will never release an Office / Linux product."

  I don't need my friend to tell me this.

• Office helps consolidate Microsoft's desktop market share. Mac Office is just what the slashdot types are telling you -- a way to avoid antitrust regulations. Therefore,
• Releasing Office for a competing operating system will only dilute Microsoft's operating system market share. This creates no additional clients; it just cannibalizes their OS sales. (Put simply, people will stop buying Windows, and keep buying Office. These are, by and large, people who were buying Windows and Office before.)

Essentially, you can look for Office / Linux the day Democrats are back in the white house, and Microsoft is split into OS and Application companies. Until then, you will have to download Star Office with the rest of the world.