Larry Osterman's WebLog

More fun with Amazon reviews.

LarryOsterman — Wed, 04 Nov 2009 22:35:01 GMT

A co-worker sent this around and I just HAD to share it… It’s not nearly as geeky as “The Story of Ping”.

For those that don’t want to follow the link, these are some of reviews for this:

“I bought this review based on all of the positive reviews, but am having some issues with space. The desk is great shape and fit for my 2004 Chevy Caprice, but I am really having a heck of a time fitting the Chevy in the office. I put my printer/fax, coffee machine, shredder, and inappropriate family photos snugly in the backseat, yet I still don't have enough room to walk around the Chevy. And worse, I can barely open the door and squeeze in. Most of the time I squeeze in the passenger side and scramble into the driver seat. I tried leaving the window open and crawling through, but Scrappy hops in and hangs his head out the window. I just don't have the heart to tell him we aren't going to the dogpark and that I am still working.
When the contractor comes to tear out the adjoining wall to my living room, I know he will ask me "Why don't you just use the garage?" But has he actually *seen* the garage! It's filled with stuff I never use like my treadmill, ab-lounger, roto-till, lawnmower... I couldn't work in that kind of clutter! NO WAY!
Don't get me wrong! I LOVE THIS PRODUCT! Now I can turn my Neil Diamond up as loud as I want to and not have Sandra from Accounting peek over my cubical with those angry little eyes. And when I want to go to Starbucks or McDonalds I can work while I drive AND in the drive thru, too! It works perfectly with my Universal Portable Urinal - Unisex and Reliance Products Hassock Portable Lightweight Self-Contained Toilet
Working from my car, and home, has never been easier. I finally threw out that crappy IKEA desk and printer stand combo! Good riddance! Best of all now I don't have to "tele-commute" to work, I "auto-commute." AWESOME.”

“My 16 year old daughter just got her license a few weeks ago. Since then, she's been going out for drives a lot after school. Unfortunately, all the time spent in the car for her has meant less time for homework. Her grades have noticeably slipped, but instead of taking away her car privileges, I bought this steering wheel desk. It's perfect for young drivers with heavy academic loads! Now she can work on her homework and still be out driving, improving her road skills and staying on top of her grades. I couldn't be prouder and would encourage all parents with new drivers to set their kids up with this super-portable work station!”

“My copilot and I both used these during our "daily grind" transcontinental flights from San Diego to Minneapolis. We had to modify them a bit to fit snug against the instrument panels (when we bought them we didn't realize the planes we fly don't have steering wheels!), but in the end it did the job. With our laptops firmly in place we were able to focus our attention on what really mattered, participating in raids with our WoW clan. During our last flight we were so immersed in trying to take down Eranikus that we overshot Minneapolis by a full hour and a half before some annoying flight attendant interrupted us, babbling something about "FAA and F16 fighters."
We'll definitely use this product again at our next gig, whatever and whenever that happens to be...
Highly recommended! “ [Editors Note: A reference to this]

“This is definitely one of the best products out there!
While commuting through downtown Seattle, I always had to make my sushi on the little center console in my Honda - try making a perfect California roll there! No way!
Now, I can safely make my California rolls, Spider rolls and Rainbow rolls - all while steering with my knee.
Downsides - it doesn't have a receptical for my egg drop soup bowl. Also, I have to keep my knife on the dashboard and my chopsticks tucked in my crotch. So, there are some flaws with this product. I would also recommend keeping your sake in a flask under the passengers seat.”

The reviews go on and on in this vein. Very funny.

Why are they called “giblets” anyway?

LarryOsterman — Mon, 26 Oct 2009 16:05:33 GMT

Five years ago, I attended one of the initial security training courses as a part of the XP SP2 effort. I wrote this up in one of my very first posts entitled “Remember the giblets” and followed it up last year with “The Trouble with Giblets”. I use the term “giblets” a lot but I’d never bothered to go out and figure out where the term came from.

Well, we were talking about giblets in an email discussion today and one of my co-workers went and asked Michael Howard where the term came from. Michael forwarded the question to Steve Lipner who was the person who originally coined the term and he came back with the origin of the term.

It turns out that “giblets” is a term that was used at Digital Equipment Corporation back in the 1980s. DEC used to sell big iron machines (actually I used DEC machines exclusively until I started at Microsoft). The thing about big machines is that you usually need more than just the machine to build a complete solution – things like Ethernet repeaters and adapters and other fiddly bits. And of course DEC was more than willing to sell you all these fiddly bits. It seems that some of the DEC marketing people liked to refer to these bits and pieces as “giblets”.

Over time Steve started using the term for the pieces of software that were incidental to the product but which weren’t delivered by the main development team – things like the C runtime library, libJPG, ATL, etc.

Later on, someone else (Steve wasn’t sure who, it might have been Eric Bidstrup) pointed out that the giblets that came from a turkey didn’t necessarily come from the actual turkey that you’re eating which makes the analogy even more apt.

Thanks to Craig Gehre for the picture.

Windows 7 Reflections…

LarryOsterman — Fri, 23 Oct 2009 17:53:31 GMT

Today[1] Microsoft formally launched Windows 7. I can’t say how proud I am of the work we did in Windows 7 – it’s been an amazing journey. This is the 4th version of Windows I’ve worked on and I have never felt this way about a release of Windows. I have to admit that I get a bit weepy with pride whenever I see a Win7 commercial (Kylie is simply too cute :)).

I thought I’d write a bit about the WIn7 experience from my point of view. I’ve written a bit of this stuff in my post on the Engineering 7 blog but that was more about the changes in engineering processes as opposed to my personal experiences in the process.

For me, the Windows 7 work basically started just after we shipped Vista. While the PMs and leads on the sound team were busy working on planning for Win7, I spent most of the time between Vista RTM and the start of the Win7 feature design cleaning up some of the Vista code I was responsible for. During the final Vista testing, I realized that there were some architectural deficiencies in some of the sound code that caused some really subtle bugs (that I don’t believe anyone outside of the sound team has ever found) so I took the opportunity to clean up those deficiencies.

I also fixed an issue that occurred when someone called the wave APIs from their DLL entry point. Yes I know that apps aren’t supposed to call any APIs from DllMain but anyone who’s read either my blog or Raymond Chen’s blog will realize that a lot of apps do stuff like that and get away with it. This fix was actually first deployed in Vista SP1 – we had identified the DllMain problem before we shipped Vista and included a workaround for the problem but we also added some telemetry so we could determine the number of customers that were affected by the bug. Based on that telemetry we decided that we had to include the fix in Vista SP1 of the number of users affected by the issue. This is a perfect example of some of the ways that the customer experience improvement program directly leads to product improvements. Before we had the CEIP, we would have had no way of knowing how much impact the bug had on customers, the CEIP gave us visibility into the severity of the problem that we wouldn’t have had before.

During this interim time, I also worked on a number of prototype projects and helped the SDL tools team work on the current version of the threat modeling tool. played around with some new (to me) development strategies – RAII and exception based programming and test driven development.

In June of 2007, we started working on actual feature planning – the planning team had come up with a set of tentative features for Win7 and we started the actual design for the features – figuring out the user experience for the features, the internal implementation details, etc. During the first milestone, I worked on the capture monitor feature – I ended up writing the feature from start to finish. This was my first time writing features using RAII and using TDD. I’ve got to say that I like it – as I remember, there were only 2 or 3 bugs found in the capture monitor that weren’t found by my unit tests and I’m not aware of any bugs that were found outside the team (which might just be an indication of how little the feature is used :)).

After the capture monitor work, I spent the next milestone working on UI features – I was on a feature crew of 2 developers working on enhancing sndvol to make it work better with multiple devices and to fix a number of accessibility issues with the UI. This was the first time in my almost 25 years at Microsoft where I had an opportunity to do “real” UI development. I know that there’s a lot of controversy about the UI choices we made but I’m pretty happy with the UI changes.

The third milestone for Win7 I worked on the “Ducking” feature. Of all the features I worked on for WIn7, the ducking feature is the closest to a “DWIM” feature in Windows – the system automatically decreases the volume for applications when you start a communicating with other people (this feature requires some application changes to work correctly though which is why you don’t see it in use right now (although it has shown up in at least one application by accident)).

The remarkable thing about Win7 development was that it was almost friction free. During the Vista development process (and in every other product I’ve worked on) development was marked by a constant stream of new issues which were a constant drain on time an energy. It felt like we moved from one crisis to another crisis. For Win7 it was different. I think it was some time during the second milestone that I realized that Win7 was “special”. The newer development process that was deployed for Win7 was clearly paying off and my life was far less stressed. In fact I don’t think I worked late or came in on weekends once during the entire 3 years that Win7 was under development – this was a HUGE change. Every other product I’ve ever worked on has required late nights and weekends (sometime it required all-nighters). But for Win7 it just didn’t happen. Instead we set a set of goals that were reasonable with achievable schedules and we executed on those goals and delivered the features we promised.

I’m so happy that customers are now going to be able to play with the stuff we’ve all worked so hard to deliver to you. Enjoy :).

[1] I started writing this on the 22nd but didn’t finish it until today.

Win7 Whoppers

LarryOsterman — Thu, 22 Oct 2009 01:39:00 GMT

Wow, one of my co-workers just sent this image out. It’s totally awesome (IMHO)…

http://twitpic.com/mehp6/full

Edit: The image tag didn't work for some reason so I removed it and just left the link...

Bonus: The first Win7 ad: http://video.nytimes.com/video/2009/10/21/multimedia/1247465293593/an-ad-for-windows-7-from-microsoft.html#

Looking for new skillz (turning the blog around)…

LarryOsterman — Wed, 21 Oct 2009 00:31:36 GMT

Just for giggles, I went looking at the various job listings within Microsoft and outside Microsoft (no, I’m not going anywhere, I was just curious). While looking, I realized that I had absolutely no marketable skills :). Nobody seems to be hiring an OS developer these days.

To repeat and be even more clear: I’m *not* leaving Microsoft. I’m *not* leaving Windows.

I’m just looking for a book or two to read to improve my skills (I do this regularly – most of my recent reading has either been on Security or WPF and to be honest, I’m kinda bored of those topics so I’m interested in branching out beyond security and UI topics)…

I could run out and browse the bookstores (and I might just do that) but I figured “Hey, I’ve got a blog, why don’t I ask the folks who read my blog?”. So let me turn the blog around and ask:

If I wanted to go out and learn web development, which books should I read?

I’ve already read “Javascript: The ood Parts” and it was fascinating but it was more of a language book (and a very good language book), but it’s not a web development book. So what books should I read to learn web development?

I can make it arbitrarily fast if I don’t actually have to make it work.

LarryOsterman — Wed, 30 Sep 2009 00:49:37 GMT

Digging way back into my pre-Microsoft days, I was recently reminded of a story that I believe was told to me by Mary Shaw back when I took her Computer Optimization class at Carnegie-Mellon…

During the class, Mary told an anecdote about a developer “Sue” who found a bug in another developer’s “Joe” code that “Joe” introduced with a performance optimization. When “Sue” pointed the bug out to “Joe”, his response was “Oops, but it’s WAY faster with the bug”. “Sue” exploded “If it doesn’t have to be correct, I can calculate the result in 0 time!” [1].

Immediately after telling this anecdote, she discussed a contest that the CS faculty held for the graduate students every year. Each year the CS faculty posed a problem to the graduate students with a prize awarded to the grad student who came up with the most efficient (fastest) solution to the problem. She then assigned the exact same problem to us:

“Given a copy of the “Declaration of Independence”, calculate the 10 most common words in the document”

We all went off and built programs to parse the words in the document, inserting them into a tree (tracking usage) and read off the 10 most frequent words. The next assignment was “Now make it fast – the 5 fastest apps get an ‘A’, the next 5 get a ‘B’, etc.”

So everyone in the class (except me :)) went out and rewrote their apps to use a hash table so that their insertion time was constant and then they optimized the heck out of their hash tables[2].

After our class had our turn, Mary shared the results of what happened when the CS grad students were presented with the exact same problem.

Most of them basically did what most of the students in my class did – built hash tables and tweaked them. But a couple of results stood out.

The first one simply hard coded the 10 most common words in their app and printed them out. This was disqualified because it was perceived as breaking the rules.
The next one was quite clever. The grad student in question realized that they could write the program much faster if they wrote it in assembly language. But the rules of the contest required that they use Pascal for the program. So the grad student essentially created an array on the stack and introduced a buffer overflow and he loaded his assembly language program into the buffer and used that as a way of getting his assembly language version of the program to run. IIRC he wasn’t disqualified but he didn’t win because he circumvented the rules (I’m not sure, it’s been more than a quarter century since Mary told the class this story).
The winning entry was even more clever. He realized that he didn’t actually need to track all the words in the document. Instead he decided to track only some of the words in the document in a fixed array. His logic was that each of the 10 most frequent words were likely to appear in the first <n> words in the document so all he needed to do was to figure out what "”n” is and he’d be golden.

So the moral of the story is “Yes, if it doesn’t have to be correct, you can calculate the response in 0 time. But sometimes it’s ok to guess and if you guess right, you can get a huge performance benefit from the result”.

[1] This anecdote might also come from Jon L. Bentley’s “Writing Efficient Programs”, I’ll be honest and say that I don’t remember where I heard it (but it makes a great introduction to the subsequent story).

[2] I was stubborn and decided to take my binary tree program and make it as efficient as possible but keep the basic structure of the solution (for example, instead of comparing strings, I calculated a hash for the string and compared the hashes to determine if strings matched). I don’t remember if I was in the top 5 but I was certainly in the top 10. I do know that my program beat out most of the hash table based solutions.

Building a flicker free volume control

LarryOsterman — Thu, 17 Sep 2009 00:50:09 GMT

When we shipped Windows Vista, one of the really annoying UI annoyances with the volume control was that whenever you resized it, it would flicker.

To be more specific, the right side of the control would flicker – the rest didn’t flicker (which was rather strange).

Between the Win7 PDC release (what we called M3 internally) and the Win7 Beta, I decided to bit the bullet and see if I could fix the flicker. It seems like I tried everything to make the flickering go away but I wasn’t able to do it until I ran into the WM_PRINTCLIENT message which allowed me to direct all of the internal controls on the window to paint themselves.

Basically on a paint call, I’d take the paint DC and send a WM_PRINTCLIENT message to each of the controls in sndvol asking them each to paint themselves to the new DC. This worked almost perfectly – I was finally able to build a flicker free version of the UI. The UI wasn’t perfect (for instance the animations that faded in the “flat buttons” didn’t fire) but the UI worked just fine and looked great so I was happy that' I’d finally nailed the problem. That happiness lasted until I got a bug report in that I simply couldn’t figure out. It seems that if you launched the volume mixer, set the focus to another application then selected the volume mixer’s title bar and moved the mixer, there were a ton of drawing artifacts left on the screen.

I dug into it a bunch and was stumped. It appeared that the clipping rectangle sent in the WM_PAINT message to the top level message didn’t include the entire window, thus portions of the window weren’t erased. I worked on this for a couple of days trying to figure out what was going wrong and I finally asked for help on one of our internal mailing lists.

The first response I got was that I shouldn’t use WM_PRINTCLIENT because it was going to cause me difficulty. I’d already come to that conclusion – by trying to control every aspect of the drawing experience for my app, I was essentially working against the window manager – that’s why the repaint problem was happening. By calling WM_PRINTCLIENT I was essentially putting a band-aid on the real problem but I hadn’t solved the real problem, all I’d done is to hide it.

So I had to go back to the drawing board. Eventually (with the help of one of the developers on the User team) I finally tracked down the original root cause of the problem and it turns out that the root cause was somewhere totally unexpected.

Consider the volume UI:

The UI is composed of two major areas: The “Devices” group and the “Applications” group. There’s a group box control wrapped around the two areas.

Now lets look at the group box control. For reasons that are buried deep in the early history of Windows, a group box is actually a form of the “button” control. If you look at the window styles for a button in SpyXX, you’ll see:

Notice the CS_VREDRAW and CS_HREDRAW window class styles. The MSDN documentation for class styles says:

CS_HREDRAW - Redraws the entire window if a movement or size adjustment changes the width of the client area.
CS_VREDRAW - Redraws the entire window if a movement or size adjustment changes the height of the client area.

In other words every window class with the CS_HREDRAW or CS_VREDRAW style will always be fully repainted whenever the window is resized (including all the controls inside the window). And ALL buttons have these styles. That means that whenever you resize any buttons, they’re going to flicker, and so will all of the content that lives below the button. For most buttons this isn’t a big deal but for group boxes it can be a big issue because group boxes contain other controls.

In the case of sndvol, when you resize the volume control, we resize the applications group box (because it’s visually pinned to the right side of the dialog). Which causes the group box and all of its contained controls to repaint and thus flicker like crazy. The only way to fix this is to remove the CS_HREDRAW and CS_VREDRAW buttons from the window style for the control.

The good news is that once I’d identified the root cause, the solution to my problem was relatively simple. I needed to build my own custom version of the group box which handled its own painting and didn’t have the CS_HREDRAW and CS_VREDRAW class. Fortunately it’s really easy to draw a group box – if themes are enabled a group box can be drawn with DrawThemeBackground API with the BP_GROUPBOX part and if theming is disabled, you can use the DrawEdge API to draw the group box. Once I added the new control that and dealt with a number of other clean-up issues (making sure that the right portions of the window were invalidated when the window was resized for example), making sure that my top level control had the WS_CLIPCHILDREN style and that each of the sub windows had the WS_CLIPSIBLINGS style I had a version of sndvol that was flicker free AND which let the window manager handle all the drawing complexity. There are still some minor visual gotchas in the UI (for example, if you resize the window using the left edge the right side of the group box “shudders” a bit – this is apparently an artifact that’s outside my control – other apps have similar issues when resized on the left edge) but they’re acceptable.

As an added bonus, now that I was no longer painting everything manually, the fade-in animations on the flat buttons started working again!

PS: While I was writing this post, I ran into this tutorial on building flicker free applications, I wish I’d run into it while I was trying to deal with the flickering problem because it nicely lays out how to solve the problem.

The story behind the mysterious “Ding” in Windows Vista.

LarryOsterman — Fri, 04 Sep 2009 03:29:20 GMT

I just ran into this fairly old post on Channel 9. mstefan reported that his applications played a “Ding” noise when selecting an item in a listview (or tree) control.

It turns out that I’d had the problem independently reported to me by one of the people here at Microsoft. Here were his reproduction steps:

Clean Install Windows
Open the sounds control panel
Set the “Select” sound to a value
Clear the “Select” sound (set it to “(None)”).
Change the selection in a listview

Complicating matters is that this didn’t occur with many apps, just a couple of Windows Forms applications that the person at Microsoft had. So I dug into it a bit.

I quickly realized that the problem was that the application was calling PlaySound without the “SND_NODEFAULT” flag. I’ve written about this flag before (in fact I wrote that post shortly after investigating this issue, so that post contains part of the story).

Digging in deeper, I realized that the application was using version 5 of the common controls (there are two versions in Windows, v5 and v6). The problem didn’t occur in the version 6 common controls (this is why most applications didn’t reproduce the problem).

So why did the problem occur?

The common controls have a single routine which calls PlaySound and that code attempts to be somewhat clever. Instead of simply calling PlaySound, the code instead read the HKEY_CURRENT_USER\AppEvents\Schemes\.Default\CCSelect registry key. If the key didn’t exist, it skipped calling PlaySound. If the CCSelect registry key existed, it would call PlaySound specifying the CCSelect alias.

I’ve actually run into this pattern a bunch in WIndows – teams decided that calling PlaySound was “too slow”, or had “too much overhead” so they tried to avoid the call to PlaySound if the call to PlaySound wasn’t going to do anything (once upon a time it was important to avoid calling PlaySound because it could sometimes hang your application for several seconds – this isn’t the case any more if you specify SND_ASYNC).

The problem is that when you hit step 2 above (setting the “Select” sound), the control panel created the CCSelect registry key with a default value of the sound file you’re setting. When you set it to “None” the control panel cleared the value of the sound contained under the key. But the key itself wasn’t deleted. So the check above that checked for the registry key’s existence succeeded and it called PlaySound. But because the call didn’t specify SND_NODEFAULT, the PlaySound API decided to play the default sound when it realized that there wasn’t a sound associated with the CCSelect alias.

I wanted to understand how this bug was introduced so I looked back at the source history of the file containing the bug. It turns out that this was actually a bug fix made to Windows XP that wasn’t incorporated into Windows Server 2003. When Windows Vista was created, the team started with the Windows Server 2003 code base and incorporated all the bug fixes made since Windows XP forked into the Win2K3 code base. For whatever reason, this particular fix was missed when the team did the merge. Because the behavior was so subtle (to trigger the change you MUST go through steps 2 through 4 to get the registry key created and your app must use the v5 of the common controls).

Needless to say, it’s fixed in WIndows 7.

What’s the difference between GetTickCount and timeGetTime?

LarryOsterman — Thu, 03 Sep 2009 00:31:17 GMT

I’ve always believed that the most frequently used multimedia API in winmm.dll was the PlaySound API. However I recently was working with the results of some static analysis tools that were run on the Windows 7 codebase and I realized that in fact the most commonly used multimedia API (in terms of code breadth) was actually the timeGetTime API. In fact almost all the multimedia APIs use timeGetTime which was somewhat surprising to me at the time.

The MSDN article for timeGetTime says that timeGetTime “retrieves the system time, in milliseconds. The system time is the time elapsed since the system started.”.

But that’s almost exactly what the GetTickCount API returns “the number of milliseconds that have elapsed since the system was started, up to 49.7 days.” (obviously timeGetTime has the same 49.7 day limit since both APIs return 32bit counts of milliseconds).

So why are all these multimedia APIs using timeGetTime and not GetTickCount since the two APIs apparently return the same value? I wasn’t sure so I dug in a bit deeper.

The answer is that they don’t. You can see this with a tiny program:

int _tmain(int argc, _TCHAR* argv[])

    int i = 100;

    DWORD lastTick = 0;

    DWORD lastTime = 0;

    while (--i)

        DWORD tick = GetTickCount();

        DWORD time = timeGetTime();

        printf("Tick: %d, Time: %d, dTick: %3d, dTime: %3d\n", tick, time, tick-lastTick, time-lastTime);

        lastTick = tick;

        lastTime = time;

        Sleep(53);

    return 0;

If you run this program, you’ll notice that the difference between the timeGetTime results is MUCH more stable than the difference between the GetTickCount results (note that the program sleeps for 53ms which usually doesn’t match the native system timer resolution):

Tick: 175650292, Time: 175650296, dTick: 46, dTime: 54
Tick: 175650355, Time: 175650351, dTick: 63, dTime: 55
Tick: 175650417, Time: 175650407, dTick: 62, dTime: 56
Tick: 175650464, Time: 175650462, dTick: 47, dTime: 55
Tick: 175650526, Time: 175650517, dTick: 62, dTime: 55
Tick: 175650573, Time: 175650573, dTick: 47, dTime: 56
Tick: 175650636, Time: 175650628, dTick: 63, dTime: 55
Tick: 175650682, Time: 175650683, dTick: 46, dTime: 55
Tick: 175650745, Time: 175650739, dTick: 63, dTime: 56
Tick: 175650792, Time: 175650794, dTick: 47, dTime: 55
Tick: 175650854, Time: 175650850, dTick: 62, dTime: 56

That’s because GetTickCount is incremented by the clock tick frequency on every clock tick and as such the delta values waver around the actual time (note that the deltas average to 55ms so on average getTickCount returns an accurate result but not with spot measurements) but timeGetTime’s delta is highly predictable.

It turns out that for isochronous applications (those that depend on clear timing) it is often important to be able to retrieve the current time in a fashion that doesn’t vary, that’s why those applications use timeGetTime to achieve their desired results.

Digging into the history bin (AKA: Microsoft Developer says that Windows is useless)

LarryOsterman — Tue, 01 Sep 2009 21:49:25 GMT

As I was writing my “25 years of Larry’s history at Microsoft in 1 year chunks” blog posts, I spent a fair amount of time digging through my email archives (trying to figure out exactly what happened at what time). During this, I ran into a link to a post I’d made on the Info-IBMPC mailing list mailing list back in 1992:

Date: Thu, 12 Mar 92 12:44:39 PST
From: lar...@microsoft.com
Subject: What do you do with your windows? (V92 #36)

|| >From: m...@Violin.CC.MsState.Edu (Mubashir Cheema)

|| I recently acquired Windows 3.0 and I don't seem to understand one
|| thing. What is it for? What do I do with it? What major advantage
|| does it have over Dos? (I don't see any except being able to use mouse
|| and also the thing is bit more colorful) I think it was made for lazy
|| people who couldn't learn couple of DOS commands.

|| Don't tell me I could multi-task with it. I've been using Amigas
|| extensively

I've got to jump in here, even though I suspect that there will probably be some form of an "official" response from MS if anyone in the DOS/Windows group is listening...... :)

I'm going to be brutally honest about this one. Basically, Windows by itself IS pretty useless. The thing that makes Windows great is the same thing that has made DOS the most popular operating system in history. It's the applications that are available for it.

GUI's (Graphical User Interfaces) have been proven to be significantly easier for users to understand for beginning users, and are arguably the wave of the future. I don't know of a significant operating system being introduced for the PC market that doesn't have a GUI available on it, be it PM, X, GEM, or Windows. Windows is arguably the best GUI available for DOS based on what I consider the most significant criteria: What applications are available for the platform.

Consider the list of available windows apps: Excel, WinWord, PageMaker, Corel Draw, WordPerfect, Lotus 123, etc just to name a couple off the
top of my head.

You also hit on one of the significant reasons to use Windows - Multi-tasking.

Windows is a non pre-emptive multi-tasking operating system. On a 386, it does an ok job of multi-tasking multiple DOS applications, but on a
286 it functions as a simple task switcher like DOS 5 does. It really shines when multi-tasking Windows applications however.

In addition, when you couple the multi-tasking capabilities of Windows with a windows mechanism known as DDE (for Dynamic Data Exchange), you
can generate some truly incredible synergy between Windows applications. With Win 3.0/Win 3.1 Microsoft has introduced a concept
known as OLE (Open Linking and Embedding) which allows you to cut and past from multiple "applets" allowing applications to take advantage of
the capabilities of other shipped applications. This allows an applet like an equation editor to manage all the information about formatting
an equation even when the equation is embedded in a word document. With OLE, you can simply double-click on the object and bring up the
"agent" that manages it (in my example, the equation editor).

For application developers, Windows gives developers the ability to develop their applications without knowing anything about the
underlying hardware of the machine - a windows application that runs on a machine with a CGA adapter will also run on a machine with a graphics
accelerator that runs in 1024x1024 with 24 bits of color.

In addition, when you write an application for windows, your application instantly will support literally hundreds of printers
transparently - Windows does all the work for you.

To re-iterate, Windows as a stand-alone product is not extraordinarily interesting - there are lots of productivity packages that provide
similar functionality to users, the real benefit of Windows is the applications that run on it.

I will also point out that there are more than 5000 Windows applications available today and still more will come out with Win 3.1.
The available windows applications span all ranges of applications from games (Microsoft's Entertainment pack, Berkley-Soft's After Dark, and
Sierra's Laffer Utilities for Windows) to Spreadsheets (Microsoft Excel, Lotus 1-2-3) to Word processors (Microsoft Word For Windows,
Lotus Ami), to Desktop publishing (Aldus Pagemaker, Microsoft Publisher), to presentation graphics (Microsoft Powerpoint), to
development tools (Microsoft Visual Basic) etc......

Larry Osterman

Disclaimer: The opinions above are my own. They are not necessarily the same as those of Microsoft. I only work here.

Remember that this was written back in 1992 after Windows 3.0 had come out but before Windows 3.1. There was no Win32, no web browser, no multimedia support, none of the things that we all take for granted in a modern system. Back then a display card that supported 1Kx1K with 24bit color was considered a monster display card (and hard disks still came in “megabytes” – I remember buying a 2G hard disk back then for about a thousand dollars).

Reading this again, I find it vaguely funny that in many ways my feelings about Windows haven’t really changed that much in 18 years – the value of the Windows platform is STILL the applications available for that platform (although the number of applications has grown from the 5000 or so back in 1992 to several million applications).

25 Years Ago Today (August 27th, 1984)

LarryOsterman — Fri, 28 Aug 2009 00:55:00 GMT

I got up in the morning from temporary housing and put on my 3 piece business suit to start my first day of work at a relatively small computer company near Seattle called “Micro-Soft” or something like that. Within a day I’d been ridiculed for my choice of dress (“You’re wearing a ne-ne-ne-ne-necktie?”) and had to sign a dozen or more forms, been handed an employee directory and shown to my new window office – a converted conference room, but still a window office. I shared the office with Joe King (yeah, that was his real name) for about 2 weeks until I got my own office.

I’ve spent the past 25 days giving a year-by-year recap of my career at Microsoft, today’s been a bit of a whirlwind. I was originally going to recap the highlights of the past 25 years but instead I think I’ll just write about some of the events of the day.

My group had a lunch where we celebrated with a “Windows Mixer” cake decorated by Steve Ball:

I received my 25 year service award – the thing weighs about 30 pounds (it comes in a footlocker!).

And if you’ve seen the sound team, you know that we almost always have a video that goes with every event…

EHO and Kristin Carr, two of my co-workers wearing their “Larry Look-Alike Kits”:

My boss, Noel Cross with his Larry Look-Alike Kit:

I also was fortunate to have several of my co-workers from years gone by come by and share in the celebration, it was amazing seeing them again after several years.

Today’s been an awesome day, and I’m really looking forward the next 25 years!

Edit: Ok, blogging while slighly intoxicated is a bad idea.

24 years ago today (1985)

LarryOsterman — Wed, 26 Aug 2009 20:50:00 GMT

Way back in 1985 I was busy working on MS-DOS 4.0. MS-DOS 4.0 was a multitasking derivative of MS-DOS 2.0 (during 1985 we integrated the changes for MS-DOS 3.1 to MS-DOS 4.1).

It’s important to remember the difference between MS-DOS and PC-DOS. PC-DOS was an IBM OS offering which was largely written by Microsoft. MS-DOS was Microsoft OEM version of PC-DOS (sold to companies like Compaq and DEC). The MS-DOS releases always lagged behind the PC-DOS releases.

Back in the mid 1980s IBM called the shots in the development of DOS – DOS releases were directly tied to IBM hardware offerings because IBM wanted a new version of PC-DOS for each new piece of hardware they shipped. For example, when IBM shipped the PC/XT, they added a hard disk (with a whopping 10M storage capacity) and they asked Microsoft to add support for hard disks. The MS-DOS team decided that the best way to support a hard disk wasto add a *nix style hierarchical filesystem with PC-DOS 2.0. When IBM created the PC/AT, they also delivered PC-DOS 3.1 which added support for the IBM PC Lan Adapter, a broadband networking adapter that IBM shipped at the same time as the PC/AT. It’s also important to remember that MS-DOS wasn’t a complete PC OS experience. Instead Microsoft provided the core OS and the command interpreter and a couple of utilities. Other utilities (like mode.com) were provided by the OEM. This changed with MS-DOS 3.2 which included a full set of the utilities that were provided by IBM. For MS-DOS 3.3, we were working with IBM under the Joint Development Agreement and as such we were finally able to ship the actual binaries that shipped with PC-DOS thus making MS-DOS identical to PC-DOS in functionality – but that didn’t happen until 1987.

MS-DOS 4.0 was unique because it was developed “on spec” – IBM didn’t see a need for a multitasking version MS-DOS and didn’t have a new hardware offering on which to attach the product. But IBM did have the PC/AT which was an 80286 based processor and it didn’t have an OS that took advantage of that hardware. So IBM and Microsoft started negotiations to take the MS-DOS 4.0 code base and turn it into what eventually turned into OS/2. I ended up not working on the OS/2 effort, instead I worked on finishing up MS-DOS 4.0 for the OEM partners who had licensed MS-DOS 4.0.

For MS-DOS 4.0 I worked on the BIOS (IO.SYS or IBMBIO.COM on PC-DOS). In MS-DOS terms the BIOS was basically the binary which contained all the built-in drivers – keyboard, screen, printer, serial port.

Edit: Removed extra "Z" introduced because I wrote this with my laptop balanced on my knee and the "Z" kept creeping in especially when typing IZBM.

Over the summer of 1985, Valorie came out to visit me for an extended summer – she worked as a tester on the Windows and Word team testing printer drivers until she left in December. And in December I proposed to her and she accepted my proposal, we got married in January 1987 (cue violins at this point :)).

Tomorrow: 1984.

23 years ago today (1986)

LarryOsterman — Tue, 25 Aug 2009 22:56:10 GMT

23 years ago, I was working on finishing MS-DOS 4.0 and transitioning to work on MS-DOS 4.1. We also moved from the original Northup campus to the brand new 4 building campus herein Redmond. At the time the company mandated that we give up our President’s Day holiday and instead replace it with the day we moved to the new campus. Needless to say this did not go over well. I still remember one of my co-workers sending an email comparing John Shirley (president at the time) with Pope Gregory.

For me this didn’t matter because a co-worker and I ended up spending the move time in France working with Goupil to finalize a number of bugs that they had with MS-DOS 4.0 (for instance MS-DOS 4.0’s floppy driver didn’t work correctly on machines with more than 2 floppy drives (we weren’t able to test this because none of the machines we had access to had 4 floppy drives, but Goupil had a machine with 4 drives on it – if I remember correctly the issue was a confusion as to how the drive select bits on the uPD765 worked).

20, 21 and 22 years ago (1987-1989)

LarryOsterman — Mon, 24 Aug 2009 22:24:00 GMT

Ok, at this point it should be blindingly obvious where this series is going :).

In early 1987 I was still working on MS-DOS 4.1, a custom version of DOS for ICL in the UK. I also got married to my wonderful wife Valorie in January. We returned from our honeymoon and I wandered into work after getting off the plane (I’d parked my car at work and took the shuttle to the airport from work). That was a HUGE mistake because I learned that the entire MS-DOS 4.1 team was going on a plane to the UK in 36 hours. These days, I’d never do what I did next: I left my bride of a week at home (with a car with a manual transmission that she didn’t really know how to drive) for a week while I flew to the UK and met with customers (these days, I’d have insisted that Valorie come with me to the UK so we’d at least be together in the evenings and weekend). I spent a huge amount of time in the UK that year finishing up MS-DOS 4.1.

Between 1988 and 1990 I spent most of the time working on the Lan Manager family of products, starting with Lan Manager 1.1 and continuing through Lan Manager 2.0 (I left the Lan Manager team for NT OS/2 after Lan Manager 2.1).

LanMan was a hoot – LanMan was when I first started working with Brian Valentine (and later for Brian Valentine). Brian was maybe the most inspirational manager I’ve ever worked for, working for him was always a blast. This was also where Danny Glasser gave me the nickname “DOS Vader” – at one point in the very late 1980s, I probably knew as much about the internals of MS-DOS than any other developer in the world.

In Lan Manager, I was the developer for the DOS version of the Lan Manager client. It’s also when I had the “8 F**ING BASICS” meeting with Bill Gates. I started with a version of the messenger service for MS-DOS and then moved onto the network client – eventually I’d added support for a fully asynchronous programming model running under MS-DOS which was pretty cool (there were some limitations but in general it worked great).

Nineteen years ago today (1990)

LarryOsterman — Sat, 22 Aug 2009 00:58:10 GMT

In 1990 I joined the WIndows NT OS/2 team after working on Lan Manager for several years. I was one of about 4-5 developers who moved from the Lan Manager team to join the much storied NT OS/2 developers. I still have my copy of the NT OS/2 workbook in my office – it’s a collection of the specs that make up Windows NT (astonishingly many of the aspects of the workbook are still valid even after almost 20 years). In my office, I have a copy of the “NT Plan” which was the original schedule for NT. Some of the entries on the “NT OS/2 Issues” page were:

“Install operating system – who will write?” [Back then, setup was an afterthought]
Programming editor – what editor will we have? Need better than a simple system editor (Better than VI!) [They ended up with “M”, the “Microsoft Editor” which was a derivative of the “Z” editor].
1024 byte sectors for system files. Needed? Needed for Japanese floppies? How needed [floppy support was critical back in the 1990s]
LAN: Who owns the redirector. Need two developers [they got one: me :)]

The original schedule for NT OS/2 was that it would be demoed at Comdex in November showing off 4 “exciting 32 bit OS/2 applications” with no network filesystem support. The plan was for an SDK release in the 4th quarter of 1990. I also have the initial NT schedule for 1991-1993 which indicates that the plan was for 5 separate releases staged from 1991 to 1993, it ended up that none of the individual releases were made but the 5th release pretty closely aligns with the final Windows NT 3.1 project (which is pretty cool given how much changed in the NT project over that time).

In all honesty, I was in over my head on the NT project – I was trying to build a component that was intended for use in a multithreaded/multiprocessing environment having never previously written code for such an environment – before that all my programming had been in assembly on MS-DOS. I learned a staggering amount during my 4 years on the NT team and while it was extraordinarily painful, I came out of the experience a far better developer.