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 272082
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: APIs
by dylansmrjones on Mon 17th Sep 2007 20:31 UTC 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

v RE[4]: APIs
by Almafeta on Mon 17th Sep 2007 21:21 in reply to "RE[3]: APIs"
RE[4]: APIs
by MollyC on Mon 17th Sep 2007 21:30 in reply to "RE[3]: APIs"
MollyC Member since:
2006-07-04

I was a developer, but have (blissfully) retired.

You missed my point.

You concentrated on my talk of developers being unable to target a fixed API with your proposed "ALL API MUST BE INTERCHANGABLE" scheme, but missed my real point (for which I blame myself for conflating multiple points). But first I'll deal with what I meant regarding devs not being able to target a fixed API. It seems to me that a natural consequence of your scheme that all API functions be replaceable is that the user/OEM has the ability to rip out components without replacing them with anything. Meaning, that the developer cannot count on all functions that his program needs being present on a given system.

The other problem is that the user/OEM can replace API with clone-api dlls that work for crap, and the user won't know to whom to turn for support, since he has no idea who made the api modules on his system.

Other issues arise, as to the granularity of API replacement. Lets say I, as a 3rd party developer, want to provide a replacement for four OLE functions, but leave the rest in place. Can I? Or do I have to replace every single OLE function? This is your scheme, so you must have thought of these things.

Another issue arises regarding the use of internal API that dlls use to talk with each other. Maybe the dll that handles HWND talks to the dll that handles HDC through an internal, private API. Are you saying that all internal functions must be made public now? Because imagine that a third party dev wrote a replacement for the HWND dll but not the HDC dll. In order for his HWND dll to work, it would have to talk with the MS HDC dll as did the MS HWND dll. Would that not mean that the private functions that MS HWND DLL and HDC DLL use to talk with each other must become public (and replaceable) public API now? Does not your scheme, in effect, require tha all private functions be public API?

These are among the issues that arise when government starts mandating software design.

I also have to wonder, as a practical matter, why a user would even want to replace, say ole32.dll, with a third-party clone? What in the hell does that buy the user? Hell, what does it even buy the developer of that clone dll? Provide advertising possibilities? If the user launches an app that makes an OLE call, and ole32.dll has been replaced by Acme_OLE.dll, then ads popup all over the place advertising Acme Software Co? (Sun already does that today on Windows, where the first time that you encounter a Java page during a web-surfing session (in IE or FF), the JVM is loaded, during which Sun throws up a message balloon in the system tray, "You're now using Java! Click here (a link to sun's web site) for more info!". That is irritating enough already without introducing the possibility of similar behavior occuring with each and every call to an OS API function that has been replaced by a 3rd party equivalent.)


But let's put that aside. Let's say, for the sake of argument, that all functions, both internal and public, are replaceable and that all available replacements work exactly the same. This lets me get to my real, underlying point:

Do you support, philosophically, the notion that OSes must allow all of their API to be replaceable? Do you support the notion that big government should force OSes to allow the entire virtual memory manager or pieces of it to be replaced? How about the graphics system? The task scheduler? Etc, etc?

I want to see you guys take your argument to its logical conclusion, and openly advocate that OSes must allow each and every one of their functions to be replaced by a third party equivalent, as a matter of OS philosophy and/or as a matter of law. Do you support this or do you not?

Edited 2007-09-17 21:44

Reply Parent Score: 2

RE[5]: APIs
by dylansmrjones on Mon 17th Sep 2007 22:17 in reply to "RE[4]: APIs"
dylansmrjones Member since:
2005-10-02

Damn a long post ;)

It's well over midnight here in Denmark, so am I excused if I answer it later, like in 12 hours?

You do raise some valid points, but there is some nonsense as well. I'll try and go soft on you ;)

Anyway, sleep tight whenever it's time for that in your timezone.

Reply Parent Score: 2

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

Yes, it's called Linux

Reply Parent Score: 2