Slashdot Mirror
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.
Well I am shock and surprised . Have you noticed that Microsoft products tend to have features that you can't easily program yourself. Say back in the late 1990s where Office had icons next to the menu options and Microsofts Own development tools didn't allow you to do so. Or crappy grid controls or page controls (in which Microsoft FoxPro had much superior ones that didn't appear until .net) MS Developers tools force use to stay 10 years behind the times.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
There the Windows API that's published, and then functions that no one other than Microsoft (and reverse engineers) know about. That's what they're talking about.
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.
You missed his point, and got caught by the simple, common example.
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.
How could Microsoft develop Windows applications without using the Windows API?
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.
It is not really a conspiracy but a well known fact that they do not publish large portions of
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.
Got Code?
I would disagree. Contractors can play a very distinct role: to fill a void (in skills) at a company. If this isn't the case, then they are contracted to fill a void in manpower. Most of the time, however, a contractor is brought on board to lend their expertise to a project.
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.
For he today that sheds his blood with me shall be my brother.
Rubbish, check out owner-drawn menus in the MSDN documentation. THere's nothing to prevent you from doing kind of thing yourself. I've done it.
Actually, most of the nice microsoft stuff (such as e.g. the look and feel in Visual Studio 2005 or in office 2007) is done as seperate code in special dlls (mso.dll in the case of various version of microsoft office for example).
.dll etc) included with a given visual studio version, look at the dlls it loads and functions it imports and identify if it imports a funtion from an os dll that isnt documented anywhere on MSDN.
The way to be sure would be to take every executable file (.exe,
The best way to accelerate a windows server is by 9.81 m/s2
Citations please?
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.
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 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.
John
Even if an API is documented, MSDN is frequently wrong. Just try asking a Wine developer.
Game! - Where the stick is mightier than the sword!