Linked by Thom Holwerda on Fri 14th Jul 2006 21:08 UTC
Microsoft In a Q&A, Neelie Kroes, who fined MS for not complying with the EC's antitrust ruling, said: "I regret that the Commission has had to take such a step today, but given Microsoft's continued non-compliance to date, I have been left with no alternative. Today's decision reflects my determination to ensure that Microsoft complies with its obligations.Microsoft has claimed that its obligations in the decision are not clear, or that the obligations have changed. I cannot accept this characterisation - Microsoft's obligations are clearly outlined in the 2004 decision and have remained constant since then."
Thread beginning with comment 143123
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Outrageous
by MollyC on Sat 15th Jul 2006 02:58 UTC in reply to "RE[4]: Outrageous"
Member since:

"None of the analogous statements are true for Microsoft's platforms. Microsoft's closed APIs prevent Microsoft customers from easily switching to competing platforms, and they prevent people from running most software written for Microsoft platforms on alternative platforms (i.e. WINE often doesn't cut it, and it never will if Microsoft doesn't open their APIs). Businesses have a heck of a time integrating competing platforms into their predominantly Microsoft infrastructure."

You're not making much sense.
Microsoft's public APIs aren't closed. See How do you think Windows programs get written if the apis are closed?

And what does WINE have to do with it? The APIs that WINE is trying to mimic are open. If they don't know how those APIs are implemented, too bad. Apple doesn't document the internal functions of Carbon or Cocoa.

What you are asking for is for all internal functions to be public APIs, which is just pure idiocy.

Reply Parent Score: 0

RE[6]: Outrageous
by rhavyn on Sat 15th Jul 2006 05:14 in reply to "RE[5]: Outrageous"
rhavyn Member since:

What you are asking for is for all internal functions to be public APIs, which is just pure idiocy.

Now I'm sure your going to explain which part of, for example, SMB is an "internal function" and thus shouldn't be documented. Because you do know that what they're supposed to document is the protocols used by Windows clients to communicate with Windows servers, right?

Reply Parent Score: 5

v RE[7]: Outrageous
by MollyC on Sat 15th Jul 2006 12:40 in reply to "RE[6]: Outrageous"
RE[6]: Outrageous
by Moulinneuf on Sat 15th Jul 2006 05:51 in reply to "RE[5]: Outrageous"
Moulinneuf Member since:

Microsoft get fined for no reason and they are complying with the courts.

- Bulshit.

Microsoft as interoperability problem with other because others are incompetent and Microsoft is Open.

- Lie.

Its you who dont make sense at all and is making up pure idiocy.

Reply Parent Score: 2

RE[6]: Outrageous
by kaiwai on Sat 15th Jul 2006 05:55 in reply to "RE[5]: Outrageous"
kaiwai Member since:

What you are asking for is for all internal functions to be public APIs, which is just pure idiocy.

Bullshit; the request is that they document their API completely - not half done, as with the case of the MSDN documenetation.

If Microsoft fully documented their API's, then wouldn't it stand to reason that Wine would be complete already?! I mean, all the information would be there, there would be no poorly documented calls, and all would be well.

Wine's completion is hampered by poorly documented API's that are either incomplete or haven't been kept up to date with the various changes they've made with each release of Windows.

The EU don't want complete documentation of the kernel and so forth; they want all the publicly API's to be fully documented, and for formats and communication protocols to be fully documented to allow improved interoperability with not only competing operating systems but to allow all developers to be on the same level playing field when it comes to software development for Windows.

I'm sorry, but does Microsoft compete on the product itself or whether they can create a document or communication protocol that no bugger can re-implement; maybe you firstly need a lesson on developing a product, and secondly, a good lesson on EU competition legislation.

Edited 2006-07-15 05:55

Reply Parent Score: 2

RE[7]: Outrageous
by MollyC on Sat 15th Jul 2006 13:05 in reply to "RE[6]: Outrageous"
MollyC Member since:

You clearly have no idea what the EU case is about. It's not about "fully documenting public APIs ... to allow all develoopers to be on the same level playing field when it comes to software development for Windows." It's about allowing Windows clients to communicate with non-Windows servers as if they were in fact Windows servers. That's it. Don't try to broaden the case to fit your own agenda.

The Windows public APIs are documented just fine. Much better than Apple's documentation, I might add (particularly the horrible Cocoa documentation; well, even the Carbon documention is lacking; you have to go to the header file to get real info on the Carbon Event Manager, as the actual documentation is vague and shallow).

It's amusing that there's all this Windows software being developed, and you guys maintain that the APIs are documented.

As for Wine, no it does not stand to reason that the reason that Wine isn't fully working is due to the public APIs not being fully documented. What I mean by that is that the documentation is sufficient for apps making calls on it; whether it's suffucient for reimplementing the APIs inmdependently is a different matter, and expecting such documentation is unreasonable and naieve.

For example, maybe a particular public function causes a series of Windows messages to be sent to the caller, but those messages are side-effects of the implementation that might not be directly related to the call itself (maybe the public function called a series of internal functions that happen to send those messages). You would demand that every message generated, and the order in which they are generated, be provided as part of the documentation of that public function. The documentation would become so bloated as to be unusable. Also, Microsoft couldn't change the implementation in the future, since so much of the internals would be documented for public use.

Let's take Apple as an example (just to move this away from Microsoft). They have the AppleEvent Manager, and it's documented. Do you really think that one could just independently implement the AppleEvent manager just based on the APis such that one could rip out Apple's implementation and replace it with your own, without any hiccups? And if not, then you'd say that the API isn't fully documented, right? Yet thousands of apps use the AppleEvent Manager. They don't need to know how it's implemented.

Reply Parent Score: -1