Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Paddington Thoughts

Paddington Thoughts

  • Comments 31

The other day, I mentioned I got sucked off on a high priority project shortly after I returned from my vacation.  I was asked to help out with the EU protocol documentation effort, working on a couple of the documents (based on some stuff I did back when I worked in the Lan Manager group).

I'm pretty darned proud of the work that the people on the documentation team have done - the specifications that were produced are really quite impressive.


But what most impressed me the most was the amount of work that the people working on this project have spent on it - I just got roped in to help with the final push, but some of those people have been working 16 hours a day, 7 days a week for months and months on this stuff. 

The level of dedication to this project that I saw was as much or more than I've seen on ANY other Microsoft project.  These guys figuratively worked their fingers to the bone typing up documents - countless late hours spread across the entire team.

In particular, the work of Henry Sanders, Iain McDonald, and several others was absolutely heroic.  Henry personally reviewed and provided technical feedback on every single specification that was submitted to the EU.  For the specification I wrote, there's no way that it couldn't have been completed without Henry's insightful comments and the invaluable help of David Kruse (he's the guy who's currently responsible for networking code I wrote back when I was on the NT networking group), and of course Veronica Skeels who made all the words I wrote look professional.

I'm not going to say one word about the politics of the EU documentation work, I just want to recognize the truly remarkable work and the heroic effort that was done on the project.


  • Dan Glick: I quite like Bill G, has done a lot of good with his dough; let's equate him with the Iraqi Information minister instead. Now, I guess that leaves whispering Ballmer...
  • I think it's a great example of the motivation you can get by applying stupidly high levels of pressure to employees. I assume Microsoft has some process for identifying that tiny fraction of people who can produce effective intellectual work for more than a few hours a day, a few days a week? Or is this just another example of the "stupid" I noted above, where people work really really hard, really really dumb, rather than taking sensible breaks to revitalise themselves?

    I admit that there may be people who can be productive and effective 16/7 for long periods, it's just that I've never met one and I've only read second hand reports of them.
  • Larry, sorry if it looked like I was going into the political side of the EU/MS mess. I only mentioned that as it _is_ the catalyst of the potentially good thing to come - the actual documentation. The remainder was really just blowing of steam (sorry about that), but Azrael did notice the meat I inteded with my post.

    The reason I think this documentation is needed - and if the only way to get it is to force MS to produce it by fining the company billions of dollars, then by $DIETY that's the way it has to be, and it's then by MS's choice - is that MS with its virtual monopoly (or oligopoly) is in the unfortunate situation it simply must do this.

    But let's take a step back and look at the bigger picture. ALL other communication protocols with mass-acceptance are 100% specified. IP? Check. TCP, UDP, ICMP, IGMP, ...? Check. NFS? Check. SMTP, UUCP, POP3, IMAP, HTTP, IRC, ...? I simply can't come to think of _any_ major communications protocol not publically specified, except for the obvious: SMB and all the RPC interfaces required to properly use it/them (without crashing the MS servers - but that's another discussion).

    This complete lack of correct specifications has hurt Microsoft, but more importantly it has hurt users in the millions. One can say a lot of things about "Microsoft opening up with CIFS" in 1997 or whenever it was, but I believe "running like a bat out of hell out of there" nicely sums up my observation after dumping the incomplete "documentation" on the MS FTP servers.

    Heck, Larry, you yourself had a post not too long ago how this hurts MS in that NAS-servers had an "issue" due to SAMBA not having access to correct documentation, why Longhorn might have to do some messy stuff to get that "fast"/"batch path" of FindNextFile (IIRC). If such an obvious display is not enough proof of how this hurts even Microsoft itself, and again not to mention millions of customers...
  • "some of those people have been working 16 hours a day, 7 days a week for months and months on this stuff."

    That is a really, really bad idea. It reminds me too much of when I worked at Adobe and we would be in the "death march" for nearly a YEAR before an Acrobat release.

    Nobody could ever pay me enough to go back to that again.
  • Michael, I spent 3 years being 3 months away from shipping NT 3.1.  I really do know how that feels, and it SUCKS.

    Mike, I know from hard experience that you CAN'T write an interoperable POP3 server by following the POP3 RFC (most clients don't bother to follow the specification).  The same is true for SMTP (for example, as far as I know, the MX resolution logic isn't correctly documented anywhere, except for the code that originally implemented it).  The Exchange 5.5 IMAP server had at least a half a dozen tweaks to work around interoperability problems in various clients caused by subtle inconsistancies in the protocol specification.

    Even after 8 years of trying, there's no standards track NNTP specification (usenet).  The only specification is RFC977, and that is horribly out of date.

    So yes, there are many INTERNET protocols that are standardized.  But there are many others that either are not, or have significant interoperability issues.

    That's the last I'll say on the subject.
  • Larry, I appreciate you want to try to stay out of it. Still, those were just some minor examples, and the crescendo was with SMB, and you yourself noting a few entries back that "Uhhh, dudes, we've got an SMB problem".

    That you use other protocols to display "See, see, these too are not 100% specified!" only displays your deperation in finding something else to blame to draw away the interest from the issue at hand. I believe Freud explained it better than I can do - but I leave that to the interested to find.

    Again, I can appreciate if you are even completely uninterested in the other protocols, but that should in this context obviously be seen as, at most, sidenotes in this context. Even if not, at least they tried!

    If you're opposing even commenting on SMB (+ added RPC interfaces) when you yourself noted the *CURRENT* problems for Longhorn a few posts ago - problems manufactured by MS not having produced correct and available documentation - just say so. But please, don't give me none of that bullshit that this would be an EU-political issue. This is all a technical issue, in Microsofts own hands, and the problem with SMB Vista/LH interoperability with "cheap" SAN-"server" was just one (of many to come?) "What goes around, comes around".

    I can't say for certain that "Had MS documented the protocols involved, they wouldn't be eating their own feces now", but "confidence is high" to borrow from Wargames.
  • Hi Larry,

    will these documents be avaliable for mere mortals like me or is this going to be stuff that only big companies or MS competitors will get if they pay enough? Will it be something that is going to be available for download in the near future?

  • It's a cool thing that it's finished! Now, where can we get a copy?
  • Let me start with a nugget I found in the Linux cookies data file...

    Arnold's law of documentation:

    - Where it should exist, it doesnt
    - when it exists, it is out of date.
    - only documentation for trivial or unused programs transends the above two laws.

    Now, of course it is not as bad as the 3rd law, because there might be exceptions to it.

    My point was - sure, documentation for these existed at some point. However, documentation did not keep up with all the bugfixes, feature requests and all other stuff that causes implementation to change. And nobody had the clairvoyance to know that 10 years down the road, somebody with a bigstick would be asking to see the documentation.

    So, gentlemen, yes, sometimes specifications dont exist. Or even if they do, they are horribly out of date. Of course there are exceptions like TCP/IP etc, but I daresay MS is not the only (or last) company that has a gulf between design and implementation.
  • Monday, July 31, 2006 3:02 AM by Feroze

    > Arnold's law of documentation:

    Sure, but the code is the documentation.  In Linux that part of the documentation gets released.
  • Stefan: No, these protocol documents will not be available to 'mere mortals.' You'll have to license the protocols from Microsoft, which presumably will require a royalty payment and an agreement that the details of the protocol are not disclosed to third parties (after all, if a licensee were to disclose the protocol to a third-party, Microsoft could not then license to that third party and could not obtain a royalty payment). This is of course incompatible with Microsoft's competitors' business models, which are to exploit Open Source to avoid having to do the work in-house - the Open Source licences would require that the protocol was disclosed in source form, specifically disallowed by Microsoft's licence terms. It's an impasse.

    The European Commission has been demanding that Microsoft make the licence terms more favourable to Open Source use, but Microsoft cannot do so without completely forgoing the revenue stream. However, the Commission cannot mandate that Microsoft make the protocols freely available because that would effectively be theft, and would not stand up in the Court of First Instance (well, I suppose you never know what a judge will say, but I think it's highly unlikely).

    Microsoft's competitors have so far generally refused to do either of the things generally accepted when you want to be compatible with an implementation of something: licensed the specifications from the original designer, or reverse-engineered the specification. It's what many groups at Microsoft have had to do in the past: the original Windows NT NetWare client, where Novell refused to write one; WordPerfect document import and export in Word, Lotus Notes connectors for Exchange, I'm sure there are many other examples. With reverse-engineering, you run the risk that you've made a mistake or that you're being compatible with a bug and when the bug is fixed your code will no longer work.

    Windows client operating systems have always been extensible. If a competitor wants to use their own directory services scheme or network file sharing semantics, they've always been able to add these capabilities to Windows.

    As for the idea that source code is documentation - it's in far too great detail, and it only gives you what the code currently does do, not what it was intended to do. In some cases differences between code and specification are corrected by modifying the spec, but generally it's considered to be a bug in the code. Good documentation gives you a proper overview of what's meant to be happening.

    Other Mike: even if the specification had been available, the bug may well still have occurred. My understanding of it is that in response to the initial 'fast directory search' request, the buggy server responded with the first set of results and a success code, but when the client asked for the next block, it then erroneously reported that the command was not supported. That cannot be a misinterpretation of what's going on. It's a bug.
  • EU simply wants to delay Vista. ;)
  • "16 hours a day, 7 days a week".  

    This is a death march, and I feel sorry for two groups of  people
    (a) those on the death marcher
    (b) the poor people who'll have to try and read documents written by tired people working day after day.

    I'm not anti-Microsoft, I make a living working with Microsoft products like Excel, VB and SQL Server, but a death march to meet a deadline is not the right way...
  • Mike Dimmick said:
    > ... the Commission cannot mandate that Microsoft make the
    > protocols freely available because that would effectively
    > be theft ...

    When a court imposes a fine, is that a "theft" of the criminal's money?  When you're convicted of a crime, you should expect to be punished.  Having your life, liberty, or property taken away by force are the usual punishments.
  • funny ringtones
Page 2 of 3 (31 items) 123