December, 2004

Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    Bobs Math


    And now for something completely different...

    As anyone who reads my blog regularly, I often put forward items that come from the classroom where Valorie works.

    Well, today's no different.

    For the season break, I thought I'd share one of their homework problem, also known as "The Christmas Tree Problem".

    For context, this is a split class of 5th and 6th graders, they're presented with a challenging curriculum that diverges from many of the traditional 5th and 6th grade topics.  One aspect of that curriculum is known as "Bob's Math" (for the teacher, Bob Whittemore).  He covers stuff that's usually far beyond the normal course of study for 5th and 6th graders, some of them are high school subjects.

    Just before the winter break, Bob traditionally assigns this homework problem...

    Find the volume and surface area of the following Christmas Tree:

    One pyramid with L=W=2’ S=2’


    A stick with no dimension.


    An equilateral triangular prism with L=8’ and W=2’.

    A cylinder where r=1’ and w=2’ is cut out

    An equilateral triangular prism with L=1’ and W=2’ is cut out

    Two cones with H=1’, r=.5’  Find the slope or slant height

    An equilateral triangular prism with L=9’ and W=2’.

    Two cylinders where r=1.5’ and w=2’ are cutout.

    An equilateral triangular prism with L=1.5’ and W=2’ is cut out.

    Two cones with H=1’, r=.5’ Find the slope or slant height


    A triangular prism with L=10’ and W=2’.

    A cylinder where r=2’ and w=2’

    Two cylinders where r=1.5’ and w=2’ are cut out

    An equilateral triangular prism with L=1.5’ and W=2’ is cut out

    Two cones with H=1’, r=.5’ Find the slope or slant height


    A base consisting of a single rectangular prism with L=W=2’ and H=3’



    Terms: L=Length     W=Width     H=Height     S = Slant Height    R=Radius


    On this note, I'm off for vacation.  I'll be back late December, but until then, I don't know how spotty my internet access will be.  I'll see what I can do to keep the blog moving forward given the moderation (which I can't remove unfortunately), but ymmv.


  • Larry Osterman's WebLog

    WMDG loses one of its own.

    So often, you don't hear about the developers who work behind the curtains here at Microsoft.  Today I'd like to talk a bit about one of them.

    One of the key developers on Windows Multimedia at Microsoft is Syon Bhattacharya.  Syon was responsible for many of the internal pieces of the multimedia work on windows, much of the core code was written by him.  If you've ever watched an AVI file, or seen a windows media player visualization, you've been running his code.

    He started at Microsoft in June of 1995, straight out of college, and worked in the multimedia group his entire career at Microsoft.  Coincidentally, he also came from Carnegie-Mellon University (I know a bunch of the other developers from CMU that came at the same time as Syon, but didn't know him until I joined this group).

    Syon was an extraordinary developer, he had an encyclopedic knowledge of the internals of the multimedia code.  When we were doing the code reviews for XP SP2, when I'd see something that I thought was a vulnerability, I'd wander over to Syon's office to ask him.  Syon not only knew the code I was looking at, but he was able to reconstruct (from his head) all of the code paths in which the potentially vulnerable routine was called.  He's the person that the multimedia team went to when they had tough problems - there didn't seem to be a problem that he couldn't solve.

    In addition to being a complete technical wizard, Syon was one of the nicest persons I've ever worked with, his unflagging good humor throughout development cycles was legend around this group.

    Two years ago, Syon was diagnosed with stomach cancer.

    He continued to work, although it was clear that the treatments were taking their toll on him - I often saw him walking down the hall looking horrible, I'm sure that the treatments were hideously uncomfortable, but he pressed on.

    Over the summer, Syon took a leave of absence to concentrate his energies on fighting the cancer that was eating away at him.

    Unfortunately, yesterday he lost that battle, he passed away at a hospice in Seattle.  His family and friends were with him at the end, and it was apparently very peaceful.  He was 30 years old.

    We will all miss him, the world is a smaller place without him.

    Edit: I'll be adding recollections to this post as they come in...

    I've asked my group (and others) to collect their memories of Syon, here's what they wrote (in no particular order):

    Ji Ma:

    I know Syon since I was transferred to DirectShow group almost 6 years ago.  He was hard working soul and low profile person and easy to talk to.  He has amazing ability to solve very tough computer problem and was always willing go extra miles to help others and he knows so much and so deep about computer and programming that he can solve almost anything that no other people can.  I found him to be indispensable dependent technical resources and ideas.  When ever I have difficulty or lack of idea, I will look up to him for help and he always let me a hand.

    He was easy going and willing to listen and we had very good work relation since many of his developed work was tested by me so we interact a lot and we were truly perfect match to each other and great team.  Many times, I just went to his office and we chat about many things in life and he was always willing to listen and provide valuable comments and genuinely enjoy and appreciate the conversation.  It is very rare in the working environment.  I will always remember him for that.  

    I have several fruit trees and some vegetables grown in our garden.  When it was harvesting time, I brought some to our group and passed to many colleges, including him.  He always admires and grateful to what he get, an apple or a tomato or what ever.  I can tell he true enjoy and appreciate the friendship that we had. 

    He talks very little about his personal life so it is mystery to me and I only know he lives around green lake area. 

    Syon, may you rest in peace and we will always remember you.

    Tracy Shew:

    When I first came to Microsoft as a contractor five years ago, it was sometimes difficult and daunting to work with developers.  These were, after all, the people who had written the code for Windows.  Many of them sometimes acted as if they were aware of this fact, and of the distinction between their station and mine – a mere software tester.  The tester – developer relationship can be antagonistic at times, particularly if I had the gall to find a bug or regression in “their” code.  Sometimes, some developers had little time for my questions, and acted as if my concerns were unimportant.  This was discouraging for me, and made me question why I was working at Microsoft at times.

    Syon, more than anyone else, gave me encouragement to continue.  He was a developer, and he was brilliant, but he never – and I mean never – acted as if my concerns were unimportant.  His door was always open, and he always seemed to have the answer ready – or if not, he knew the person to go to.  And he never made me feel ignorant or inferior to him for having to answer a question.  I quickly learned that Syon was a valuable resource, a wealth of information.  But it was much more than that.  Syon taught me, through his example, that I was not a “mere tester” – that I was making an equally valuable contribution to the product.  This encouraged me to continue at Microsoft, eventually becoming a full-time employee in test.

    I had the pleasure to work closely with Syon for almost four years, being the main tester responsible for checking his code.  Syon’s skill was unquestionable; problems were very rare, and, if one was encountered, Syon was extraordinary at quickly locating the difficulty – even if it was outside his area.  I do not know the number of times he has trudged over to the lab to look at one of our machines.  “Why is it doing that?” we would ask, looking at a bazaar error message or a garbled, incomprehensible stack trace.  I sometimes felt that we took advantage of his openness and generosity – not many developers will “dirty their feet” by coming into the lab to look at a sick computer, unless you can first prove it is their code at fault – they would rather have a remote, at the very least, or have you port the bug off to the “owner” – something which is sometimes difficult to determine.  I tried to use Syon as an “avenue of last resort,” lest we overuse the resource – if we absolutely couldn’t determine the issue, and know one else knew what was happening, only then would we bring in Syon.  And, in four years of steady work, day to day, I can count on one hand the number of times we managed to stump him.  And never, not on a single occasion, did Syon refuse help because he was too busy, or because it was not his area, or for any reason at all for that matter.

    Since Syon’s illness took him away from work, there hasn’t been a week go by that this resource hasn’t been missed.  Very frequently, an issue will come up, and someone will say, “If Syon were here, we could figure this out.”  His combination of knowledge, intuition towards problems, and plain generosity in sharing what he knew is unequalled.  People often use the word “irreplaceable” when they lose a colleague, but for us there is no degree of exaggeration in applying it.

    For me, though, Syon was more than a resource.  He demonstrated to me the value that I was contributing to Microsoft, and a vision of the partnership that should exist between development and test, and between teams, where “ownership” should not be used either as a dividing line to avoid issues, nor as a way of assigning responsibility or blame.  Syon simply loved making the best code he could, and he loved solving problems, so he saw all of our contributions, whether development or test, assisting in this process.  He encouraged everyone around him to do their best, and to be excellent.  I wished I could have known him better – losing him is a tremendous blow, certainly professionally, but also personally.  Even though we had a professional rather than social relationship – you would have to call us colleagues rather than friends – I am grateful to him for many different things, and especially for the encouragement he gave.

    Eric Rudolph:

    Syon always was a team player, and he ended up being the backbone of the DirectShow product at Microsoft. After many other people had been reorganized, or had moved on, Syon stuck with DirectShow and not only supported it, but he also supported it's customers and all the accompanying hassles. Not only did he do this really well, but he did it with a gracefulness and humbleness that made it seem easy. Syon knew everything about everything, he was the go-to guy when it came to something that nobody else knew. I don't know a single person at Microsoft (myself included) who wouldn't use that kind of responsibility as a bargaining chip to further their career, but not Syon. When I asked him, "why don't you try and promote yourself more?" He would say, "oohhhh, I guess I'm just lazy." But Syon was anything _but_ lazy. Maybe unmotivated for self gain, but that was one of the things that was cool about him. On a personal note, Syon wasn't easy to get too close to, but I'm proud to count myself among his friends, and he was always up for doing anything. He was my personal movie critic, if I wanted to know if a movie was good, Syon was the first person I would ask. He was an amazing guy, and the effects of who he was and what he did to help people, will ripple outwards forever. I respect him immensely, he taught me many things while I had the chance to work with him.

    Martin Puryear (Dev Manager for WMDG): 

    Syon was one of those rare selfless people that willingly took on any task without a complaint, regardless of the task.  Sometimes the most important tasks are the most tedious as well - ensuring that myriad far-flung fixes were ported back and forth between different OSes; painstakingly crawling through very old Windows source code looking for security vulnerabilities.  I'm fairly certain that I never heard him ever utter a complaint - if he did, then I'm sure it was accompanied with a smile that seemed to say "well, these things happen." 

     Syon was a sterling example of the phrase "still waters run deep."  Over the years he built up considerable expertise in the multimedia arena, but you might not know it from watching his actions.  He always made time to help others, answering even the most basic questions.  Upon asking, one quickly discovered that he understood the overall system and how your question related - and he usually knew the technical details that you needed as well.  After RobinSp himself (overall architect for quartz/ActiveMovie/DirectShow), SyonB was the one to which we repeatedly went with hard problems facing that architecture. 

     Syon didn't have the "rough edges" sometimes found in SW engineers (including the stereotypical MS developer).  If you were wrong, he would couch his words with a soft-spoken "I believe the way it works is…."  He didn't have an egotistical bone in his body - in fact it was understood among managers that we needed to make sure that he got the recognition he deserved. 

     Syon was a class act - in this day and age, the industry needs more like him.  Truly, the world needs more like him.  He will be sorely missed as a coworker and a friend. 

    Steve Rowe:

    When I think of Syon I three adjectives come to mind:  quiet, helpful, and intelligent.  Syon was always soft spoken.  I never saw him get angry or snap at anyone.  He was always calm and collected.  Unlike some people who are good at what they do, he didn’t need to prove it.  He didn’t need the limelight.  Syon was always willing to help.  I never asked him a question he didn’t know the answer to and no matter how busy I’m sure he was, he always took the time to answer my questions.  All you had to do was ask and whatever small feature or tool or tweak you needed would be added.  I recall one time I stopped by to ask him to mock up a fix for a particular issue.  We didn’t need the full implementation, just a simple version to prove it would work.  The next day I had the complete version on my desk.  Syon was extremely intelligent.  He knew the system forwards and backwards.  He rarely had to consult the code, he just knew the answer.  We’ll miss his expertise around here but more importantly, we’ll miss him as a person.  It is rare someone so kind, so willing to help, and so smart comes along.

    Tuan Le:

    Hi Larry, please post another one from me.


    At work, Syon is simply brilliant. Syon will take on any task, big or small, challenging or tedious, with the same level of enthusiastic (in his own quiet, pleasant demeanor), and always come through with amazing execution. It is obvious that Syon takes pride in what he works on and set a very high bar for himself. As a person, Syon is a confidence, generous, patient, gentle, and thoughtful person. Syon is simple wonderful to have as a co-worker, and a friend.


    Syon is someone I instinctively trust and often share thought on things with. My kids love him! Syon always has things or toys to entertain them when ever they stop by his office. It’s hard for us to accept the fact that Syon has moved on, we often talk about Syon as if he is still with us. Of the many things that Syon enjoys, food and speed are high on his list. We talked often about different cuisine / food blog / car racing / driving school / traveling / etc, and we would go out a try a new restaurant whenever we get a chance. Syon enjoys trying and doing new things, he is always eager to join and share with us. We are very fortunate to have Syon in our lives, and he will miss all the good time we have with him.

    Savvy Dani:

    My first encounter with Syon’s hard-core technical skills was soon after I joined the group. There were some 20 odd high-priority non-trivial bugs that needed immediate attention on a Friday afternoon. I didn’t know the team well enough, but there were many strong voices saying ‘Give it Syon’ and I decided to play along. I understood why when I came back on Monday and all issues were resolved. When I tried to praise him, he just shrugged it off with a gentle, self-deprecating smile. I became a Syon fan after that. Time only added good things to my list - extremely smart, dedicated, gentle, compassionate, unruffled, good sense of humor and on and on. I don’t think anybody ever found anything negative in their interactions with him unless he was too good to be real.

    But Syon was real enough when I got to know him better, What stands out for me during the two years I have worked with Syon are my 1:1s with him. I usually started my Fridays with his meeting. Since he was very quiet, we could not go beyond 15-20 minutes initially and that with me doing most of the talking. Since technical issues were a no-brainer for him, our meetings dwindled into silence soon. I told him frankly that we have got to do better, so we came up with this idea to talk about personal things and get to know each other in non-work related ways as well. Syon accepted this gamely and we went on for a year or more. There was a lot of laughing and a good number of discussions during this time. We talked about his love for car racing and taking his Audi for a spin on the safe track (?). We would catch up on the latest movies, good restaurants, his unsuccessful experiments with Indian recipes, my fluctuating aspirations to be a literary fiction writer etc. I suddenly realized this summer that our meetings had gotten longer and that he was doing most of the talking. We would go past the slotted hour and then walk down to lunch. When we exchanged hugs as he went on leave, I knew I was going to miss my friend.

    Syon is not a typical Indian name and I asked him about it once. I believe there are two stories behind his name. a) He was named after Sayanacharya, a great Indian philosopher who lived in the 14th century A.D whose commentaries apparently defined the speed of light to be pretty close to the numbers we have today. b) He was born in London close to Syon park and his parents shortened his name to Sayana and then morphed it to Syon. ‘Acharya’ literally means Master, so Syon definitely lived up to his name.

    Bertrand Lee:

    Syon was from my ECE '95 cohort at CMU, and I remember seeing his name in the CMU newsgroups when he participated in various technical discussions.


    However, I only got to know him a bit better when I worked with him in WMDG, and he struck me as one of the most knowledgeable engineers I have ever had the privilege to work with. As many would attest to, he was _the_ DirectShow guru, and any time I had some intractable DirectShow bug that I was making no headway into, I would consult Syon and he would very willingly come over and help me to debug the cause of the problem, which due to his deep expertise took hardly any time at all, even for the most complex problems.


    More importantly however, he was one of the most gentle-natured and helpful people I've ever known, and I will always remember and miss him as a great person, coworker and friend.

     Steve Ball:

    Hey Larry -
    Although I barely knew Syon, and only had a very small set of direct interactions with him around DShow, I do have a few small observations from my experience in working with and near him over this past three years. 
    Syon was a like Zen master.
    While I run around like a headless chicken most of the time, being with Syon in a meeting or even simply passing him in the hall was always like being in the presence of a great Master.  His pace, his interactions, his movements were always intentional, methodical, calming, even charming.   He set an example just in his being who and how he was: collected, positive, responsive, and ready to embrace and solve even the toughest problems. 
    Just being near him was a calming.  His presence, sincere smile, and the peaceful look in his eyes often felt to me like a gift and provided a simple and wonderful reminder to slow down, collect myself, and be thankful for the amazing resources and opportunities we have at our fingertips everyday.
    His very presence was a gift, and his absence touches me deeply.
    With best wishes to his closest friends and family,
    A Co-Worker:

    I think you're experiencing what a lot of other people have: Syon was such a quiet, unassuming guy who didn't really like to talk about himself much that it wasn't easy to get to know him; he would probably have been embarassed by all this attention.  But everyone who came into contact with him remembers him as the kind, helpful, thoughtful person that he was.  As news of his passing has spread, we've been amazed at the number of people who've come forward with stories about Syon.  Some didn't even know he had been so sick - it just wasn't in his nature to talk about himself.  He died the way he lived: peacefully, with his quiet, inner strength shining through.

    Alex Wetmore (friend from college):

    Syon was always really quiet.  On our last visit together we were trying to remember how we met, but I'm not really sure.  From my freshman to junior years at CMU he spent a lot of time hanging out at my dorm room (my 4th year, his last year, I moved off campus and it wasn't as easy to do so). 
    Recollections are hard.  He was so quiet, but with a great sense of humor.  He never wanted to be a burden on anyone.  In his freshman year he had a collapsed lung and didn't even tell anyway -- I saw him everyday and never learned about it until I didn't see him for two days and his roommate found out where he was.  He loved food which I think made the stomach cancer even harder.  He and my wife Christine used to go hunting around Seattle for the best fried chicken, hamburgers, or other comfort/junk food.  He also loved really good food and knew all of the best resturants in town (but was quiet about it...not the normal belltown foodie type).  I think he was social at heart and liked to be around people, but had a hard time opening up.
    He was at CMU from 91 to 95, EE/CE

    Alok Chakrabarti:

    The most I remember about Syon:
    1.  Whenever I had a stress issue to debug involving a whole bunch threads and random locks taken by components such as DDraw.  I would pull my hair out for a while, narrow it down a bit, and then get totally stuck.  The next step was to walk over to Syon office, ask him to connect the remote (mostly wdeb in those days of Win9x) and go through all those threads and finally figuring out what the problem was, and what to do about it -- mostly assign the bug to someone appropriate.  It became a common thing almost everyday, and I am sure he had enough work to do, but he never stopped taking the time to help out.
    2.  His calmness and that smile: I have never seen Syon getting upset with anything.  He was so calm always.  And that slice of smile he had on his face -- I still remember so vividly.
    3.  His typing speed: That was unbelievable!!! I still can't really type after working with PCs for about 19 years.  But his typing was just out of the world.  And he would thinking even faster that his typing.
    I always will remember him as a person I wished I could be somewhat like, but knew I didn't even have a chance.  He was much younger than me, but still my hero, not to say just today -- I always thought that way.  Such a brilliant but unassuming person, so helpful and nice.  Syon has been so unique.
    Wendy Liu:

    When I first joined MS, Syon was recommended highly on the list as the goto guy for any technical question. He is one of the gurus on DSHOW.

     Syon was not the person who liked to talk too much at work. He always had a cool style and you never saw him rush in the hallway. When you chatted with him, he always spoke warmly, slowly and carried a smile; when you asked him for help, you never expected him to say no. From time to time, he brought fresh bagels and cream to put outside his office to share with us.

    For the last four more years, I have got many helps from Syon. I still clearly remember that I once asked him to take a look at bug which I had been working for the whole day. As usual, he didn’t talk much, and sitting in front of the machine and his fingers moving quickly on the key board, his mind was completely on the bug. He tried various ways to poke it, and more than half an hour passed, we still didn’t get any clue. I began to apologize for the time and asked him to stop there. Still in deep thinking, he kept working. Then he said “Let’s try this.” Bingo! We found the problem.

    Syon was one of the few people I have known who never showed any impatience or frustration. Even when he was telling me that his family doctor had mistaken his symptoms for years, he just sounded unhappy about it and there was no anger in his tone like what I felt at that moment. That was the only time I heard he complained, and it was in such a cool way.

    It is a great loss for all of us to miss such a good colleague. We will always member him.

    Wenhong Liu

    Brent Mills:

    While Syon and I were not close buddies, I always felt comfort in speaking with him, and he always made me curious enough to ask what he’s been up to and how he was doing (before he was sick).  I have not met a more genuinely nice man…Ever! 

    After he left MS, I exchanged a few mails with him and he seemed positive as usual, but I couldn’t help thinking that bad news may be on the horizon….I don’t shed tears easily or often, but I remembered thinking to myself that any person and especially not one as good as he, should be going through something like this; the tears flowed.

    I have and will continue to miss Syon and I hope he is in a better place.     

     Ted Youmans:

    Six years (I think) and I have no anecdotes or stories. What is so surprising about this is that I liked Syon quite a bit. He was one of the nicest and most intelligent people I have had the pleasure of working with here as MS. When I actually came up against something in DShow that I couldn’t find an answer to, he was usually the only one that could answer it. I truly wish I had something to offer for your LJ or for the memory book, but I am coming up with a complete blank. Maybe it’s because I don’t take enough notice of day to day happenings or maybe it’s because the extraordinary was an every day occurrence for Syon and none of it sticks out any more than any other day. What I can say is that he will be sorely missed and this place hasn’t really been the same since he left.

    Penelope Broomer:

    Other than building checkins for Syon during Win2K, he was the point person for the multimedia team, I never got to work with him directly, I therefore consider myself to have been one of Syon’s friends rather than a colleague.  Syon came to our home two or three times, we love our curries and he was very polite about the home made curry we inflicted upon him during his last visit!


    Like many, I have fond memories of Syon, one that springs to mind is the time that he rescued Stephen (stestrop) from the car park at Barnes & Noble in Bellevue.  I was working in the build lab at the time and it was my turn to be on the ‘late shift’, Stephen, facing another night in on his own, went off to Barnes & Nobel to pass some time.  He must have had a lot on his mind as it wasn’t until he was in the store browsing through the computer books that he realized that he didn’t have his car keys.  Concerned, as he thought he’d locked them in the car, he returned to the vehicle only to discover that he’d not only left them in the car but that the car was still running!  He called me in the build lab in a state of panic asking me to go and rescue him – this was as we were coming up to shipping Win2K - it was late in the evening, I was on my own and I couldn’t leave the build lab.  Several calls later Stephen asked me to try calling Syon in his office, Syon was still at work and without hesitation agreed to go to Stephen’s rescue, that’s just the kind of person he was.

    Soccer Liu:

    I remember him as an soft-spoken and sharp thinking gentleman. I worked with him on only on several instances. I had a couple of conversations with him. I really miss him.

    Robin Speed (and Eric Rudolph):

    I guess this old email from Eric sums up Syon rather nicely work-wise..

     He was also a really nice guy – sounds bland but in this case it is true.  He never pushed himself forward – almost to a frustrating level - but always had time for everyone.  People all over knew and respected him.  Someone the word humble truly applied to.  What an unfair world.


    From: Eric Rudolph
    Sent: Tuesday, May 04, 1999 8:53 PM
    To: Robin Speed
    Subject: Syon B, Master Brain

     Whatever we're paying Syon, it's not enough. He always knows exactly how to fix any weird compiler, linker, or base class problems I'm having. The man's a genious.


  • Larry Osterman's WebLog

    Win32 on Win64 Registry support

    We've recently spent a bit of time ensuring that we have a good Win64 story for our components.  For the vast majority of our stuff, it's pretty trivial - our component's a part of the windows base, so it's a 64bit native application, done.

    But of course we need to be able to support 32bit applications that use our stuff (it's audio, after all).  So I spent some time working on our 32bit-on-64bit story.  For us, the 32bit-on-64bit story was pretty easy - all our inter-process interfaces are cleanly defined using technologies like RPC, so we should be able to support 32bit applications by just putting the 32bit version of the DLL on the system (in the SysWow64 directory).

    There's one situation where we need to duplicate handles from a 64bit process to a 32bit process, but the good news is that NT handles that perfectly - DuplicateHandle knows the type of the target process and does the right thing.

    We finally got around to testing this last week and not surprisingly, we ran into an issue.

    When running one of our 32bit components, we discovered that we couldn't access any of the data put into the registry by our 64bit applications.

    So it was time to start digging.  The problem is that there are actually two separate registries on Win64, one for 32bit applications, the other for 64bit applications, so I needed to be able to open key in the 64bit registry not in the 32bit registry.

    Fortunately, Raymond and Junfeng came to my rescue and pointed me to the KEY_WOW64_64KEY

    In fact, Junfeng has this great post that describes exactly this issue, including how to use this key.  He also includes this link that describes the registry virtualization.

    So we were set.  Except we discovered that we couldn't delete any of the keys - the RegDeleteKey API kept on failing with ERROR_FILE_NOT_FOUND.  So did ShDeleteKey.  Clearly these APIs were ALSO going to the 32bit registry.  Once again, Junfeng came to the rescue with this post (made exactly after the last one :)) that pointed to the RegDeleteKeyEx API which allows you to specify the KEY_WOW64_64KEY flag.

    So problem solved, and now our stuff is working perfectly on Win64, for both 64bit and 32bit apps.  O Frabjous Day, Calooh Callay!


  • Larry Osterman's WebLog

    What does _imp_<Function> mean?

    Someone here just asked this question to one of our internal mailing lists:

    I think this is a rather basic question, but I can’t find an answer in any debugging books I have or on the Net with google.

    How does “_imp” get added to function names and what does it mean? Often when I am debug in ntsd I jump into functions named _imp_XXX. I’m curious what this decoration means? Is it related to functions exported from a DLL?


    It's actually a good question, the answer has to do with how DLL's work under the covers.

    When you reference a function located in a DLL, the compiler just inserts:

        call CreateFile

    into your source code.

    When you link your module with the library, the librarian creates a "thunk" for that function that looks like:

        jmp [_imp__CreateFile]

    It also defines a global variable named "_imp__CreateFile",  in your data section.  It also inserts a DLL import reference in your binary that contains the name of the external reference (the DLL name and the entrypoint in that DLL).  That import reference also contains the location of that global variable (table that contains the global variable's called the "Import Address Table", or IAT).  When the loader fixes up your module, the loader will insert the address function referenced by the import reference (CreateFile in this case) into that global variable.

    This way, the loader only needs to fix up one location in memory for each DLL import, not every single possible occurrence, which can be a HUGE performance win when loading the module.

    The interesting thing about this is that the call into the thunk is actually unnecessary.  The compiler could just as easily have inserted:

        call [_imp__CreateFile]

    when it generated the code.  But there's one small problem - the compiler has no way of knowing if the function you're calling is located in a DLL or in another source file.  Since it can't know the difference, it assumes that the code's in another source file, and thus doesn't call into the function pointer.

    Fortunately, there IS a solution.  The compiler defines a declaration specifier called "__declspec(dllimport)" that informs the compiler that the function in question will be located in a DLL.  In that case, it uses the latter form of the CALL instruction instead of calling into the thunk.

    This can be a huge improvement in performance because removing the thunk improves level2 cache locality.

    So if you see the call [_imp_<function>] pattern, you know that the DLL used __declspec(dllimport).

    And if you see a call into your DLL that's going through the thunk, you should seriously consider using __declspec(dllimport) to improve your performance.


  • Larry Osterman's WebLog

    Moving Offices

    Well, last week, we had yet another office move.

    Office moves are sort-of a tradition at Microsoft, this one's something like my 20th.  Personally I think that management schedules them just to make sure we don't collect too much junk in our offices... 

    For me, it doesn't help, I moved 14 boxes of stuff this time (and a boatload of legos that were stashed in my grandmanagers office).

    As I said, moving's a regular occurrence - I'm in my 4th office in this building alone.  Fortunately, intra-building moves aren't NEARLY as painful as inter-building moves, but they're still a pain in the neck.

    My longest time in an office was something like two years, my shortest was 2 weeks (they moved us out of building one into building four for two weeks while they moved another group out of building two, then moved us from building four back into building two).  I've had corner offices (twice, once in building two, another time in 25), I've had window offices and I've had interior offices.  I've got to say that I REALLY hate corner offices - my office has a whiteboard, a corkboard and two bookshelves, but in a corner office, you lose one of your walls, which means that you can only have two of the 4 items (we have modular shelving and corkboard units in our offices, in an interior office, you get two walls full of hanging shelving racks, in a corner office, you only get one, plus a partial one).  The great view doesn't even come close to making up for the loss of a bookshelf.  In my case, one of my bookshelves is filled with lego models, but who's counting :)

    I can't wait to see the view from my new office though - it faces more-or-less northeast, which means that I get to see the Cascades.  I took the opportunity to reorient my office as well - traditionally, I have had my office laid out like this:

    But I'm laying my new office out like this:

    just to take advantage of the view (Ignore the units, they're Visio goop from when I made the drawing).  I like facing the door (so I can see who's coming), but I figured that the view would be worth the startle effect.  I suspect I'll end up getting a mirror to put into the window so I can see people at the door...  The cool thing about the new layout is that I'll be able to add a round table to the office, so I'll be able to get the manipulative puzzles off my main desk onto the round table.

    Unfortunately, this morning, just before came into work to unpack, the fan motor on the AC blower feeding into my office gave up the ghost, filling the office (and the corridor) with REALLY noxious fumes, so I'm currently installed in an empty office near my office (I'd forgotten how heavy a 21 inch CRT monitor is).

    Anyway, today's tech-light, hopefully I'll get bandwidth to do more tomorrow.

    Edit: Clarified text around new office layout, it was awkwards.


  • Larry Osterman's WebLog

    Going dark until next week


    No posts until then, moving offices and...


  • Larry Osterman's WebLog

    Interview Questions


    Heather, Gretchen and Zoe are going to kill me for this one, but it was cute...

    Yesterday, we had a 5th anniversary lunch for one of the developers on our team.  One of the other developers related the following story about his internal interview.

    First a bit of a word about internal interviews.  We interview internal candidates for positions, just like we interview external candidates - the internal candidate carries a bit of history forward, but they can be just as grueling, both for the interviewee and the interviewer (especially if they're new and interviewing someone more senior).

    In this case, the interviewee came into the office, and the interviewer asked him a coding question (yup, we get them too).

    "Design a vector template class, with the following operators and characteristics..."

    The interviewer was stunned at the response:

    "No.  That's a horrible way of doing it, it wouldn't make sense."

    It totally took the interviewer by surprise.  What do you do when the person you're interviewing refuses to answer your question?


    Well, in this case, he gave him a hire recommendation - the interviewee was totally right, the question he was asked was completely arbitrary and he gave great reasons why it was a poor solution to the problem.  They moved on to other things and, as I mentioned, the guy was hired into our group.

    Btw, I would NOT recommend doing this on your interview, unless you REALLY knew what you were doing.  For everyone who gets away with stuff like this, there are a dozen who don't.

    But it was kinda funny.  I'd have loved to see the expression on the interviewers face.

  • Larry Osterman's WebLog

    I couldn't pass this by: KenJen's now working for Microsoft as a spokesman for Encarta


    From Betanews (found on Neowin):

    Jeopardy Whiz becomes Encarta Spokesman

    You go dude!


  • Larry Osterman's WebLog

    Slavish Compatibility


    It's no secret the levels of effort that Microsoft goes through to maintain software compatibility.

    However, it's not as well known that Microsoft's hardware division has a similar passion for compatibility

    Back in the early 1990s, Valorie worked on printer drivers for Windows 3.1. Her division was led by Steve Shaiman (another person in the division was a program manager named Gabe Newell)

    When Steve was cleaning out his office one day, he found a box in his office, and he checked what was inside it.

    It was the very first shipment of Microsoft Mice, newly arrived from the factory in Microsoft Taiwan.

    He kept one for himself, gave one to Valorie, and sent the rest to the Microsoft archives. Valorie, in turn gave the mouse to me, since she knew I had a collection of Microsoft mice hung up on my office walls.

    Fast forward ten years, it's now 2001. I'm working in the Connected Home Business Unit, which was (at the time) located in the same office area as the Microsoft hardware group.

    Just for grins, I showed the device compatibility tester for the hardware division (the entire wall of his office was covered in mice).

    So what's the first words out of this guys mouth?

    "Hmm.  I wonder if this thing works with our current drivers?  No reason it shouldn't.."

    He removes the mouse from the packaging, plugs it into the serial port of his Windows 2000 machine, and the mouse driver on the machine detected the mouse, and started using it.

    So the current Microsoft mouse driver even supports the very first Microsoft mouse ever delivered.


    Now THAT'S compatibility.

  • Larry Osterman's WebLog

    Why doesn't Disney's "Adventures in Typing with Timon and Pumba" work on my PC?


    Sorry for the sort-of dorky title, it's for google.

    Today, Sharron finally finished the Aventures in Typing program.  Her 3/4 class uses it to teach typing (yeah, they teach typing to 3rd graders these days).  It's actually a pretty cool typing program.  At the end of the program, Timon and Pumba play a little song, and the entire class clusters around the person who just passed the program to cheer them on.  Sharron's been working on it really hard, and it's awesome that she's finally passed it.

    We're actually the person who found the program for the class, Daniel used it to learn how to type back when he was in 3rd grade.  To give Sharron a headstart, we installed it onto her machine.

    When she started the program, she got an error "Assert Failed: NumAudioChannels == 2/c:\src\DivCore\PlatformWin95\SsoundSystem.cpp line 119 ".  I spent a huge amount of time trying to figure it out (now it can be found on the web but at the time it wasn't available on google).

    The reason that this fails is because there was a winmodem installed on my daughters machine with a 3rd party driver for the modem installed.

    The way that winmodems work is that they effectively function as PCM audio output devices - the modem driver on the PC generates the modulation tones that will be emitted on the phone line, and submits it as a PCM stream to the waveform audio output device on the modem.

    Some modem manufactures hook their modem devices up as waveform devices on the PC (the built-in driver for winmodems doesn't), this makes their drivers easier to write, but it can cause problems.

    You see there are a bunch of applications out there that write to wave channel 0 and assume that it's always the default audio device on the computer.  Since most computers only have one sound card, that can be a reasonable expectation, but if you're running on a machine with one of these winmodem drivers installed, there are TWO audio devices.  If the winmodem gets wave device 0, then it will be the device that is used as the "default" device for these apps.

    Timon and Pumba is one of those applications that assumes that device 0 is the default audio device - they start up and find the modem and check to see that its a stereo device.   Since winmodems are mono, the application fails.

    For Timon and Pumba, my solution was simply to remove the OEM driver for the winmodem - that removed the waveform driver, windows inbox driver picked up the modem and it appears to work ok (of course we don't actually use the modem since we have broadband at home, but...).  I've also read that disabling the waveform device will also fix the problem.

    If you're writing a waveform based application, and you want the default audio output device, you should use the special wave device WAVE_MAPPER instead of 0 to get the default device.

    Btw, in Windows 2003, we changed the audio device mapping code so that the default audio device always appears as waveform device 0, just to solve this problem.  It doesn't help Windows XP customers, but in future versions this shouldn't be a problem.


  • Larry Osterman's WebLog

    Why is the compiler flag for symbols -Zi?

    If you want the compiler to emit symbols for your application, you need to specify the "/Zi" command line switch.  But where on earth did they chose "i" for the flag to enable symbols?

    It has to do with the original Microsoft symbolic debugger.

    Way back when, in the mid 1980's, Dave Norris and Mike O'Leary were working on the debugger for Microsoft C version 4.  They realized that they really wanted to work on a true source-level debugger, and so they proposed (and got approval) for the project.

    That project, code named "Island" evolved into the first Microsoft symbolic debugger, eventually named CodeView.

    To enable symbols for "Island" in your binary, you needed to specify a special compiler switch, named for the debugger - so /Zi was born.

    Just a silly piece of ancient history.


    On a more personal note, we're getting really close to the end of our current milestone, and we're moving offices next week, so I'll likely be going dark for a short while in the near future.  We'll see how crunched I am, but...


  • Larry Osterman's WebLog

    Hiding Complexity

    In a comment on yesterday's post, Manip asked:

     Larry: You said Macros work to hide the complexity and say so like it is a bad thing.. ? Excuse me but I thought that was the POINT of using a Macro..

    Actually, in the world in which I live (writing systems programs that exist in the working set of hundreds of millions of users), hiding complexity is a very, very bad thing.

    You need to be VERY careful whenever you do something that hides complexity, because it's likely to come back and bite you on the behind.  I wrote up this story back in April, but it bears repeating:

    Way back in the days of MS-DOS 4.0,   I was working on the DOS 4 BIOS, and one of the developers who was working on the BIOS before me had defined a couple of REALLY useful macros to manage critical sections.  You could say ENTER_CRITICAL_SECTION(criticalsectionvariable) and LEAVE_CRITICAL_SECTION(criticalsectionvariable) and it would do just what you wanted.

    At one point, Gordon Letwin became concerned about the size of the BIOS, it was like 20K and he didn’t understand why it would be so large.  So he started looking.  And he noticed these two macros.  What wasn’t obvious from the macro usage was that each of those macros generated about 20 or 30 bytes of code.  He changed the macros from inline functions to out-of-line functions and saved something like 4K of code.  When you’re running on DOS, this was a HUGE savings.

    Because the macro hid complexity, we didn't realize that we'd hidden a huge size problem in one line of source code.  When you're dealing with an OS that runs on machines with 256K of RAM, that hidden complexity is a big issue.

    The usual reaction that people usually have to this story is "What's the big deal.  That was 20 years ago, you idiot, machines now come with gigabytes of RAM, nobody cares about that stuff."

    But they're wrong.  The same issue shows up even on today's machines, it just shows up differently. On today's machines, the bottleneck isn't typically the amount of physical RAM on the machine, instead, the bottleneck is in time to read an image from the disk. 

    The thing is that the speed of RAM is limited by the speed of light, and the laws of quantum physics, but the speed of a hard disk is limited by the physics of large objects.  As a result, reading data from RAM is blindingly fast compared to reading data from disk (no duh). 

    Every page that's faulted into memory while loading your application adds between 10 and 50 milliseconds (or more, if the machine's got a slow or fragmented hard disk) to the boot time of the system. The larger your code, the more time it'll take to load it into RAM. 

    If the user can't use the system until your code's been loaded into RAM, then you just kept them from doing their work.  And that's the world in which I live - the system can't log the user on until the audio subsystem's loaded (at a minimum to play the logon chime), so it's really important that my code come in as quickly as possible.

    We have teams of engineers in Microsoft whose sole job is to profile the disk boot process of Windows - they investigate literally every read from the disk that occurs during the boot process to ensure that it's necessary.  If a components code is taking "too many" disk reads to load, then these guys will come down like a ton of bricks on the poor developer responsible for that code.

    So it's CRITICAL that I know where all the code in my application is going, and what it's doing.  If I've hidden complexity in a macro, or a templated function, then I may have many pages of code hidden behind a single line of source.

Page 1 of 1 (12 items)