Developers As Pawns and One-Night Stands 268
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.
tagged as Duh! (Score:4, Informative)
Re:Stupid-ass Question (Score:4, Informative)
The original example from Win 3.1 that's always talked about is a certain timer function. The function that would provide timers to programmers could fail with insufficient resources, and you had to code around that. MS had an API, not in the documentation, used in Office, that would return a timer no matter what. They never had to code the error condition, where everyone else did.
Re:tagged as Duh! (Score:5, Informative)
FoxPro was initially developed in a cross-platform manner, by a different company. Also, the team inside Microsoft that eventually took it over was separate from the MFC team. There's really no reason why you should expect that all of their custom controls should be made available as part of a library. It's not like they wrote to some hidden high-quality grid control in the MFC that wasn't exposed to non-Microsoft developers - they just built a better grid control using the same interface that was exposed to everyone, the same way you'd have to if you wanted the same functionality. I've seen some code for the grid control of another MS product, and it is pretty much straight to Win32 drawing calls, event handling, etc. It looked like it was very painful to get right.
Of course, I'm personally of the opinion that MFC is total crap, but then again I've been spoiled by well-designed libraries like Qt.
Re:It's just the name of the game (Score:2, Informative)
Java?"
Well yes, in a Word. For one thing Java has never really been controlled by a single vendor and the JCP, for all its faults, has worked pretty well for around 10 years now.For another the source for much of Java has always been visible and available and clearly specified. And finally whilst Microsoft deliberately keeps parts of the Windows API hidden from developers to give it an edge, the same has never been true of Java.
Re:Interesting stuff... (Score:2, Informative)
Re:Stupid-ass Question (Score:5, Informative)
Microsoft actually had two layers of API. There was an internal API used by other Microsoft employees, and the public API advertised and documented for other devleopers to use.
There were several articles in Dr. Dobb's Journal detailing diferences between the APIs, written by people who were trying to tear under the hood in ways Microsoft STILL describes as criminal.
Some of the public API structures did nothing but rearrange the arguments, call a delay timer, and then call the internal API. Seriously.
The material described in these articles was part of the first big push about Microsoft abusing it's monopoly position. After all, people were builidng proof that Micorsoft was specifically making it impossible for anyone to write applications that could finction as cleanly, quickly, smoothly as Microsoft's own, or that could even be as small as Microsoft's own. They used the natural OS monopoly to make it impossible to compete fairly in the application market for that OS.
I wonder why Microsoft calls the efforts to uncover the API differences criminal?
And for those who want to call this blatant Microsoft bashing, go check Dr. Dobb's Journals from the early Windows 3.1 era for yourself. I don't have to make this up. The facts do more bashing than anything I could make up.
Re:Stupid-ass Question (Score:3, Informative)
Well, AFAIK, Microsofts own apps do use the windows API, but the published Windows API (available and recommended for use by third party devs) is only a subset of all that's available.
People are crying foul because some of the hidden stuff is quicker/easier to use/more reliable than the published stuff thereby giving MS an advantage when developing its own apps over a 3rd party doing the same (1-2-3 vs Excel for instance) AND making it much more difficult to produce an API call conversion layer (like WINE) on a non-windows platform which will acurately and completely run MS windows apps.
The only reason I can think of as to why they wouldn't publish the full API is that the hidden parts are unstable and subject to frequent change - which can't be true when they're using those hidden features in major business applications.
(Although that might explain the trainwreck called Lotus Notes.)
No it wouldn't.
Re:Woo (Score:5, Informative)
their api's. This fact has been brought up in court numerous times. Just recently they tried to hold
back the security api until it became public they where doing so. If it was just a conspiracy they would not be having to produce a actual published api for the EU.
When you develop software for windows you are coding on a platform owned by your direct competitor. The fact that they hold back stuff for internal use should really be no surprise.
ARTICLE MIRROR (Score:1, Informative)
Eric Lai
January 08, 2007 (Computerworld) A Microsoft Corp. technical evangelist referred to independent software developers writing for Windows and the company's other software platforms as "pawns" and compared wooing them to convincing someone to have a one-night stand, according to testimony presented Friday against Microsoft in an ongoing antitrust case in Iowa.
"If you've ever tried to play chess with only the pieces in the back row, you've experienced losing, OK, because you've got to have those pawns," James Plamondon said in a Jan. 16, 1996, speech to members of Microsoft's developer relations group. His comments were part of a transcript presented as evidence in the Comes vs. Microsoft Inc. class-action lawsuit in Iowa.
"They're essential," he said about software developer pawns, according to a transcript of his remarks. "So you can't win without them, and you have to take good care of them. You can't let them feel like they're pawns in the struggle."
In the speech, entitled "Power evangelism and relationship evangelism," Plamondon continued: "I mean, all through this presentation previously, I talked about how you're using the pawns and you're going to screw them if they don't do what you want, and dah-dah-dah. You can't let them feel like that. If they feel like that, you've lost from the beginning.... So you can't let them feel like pawns, no matter how much they really are."
Plamondon a technical evangelist for eight years at Microsoft, did not return an e-mailed request for comment.
The excerpt was presented during testimony by Ronald Alepin, an expert for the plaintiffs in the lawsuit, who allege that Microsoft charged higher prices to Iowa consumers as a result of illegal monopolistic behavior. The suit seeks $330 million in damages.
In other comments about developers, Plamondon equated working with them to taking someone out on a first date. "It's like you're going out with a girl; forgive me, it goes the other way also. You're going out with a girl, what you really want to do is have a deep, close and intimate relationship, at least for one night. And, you know, you just can't let her feel like that, because if you do, it ain't going to happen, right. So you have to talk long term and white picket fence and all these other wonderful things, or else you're never going to get what you're really looking for."
The plaintiffs have created a Web site [iowaconsumercase.com] that includes transcripts of testimony presented in the case.
Other evidence presented last week included an internal Microsoft memo from Oct. 18, 1991, entitled "Excel brainstorm group." Brad Silverberg, then-head of Windows development, wrote "I'd be glad to help tilt Lotus into the death spiral. I could do it Friday afternoon, but not Saturday. I could do it pretty much any time the following week."
Lotus Development Corp.'s 1-2-3 was the dominant spreadsheet program on Microsoft's DOS operating system in the 1980s, but it lost ground to Excel on the Windows operating system.
Alepin, a former chief technology officer at Fujitsu Software Corp. and currently a San Francisco-based adviser for high-tech law firm, Morrison Foerster LLP, testified that 1-2-3's eventual demise was caused in part by Microsoft encouraging Lotus' programmers to use Windows application programming interfaces (API). Microsoft Excel's own developers had already decided those same APIs "were not worthwhile using because they were complicated," he said. "They used large amounts of memory. They were slower than other ways of doing it."
Alternative APIs, Alepin testified, "were not provided to Lotus and to other companies like Samna [maker of Ami, a GUI-based word processor later bought by Lotus, that was released a year before Word for Windows 1.0]."
The Comes vs. Microsoft trial, which began in early December, is expected to last up to six months. It, along with a lawsuit file
Re:News flash - sky still blue! (Score:5, Informative)
Many organizations work with contractors because it's easier to hire and release a contractor than it is to hire and release a full-time employee with positional power. With contracting, there's typically a trial period during which the organization has made no guarantee of your employment with them. So the contractor benefits from higher wages, and the organization benefits from one less salary commitment.
Re:Woo (Score:5, Informative)
Re:Undocumented APIs (Score:4, Informative)
The way to be sure would be to take every executable file (.exe,
Re:Woo (Score:2, Informative)
Re:Stupid-ass Question (Score:5, Informative)
Re:Woo (Score:3, Informative)
I've never seen confirmation that MS apps make any significant use of non-documented OS APIs. The Office group writes much of their own code to be sure, but most of the big players do that.
It is easy enough to use a dependency checker and find all the symbols that a program imports from a DLL. If you cross reference the imports with the documentation in MSDN, it is easy to spot something that is not documented. Given all the axes to grind out there, I can't believe someone hasn't done this already, and I dont recall reading about all the incriminating evidence that was found.
A more plausible claim, and one much harder to prove or disprove, is that the Office team has access to Windows source code, so that rather than creating something from scratch they can just grab a copy of the menuing code and create their own version.
Re:Woo (Score:3, Informative)
Re:tagged as Duh! (Score:3, Informative)
There ARE APIs in the core windows DLLs that are undocumented. But those are for use by other parts of windows and are not used by MS application products (I havent seen any use by microsoft products)
Re:Woo (Score:5, Informative)
While I agree with you that the current Office developers are simply good and talented coders and aren't simply leeching off of some undocumented API for their spiffy graphics, it's long been alleged that Microsoft has used undocumented APIs for Office. While I can't find the cite, I believe this was a key part of the anti-trust lawsuit.
You can see "documentation" for many of them on the Sysinternals [ntinternals.net] site. One thing I'd warn against is actually using these calls in production code. Undocumented means unsupported -- MS could decide tomorrow to yank these in their next XP hotfix, and your code would be left hanging high'n'dry. 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.
Re:Woo (Score:5, Informative)
Re:Lotus Notes DOA anyway (Score:3, Informative)
Re:Undocumented APIs (Score:3, Informative)
this would be similar like calling every application developer that runs on windows a "windows developer".
if you were a kernel developer, your driver would be in kernel, and it would be updated for most changes, at least so i've heard.
as for what benefits not-fixed abi/api gives...
i think http://lwn.net/Articles/159313/ [lwn.net] has it quite well put (also see comments).
rephrasing what i can remember now (that article probably contains even more) in regards to benefits - but i'll list benefits from a user viewpoint, not a kernel dev viewpoint, where benefits are quite obvious.
- faster, a lot faster fixes than for closed-source drivers;
- fixes at all. a lot of vendors just don't fix some problems;
- no need to toss out hardware because vendor has decided to stop supporting it (which happens pretty fast in most cases);
- faster driver availability for new kernel versions (no need to wait for nvidia, for example, to release new version);
- availability of new functionality (like power management and probably a bunch of other things);
- i suppose also changes that improve security, stability & performance are easier to make.
- driver availability on other architectures (maybe less important for average user, but there were some problematic drivers on amd64 - and i suppose, having usb hw work on some more exotic hw would significantly ease the quest to build home complected low-heat and silent media computer, for example)
- much better support (vendors tend to be less interested how their product works than most kernel driver devs) and bigger chances to diagnose the problem - solving problems with proprietary kernel modules is no fun...
and a bigger flexibility and better maintainability of kernel drivers gives kernel developers more time to work on other issues, which in turn give users a lot of indirect benefits
so, is your inconvenience (as a proprietary kernel module developer) less important than real kernel developers' and users' (read - _my_
proprietary hardware drivers are bad for users in longer term than "now", so if some aspect that is convenient for kernel developers also works as a motivator to get drivers in kernel - well, that is another one good thing.
it's not like hw developers will run screaming in joy to write closed drivers if abi/api is made stable. those who are interested, write either closed or opensource drivers anyway, for others a decision like that is more political than technical (actually, providing one or two interested developers with reference hw and documentation would in most cases turn out much better drivers for much less money spent
Re:Undocumented APIs (Score:3, Informative)
I don't see what the problem with OpenAFS is. Either it's GPL-compatible, in which case it can be included, or it's not, in which case it can rot.
Re:Woo (Score:3, Informative)
Ok Windows fan boy, chew on this a little bit..
In its Findings of Fact, the District Court found that Microsoft had repeatedly withheld such information from ISVs, or used its disclosure as an incentive for 'friendlier' behavior, in an effort to preserve the applications barrier to entry (Findings, 84, 90, 91).
The rest I am not going to bother addressing, go back to playing with your rental operating system.
Re:Undocumented APIs (Score:2, Informative)
It's their right to change the API whenever they want to, as it is Microsoft's. I've written drivers for windows as well, and the kernel API for windows is much better than the linux one. It rarely changes, except between major releases of the operating system and small security updates.
VME-bus driver (Score:2, Informative)
Kroah [kroah.com] on obscure drivers not being accepted: Possibly your situation is more of a legal problem than it is a technical one. If such a VME acquisition driver is technically feasible, as well as preferable to hacking against a moving target, that is.
The actual recollections of someone that was there (Score:2, Informative)
Re:Undocumented APIs (Score:2, Informative)
Now you listed 2 possibilities so far:
1) Submit the driver to the kernel maintainers
2) Buy another OS
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.
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.
It seems like there is a 3rd solution that solves everyone's problems:
3) Make a stable kernel API for drivers
Kernel maintainers won't need to maintain drivers at all. Third parties can work with custom harware more easily. 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? Don't do something that benefits me, because it might benefit my enemy?
Re:Woo (Score:3, Informative)
But