Sure, all programs would continue to be written for the Win32 API. So what??

Here's the catch... you can run it on a free operating system! Guess what happens then... MS looses their ability to force OEMs to install MS Windows and MS Office together on all PC's. Then bingo - no way to maintain monopolies in other markets by leveraging the monopoly in the OS market. They might even loose the OS monopoly.

And if users don't want windows, they can choose Linux. If they don't want MS Office, they can run any alternative like StarOffice. And guess what... MS can't do anything about it. They want to raise the price of windows if the OEMs don't install MS Office? No problem, the OEM switches to linux and offers a lower priced PC! They can pass the cost of MS Windows to the customers that choose it.

THAT's the difference between Linux and OS/2. If OS/2 was free, and free of MS proprietary licensed code, we'd all be running OS/2 now most likely, or MS Windows would also be free, or A LOT CHEAPER to be sure.

Perhaps this one thing would be all the remedy we need.


But you've defined the exact same role. "Open sourcing the api" is somewhat meaningless. The Win32 API is so convoluted that merely documenting it isn't enough. (but it would be a nice start).

Microsoft has historically documented much of Win32 - but kept "secrets" as to the "best way" to do things. The only way to prevent that, would be to force all of Winddows to be released (not likely)

And then it *still* has the possibility of changing *every patch release*. Sure, Ok, here's the source, have fun.

You've got to deal with that possibility - merely forcing documentation of the API isn't enough. Either you need a structural remedy such to force prompt and efficient documentation and explanation, or you need a conduct remedy for that.

I think you also forgot part of my remedy proposal:
"Any future API calls must be documented immediately and the Wine project notified 6 mos before any code is released into the market."