April, 2004

Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    Bonzer mailing list of the evening :)


    I thought I'd put in a plug for one of the funniest mailing lists I've seen in quite a while:  This is true.  Randy Cassingham, the moderator collects unusual stories from around the world and posts them weekly, with insiteful taglines attached.  Valorie got me hooked about a year ago, we're both subscribers to the premium edition.

    Every story on the list is verified to be true.

    One of my favorites is the “honorary unsub“ - it's an obituary for someone who should have been be famous that died the previous week.

    Oh, and he's got an RSS Feed too so you don't need to get even more email :).


  • Larry Osterman's WebLog

    Erroneous assumptions


    Has anyone noticed that all of the Win32 documentation has something like this for each API:

    Return Values

    If the function succeeds, the return value is NO_ERROR.

    If the function fails, the return value is one of the following error codes.




    Something about the ERROR_INVALID_PARAMETER error


    A system error code defined in WinError.h.

     I can’t think of the number of people who have complained about the last line in the table.  Why on Earth can’t Microsoft bother to document the errors returned from this API anyway?  Are they being stupid or something?

    Actually the answer’s somewhat simpler.  We’ve been burned by doing this in the past, and we’re not willing to get burned again.

    One of the pieces of memorabilia I have on my desk is a copy of the MS-DOS 2.0 reference manual (published by Microsoft in 1984).  On page 1-143, near the description of the Create Handle API (the MS-DOS equivilant of open()).  It indicates that the API has the following return values:

                            Carry set:
                                        3 = Path not found
                                        4 = Too many open files
                                        5 = Access denied

    That’s it.  Microsofts (and IBMs) documentation specified the complete set of errors returned by all the DOS APIs.  We told all our customers that the ONLY error codes that the INT 21, 0x3DH API would return are errors 3, 4, and 5.  And you know what?  Our customers believed us, and they wrote their apps with that assumption.

    Well, along came DOS 3.1, which added support for networking.  And with that came a whole host of ways for the APIs to fail.  Things like “Network path not found” (the file is on a server and the server’s down).  Or “Sharing Violation” (someone else has the file open and they’re not letting you access the file).

    Originally, the DOS developers just returned the new error codes, thinking that most app authors were smart enough to realize that there might be other error codes returned from the APIs in the future.  And we started testing.

    And we discovered just how wrong that assumption was.  Apps crashed left and right.  EVERYONE’S apps crashed.  Why?  Because Microsoft and IBM had told them that they would never see any errors other than 3, 4 or 5.  And since RAM was at an absolute premium on these machines, they didn’t waste valuable code space on useless features like error checking for errors that could never ever be generated.  When your app is going to be running on a machine with 64K of RAM, then defensive programming becomes an optional feature.

    So Microsoft invented the DOS error mapping table.  It defined a mapping from all the new error codes into the DOS 2.0 set of error codes.  To find the REAL error code, you called the “Get Extended Error” API which returned you the “real” reason for the failure.

    This table still exists in the Longhorn source tree (just for grins, I looked it up the other day).  It’s in the NTVDM logic, so it’s not a part of any of the Win32 logic, but the bottom line is that it’s still there.  And it’s likely that we’ll never be able to get rid of it (at a minimum, we’re not going to be able to get rid of it until we get rid of the 16 bit DOS support, which isn’t gonna happen anytime soon).

    And ever since then, Microsoft has refused to completely document the error codes from its APIs.  By not documenting the complete set of error codes possible, it moves the onus of handling new error codes from Microsoft to the application author, where it belongs.


  • Larry Osterman's WebLog

    One in a million redux


    I mentioned my “one in a million is next Tuesday” to my wife the other day, and she asked me “So did you include the bit about the PCs clocks?”

    And it hit me that I hadn’t.  Doh!  So here it is.  It’s kinda fascinating actually.

    Time on a PC is kept via counting the number of clock interrupts that have occurred.  Every PC contains a crystal that operates a clock chip that interrupts the CPU approximately every 10 milliseconds. So NT increments the system time by 10 milliseconds every time it receives a hardware interrupt.

    But the problem is that the crystals used internally in the system have a failure rate of as high as 100ppm – in other words, 100 times every million clock ticks, the clock chip won’t actually generate an interrupt.  For most applications, this isn’t a significant problem – instead of the system context switching every 10 milliseconds, every once in a while, the system context switches in 20 milliseconds.

    But for time, this is an utter disaster.  Given a 10 millisecond timer, there are 8,640,000 clock ticks per day.  If 100 per million clock ticks are missed, then that means that the system misses 864000 clock ticks, which is about 864 seconds.  That’s over fourteen minutes per day!

    Now, in practice, the amount of drift is actually much lower, but still it can be quite significant.

    So how does NT fix this?  Well, back in NT 3.1, once an hour, NT would interrogate the on-board real time clock chip (the hardware that keeps your date and time up-to-date even when your computer is powered off).  If the system time differed from the real time clock chip, then it would simply reset the system time to match the time on the RTC.  Which meant that time could jump forward or backwards significantly – so it was possible for the assert to fire in the following code:

                ASSERT(CompareFileTime(&time1, &time2) < 0);

    Clearly this was an unacceptable situation, so something had to be done to fix it.  The fix (in NT 3.5) was to change how time was accounted for in the system.  In the old system, every clock interrupt bumped the time by 10 milliseconds.  With the change, when the system measured the time from the RTC, instead of applying the new time immediately, it calculated an adjustment to the 10 millisecond amount.  If the clock was behind, each tick might count as 11 or 12 milliseconds.  If the clock was head, each tick might count for 8 or 9 milliseconds.

    This is actually pretty cool (ok, I think it’s amazingly clever), but again, there can be problems.  What if you’re using the current time and some high performance counter (like QueryPerformanceCounter)?  Then the clock drift will cause your measurements to be skewed from the real time measurements.  We actually ran into this problem in the SCP project – our clock tests were showing that the clock on the SCP chips was drifting, but we couldn’t see why it was happening – it turned out that the SCP chip clock wasn’t drifting, it was the PC’s clock that was drifting.

    To allow people to compensate for this drift, a new API was added: GetSystemTimeAdjustment.  The GetSystemTimeAdjustment API allows you to determine the clock interrupt frequency (that’s the lpTimeIncrement parameter), and the adjustment that’s applied to each tick (that’s the lpTimeAdjustment parameter).

    Edit: Fixed the result of CompareFileTime.


  • Larry Osterman's WebLog

    You snooze, you lose


    Like most companies, Microsoft has an in-house “newspaper”.  In our case, it’s called the “MicroNews”.  It’s been published weekly every week since I started (I remember one of the articles in the first one I got was announcing that Microsoft had finally gotten large enough to fully occupy the Northup Way building).  It has the usual corporate PR stuff, birth and wedding announcements, pieces about interesting things that employees are doing (there’s a production of The Importance of Being Earnest starting next week on campus, for example).  Basically the same stuff you’d expect in a in-house newspaper.

    At some point, a number of the employees at Microsoft decided that the MicroNews was too boring, so they came up with an “alternate” version, called the MicroSnooze.  The Microsnooze was where you got the REAL information about what was happening at Microsoft.  You had articles announcing the new Microsoft shuttle buses (the campus had gotten so large that we were using dirigibles).  It’s also where you discovered the REAL story behind the name Microsoft Windows (We were going to call it Doors, but someone lost the key). 

    One of my co-workers  was nice enough to drop by a copy of the ‘snooz from 1995.  In it, you find:

                Lengthy Court Battles Expected as Microsoft Sues Itself – a report on Microsoft suing itself in district court, complete with quotes from “Very Senior Corporate Attorney Drew Blank”.
                New Consumer Title Offers Support, Reassurance – a report on Microsoft Mom™.
                An announcement that Microsoft is giving away a corporate Vice Presidency in a United Way raffle.

    And the following letter to the editor:

    listen to me!
    all over the company people are looking for ways to reduce waste, both to save costs and lessen environmental impacts.  however, one of the most conspicuous forms of waste is staring us right in the face.  i mean, of course, excess use of capital letters.

    it’s a fact that most of our senior executives already know – capital letters are largely unnecessary, since they tend to duplicate information that’s already expressed adequately via punctuation, capital letters use extra toner when printed, and contribute significantly to the incidence of repetitive stress injuries.

    most importantly, capital letters use substantially more monitor energy than their lower case counterparts (on average 1.8 times the amount, weighting the average for character distribution in english).  consider the following: on my 15-inch monitor, I have an average of 141 capital letters on my display at any given time.  computing this based on a nine-hour work day, five days a week per employee (conservative for the typical microsoft employee), and factoring in what microsoft pays puget power per kilowatt-hour in its redmond-area locations, i estimated that using capital letters costs Microsoft an average of $72,000 per year per employee, and that doesn’t even count people with more than one monitor in their offices or our assorted test labs.

    so my advice is, just say N-O to capital letters, we’ll all be glad that you did.

    ss. lemmings

    Originally the Microsnooze came out whenever the guys writing it felt like it, but over the years, it’s sort-of become an April first tradition.  Nowadays it’s published by the same team that publishes the MicroNews, but it still has some of the original irreverent tone.


  • Larry Osterman's WebLog

    Just saw this on PRWIRE


    Microsoft announces dramatic changes to European business model

    Company to radically reduce operations

    REDMOND, Wash. – April 1, 2004 -- Microsoft Corp. today stated that it has determined that it’s best available legal recourse in its ongoing dispute with the European Union is to immediately suspend all of its European operations.  As of April 1st 2004, Microsoft will no longer provide software to European markets.  In addition, it is ceasing all business operations, and closing all of its European branches. 

    “Microsoft was looking forward to continuing the appeals process, but our legal advisors have informed us that shutting down in Europe is in Microsoft’s long term best interests”, Microsoft spokesman Dennis Andersen said. 

    "I’ll really miss my Italian roasted espresso," said Steve Ballmer, chief executive officer of Microsoft. "but that’s just a part of what you have to pay for standing firm."

    In addition, all support for Microsoft products will also cease as of that date.  Customers with outstanding issues are urged to contact the European Union Antitrust Division, which has agreed to assume support responsibilities for Microsoft.  European Anti-Trust commissioner Mario Monti said “It’s the least we could do to help the Microsoft consumers during the transition time between their current situation and when they are able to experience the liberating benefits of a competitive market”.

    In a related announcement, Microsoft Chief Software Architect Bill Gates has announced that Microsoft will save an estimated $1,000,000,000 in costs because it no longer has to localize its products to the European languages.  “We’re relieved that we can now remove support for French, German, and the other 32 European languages so we can concentrate on our growing markets in India and China”.

    Founded in 1975, Microsoft (Nasdaq "MSFT") is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

    Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

    Note to editors: If you are interested in viewing additional information on Microsoft, please visit the Microsoft® Web page at http://www.microsoft.com/presspass/ on Microsoft's corporate information pages. Web links, telephone numbers and titles were correct at time of publication, but may since have changed. For additional assistance, journalists and analysts may contact Microsoft's Rapid Response Team or other appropriate contacts listed at http://www.microsoft.com/presspass/contactpr.asp


Page 2 of 2 (30 items) 12