Developers As Pawns and One-Night Stands

jcatcw writes "At the Comes vs. Microsoft antitrust case, last Friday's testimony included evidence that James Plamondon, a Microsoft technical evangelist, in a 1996 speech referred to independent software developers as 'pawns' and compared wooing them to trying to win over a one-night stand. Last week's proceedings also included testimony by Ronald Alepin, a former CTO at Fujitsu Software Corp. and currently an adviser to the law firm Morrison Foerster LLP. He said that Lotus 1-2-3 was killed, in part, by Microsoft encouraging Lotus's programmers to use the Windows API even though Microsoft's own developers found it too complicated to use." The plaintiffs have created a site that includes transcripts of testimony presented in the case.

Stupid-ass Question

[Blakey Rat]

If you're writing an app for Windows, what is the alternative to using the Windows API? How could Microsoft develop Windows applications without using the Windows API? Was Lotus seriously considering developing Lotus 1-2-3 in Java? (Although that might explain the trainwreck called Lotus Notes.)

Re:What's The Big Deal

[a_karbon_devel_005]

ISV's are, in essence, Microsoft's customers. RMS is not a customer of Microsoft. That's the difference, really.

This is Microsoft employees saying their customers, the ones they're supposed to be developing good API's and such for, are pawns and they should never be catered to.

Re:It's just the name of the game

[biz0r]

Correct and thats one of the big reasons OSS is so appealing and works well...it removes that 'tie in'.

Re:Woo

[Anonymous Coward]

What more tools than a programming language, and an API for basic operations, are really needed? Office looks the way it does, and has as many features as it does, because MS spends a significant amount of money developing it. Give any other software program the resources used to develop Office and I am sure that it would look 'modern' as well - no matter what API is used.

Re: Removes it???

[rowama]

OSS doesn't remove tie-in, it adds more. Rather than being tied to a single company, OSS may be tied to more than one company and/or a large population of independent developers. So OSS removes the single point dependency.

Re:Stupid-ass Question

[Anonymous Coward]

I really don't see how it even matters. It's Microsoft's OS, they can do what they want with it.

No, they can't - not while they are monopolists. That's they way the anti trust laws work.

Re:And this is relivant because Anti-competitive.

[Vellmont]

Probbably because tricking developers into using the Windows API, (which Microsoft knew to be problematic) is a part of Microsoft's anti-competitive behaviour. Anti-competitive behaviour isn't illegal unless you're a monopoly like Microsoft is. The article references Microsoft encouraging Lotus to use the Windows API, and claims that contributed to the decline of Lotus 1-2-3.

Re:News flash - sky still blue!

[OneSmartFellow]

You are simply deluding yourself, to your employers delight, that you as a permanent employee, have any more job security, or value to the company, than a contract programmer.

I have survived several RIFs in some large banks as a contractor, while FTEs I sat and worked with were let go.

Contracting is a much more honest relationship between employer and employee. I don't work, they don't pay. They don't owe me anything, I don't expect anything from them. I don't put up with the corporate bullshit, they don't expect me to. When I work overtime, I get paid. I don't 'request' time off, I inform that I won't be in. I don't have to fit in to any corporate team bonding excercise, although on the occasions I do attend, which usually involve lots of beer, I am heartily welcome.

And I take home about 50% more than similarly employed FTEs in the workforce.

Re:Woo

[MobyDisk]

Looking at your resume [googlepages.com], you haven't done much Windows API work, and in 1996 you hadn't done any. So let me correct a common misconception about Windows API programming:

There is no reason that someone else could not make controls that fade in with graphics and color menus. No secret Windows APIs are or were required to do this, even at that time. Windows has always allowed applications to draw whatever they want in their windows, and that includes transparency and fading. The win32s extensions [wikipedia.org] for Windows 3.11 even offered support for non-rectangular windows. Even easier, Microsoft licensed their Office controls to applications developers who wanted to do it. There are no special undocumented API calls required to do this stuff.

Re:Undocumented APIs

[oliverthered]

someone would still have to write parts of the modules every time the ABI. That's not one of the benifits of having the modules included in the Linux kernel.

Re:Undocumented APIs

[cduffy]

Remember, he's not in "GPL hippie-land" -- so inclusion upstream isn't an option.

That said, I think the whole GPL-only symbols thing is stupid, myself -- it means that Free-but-non-GPL projects like OpenAFS get hamstrung.

Re:Undocumented APIs

[vertinox]

Maybe a stable (and available to us that don't work in GPL hippie-ville) API is needed

BSD?

Re:Undocumented APIs

[dwheeler]

There's a standard way to eliminate the rewrite: get the module into the kernel, where others will help maintain it. The kernel _HAS_ a stable API - it's the interface to userland. The kernel also has a standard way for drivers to interface with other drivers - it's submitting source code. In other words, there _IS_ a standard internal API for kernel modules; it's called "C".

Clearly, you want to have a proprietary driver. Thus, you want to do something that the developers have ACTIVELY and CLEARLY stated that they are working against, and give no quarter for. You obviously don't like that, and that's your right. But you didn't write their code, nor pay for it, so they are not responsible for your desires... and that is their right.

This is very different from the Windows situation. Microsoft has kept some APIs quiet, and even the very existance of some APIs. In contrast, this Linux kernel policy has been clear for over a decade. You may not like it, but you have no right to complain; this policy was certainly there before you decided to write a line of code. As long as an organization makes clear what the rules are, then you try to work against them at your peril.

Yes, a stable internal API of the kernel would be a possibility. Windows, for example, has one. But most Windows crashes are from BAD DRIVERS; the drivers cannot be fixed, and the Windows interface can't be fixed either. That's not good evidence that this would be a GOOD thing for users. The reliability of Linux is actually pretty good evidence that their process actually works better for end-users.

Unbelieveable

[t'mbert]

None of these API's just fell out of the sky and landed in Microsoft's lap; they were built tediously and at great expense. And let's not forget that these are not the types of functions that are really making Microsoft top dog. Microsoft is top dog due to social and business factors, not API's and technical ones.

Funny that there are endless discussions about the poor technical quality of Microsoft's products, and at the same time rants that Microsoft is gaining an unfair advantage via technical means. Either the technology is good or it's not. If this case is valid, then we must also acknowledge that Microsoft's technology is king too.

Closed Linux drivers are distributed all over

[Anonymous Coward]

And drivers are kernel modules.

Using a GPL "Bite me, RMS" module to re-export GPL symbols with "EXPORT_SYMBOL" instead of "EXPORT_SYMBOL_GPL" is perfectly legal. GPLv2 doesn't say "You can't use EXPORT_SYMBOL in GPL kernel modules, you must use EXPORT_SYMBOL_GPL." And IIRC Linus himself has stated that GPLv2 will remain the kernel license.

So "EXPORT_SYMBOL_GPL" is completely useless. It doesn't prevent closed-source drivers from accessing GPL symbols, because those proprietary drivers can access those symbols using another module that is GPL. And that second module is trivial. Who cares if it's GPL'd and distributed? It doesn't do anything other than export symbols that everyone who can understand source code already knows is there anyway.

Re:Woo

[Foolhardy]

Even Microsoft documented at least one! Here's a comment in the Win2K source code that got leaked onto the net a few years ago:

private\mvdm\wow32\wcntl32.c: // These undocumented messages are used by Excel 5.0

Wow32 is Windows on Win32, i.e. the Win16 API. Excel 5.0 was released in 1993. Microsoft wasn't an OS monopoly in 1993. Your one example is 14 years old-- too old.

You can see "documentation" for many of them on the Sysinternals [ntinternals.net] site.

For one thing, that site is from ntinternals.net by Tomasz Nowak, unrelated to Sysinternals [microsoft.com] by Mark Russinovich and Bryce Cogswell, which was recently bought by Microsoft.

The functions on that site are indeed largely undocumented (many of the functions are officially documented [microsoft.com] as part of the DDK, but only for use in kernel mode). The functions are considered private to the OS. No one is accusing Office or other Microsoft non-OS products from using those functions. They are only used to implement the Win32 API and some system services. I, too wish that they would document those since they are considerably cleaner and more stable interfaces than the Win32 equivalents, but please don't confuse private parts of the OS with special functions for MS applications.

Not that they're likely to do it, but what if one of these had a worm come along exploiting it? The quick and obvious fix would be to simply remove it.

It'd be very infeasible for them to remove any of those functions; they're used heavily inside the OS to get things done. Never has a working function in the native API been removed or seriously changed. It'd be like removing the mmap() syscall from the Linux kernel in response to the mmap() vuln they had a while ago.

Re:Undocumented APIs

[Rich0]

1) I assume that the kernel maintainers won't accept maintenance work for this driver. It would be silly for them to volunteer to maintain everyone else's proprietary software. :-)

But it wouldn't be proprietary if you gave it to them...

2) Buying another OS. Is that really what you advocate? It kinda takes away Linux's reputation as a hobbyists tool if you are suggesting that people not use it if they need a custom driver.

Well, there isn't much point if they're going to keep it to themselves. How many hobbyists need to hang onto the code, and wouldn't donate it back to the kernel team?

And commercial closed-source drivers will be easier to maintain. It seems to me this option benefits everyone - even people you hate. Is this an example of cutting off one's nose to spite their face?

But only the closed-source vendors would be able to maintain it. Suppose I have a TNT2 card - do you think that Nvidia is going to release a driver for it when linux 2.8 comes out?

The idea is to get rid of the closed-source easy-out - which should result in more code being opened. Sure, some code just won't get used at all, but that puts vendors who refuse to open their code at a disadvantage, at least among linux users. And why should Nvidia profit by selling cards to linux users when they don't release their code? The drivers wouldn't work without the kernel, and the kernel was made GPL to force redistributers to release their sources. Now, the kernel won't go GPLv3 anytime soon, but other software will, and future GPL versions will only tighten some of the closed-source loopholes that currently exist.

It has worked pretty well so far. And if somebody wants to make their own middle-layer they can, just don't expect the kernel team to help you out.