Linked by Thom Holwerda on Mon 17th Sep 2007 15:17 UTC, submitted by Rahul
Legal Microsoft suffered a stunning defeat on Monday when a European Union court backed a European Commission ruling that the US software giant illegally abused its market power to crush competitors. The European Union's second-highest court dismissed the company's appeal on all substantive points of the 2004 antitrustruling. The court said Microsoft, the world's largest software maker, was unjustified in tying new applications to its Windows operating system in a way that harmed consumer choice. The verdict, which may be appealed only on points of law and not of fact, could force Microsoft to change its business practices.
Permalink for comment 272103
To read all comments associated with this story, please click here.
RE[3]: APIs
by alexandru_lz on Mon 17th Sep 2007 21:29 UTC in reply to "RE[2]: APIs"
Member since:

The Windows N issue, as I see it, is not Microsoft's fault, but it's also irrelevant.

To start with a purely personal point of view, EU's decision was plainly stupid in this case. The issue goes beyond MS integrating a media player in their operating system. This itself would be enough of a reason for me not to consider Windows N if I was selling computers. It's just something to patch up the things on paper -- technically and practically, it's useless.

Windows N was obviously designed only so that Microsoft abode EU rules, and frankly, I can't blame them. Nobody should blame the resellers either -- it's freedom of choice after all: everyone is free to resell whatever they want.

But frankly, I wouldn't buy it either. Since it's priced the same as a regular Windows XP license, there are just two cases:

a) I already own Windows -- and it's much cheaper to buy nLite or whatever other tool that strips Windows.

b) I am purchasing a new computer and I don't have Windows -- but since nobody except Dell is offering it (actually, I don't think Dell is offering it now, but it did at one point), it's still cheaper to get nLite.

And frankly, I can understand the OEM packagers issues. Windows N only addressed the issue of WMP, not the entire interoperability issue, and has exactly the same price. In this context, if I were selling computers, I wouldn't even bother to purchase Windows N OEM licenses (or whatever the procedure is for this).

Besides being a minor difference, Windows N didn't even get a huge amount of publicity. If you'd ask your regular computer buyer, I can bet he didn't even know what Windows XP Edition N is. And frankly, for an OS that is just as lousy as the other edition, only lacking an even lousier media player, the effort is just not worth it.

There's just no reason for an OEM to go through the hassle of stocking it. There's no EU ruling on that, they already have perfectly working contracts for distributing the regular edition of Windows XP -- why go through this hassle? Yes, I realize this defeats the purpose of Windows N -- but let's be frank and admit it, it's not Microsoft's problem here. They did their part of the contract.

The rest of this post is off-topic, feel free to ignore.

I agree. In fact, I think we should go back to the days where all OSes had interchangable memory managers available from both 1st and 3rd parties, interchangable task schedulers available from both 1st and 3rd parties, interchangable file systems from 1st and 3rd parties, etc (I guess Linux does do the 3rd of these). [etc., I'm not quoting the whole post but I'm also answering to the rest of it]

Just as dylansmrjones pointed out, this entirely depends on Microsoft releasing the specs. In order to provide an API interchangeability, all APIs must expose exactly the same set of functions, with only the back-end principles being different. Obviously, since everyone who knows Microsoft's solution to various aspects of its OS (memory manager, but not only -- also GDI, DirectX etc.) is under NDA -- if there is anyone who knows each of these aspects -- it's impossible to develop a replacement for these which would still provide 100% compatibility.

Also -- as pointed out by dylansmrjones -- Windows XP does support some of these features, including, but not limited to interchangeable filesystems.

What you are asking for -- although probably every EU lawyer's dream -- is... well, not technically impossible, just kind of useless.

The issue is not allowing someone to remove or replace various parts of the system's API. The EU, the users and everyone else is (are? screw you, English language!) in no position to dictate a developer how to structure their system's back end. If Microsoft or (Linus Torvalds) wants Windows (or Linux, or BSD, or whatever other operating system) to have one scheduler, end of story, it's their own problem and they can do it whatever way they want. They can make it sing and dance, as long as it doesn't impact interoperability and as long as it doesn't prevent some other technology to work for a non-technical reason.

Freedom of choice is good to encourage, but I hardly think it is useful when taken to such extremes. Something along the lines of kernel modules is simply enough outside an OS research laboratory.

Furthermore, there is another problem with your idea of an OS that shouldn't provide any API at all, but only an API component manager. If we don't take the operating system concept past the bootloader -- fine, but after that we inevitably end up having at least one API -- the one which the system uses for its most basic tools.

Oh, it sounds cool in principle, allow users and developers to use whatever they want -- but we have already done that with X11 and look where it's taken us. There are at least five major X11 UI toolkits (Qt, GTK, wxWindows, Motif, Athena Widgets, and we're not even mentioning XForms, FLTK, Interviews, Tk and everything else), and, ignoring the fact that every Unix desktop ends up looking like a parrot unless you spend some time with theming, there is the problem of memory consumption when loading all these libraries, copy-paste not working between some of them, drag'n'drop not working or working erratically, button positions getting reversed and so on -- just because of the policy but no mechanism principle.

Reply Parent Score: 2