Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    Jon Wiswall's started blogging...

    • 0 Comments

    I don't normally do “hey, he started blogging” posts, but I just noticed that Jon Wiswall has started a blog.

    Jon's one of those guys who can be counted on for insightful and intellegent answers during internal discussions, I know that when I see one of his responses, his answer's going to be the right one.

    Subscribed.

     

  • Larry Osterman's WebLog

    New Exchange 'blog post, this one on push notifications

    • 0 Comments

    Nico over in Exchange just told me that he posted my article on Exchange’s Push Notification feature, so included by reference :).

  • Larry Osterman's WebLog

    Three years ago today

    • 0 Comments

    I was cleaning up the remaining bits in the Simple Control Protocol, and wondering what I'd be doing next.

    SCP was a cool project to work on - it was a low bandwidth networking technology intended for home automation.  On the project, I was responsible for many of the DDK components, and a bridge that alllowed you to control SCP devices using UPnP

    17.

  • Larry Osterman's WebLog

    Comment Policy is now up.

    • 0 Comments

    I got nailed by a new blog-spammer yesterday, so it's my turn to follow KC and Raymond and post a comment policy.

    My new comment policy can be found here.  It's unlikely to change anything, except for the blog-spam, I've never had any issues with anyone commenting on my post that violated it, but...

     

  • Larry Osterman's WebLog

    Just ran into this on /.: Amit Singh's essay on computer security.

    • 0 Comments

    Which can be found here.

    A truely fascinating read.  I just had a quick read-through this morning, but I definitely want to go back later today and read it in more detail.

    From what I saw earlier, no FUD, just facts.  Very nicely done.

     

  • Larry Osterman's WebLog

    Every programmer should know assembly language - part two

    • 0 Comments

    Jeremy Kelly pointed me to this post that he made about a debugging session that the Exchange escalation guys did that discovered a rootkit running on a customers machine.

    It is an awesome detective job, and it’s a great example of exactly why (a) Every Developer needs to know Assembly and (b) Why you need to reformat your machine after you’ve been infected.

    The ONLY way that they discovered that this machine had been rooted was the fact that the rootkit had a bug.  If it hadn’t been for the bug, the poor customer would have never known that he had a problem, until much later.

    And yes, stuff like this happens a lot.  We’re very fortunate that we have some really talented escalation engineers working here that can diagnose stuff like this, but it’s a part of the skill set that developers and support people need to have.

     

    Way to Go Jeremy, a great read.

     

  • Larry Osterman's WebLog

    More Exchange stuff posted

    • 0 Comments

    KC just told me that she posted one of my Exchange articles, this one about Bedlam DL3.  Enjoy!

     

  • Larry Osterman's WebLog

    Dave Ross has a weblog!

    • 0 Comments

    My favorite talk radio host has a ‘blog!

    http://www.daveross.com/baghdad/baghdad.htm

     Now I need to convince him to add an RSS feed.

     

  • Larry Osterman's WebLog

    Another Exchange blog posted

    • 0 Comments

    KC just posted another of my Exchange blog entries.  This one’s on the Exchange 2000 access rights and how Exchange 5.5 access rights were represented in Exchange 2000.

    Enjoy!

     

  • Larry Osterman's WebLog

    Exchange 5.5's access check logic

    • 0 Comments

    I just noticed that KC posted the first of the blog entries I wrote for the Exchange team last week, check it out!

    http://blogs.msdn.com/exchange/archive/2004/03/17/91454.aspx

     

     

  • Larry Osterman's WebLog

    I win the google prize!

    • 0 Comments

    My post on “how do I explain dividing fractions” from yesterday is the #1 google hit when you search for:

    what do i do to figure out fractions with different denominators

     

  • Larry Osterman's WebLog

    PlaySound(xxx, SND_MEMORY | SND_ASYNC) is almost always a bad idea.

    • 0 Comments

    Whenever you submit a crash report to OCA, a bug gets filed in the relevant product database and gets automatically assigned to the developer responsible for the code.  I had a crashing bug in the PlaySound API assigned to me. 

     

    In this case, the call was crashing deep inside of the waveOutOpen API and it was crashing because the input WAVEFORMATEX structure was bogus.  The strange thing is that the PlaySound API does some fairly thorough validation of the input WAVEFORMATEX read from the .WAV file and that validation had to have passed to get to the call to waveOutOpen.

    I looked a bit deeper and came to the realization that every single one of the crashes (in maybe a dozen different applications) had specified SND_MEMORY | SND_ASYNC in their call to PlaySound.

    I’ve talked about that particular combination before in my blog, but I wanted to call it out in a top level post in the hopes that people will stop making this common mistake.

    When you call PlaySound with the SND_MEMORY flag, it tells the PlaySound API that instead of reading the audio data from a file, you’re passing in a pointer to memory which holds the wave contents for you.  That’s not controversial, and can be quite handy if (for instance) you want to build a .WAV file in memory instead of calling the wave APIs directly.

    When you call PlaySound with the SND_ASYNC flag, that flag tells PlaySound that instead of blocking until the sound has finished playing, the API should return immediately instead of blocking while the sound is played.

     

    Neither of these flags is controversial and neither of them is particularly dangerous until you combine the two together.

    The problem is that there’s really no way of knowing when the sound has finished playing and thus when the application frees the memory, it’s entirely possible that the PlaySound API is still using it.  That means that if you ever call PlaySound with both of these flags, you stand a very high chance of crashing due to the combination of these behaviors.

     

    The unfortunate thing is that this behavior has existed since the SND_MEMORY flag was added back in Windows 3.1.  The only safe way of dealing with this that works on all current Windows operating systems is to call PlaySound(NULL, 0, 0) before freeing the memory – the call to PlaySound(NULL, 0, 0) will block until the currently playing sound has completed playing (or abort the playsound if it hasn’t started yet).

  • Larry Osterman's WebLog

    Windows 7 fixes the PlaySound(XXX, SND_MEMORY|SND_ASYNC) anti-pattern

    • 0 Comments

    A number of times in the past, I’ve mentioned that the PlaySound(xxx, xxx, SND_MEMORY|SND_ASYNC) pattern is almost always a bad idea.  After the last wave of crash dumps were received for this problem, our team decided to do something about it.  Starting with Windows 7, if you call PlaySound with SND_MEMORY|SND_ASYNC, instead of relying on the memory passed in by the application, we allocate our own buffer for the sound file on the heap and copy the file into that buffer.  We’ll only do it for WAV files that are smaller than 2M in size, and if the allocation of the buffer fails, we fall back on the original code path, but it should dramatically reduce the number of apps that crash while using this pattern.

    It’s a little thing, but it should make life much easier for those applications.

  • Larry Osterman's WebLog

    Nine years ago today (August 2000)

    • 0 Comments

    The biggest event on my plate in August was that I took taken delivery of a brand spanking new Itanium machine that was intended for 64bit Exchange development :).  We also shipped Exchange 2000 during mid 2000.  2000 was a time of some turmoil for the Exchange store development team – after shipping Exchange 2000, much of the store team left Exchange and moved to SQL server (where several of them still remain).  I chose not to remain with the rest of the store team and instead moved onto the SCP team (I wrote about that team yesterday).

  • Larry Osterman's WebLog

    Why are they called “giblets” anyway?

    • 0 Comments

    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.

Page 33 of 33 (815 items) «2930313233