Post a Comment
I guess I missed the part where Pepsi had been analyzing Coke's chemical composition in their labs for decades and had not been able to crack it. Also the part where the Coca Cola's management, employees, and security are such that Pepsi's attempts at corporate espionage had been foiled as well.
So I guess they just have one more alternative:
If it can't be analyzed in the lab, and it's such a secret, do you really want to drink it? Especially when they used to put stuff in it which is now illegal?
I'm not 100% sure what your point is, but I should point out: Pepsi not knowing Coca Cola's secret formula doesn't prevent their products from attracting Coke's customers, and it doesn't affect the customer's ability to drink both brands interchangibly. Businesses can put Coke and Pepsi vending machines side-by-side in their cafeterias without negatively impacting the usability of either machine.
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.
Further, most nations have a regulatory body like the FDA in the US that ensures that products like soda are safe for consumption. If they might not be safe for all people, such as diet sodas with aspartame, they require a standardized warning, such as "phenylketonurics: contains phenylalanine." There is no government body in any nation (that I know of) that ensures that commercial software in safe and secure.
While it is unreasonable to expect Coca Cola to open their formula, it is reasonable to expect them to provide nutritional information, major ingredients, and instructions on how to open the can, if necessary. The same goes for Microsoft.
"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 www.msdn.com. 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.
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?
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
From what I've read, the Windows network protocol isn't so much a "protocol" as it is a bunch of RPC calls
First off, if you don't have any first hand experience you shouldn't comment at all. Second, just because Microsoft chooses a dumb way to implement something doesn't mean they can choose to thumb their nose at a court ruling.
Now do you see how stupid this is?
No, but your explanation of the Windows server protocols that Microsoft were supposed to document is pretty dumb. Here's a little help, if you're sending it across a network it's not "internal."
I'm sure you can imagine the difficulty in coming up with a "public protocol" based on your internal functions; functions that were never intended to be public, and therefore aren't documented in a way that would be suitable for public consumption; functions that are called by the program as needed rather than according to some "protocol".
We're talking about how a Windows client talks to a Windows server. That's the definition of a protocol. You certainly aren't making yourself look smart.
Oh, and the EU guy is full of crap. If the EU's demands were so clear, how come they issued clarified requests in March 2006
Because until then Microsoft hadn't said that they EU's "demands" were unclear. Maybe you should be asking why it took Microsoft two years to decide that the "demands" weren't clear.
Because until then Microsoft hadn't said that they EU's "demands" were unclear. Maybe you should be asking why it took Microsoft two years to decide that the "demands" weren't clear.
If you had bothered to look up stuff you would know that MS have repeatedly requested clarifications since the first time the EU said "this is not enough" and even been refused that for fear that MS would use that in their appeal.
They're not asking for how to do the RPC calls, they're asking what the RPC calls are.
If they've developed a large piece of software with no documentation on the internal API's I'm utterly impressed. Sure, maybe it's all in the source code, but if they had any discipline (which would be beneficial) they could write a program (like doxygen) to pull these comments out for documentation.
Of course, they certainly would need to be scanned, by human eyes, to make sure they're not revealing anything you don't want to tell!
They issued clarified requests and a new timetable at Microsoft's request in an attempt to be reasonable and helpful to them. And, I could be wrong, but I believe "this guy" is in fact a "woman."
http://en.wikipedia.org/wiki/Image:Neelie_Kroes.jpg
(Does that look like a woman to anyone else? end sarcasm)
The fines issued are for the failure of compliance between Dec something and June 20th, which is pretty nice considering it's now July 14th (15th here) and not June 20th. They even dropped the initial fine rate by 25%.
What do you want, for them to say "we're sorry Microsoft, we'll let you go cause it's not fashionable to dislike you anymore?"
I fail to see why these RPC api's should have already been documented. The way it works is that the server team writes a server and some fake clients for it as tests. The client team then writes the client based on the RPC interface (represented by IDL) and finds some bugs in the server, some of which are fixed and others of which are worked around. There are a couple of feature requests for things that the client needs and that's about it. In the end you have a pretty messy API but it all works and with a bunch of testing, you're golden.
Do this for several versions, all of which have fixes in the clients to interoperate with older servers and vice versa, and you get SMB/CIFS. Can you reimplement this? Yes, but why would you want to? You can write your own client/server system to work seamlessly with windows since all of the relevant parts are pluggable.
"Do you know the difference between internal functions and public APIs?"
Sure, but explain to me why it is okay for the Excel team to use Windows "internal" functions that no other spreadsheet vendor gets any information about.
Unless you're of the opinion that Excel is in fact part of the Windows operating system, Microsoft has effectively gained an advantage by using function calls only they know about. The only way they could do this without having their 3rd party developers giving them the fingers is simply the fact that Microsoft are in a monopoly position.
And boy, do they abuse it.
Sounds like a fair advantage. You don't document internal API's because:
1.) They change.
I don't need a number 2, that's simply why you don't give public docs on internal calls, because when you change them you'll anger many people who assumed they were stable.
If Microsoft wants to have the Excel team use internal calls to get a constant speed advantage, good for them! They'll be the only ones in industry who'll be able to easily keep up with the changes to these internal functions.
Fair it is not, nor can it be! But to try to justify with
" 1.) They change"
is an insult to ones intellect. Please refrain from posting such mindless comments. In case that you need facts to rebute your statement (I can't believe I'm doing this)... :
Excell still works even when you don't update it at all while at the same time you upgrade OS (say from Win98 to WinXP) and/or you apply patches and updates.
API's usually don't change, it is their implementation that changes.
What do you mean by "change all the time"? Do they change when a new OS is released, or when they release updates? Besides that, statement that "interfaces change all the time" is completely wrong! If they did you would get a useless computer. IMPLEMENTATION of interfaces might change while the INTERFACES themselves are kept unchanged for as long as possible. And this, dear Molly is what is taught in computer science classes which you obviously skipped. But to get back to the topic, this fine is very well deserved. Bravo for the EU. This just goes on to show that there is something wrong with the US system of lobbying, and the influence of big companies on US legislation. MS has had more then ample time to comply with the ruling, thay chose not to. It is a decision. Good or bad, time will tell. Personaly I think it is a bad one.
Internal API's are usually internal because they're a part of the implementation
. Hence, yes, internal API's change. So, if you don't want to support them, you don't document them!
Believe it or not but Microsoft has everything to gain from competitors building with its libraries and there's no reason for them to try abuse any extra abilities from internal API's to get an advantage. This is especially true in a market where they're the undisputed king of the hill, and for good merit, spreadsheets. They don't even need a speed advantage on Excel, they've got a "it works really well why switch" advantage
.
As for the rest of Office, that might not be so true
.
Please provide evidence that Excel uses internal apis, if you can. And if you cant, don't make the charge. You have no evidence that it does. (Oh, and there's a Mac version of Excel too, do you think it uses internal windows funcions as well?)
And again, the EU case has absolutely nothing to do with your unsubstantiated claims that Microsoft's non-OS programs make use of internal functions.
And your post was actually modded up. What a joke.
I think old office apps like Excel and Word use old, undocumented APIs, but it's usually a case of "this is old cruft that we have always used and we don't want to re-code everything, why would anyone else want to use this?"
What could office want to do for better performance that an internal API would help with? Fast loading in office is achieved by making sure DLLs don't get rebased and delay-loading as much as possible. Once office is loaded, almost everything else is gated by the speed of the person at the keyboard.
Let me explain this to you.
1.) Microsoft is not being asked to open its API's.
2.) Microsoft is being asked for specs on its network protocols.
3.) You can already read all kinds of lovely about Microsoft's Application Programming Interfaces. Its network protocols are another story.
4.) "Open," especially in the context of "Open Source," means to allow others involvement in changes. Much like an "open-minded" person is malleable in their opinion, an open specification (be it software, an API, or a protocol) allows outside groups to contribute. In Unix permissions: Open is similar to rw-, where viewable is r--.
And the Coke ingredients are written on the side of the can, the FDA already requires that. I think it may actually be a decent analogy too! Unfortunately it just doesn't show your side of the argument.
The fact that people have voted your comment up just goes to show that, just like slashdot, first comments always get inflated scores. It's sad really, but there's nothing I can vote you down for (you're just wrong, and that's allowed here).
I'd love you to show how the "greedy bureaucrats" actually get more or less money depending on how much they fine.
I suspect they are *very* well paid whatever they do. Its not like they fine you, and they get to put it in their own pocket.
I suspect it will go in the great big pot where all the rest of the EU's money is drawn from.
[QUOTE] All sane people know that.
But hey, Europe also needs it OJ trials.
[QUOTE]
Apparently all people who know nothing about it confirm the first post. There is a difference between opening up the documentation and opening up the source code, actually MS has opened the source (for the correct fee of course), but the source was not wat the EC was asking for, so they fined MS for not complying.
Here's what Jeremy Allison, of Samba, had to say regarding this matter:
http://www.theregister.co.uk/2002/03/19/why_microsofts_eu_concessio...
"There can't be a specification that's worth anything," says Jeremy Allison, joint lead of the Samba Project. "The source code itself is the specification . The level of detail required to interoperate successfully is simply not documentable - it would produce a stack of paper so high you might as well publish the source code."
Now you see why it's been difficult for Microsoft to document a "protocol" that would satisfy the EU, and why Microsoft offered the source code.
Oh, I also read that the EU is pissed that Microsoft "included [sic] several hundred pages detailing how to handle errors, while failing to document how the errors happen." Look at almost any API documentation, and you'll see that the documentation regarding errors is brief. Errors can happen for any number of reasons (low memory, network disconnects, etc). The idea is for a component to notify the caller of the error by throwing the appropriate exception or returning the appropriate error code, so that the caller can deal with it gracefully, regardless of exactly how the error occurred. Pages and pages on how/why errors might occur is foolhardy and leads to more bloat in the spec. Some errors do need such documentation, the vast majority do not.
All you trollers are the same. You actually managed to miss, in a register article, the followinf sentence :
"There is information that the Samba developers want to see: the IDL descriptions for remote procedure calls".
And even more :
"These IDL descriptions are *key* for providing interoperability with Microsoft clients," wrote the team in a submission to the EU commissioners earlier this year. "If these IDL descriptions were published, open and equal interoperability with Microsoft products would be greatly enhanced (although still not perfect"
These are part of the API we're talking about.
Do you have nothing better to do than trolling really ?
You're so eager to use red herring you can't even check the whole article, or are actually counting on people not reading a link to deceive them.
That's how the MS camp has always been : low and lower.
It's pretty sad really.
you get the idea of a monopoly which apple isn't. I'm sure itunes is already under the radar. And you get the idea that MS was *not* asked to open source anything, just for documentation. I wodner why you people don't get it? It's good for us consumers so why protect MS which takes away our rights every day?...
For anyone it is not clear to: DG Competition is an extremely powerfull antitrust organisations.
To put it in US terms: It can be compared like Microsoft fighting against the FBI. They have been provided with all facilities and laws to fight state backed monopolies, like in the telecom industry. Yes, they can even get governments on their knees.
They impose fines, they forbid mergers, they raid companies their offices. Under commisioner Karel van Miert the DG Competition was overturned in several import cases by the court. The DG Competition was then considered handcuffed.
His successor, Mario Monti alias Super Mario, changed things completely. He strengthened the organisation and put procedures in place that reduced the chances of being overturned in court. He succeeded in passing several EU wide competition guidelines (=laws).
The European telecom and car industry quickly felt the new policy. Not only Monti was extremely active within the EU, he had no trouble starting cases against foreign companies. Microsoft can tell, GE and Honywell can tell, and Nintendo can tell.
Most companies change their behaviour after getting fine. For a company like Nintendo, the 85 million they had to pay was a lot of money. Microsoft has much larger profit margins, so they could affort to toy with the DG Competition.
Even Microsoft is coming to the conclusion that that doesn't work out.
It has not been clear to me what the reason for fining microsoft was. It's not like they were "toying" with the commission. They were told to "provide complete and full documentation" for all their Server-Client protocols. They provided some documentation, which did not meet the approval of the commission. They were given a new deadline and a new process for going forward. The process involves handing documents over in several installments to be checked by the EU's trustee, edited, and then turned in to the commission. MSFT has been meeting all of these deadlines and the documents have been approved thusfar. What purpose does it serve to fine them, when they have been behaving exactly as the commission has ordered them to since it found their documents insufficient the first time?
It should be mentioned that no one has ever in the past been asked to retroactively document a closed source/closed spec interface like this. I'm pretty sure MSFT took the Windows client/server interface to be a completely internal implementation detail. It should also be noted that the interface first came about in the DOS LANMAN days, long before the dominant windows client even existed. In light of Microsoft's behavior, how can a fine be justified?
* Microsoft has been officially warned to open the protocols in August 2001. They ignored the warnings.
* So, they had to be fined. After record fines in March 2004 they had to open the protocols within 120 days. They tried to postpone until after the appeal, but they were rejected it. This was in december 2004.
* Microsoft then published some documentation. It was considered garbage by everyone who saw it.
* The EU then set a deadline in place, the corrected documentation had to be received at 15 december 2005.
* Microsoft did not.
* Microsoft got an extention multiple times.
* The EU send Microsoft a warning of non-compliance.
* Microsoft refuted it and came with silly offers like Windows source code.
* The EU puts the wheels in motion to fine Microsoft again.
* Ultimately Microsoft started to change its behaviour.
I don't think Microsoft has behaved as ordered. They got extenstions multiple times, they did turn in not a single page of documentation. The whole goal of the remedy was to get open documentation that is free of intellectual property issues. Source code won't help here.
The EU concluded that on 20 June, Microsoft was still not compliant. So, they got fined for the period December-June. If they get into compliance after that date, perhaps further fines will not be necessary.
Running = killing themselves.
If they run, competitors will have 100% of the market in Europe. You can guess those competitors will develop any software package there is demand for in the EU.
Of course those competitors will not stay within the borders of the EU. They will actively compete against Microsoft in other markets. Because there is money behind it, there exist enough resources to make the alternatives 100% compatible, making it Microsoft really hard to survive.
Also the EU is Microsoft's largest market, providing 40% of there revenue. No company can explain that to their shareholders.
Microsoft might have been foolish, but they are not that foolish.




