February, 2007

Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    Vista Ship Gift, Part 2


    It's a Microsoft tradition that the people who worked on a project get a copy of the project when it ships.  I've got copies of OS/2 1.1, NT 3.1, Exchange 4.0, 5.0, 5.5 and 2000 on my shelves, for example, all with their shrinkwrap untouched.

    Well, my copy of Vista finally showed up yesterday, and the ship gift people totally outdid themselves this time.

    Here is. 





     You probably can't make it out in the pictures, but across the front and back is a subtle wash consisting of code - don't know what code it is, but it's code.

    On the front is the word "HANDCRAFTED" and the Vista logo

    On the back is the text:

    "BY YOU

    We build software line by line, idea by idea, side by side.  Our software is an expression of ourselves, our best moments, our toughest challenges, our greatest hopes.  So it's a strange and beautiful day when this handcrafted product leaves our labs and appears on millions of computers around the globe.  Remember this day.  You have changed the world."

    Inside the fold is a collection of pictures, some from the ship party, some from inside Microsoft:

    I normally don't open the packaging on my ship gifts but in this case I made an exception, because again, this one was special.




     The text on the back reads:

    "FOR ALL THE...

    Delighted customers, great ideas, tough deadlines, clever solutions, lines of code, pages of specs, runs of automation, lines of text, screens of UI, missed dinners, fixed bugs, inspiring teamwork, countless iterations, courage to break the rules, time away from loved ones, times you rose to the occasion, late nights, early mornings, delayed vacations, chances you took, long meetings, short meetings, canceled meetings, killed features, features that wouldn't die, crashed machines, moments of victory, moments of defeat, coffees, doughnuts, pizzas, beers, relentless dedication, blood, sweat, and tears.


    And I want to thank whoever it was on the product team that designed this packaging.  It's absolutely awesome, and I think it totally captures the effort that went into Vista.  I especially love the text on the inside package.

    It's funny - when the commemorative edition started showing up, I noticed something unique. In my 22+ years at Microsoft, I've NEVER seen people take the "thank you" copy of the product out and show it to others.  But when we got this copy, there were lots of people walking around the halls showing the box off to others.  Every one of them called out the text on the package as being meaningful.

  • Larry Osterman's WebLog

    The Sad Story of CoGetMalloc


    Ok, I admit it.  I'm a geek.

    I'm actually one of those people who rants over the loss of the printed version of the platform SDK documentation (I still have some of the original Win32 Platform SDK documents in my office and use them regularly).

    One of the things I used to LOVE doing is to take the old platform SDK documents, there was all SORTS of stuff that you could find in them.  It was just FUN to read through and look at all the cool APIs people had come up with.


    If you look through the COM documentation, you'll find a bunch of rather fascinating entries (I started this article with the comment that I'm a geek, right?).

    COM describes a bunch of memory allocation routines - there's CoTaskMemAlloc, CoTaskMemFree,  CoTaskMemRealloc.  There are even APIs to allow you to spy on allocations (CoRegisterMallocSpy and the IMallocSpy interface).  This makes sense - as a part of the contract for any interface, the allocation strategy associated with that interface needs to be documented, COM encapsulates the allocation strategy in the CoTaskMem* APIs.

    There's also this rather odd duck of an API called CoGetMalloc.  CoGetMalloc returns a pointer to an object that implements the IMalloc interface.  And it turns out that the CoTaskMemAlloc, CoTaskMemFree and CoTaskMemRealloc routines are really just procedural wrappers around the IMalloc interface.  If you think about it, this is just wierd.  Why on earth would there be a function that allows you to retrieve a pointer to an interface that duplicates other functionality?  It's not likely it's for efficiency.

    It turns out that way back when - so far back that it's almost in prehistoric times (we're talking Win3.1 here), the COM memory allocator operated on a per-apartment basis.  It was possible to replace the default allocator for a particular apartment, and that allocator would be used for all subsequent COM calls.  Obviously you can't perform such a substitution on-the-fly, so you had to establish the allocator when you created the apartment in the first place.  And that's what the first (now reserved) parameter to the CoInitialize and CoInitializeEx API used to do - it was a pointer to an IMalloc object which would subsequently be associated with the apartment.  In Win3.1, that first parameter was a pointer to an IMalloc object.

    At some point after this, it was determined that having the ability to provide an application specific allocator was a bad idea and the functionality was removed - I'm not sure why, but it was.

    After the ability to set an allocator was removed, there was no need for an API to retrieve the allocator (after all, since there's only one allocator, you're always going to get the same answer).  But of course, since it's been a documented API since COM was first created, it lives on.  It's the COM version of the human appendix - a sad remainder of a time long gone that has outlived its original purpose.

  • Larry Osterman's WebLog

    Why was the ability to specify an allocator during CoInitialize removed from the system?


    Yesterday I talked about CoGetMalloc.  One thing I didn't include was why the ability to specify an allocator was removed from the system.  If you've read Raymond's blog, the answer should be obvious.  I suspected it, but wasn't sure, but after I submitted yesterday's post, I got an email internally.

    The ability to specify an allocator was a feature added back in the days when applications were trusted not to screw up.

    Unfortunately, whenever applications are given the ability to screw up, they did.  They provided their own IMalloc implementations, many of which didn't correctly implement the IMalloc contract.  Now this isn't necessarily a big deal - the application just stomped on itself, right, so it's the application's fault, right?  Well yeah, but sometimes these 3rd party allocators took out windows components as well.  All in all, it wasn't very pretty.

    When the 32bit version COM was implemented (for NT 3.5), the decision was made to deprecate the first parameter to CoInitialize/CoInitializeEx.  The IMallocSpy API was added to allow applications the abiity to track leaks and monitor memory.  The COM guys were able to get away with this breaking change because all 32 bit applications were new applications, thus no existing applications would be broken by the change.

  • Larry Osterman's WebLog

    Witnessing the CSI Effect first hand


    Recently someone internally proposed that windows automatically filter the output of the speakers from the audio samples being captured.

    I was chatting with Valorie at dinner last night (we had dinner at The Herbfarm for a combined 20th anniversary and 45th birthday celebration - major yum) and their proposal came up.  All of a sudden I realized that I was seeing a perfect example of the CSI Effect.

    The CSI effect is SO cool.  The CSI techs get a 911 recording of a phone call, and they ask Archie the digital magic guy to "clean it up".  Archie starts playing it back, and the cool waveform shows up on the screen.  Catherine Willows says "Get rid of that road noise", Archie clicks his mouse a couple of times, and Voila! all of a sudden you have a perfectly clear representation of the voice of the kidnappers accomplice.

    This shows up in other ways, but most often, it's a variant of asking the lab rat to "remove that guys voice", and magically he (or she) does it.

    For CSI shows, it's easy.  Why?  Because the CSI special effects people created the tape in the first place by taking all the original elements as separate tracks (the kidnappers voice, their accomplice, the road noise) and merging them into a single tape.  Then when it comes time for them to extract the specific sound that is necessary to advance the plot, what do you know, there it is!


    However, in the real world, extracting sounds like this is a bit like separating out the salt and pepper from the salt & pepper mixture they use at Subway restaurants (or unscrambling an egg if you'd rather).  The problem is that when you enter the digital domain, all you have are discrete samples, it's not clear where those samples came from.

    Complicating things is that many inputs are usually mono, and the source of the audio almost always comes from multiple locations (which means that all the samples from all the different sources get squished together).  As a result, picking out the inputs that come from the various discrete sources can be quite complicated (especially indoors where sounds reflect off walls and stuff).

    Now in the case of the "automatically filter" proposal, the filterers have an advantage that the CSI guys don't.   They have the pristine audio samples before they're handed to the audio card.  That means that they have a representation of the samples they're trying to remove, and that helps a LOT.  The problem is that between the pristine audio samples being rendered and the captured audio samples, there's this nasty ugly place called "the real world".

    And in the real world, things get messed up.  And there are TONS of ways that they can get messed up.  They get messed up by low quality PC speakers, by crappy microphones, by ambient room noise, etc. 


    Now it turns out that there's a huge body of work involved in just this problem because fixing it is really important to a large set of people (mainly telephone companies, which have to deal with this issue all the time).  In the industry the techniques used to remove the source are known as "Acoustic Echo Cancellation".  The thing about AEC is that it's not perfect.  It's good, and you can apparently remove about 25dB of the input source, but it's not perfect (The "volume" of a signal halves at every 6dB reduction, so the microphone will actually pick up the output of the speakers, but at around 1/8th the original volume) .  The Wikipedia entry I linked to above has a list of some of the problems facing AEC algorithms.

    One other problem with AEC is that the process degrades the quality of the captured signal.  Maybe not much, but some.  When the ultimate receiver is a human ear, the reduction in quality isn't that big a deal (because the human ear is incredibly forgiving), which is why the telephone companies and most voice IM applications use it.  On the other hand, that degradation would be disastrous if you were to record a concert.


    But right now, the idea of simply stripping out the output audio samples and generating a pristine version of the captured signal isn't feasible, at least not without having the benefit of Jerry Bruckheimer's crack special effects people working for you.


    OT: While researching this post, I found a cool blog called "The CSI Effect", written by Andrea Campbell, an author who specializes in writing books about forensic science and criminal justice.  It looks like fun (yeah, I'm a total geek, I know that).

  • Larry Osterman's WebLog

    Remembering old CPU bugs.


    I was browsing through the Bonus Chapters for Raymond's book and I remembered an old CPU bug we encountered with the early 286 processors.

    Back in those days, it was common to manipulate the processor directly, especially from inside the operating system.

    Whenever we needed to have a period of time when we didn't want the OS interrupted by the hardware, we used the handy CLI instruction to turn them off.

    The CLI instruction (and it's partner STI) clears (and sets) the "interrupt" flag that's part of the processor state.  There are two other instructions of interest - pushf and popf which push all the processor flags onto the stack and pop them off.

    As a result, periodically inside the system ROMs and OS, you'd find the following sequence:


    pushf                              ; Push flags on the stack
    cli                                   ; Disable interrupts, we're doing something



    popf                               ; Restore interrupts to their previous state.


    The problem was that this version of the 286 had a bug in the popf instruction. If you executed a popf instruction when interrupts were off and the flags value on the stack also had interrupts disabled (in other words you were transitioning from "interrupt disabled" to "interrupt disabled"), the processor would enable interrupts (and then turn them off again).


    Unfortunately that had the side effect of potentially allowing an interrupt to occur when the system didn't expect it.

    I'd forgotten how we fixed the problem, but amazingly enough, the first hit I searched for was from a Mike Abrash article in Byte magazine which (in part) discusses the issue and describes a workaround.

  • Larry Osterman's WebLog

    A Midsummer Night's Dream at Everett Performing Arts Center



    It's openng night!

    Daniel opens as Demetrious in Shakespeare's "A Midsummer Night's Dream" tomorrow!



    Songs like "Why do fools fall in love?," "Goin' to the Chapel," and "Love Potion #9" highlight the emotional narrative of this classic comedy of teen age romance and an elopement run amok. Enter the 1957 Athens High School gymnasium as students and faculty alike prepare for a magical prom night full of romance and mayhem. It's pure Shakespearean verse with poodle skirts, greasers, and cheerleaders.

    February 9–18, 2007


    February 9, 10, 15, 18 at 7:30 PM, February 10, 11 at 2:00 PM


    Everett Performing Arts Center, 2710 Wetmore Avenue, Everett.


    Ticket Prices: General $9, Youth and Senior $8

    Edit: Larry shouldn't post after midnight :)  Fixed some spelling "issues"

    Box Office: (425) 257-8600.

  • Larry Osterman's WebLog

    Living with Windows Home Server, Day 0.


    Soon after I posted this mini-review of my Mirra home backup solution, Charlie Kindel sent me mail describing a new product he was working on code named "Q".

    I was darned impressed with the idea, and was briefly tempted to jump ship from the audio team and help out (obviously I didn't). 

    Fast forward to the beginning of January this year.  Charlie stopped by my office on his way to the lead PM in my group.  We chatted for about 15 minutes about what Q was, and I got really excited.

    Charlie took pity on me and offered me a chance to beta test the WHS software when it finally hit beta.


    Well, yesterday WHS Beta 2 went live and today a nifty new box showed up in my office (thanks Charlie!).

    Being the geek that I am, I immediately ran home and set it up, and I've got to say, the WHS guys really outdid themselves.

    Installation was totally smooth, one UAC elevation and it was done.  I've currently installed the client on 2 of the 6 machines we own, and it's worked very well. 


    The WHS management console is simple to use, scheduling a manual backup was trivial.  One limitation I noticed is that you can't backup up multiple machines at the same time, that may be an issue if you have a large number of machines in your house (I've not hit it yet, so I can't say).

    One thing that surprised me was the speed of the backup process.  It started slowly, analyzing the hard disk, but once it started, it SCREAMED (it maximized the 100Mbs ethernet link I have between the two machines).  That, almost more than anything else impressed the heck out of me.

    Next step: Loading up my music and photos onto the server.

    If my first impression holds, it's going to be hard to give this one back once the beta's done :).

  • Larry Osterman's WebLog

    Looking for Autumn...


    I just noticed this on Engadget.

    A Vanity Fair writer named Nick Tosches set off on a seemingly quixotic quest to find the origin of the Windows wallpaper "Autumn".

    Eventually, through many twists and turns (and some apparent arm twisting by a senior photo editor at VF), he was able to discover the name of the photographer, and from him (and some interesting detective work by some locals) he was able to find the original location of the photo.


    An awesome read.

Page 1 of 1 (8 items)