MS Office for OSX? Why not for Unix as Well? 479
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.
Office X uses Aqua (Score:4, Informative)
Re:Office X uses Aqua (Score:2, Interesting)
also, carbon is the set of apis that are a modified subset of the standard mac os toolbox. it is used for applications that can run native in os x as well as mac os 8.6 through 9.2. it's not a windowing system.
that said, the office v.x team had to rejigger all the graphic doodads in the applications to make them all lickable... ick. to the aqua theme. double ick.
Re:Office X uses Aqua (Score:3, Interesting)
They hacked off the parts of the MacOS 9 APIs that would be too difficult to implement in OS X's environment (especially things like OS traps that opened up potential conflicts and created instability). Unfortunately, a lot of things in OS 9 required these traps to work correctly instead of access sockets to other processes and the like. This makes it difficult for programmers that worked with these unusual parts of the APIs just to port to Carbon.
Cocoa is even worse to port to, since you have to write the app from scratch. The good news is that a Cocoa app is setup in such a way that Apple can add new features or tweak with the UI slightly and the app will automagically adapt without needing an update.
Porting either Carbon or Cocoa over to another *nix is as difficult as porting Win32 code to a *nix. Of course, some of these apps being written to be run as daemons under OS X with the POSIX libraries will be rather easy to port to another *nix, the problem being: They are trying to make money off of a webserver, ftp server, etc. Marketting to a group already with free ftpd and apache is a tough sell. MS Office could be just as tough a sell once OpenOffice truly matures.
YES (Score:2, Insightful)
Yes i think it does. What do most people use their machines for in the office? My lawer writes letters on his laptop. My accountants does spreadsheets. I write reports (ok so i use Lyx for scientific ones)
A good office suit is important and while Abiword is fast and more than most people use MS Office is a brand name.
Maybe, but standard office file formats would do (Score:5, Insightful)
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
Re:YES (Score:3, Insightful)
At one time we used to lease over 200 high end Sun and HP workstations. As their leases run out they are all being replaced by dell workstations. Why is this? Well, for one they are cheaper, but primarily its because at this point 99% of the engineering software that used to be unix only now run under win2k, plus they can use Office/Outlook.
Welcome to the real world.
Re:YES (Score:2)
Re:YES (Score:3, Informative)
I work with several publishers who won't accept manuscripts in anything but Word, which means that if you want to write or edit for those companies -- even if you're working on their Linux books -- you have to bow down to Office.
There are a lot of people who HATE Windows but love Office. Honestly, StarOffice et al. haven't caught up to Word's revision features. I wish they would, and soon, but until then there are a lot of businesses that would benefit enormously from being able to run Office on Linux or *BSD because the only apps they need are mail, browser and Word and Excel. (And maybe Access...) Frankly, I'd rather write in Vim any day, but just try to convince a large publisher to accept chapters in plain text, LaTeX or DocBook. And I'm not talking about O'Reilly.
StarOffice is just fine for typing a quick letter or whatever, but its revision control isn't up to snuff and it still has trouble converting Word docs. I'm no champion of Microsoft or their products, but if Microsoft were to port Office to Linux I strongly believe you'd see a surge in Linux on the desktop -- precisely why they won't do it. Why don't you see tons of Macs? Damned expensive hardware, that's why. Commodity PCs + Free OS + Office == Happy Businesses.
I really don't know anyone who uses Linux to be "trendy" though I know a lot of people who find the migration difficult if they try to replicate the Windows experience under Linux.
Re:YES (Score:3, Insightful)
As long as your publisher can read your documents, why will they care whether the
I think SO suffers to a large degree because so many found 5.2 so loathsome. SO (or OpenOffice) 6 is much, much nicer.
Not just Office (Score:2, Insightful)
Re:Not just Office (Score:3, Funny)
Re:IE under UNIX ? (Score:2)
Re:IE under UNIX ? (Score:2)
Here it is from the horse's mouth on MSDN: Creating a UNIX Application Using the Win32 API [microsoft.com]
Re:Not just Office (Score:2)
get the facts right (Score:2, Interesting)
Re:get the facts right (Score:2, Informative)
You really should get a clue before you get out your flamethrower. Cocoa does not make a GUI app portable to other UNIX boxes. Cocoa apps are not X Window apps; they therefore cannot run UNIX systems for whom X Window is the only GUI. For the app to be portable to another UNIX, either the app would have to be an X Window app (and thus not Cocoa) or the target UNIX would have to support Aqua (wouldn't Apple's legal team have a field day with this one?)
You're 100% right on one point: YOU REALLY DON'T UNDERSTAND THIS ARGUMENT
Both of you understand the argument. Unfortunately, you, AC (and the original poster), do not understand Mac OS X.
Re:get the facts right (Score:3)
Cocoa is NeXTStep, right down to things being named NSfoo. Well, it is NeXTStep, plus some extra development, but not a ton of extra stuff (I guess they were busy doing other things).
So something that could run NeXTStep apps could run a subset of Cocoa apps. More importantly if the thing that ran NeXTStep apps were extended to do the extra things (like sheets, and adding "display PDF" (not too hard given Display PostScript)) it could probably run a lot of Cocoa stuff...
Where could we find something like that? Maybe GNUStep? I mean they have been working on it for a long time...
P.S. X Windows isn't a GUI. It's a rendering engine, and a method to get raw user input. Gtk and Qt are more like GUIs (technically they are just GUI toolkits, a big paper document called a User Interface guide is a real important part of the GUI...), oh I think I got off track. Anyway X is a base to build GUIs on, and one could imitate the OSX GUI (more or less -- Alpha transparency between the new GUIs apps an other apps could be a pain).
In fact people have been working on it for a while, go look at GNUStep, it's not Cocoa, but it's what Cocoa was before Apple bought it, and doing the rest is doable. Not a trivial afternoon's work, but not a decade long effort either.
And while you may, you don't seem to have a great handle on X11...not that it is an easy thing to understand, or all that frequently a useful thing to understand...
OS X GUI is not X Windows (Score:3, Redundant)
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.
Re:OS X GUI is not X Windows (Score:3, Informative)
OS X has something called a Remote Operation API (apparently only documented in header files), that allows you to remotely display an OS X desktop, and to inject input device events. It's more like VNC than the X Window System, but it's use is transparent to applications. There's an OS X VNC port that uses it.
In this case, it wouldn't work. (Score:4, Informative)
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. (exactly right) (Score:3, Informative)
In the near future, we will see many, many more 'main stream' applications such as Adobe's prestigious family of design applications, Macromedia's design, multimedia and production applications, etc. running 'natively' on OS X. Don't look for any of these applications to be ported to UNIX. Developing for OS X is absolutely nothing like developing for UNIX, take it from a developer.
For example, a carbon applications is still based on the same MacOS APIs that have existed in the past - with a few omissions and a few additions, of course. The point of Carbon, though, is to make porting existing MacOS applications as easy as possible. Cocoa, on the other hand, is very different and is a totally new creature, and one that is proprietary, I'm afraid. I don't think we will see a Cocoa compatability layer for Linux - ever. These OS X applications are not based on the FreeBSD/OpenBSD foundation of OS X, it is the OS itself that is based on these foundations, not the applications that run on top of the OS.
A valid analogy might be the fact that in a large part, Windows NT was initially based in a large part on VMS, if I recall - maybe not the actual code, but I have heard varying reports of that as well. Of course, no application that runs on NT will run on VMS (without significant recoding). This is because the foundation of these OS's is less important than the APIs they are written against.
Bottom line here is that OS X is far more than a foundation of FreeBSD/OpenBSD with a pretty window manager. For more info, check out Apple's site for developers: click here [apple.com]. You'll find info on Darwin (the FreeBSD/OpenBSD layer), Cocoa, Carbon, how the various layers interact, what depends on what, etc. Enjoy!
Mac GUI and APIs (Score:5, Informative)
Most UNIX-like systems use an X11 server to draw graphics on the screen. MacOS X does not use X11; instead it uses Quartz [apple.com], a Display PDF server, derived from NeXT's Display PostScript server. (The GNUstep [gnustep.org] 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:Mac GUI and APIs (Score:2)
It can be accessed from Java as well and I believe other bindings are possible, just not in existence yet.
Re:In this case, it wouldn't work. (Score:2)
Cocoa, the native API for Mac OS X, is not X11-based. It is not OpenStep.
Re:In this case, it wouldn't work. (Score:2)
Re:In this case, it wouldn't work. (Score:5, Informative)
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.
Re:In this case, it wouldn't work. (Score:3, Informative)
Er, those are APIs, not languages. There is a C language binding for Carbon, and probably an assembly one, and maybe Pascal... Cocoa has a ObjectaveC binding, and a Java binding, and with the newer dev kit it may sort of have a C++ binding, or maybe that's just the ability to do some sort of twisted intermingling of C++ and ObjC.
Sure, unless you could somehow get an ObjectaveC compiler...like gcc. Oh, and a ObjC runtime system...like the GNU version of NeXTStep (which I thought was AfterStep, but that may just be a window manager...I know there is one though). Cocoa is mostly NeXTStep, down to all the classes being named things like NSfoo. There have been some people busily cloning under Unix it for the better part of a decade.
Well, if they did it in Cocoa they may be able to use the NeXTStep clone, more likely they did it in Carbon, and the best bet for that would have been a company that did a Mac API clone some years ago, but I think they went bankrupt in the very early '90s because almost nobody wanted to port Mac apps to Unix, even if they made it a pretty trivial port.
More importantly, the Mac has about 5% of the desktop market (as of the start of 2001 -- it may have gone up, Apple had a pretty good year with the iBook and TiBook). That's pretty small, but Unix in general (not counting OSX) has a smaller share, and there is some effort in porting between them (should be minimal for well written apps -- they even frequently "just work"; but that doesn't help staff a support center with everything they need). Is it worth MS's money to port Office to other Unix systems? Even if MS didn't have a vested interest in keeping everybody out of their party?
I don't think it really does. That's not to say they wouldn't give Linux the big miss even if they thought they could recoup their porting investment, but I doubt they could. How much money is Loki making (and Loki has a bunch of portability libs they have written already...).
Office X is out (Score:5, Insightful)
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.
Re:Not Unix? (Score:2)
from either of them to unix is a significant task.
Re:Not Unix? (Score:2)
For intents and purposes based on common definitions of that a Unix is, macosx is unix.
Carbon and Cocoa are API's made for macosx, therefore they are API's for a unix, they aren't api's for linux or freebsd or whatever but they are unix api's and actually porting them to other unixs/unices/whatever wouldn't be that tremendous of a task, the problem is that they aren't opensource..
Re:Not Unix? (Score:2)
I have nothing to add.
Re:Not Unix? (Score:2)
porting Carbon or Cocoa to unix would be easy except
that they're not open source is like saying that it
would be easy to take a trip to the moon except that
it's far away. When I said that porting from Cocoa
or Carbon to unix APIs would not be trivial, I meant
exactly what I said. A Carbon port of Office can't
be a basis for a Linux port because *Carbon doesn't
run on Linux*.
Re:Not Unix? (Score:4, Insightful)
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.
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).
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!
Re:Not Unix? (Score:2)
Yeah you do, different CPUs in many cases, and a different implmentation may have diffrent bugs (or fix some that a few things rely on). It should be an easy port though...unless the orignal was written in assembly.
No Offense.... (Score:5, Informative)
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.
Re:No Offense.... (Score:2, Insightful)
Yes, it does make it a Unix.
It does not make it X11 or even KDE, GNOME, etc.
Unfortunatly, the GUI is the part that requires the biggest effort to port a programme, especially if you want to conform to conventions of a desktop environment. All other differences between operating environments are more or less trivial.
Re: (Score:2)
Yes, we need Office on *BSD and Linux (Score:3, Interesting)
The weak link in Microsoft accomplishing an Office on Linux or Free/Net/OpenBSD, unfortunately, is XFree86. Apple gets around this with Aqua/Quartz and video-card integration (nVidia and ATI).
Come on! (Score:2, Insightful)
Re:Come on! (Score:2)
I don't see how that follows at all. Linux has a negligible market share of the target audience for MS Office. Those who do have it have demonstrated a willingness -- or even desire -- to use alternatives to MS software, and hence are highly likely to opt for things like StarOffice or Abiword instead. Porting to Linux would cost an enormous amount of time and money. I'm sure it doesn't take a genius to see the MS point of view...
Nowhere near easy to port (Score:4, Insightful)
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
Re:Nowhere near easy to port (Score:4, Interesting)
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.
Re:Nowhere near easy to port (Score:2)
Mac-on-Linux is like Plex86; it provides a way to run 2 OSes on a machine at the same time while not using emulation. It is not like WINE, as it does not actually implement the APIs of the OS whose applications it runs.
Re:Nowhere near easy to port (Score:3, Interesting)
OTOH, just as an educated guess it seems to me that, should there be need, a POSIX implementation of Carbon would be easier than WINE, just because of the higher quality and consistency of the target. But with Mac developers going for Cocoa (OpenStep), I doubt there will ever be such a need.
Unless -- and that's next to impossible -- Microsoft Windows failed, and their main claim to a monopoly became Microsoft Office v.X, and they decided not to port it to Cocoa -- that could be if they decided this would restrict it better to the Macintosh.
Or if someone reached the not-so-farfetched conclusion that w32 is too much of a moving target, and decided instead to implement Carbon on POSIX. Provided again that Microsoft wouldn't port their Office v.X to Cocoa.
About NIB, check http://gnustep.org./ if you are really curious. If my memory doesn't fail me they were trying to get compatible with Apple NIBs.
An analytical look at Office for UNIX (Score:5, Interesting)
- 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 [microsoft.com] is a good thing,
evolution-wise and principle-wise [fsf.org].
- 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 (Score:3, Insightful)
Re:An analytical look at Office for UNIX (Score:2, Insightful)
And Linux isn't bloated?
> MS Office defies the basic principles of UNIX.
Of course it does. It's not a UNIX app.
> It will probably need to run as root
How do you figure?
> and make our systems unstable
But then that's a fault of UNIX allowing an application to bring down the system.
> No freedom.
Pray tell how a UNIX port would give you LESS freedom?
> Don't be surprised if you
> will need a Passport account just to run Word.
That's just ridiculous.
> Why would anyone work on improving Koffice,
> StarOffice, or LaTeX if MS Office exists on
> the UNIX platform?
You must be forgetting that Microsoft would still charge hundreds of dollars for Office/UNIX...
Even if Microsoft does sell a lot of Office/UNIX, then the Koffice/StarOffice people will have a whole lot of customers available to directly lure -- right now they have to convince many people to change platforms!
> User friendliness.
Don't make me laugh. Every new iteration brings a new really really stupid and annoying 'feature'... (e.g., clippy, smart menus, smart tags)
> Hackability.
Who'd bother to hack a hack?
Simon.
Re:An analytical look at Office for UNIX (Score:4, Insightful)
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.
Re:An analytical look at Office for UNIX (Score:2)
FYI, under OSX you don't need to be root to run it, but you do to install it (same with many other programs).
Re:An analytical look at Office for UNIX (Score:2)
Fire up top next time you do that...you'll see that when you give the installer the admin password it uses it to run something as root (or to transform into a root process itself via some Mach magic). You may not count that as "being root to install", but I do.
That's pretty cool, I didn't know that. I like that kind of installer more.
Re:An analytical look at Office for UNIX (Score:2)
What do you think it wanted the root password for? :-) Or how it can install in /Applications when you can't write files there....
Yeah, the iTunes thing was kinda sucky, and other Unix venders may have made similar mistakes, but they didn't promote use of spaces in file names all over the place...nor do most of them hide the install process (not that I have used many comercial Unix installers).
Why register? (Score:2)
Just outta curiosity, why do you want to register it? Is it forced?[1]
I've never felt the need to voluntarily submit my contact info[2] to some corporation - I paid for the software, it's a done deal.
After all, it's not like the software has a warranty.
C-X C-S
[1] Even if it is, there's most likely a crack.
[2] Data which will probably eventually end up on some spammer or junkmailer's list...
Microsoft vs. Unix security (Score:2, Offtopic)
- 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.
Re:Microsoft vs. Unix security (Score:2, Troll)
1) Most windows are of 9X variety, where there is no such thing as a root user, thus any exploit, thus any trojan code automatically can do anything it wants to the system. This is repeated on NT where you have to be admin to do lots of things, so many people grant admin to the desktop user (especially developers) -- This is compounded by the fact that NT servers often run as a privileged account. IIS does this so it can do a runas user -- also a prime example of stupid feature to integrate IIS with operating system.
2) Default installs on windows are notoriously over featured a.k.a. insecure
3) There is no chroot command. If you have to have a server running with special privilege, at least the chroot limits the target area for damage available to exploits
4) There are a lot more complexity on Windows. Windows is probably 100 times more complex than Unix in terms of shear numbers of API's, addons, etc. This almost guarantees there will be a signicantly larger number of security holes
5) Windows does not provide the tools that make it reasonably easy to secure it and keep it that way.
Re:Microsoft vs. Unix security (Score:2)
VBS is not used in free software, Gnome Basic is being developed, as well as OpenOffice Basic, but they close VBA security holes.
Also security is a problem not only because of the scripting languages, but also what they are allowed to do in programs -- including OS's. Also perl, Scheme and the uses made of them are much safer than the equivalent proprietary (read Microsoft) systems.
Finally, OpenBSD does code review, and some of it trickle up to maintainers of the packages. Debian also tries to do some code review (albeit still limited in scope), and there's a specialized team for the Linux kernel.
That Viral GPL (Score:3, Troll)
While Word for Linux wouldn't be a bad thing for the Linux community, I don't think it's the hottest thing needed. There's a slew of word processing programs for Linux, several of which can handle .doc pretty well. Sure, John Q. Public might be more likely to use Linux if he could use Word itself... But I digress.
Cocoa != X11 (Score:4, Redundant)
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.
Re:Cocoa != X11 (Score:2)
avoid paying royalties to Adobe, I believe.
You have to define *NEED*. (Score:2)
You have to define need.
Is it need from the perspective of long-time Linux/UNIX users? Those that feel Microsoft software is unstable and filled with security holes will likely say, "No! We don't NEED Microsoft Office."
Or is it need from the perspective of prospective users? Users that come from a Microsoft dominated platform will likely say, "If it doesn't have Microsoft Office then it isn't compatible with how we work and it's not what we NEED."
Which is it?
Here is why... the story of 2 api's (Score:4, Redundant)
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 [oreillynet.com] 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 (Score:5, Insightful)
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
Office X is already on shelves (and besides...) (Score:2, Interesting)
Read about it here [microsoft.com].
Do those shots look like the X Window System to you? No? Maybe that's because Office X isn't written for the X Window System, but rather is a port of Microsoft's previous Mac OS codebase (dating back years) to updated Mac OS services and API's.
Furthermore, if Linux is the antichrist to Microsoft, why would they want to make their office suite available on it (or other similar free unix-like variant)? That would only provide more reason for people not to buy into Microsoft. (And look at how well commercial Linux office suites *cough Corel Office cough* have sold in the past.)
-benI can see a day when Microsoft helps write WINE. (Score:2)
Other comments in this thread have mentioned that the OSX GUI isn't X. That Microsoft used a subset of the MAC GUI to port Office to OSX. I'm sure that required a bit of work and not a little expenditure of capitol.
Now, as I said before, I can see a day when Microsoft helps write WINE. As you can plainly see, WINE potentially can help Microsoft programs run on many platforms without the need for extensive porting. It's a win for Microsoft isn't it? Well, it will be when they finally realize that there is a viable market in Non-Microsoft OS's.
I see software development happening at the speed of hardware development. I see people buying software and it just runs - no matter what brand of computer you own. I hear old folks talking about windows and their children think they mean the holes in the walls that you look out of. I hear old folks talking about operating systems and their children thinking - what is an operating system?
OS X GUI Thankfully Nothing Like X Window System (Score:5, Interesting)
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.
Wrong (Score:2, Interesting)
The real reason exists Office for the Mac OS? It's often cited as MS's 3rd most profitable product, which is undoubtedly why there is already an OS X version out.
Why not port it to other Unices (including Linux)? Office, as its name implies, is meant for workplace desktops -- a space where Unix isn't exactly prominent.
why MS this and MS that? (Score:2)
I think the recent attention given to portable
Nope. (Score:2)
Isn't that why we have StarOffice?
MS Office ALREADY ported to UNIX... (Score:2, Interesting)
Posting anonymously because of NDA/SPA/DMCA/whatever...
Microsoft has already ported everything from Internet Explorer to Windows Media Player to Microsoft Office. Only IE and WMP were ever made available to the public (for obvious reasons). These ports were done with the Mainwin kit from Mainsoft [mainsoft.com]. Mainwin is similar to Winelib except that it uses real Microsoft source code (including all secret API's, also explains why IE and WMP are so bloated on UNIX) and runs on more platforms (Linux, SunOS, HP/UX, AIX, IRIX, Tru64).
two reasons (Score:2, Insightful)
1. There's suitable demand for it.
2. It's profitable.
I'm no expert, but I don't think there's much demand for Office for *nix. And even if there was, it wouldn't be profitable like Office for mac due to way less market share.
Uhh.. (Score:2)
No shit.. everyone knows that. It's not necessarily illegal, though. The courts have been over this. You cannot *force* them to develop their product for another platform....at least, the courts have not chosen to try to do so.
Where is the financial sense for microsoft to put money towards developing office for unix? There isn't one.
Fundamental Assumptions (Score:2)
Linux is a Unix clone, right? At this point, I don't think anyone disputes that Unix is a server OS, not a desktop OS. It does a great job at doing all those complicated server things (too many to enumerate here).
In big business, in America, Linux has done best as a server OS. OEM vendors who sell machines with Linux preinstalled do so with their server lineup. For example, IBM. [ibm.com]
I'm a firm believer in using the right tool for the job. As such, it makes perfect sense to me that video production houses use Avids instead of IBM Thinkpads. And that most businesses put Windows or Macs on the desktop and Unix (or some kind of server OS) in the air conditioned rooms.
My point is simply that Linux excels at being a really fast, stable server OS. Benchmarks have shown over and over that it can do it faster than a Windows server. Why would you need an office productivity suite on your server?
(If I don't instantly get modded down to -1 Troll, please try to reply in a polite fashion. I'm more likely to read and reply if you leave out comments about my mother.)
Unix misses Carbon. (Score:2)
Ex: In Word for Office v. X (aweful name btw.)
-Type a letter (long painful task),
- Save your new document.
-Type a name for your new document. You are on OS X so no problem about file names greater than 31 chars so you type a very long descriptive name
- You save.
- BING! Error message after the save window has disappeared. "can't use more that 31 chars."
Repeat in Excel, rinse in PowerPoint, get the same error in Internet explorer with file truncation when downloading from the Web and you finally get the idea that what's living under this crap is not Unix (like GNU) and has been around for more than 2 years.
M$ QA: which QA?!?
PPA, the girl next door.
History folks (Score:2)
Re:History folks (Score:2)
the question is not 'why not?' but 'why?' (Score:4, Insightful)
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.
port easier from Windows code base (Score:2)
I suspect Microsoft probably just doesn't see any value in this. Right now, they likely perceive the market as small. And if the market ever got big, that would just mean that their desktop monopoly was threatened. What possible reason would they have to port?
And, frankly, do we really want it? MS Office on Linux would completely wipe out all the other efforts. Sure, Linux would get more commercial users, but they would all be just as tied to Microsoft as they are now. I'd rather see less adoption of Linux and more open source efforts.
Damned if you do, damned if you don't (Score:2, Interesting)
2. Why do we need IE on Linux? Galeon is by far the best revision of a browser I've seen on Linux as far as rendering and functionality goes. The only problems I've had thus far is when trying to access a site that requires Netscape or IE and does a JS check to insure browser type. That's poor coding and has nothing to do with the functionality of Galeon.
The whole idea behind open source isn't that it's free - although in most cases it is and that's a nice fringe benefit - the idea is that if YOU don't like what you have or have a good idea that you can extend and improve upon what's out there and give back to the community.
If SO or Galeon/Opera/Mozilla aren't what you want, code up what you do want - or make suggestions to the guys writing it. They're more likely to take your opinion into consideration than the guys at MS.
And lastly, I don't want to see MS products on Linux. Bloated, insecure applications with "technical support" backdoor trojans are not what I want out of an OS. If I want MS to know what hardware/software I'm running I'll write them a freaking letter and tell them. Otherwise, it's none of their damn business. Tell that to Dell and MS, who by default install 3 different accounts on XP machines for "technical support" remote access. Or how about the scripts in ME that run periodically to ship an XML document off to Microsoft detailing the hardware/software on your PC.
Is this the kind of crap you want on your Linux? I don't.
-----
Mac emulators for Linux and other unixes (Score:2)
Key point you've forgotten (Score:2)
To run Office on a Linux system (or *BSD, or Sun), you'd have to basically reverse-engineer EVERYTHING about Microsoft office. This is because it is not Posix, and not written to use any sort of X system. As said before, all the calls that would be made to the Mac API.
MS already HAS Win32 to Unix porting tools (Score:2, Interesting)
MS has no need of emulators like Wine. MS, I believe, actually owns MainSoft, and in any case, has allowed them to port Win32, COM MSXML, and a boatload of other junk to SysV Unix and Linux.
If MS doesn't release applications under Linux, it's because they don't want to.
Linux users wouldn't buy it anyways. (Score:2, Informative)
Come down to it. (Score:2, Insightful)
How many Linux users would buy Micorosoft Office for Unix?
Heh? Would you? For me I can tell I would not, and guess thats the way of a huge percentage. And now for programming, all the beatiful idealism aside, when programming commercially you also have to bend to the market rules, altough we programmers generally hate that deeply
Mac OS X is not Linux or UNIX (Score:5, Interesting)
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 [macnn.com] which sparked this thread [slashdot.org] 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...
Office v.X (Score:2)
Office v.X uses the Mac Carbon API which allows applications to be easily ported to OS X from previous versions of the Mac OS while allowing it to take partial advantage of new OS X technologies such as Aqua and Quartz.
A funny statement on the Office X box (Score:2, Interesting)
Office X brings you the power of Office, with the simplicity of the Mac on the stability of Unix.
Funny
Listen up on Mac OS X (Score:3, Interesting)
There's an explantion of how to set up mod_ssl in PDF, installing links (the browser), even an OS X port of zork from Unix, and a Solution Guide written for the novice for installing XFree86 (the X Window Server for OS X), fink, WindowMaker and GIMP, among other things, at http://homepage.mac.com/rgriff/index.html This "home page" is really a download site and has other items and belongs to the guy who does MacOSXHints at http://www.macoshints.com/. They speak a little Unix and Linux there in the forums. What _is_ this problem about X Windows on a Macintosh running OSX?
Mac people have been putting up Linux and FreeBSD web sites for years. We talk a little *nix ourselves, we just prefer the colorful flavored brand and like having the best of all *nix worlds in one.
Why fool around with Office for Unix? Run it on a Mac. Exchange files in business easily. Run Windows 98, 2k, or XP under VPI 5.0 (OS X version). Boot into suse or redhat, pick your flavor, all on one drive. Use all the "classic" software like Photoshop 6 or Quark Express while running Classic under OSX, both coming to OS X in carbon or cocoa form in 2002. Let's see, there's Adobe Illustrator X and Macromedia's Freehand 10, there's a complete business suite for small business in OS9 or OSX, and students may be interested to know that the two top math apps used in grad schools are available in X, along with a host of biological science and chemistry apps. Many of the BeOS folks are moving back to X.
Sales pitch? You betcha Red Ryder. I used to do Unix, then Linux, and now I do it all with a base of OS X with built in Apache and a host of *nix shipping with the user version of X, not to mention a Developer's Toolkit tossed in with everything from the basics (like a free compiler) to advanced scripting support with AppleScript Studio, a free download if you sign up for Apple Developer Connection. Cost: free. http://www.apple.com/macosx/
Did I mention that Darwin is open source, a derivative of FreeBSD, and is the heart of Mac OS X?
Hey dudes, this is where *nix for the desktop is headed, jump on board.
(duh....what a rant).......
This is not going to happen. (Score:4, Interesting)
I don't need my friend to tell me this.
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.
Re:Office (Score:2, Interesting)
AWG
Re:cuz (Score:3, Informative)
MS will continue to make a Office suite for MacOS because if they don't it will be another prime example of how, as a monopoly, they can control the fate of other companies.
They are not going to make a Office suite for Linux because they don't right now and they don't feel they have too. If Linux only has 0.24% of the market its easy to economicaly justify that. Plus there are all the other reasons they will not....
Re:cuz (Score:2, Informative)
not to mention -- dudes, do a teeny bit if research! a mac os x-only version of ms office has been on the shelves for months. in addition, we've all known ms was working on it for the better part of the year. i'm not a fan of either -- i'm not promoting them -- but really, think before you sound an alarm.
for a unix-based effort, go look at www.openoffice.org.
Re:cuz (Score:2, Insightful)
i know this from cruel experience, i used to work for a small group that did its newsletter in ms word's
staroffice came close, abiword did a decent job, but the problem was always the images and the tables -- the images would always either get mangled or not show up at all, and the tables were never correctly rendered
i ended up rewriting the entire template in abiword, but no one who cares more about getting the job done than promoting opensource would bother..
Why MS Makes Office For Apple (Score:3, Insightful)
Actually, MS don't just make office for Mac to avoid the lawyers, they make it because it makes a heck of a lot of money for them (comparatively little pirating on Macintosh so software generates far more revenue for the size of the user base). Why would MS completely recode Office and spend time making it "Mac-like" if they were just trying to please the lawyers?
Most people don't realise this but as is continuously stressed at product demos, Office:Mac is not a port of Windows and is developed by a completely separate team that is free to implement whichever features they choose. Some code is shared between the team but the product is far from being a straight port and hasn't been since Word 6 turned out to be such a flop.
They are not going to make a Office suite for Linux because they don't right now and they don't feel they have too. If Linux only has 0.24% of the market its easy to economicaly justify that. Plus there are all the other reasons they will not....
Not porting Office to Linux isn't just justifiable, doing otherwise would be economic suicide. There are very few Linux users on the desktop, even fewer of them who really need Office (most Linux users hack code, Office may be used for documentation but business users will either standardise on some other format or provide a convienient Windows box, home users are unlikely to write documentation or would just use another format).
Then, after we've narrowed down the number of users this far, look at how many Linux users would like to pay $500 (estimated US price, I'm Australian) for an Office suite? Linux users are used to getting software for free, it's part of the free software movement (part, not all - freedom is the main focus). These users would most likely either illegally obtain a copy of Office or simply do without it, further harming sales.
Microsoft isn't the only company shying away from developing commercial programs on Linux and for good reason - there is no way it can be economically justified unless the software appeals to the geeks who make up 99% of the Linux user base. Most geek software is written by geeks, for geeks and so is opensource, commercial software is more often made for the average user and so isn't worth porting to Linux.
Re:cuz (Score:2)
MS has since sold the shares anyway.
Re:cuz (Score:2)
Actually:
Re:Use Terminal-Server or citrix (Score:2)
Misconception alert: When you but TS, and use it remotely, you need to by a "Desktop" license. That means a workstation (or pro) license to MS. Office gets the same treatment. 1 user = 1 license. 20 users = 20 license. What it comes down to is the fact that MS get's the same amount of cash if you run it on your PC, or remote over Term Server.
Seeing I'm on the subject, have you ever actually USED the Ica client on Linux? It is crap. Nothing paints right, and it is slower than your mother on ludes. On a 100Mbit LAN, it performs like VNC over a 2400 baud modem. I compare that to running the ICA client on Windows, and it works like you are sitting on the real term server machine.
Re:Based on GNU hurd (Score:2)
Re:This is really simple. (Score:2)
Re:This is really simple. (Score:2)
Er, is there any problem with "all of them"? I've written a bunch of X apps, and none of them give a crap what window manager you run them under.
The rest of your argument looks more or less correct, look at all the complaints about Mozilla using GTK and not Qt, and then about it not really using GTK so much, and...
Of corse that didn't stop other Unix apps from making the choices (normally badly -- er, I mean normally Motif), and not get too many complaints...well, maybe a lot of complaints, but they are easy to brush off...mostly because I have no access to explosives, no, wait, I didn't say that out loud.
Re:This is really simple. (Score:2)
Re:Did the poster bother to do ANY research? (Score:3, Insightful)
"Aqua" refers to the GUI layer of the Mac OS API's, i.e. the PDF-based, Display PostScript-derived graphics layer (quartz) and the "look and feel" that goes along with it. Aqua is not an API in and of itself.
There are 2 native Mac OS API's-- Carbon and Cocoa. Carbon is a streamlined subset of the classic OS 9 API's designed to work well under preemptive multitasking. Cocoa is the NextStep-derived API's, which are supposed to be the future of the Mac OS.
Developers typically choose one API or the other to write their code in. Carbon prefers C/C++ and makes it easy to port existing OS 9 apps to the new OS. Cocoa uses Objective C or Java as the base language, and generally requires a from-scratch re-write.
Unlike the switch to PPC, Mac OS X does *not* run anything in emulation (aside from the Classic process, which can be switched off entirely if one doesn't want to run classic apps) Carbon is a 100% native Mac OS X API's, and is fully preemptive, fully uses modern memory management, etc. No "old MacOS code" is to be found in Carbon. They implemented many of the same API's, but the code to do so is entirely Mac OS X native.
Office X (like most existing apps) was most likely written as a Carbon app. That means that it has *no* similarlities to OpenStep, and porting it to OpenStep would be practically the same as re-writing it from scratch.
When you say "there aren't any significant OS/X native apps," perhaps you mean that there aren't very many Cocoa apps. This is true, but it's simply wrong to confuse Cocoa with "native." Carbon is *not* a Mac OS 9 emulation layer. Carbon apps are every bit as "native" as Cocoa apps. They happen to call an API set similar to the classic Mac OS API's for the convenience of developers, but the code implementing these API's is entirely new.