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.
Thread beginning with comment 271996
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: APIs
by dylansmrjones on Mon 17th Sep 2007 16:12 UTC in reply to "APIs"
dylansmrjones
Member since:
2005-10-02

Actually such HTML-components can easily be replaced by compatible alternatives.

The IE ActiveX Control ought to be removable because there is an alternative with quite some compatibility (Mozilla ActiveX Control).

Rather than relying on a specific HTML-component, the OS ought to have a framework for HTML-components. Think translators or plug-ins. Applications could then use the HTML-widget without having to worry about the actual rendering engine behind the widget, due to the plug-in / translator structure.

Reply Parent Score: 3

RE[2]: APIs
by MollyC on Mon 17th Sep 2007 20:01 in reply to "RE: APIs"
MollyC Member since:
2006-07-04

Actually such HTML-components can easily be replaced by compatible alternatives.

The IE ActiveX Control ought to be removable because there is an alternative with quite some compatibility (Mozilla ActiveX Control).

Rather than relying on a specific HTML-component, the OS ought to have a framework for HTML-components. Think translators or plug-ins. Applications could then use the HTML-widget without having to worry about the actual rendering engine behind the widget, due to the plug-in / translator structure.


--------------------------------------

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

The IE libs are part of the Win32 API that apps rely on, but that doesn't mean that the user shouldn't be able to rip that out and replace it with a dll that supports a clone of that api that purports to do the exact same thing. The user should also be able to rip out the entire GDI subsystem and replace that with a clone api dll. And GDI+. And DirectX. And the HWND api. And all of .NET. And all of OLE too. And WPF. And WCW. Etc.

In fact, I don't think OSes should provide any API at all. Just let the OS provide an api component manager and let the user go out and buy a dlls that support the various APIs that he thinks he might need from third parties and plug them in.

It would suck for programmers that are used to targetting a fixed set of APIs. And it would suck for users that wouldn't have the first clue whom to turn when something goes awry. But I'm sure both programmers and users will adjust and come to appreciate how better off they are under a hodge-podge system.

Oh, but this should only be done for Windows. OSX and the like should still be able to provide a fixed target API for its users and programmers.

Edited 2007-09-17 20:06

Reply Parent Score: -1

RE[3]: APIs
by dylansmrjones on Mon 17th Sep 2007 20:31 in reply to "RE[2]: APIs"
dylansmrjones Member since:
2005-10-02

*sigh*

You are not a developer, right?

Your post is so filled with selfcontradicting statements I hardly know where to begin.

But let me take one thing right now: In order for components to be interchangeable they MUST NECESSARILY expose the SAME API! Therefore it will pose NO problem for developers. Interchangeable components require a FIXED API in order to work. This fixed API means that the developers don't have to care about the components in use of the End User's machine. It'll work anyway because the API is identical. Especially with a plug-in structure.

EDIT: Windows supports interchangeable file systems btw.

Edited 2007-09-17 20:33 UTC

Reply Parent Score: 6

RE[3]: APIs
by alexandru_lz on Mon 17th Sep 2007 21:29 in reply to "RE[2]: APIs"
alexandru_lz Member since:
2007-02-11

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

RE[3]: APIs
by stestagg on Tue 18th Sep 2007 09:27 in reply to "RE[2]: APIs"
stestagg Member since:
2006-06-03

Well, that's pretty much th case already for Linux, so thanks. Ok, the scheduler debate recently has highlighted some resistance to pluggable schedulers, but there are known ways to replace, and bundle for sale, a different scheduler. The GUI layer (HWND API??) can be replaced, albeit not so easily, but GTK/Gnome can be compiled for DirectFB instead of X, just by specifying a simple ./configure switch. As for filesystems, take your pick. I think they've even got Linux booting from NTFS nowadays, so even MS get a piece of the action. There's plenty of choice of window manager. It seems that Linux wins on consumer choice every time.

But all that is meaningless, It's not about 'big governments' conspiriting to topple this great example of good American capitalism, it's about making sure that people have choice, and if MS have manoeuvred themselved into a position where they are stifling free maket and consumer choice, even accidentally, then this must be rectified.

Remember, America isn't really the land of the free (in its strictest sense), there are laws to prevent certain behaviours, you aren't allowed to go out and shoot random people in the street, because it's accepted that freedom must be protected by law. The same is true of a free-market.

Reply Parent Score: 3