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 271990
To read all comments associated with this story, please click here.
APIs
by Myrd on Mon 17th Sep 2007 16:04 UTC
Myrd
Member since:
2006-01-05

So... what about programs that play Video through video APIs, or programs that display HTML through html APIs?

If these components can be uninstalled, then those apps need to add extra code to check if this stuff is available, and tell users to re-install it if not - which would be annoying for both developers and users.

Oh? You say they should leave the functionality there, in DLLs and such, and just uninstall the actual apps? But then you're just uninstalling a tiny shell around the big component... It doesn't really do anything except save a tiny amount of space on your drive...

However, the OS should be configurable to set different applications as the defaults for different actions, such as watching movies or browsing. And all protocols should be documented...

Reply Score: 4

RE: APIs
by dylansmrjones on Mon 17th Sep 2007 16:12 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: APIs
by Kroc on Mon 17th Sep 2007 16:14 in reply to "APIs"
Kroc Member since:
2005-11-10

Whether kHTML in Konqeror, WebKit in Safari, or Trident in IE, the HTML rendering engine is part of the OS. You are right that the browser is just a shell around this, and that is the same of almost all 1st party platform browsers.

However, Microsoft doesn't get rid of the shell at all when you try remove IE. If you click the mail button in MSN, it _always_ brings up IE, regardless of which is your default browser. There is no option to change this behaviour. You are stuck with this retarded behaviour.

Reply Parent Score: 6

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

Actually, Konqueror is an optional part of KDE, just like Epiphany is optional in Gnome.

I'm a Gnome User and I don't have Epiphany (or Evolution for that matter) installed. I do have Konqueror installed though (and therefore also KDE since KDE is a dependency for Konqueror).

You can have KDE without KHTML and you can have Gnome without Gecko/GTKHtml but you cannot have Windows without Trident/IE.

Reply Parent Score: 4

RE[2]: APIs
by PlatformAgnostic on Mon 17th Sep 2007 17:39 in reply to "RE: APIs"
PlatformAgnostic Member since:
2006-01-02

There's a really obvious reason for this: the interaction with other browsers has not been subjected to testing. They probably don't want to allow other browsers to be launched from Messenger because they haven't tested the interactions and are afraid of a bug similar to that Firefox url validation thing that came up last year (IE and firefox do the validation in different places, making Firefox vulnerable when IE was not).

Reply Parent Score: 2