Steve Ball posted an article about some "glitching" issues in Vista. I can't resist adding my two cents.

For me, Vista definitely glitches a LOT more than previous versions of Windows. As a fairly experienced developer, I think I understand the reasons pretty well, so I can explain it away. But as a user, when my laptop audio is glitchy, I want to find the developer responsible and (censored for mild descriptions of hypothetical violence).

I've read a lot of comments raising various theories, some that call into question the sanity of the Windows developers. I can't say I blame them. There is definitely some room for improvement in the way things work. However, in the interest of fairness and progress, the attention should be focused where it will do the most good. That means we shouldn't simply blame the Windows developers unless there is really something they can do about the problem. And that means that before we start placing blame, we probably ought to figure out where the problem really lies.

The first complaints always mention something about the "lame" and "brain-dead" Windows NT scheduler. However, I'm pretty convinced that this is not the problem. In fact, my audio sounds BETTER when my system is under load (more on this later). I agree with the statement that audio glitches under CPU load are usually the fault of the OS and the scheduler, but I've seen very little correlation between CPU load and audio glitching. I haven't seen any evidence that the CPU scheduler at fault.

Hard disk load is occasionally an issue, but that is generally fairly obvious and easy to fix at the application level. The application simply didn't buffer enough sound samples and ran out of music to play while waiting for the hard drive to load the next bit of music. Either tweak the buffering algorithm of the application or get a faster hard drive (or network).

Memory can also be an issue. Some buffer or code needed to play the music might be paged out because you're running low on free memory, and it didn't get paged in quickly enough once the application tried to access it. This could possibly be blamed on the OS if the OS is too aggressive in trimming the working set. If an app pre-loads 60 seconds of audio, that means it doesn't won't touch the last page of the buffer for 60 seconds, which might be long enough for the OS to page out the buffer. Here, you would probably get better results by buffering only 5 seconds worth of music. In any case, I haven't had any significant trouble with this on Vista (except once in a while when I let Firefox run too long, it eats up 1.5 GB of RAM, and my system goes into memory panic mode).

Drivers are a much more significant issue. Traditional OSes (XP, Vista, Linux) can't really schedule a driver's activity. Once the driver starts doing something it thinks is important, it can only be interrupted by a higher-priority driver. On a single-CPU system, if a driver takes over, no new audio can be buffered until the driver returns. Many drivers written for XP or earlier systems (where the audio buffer was somewhat more forgiving -- more on this later) cause trouble by doing too much processing at once. In testing (under XP), the driver's latency wasn't a problem, but on Vista, the latency requirements are much less lenient. I've seen significant Vista audio glitch issues go away after upgrading from an XP-era driver to a newly released Vista-compiant driver.

Even if the driver only does 1 millisecond of work at a time (or whatever the Vista latency recommendations are), if it has to do this 1000 times a second, it will still use up all available CPU time. Drivers have priority over all applications, so on a single-CPU system, this leaves no CPU for the audio application and mixer. On a multi-CPU system, this can still be a problem if the driver holds certain locks that are needed for audio processing. This is why Vista throttles network activity when the audio channel is open -- network packet bursts can easily use enough CPU to cause audio glitches. Probably a good idea overall, though it seems that the throttling algorithm is a bit too aggressive and has some room for improvement.

Another issue is power management. This turned out to be the major problem on my laptop. My laptop's motherboard (CPU and chipset) goes into sleep mode whenever it detects that it is "idle". That's actually a pretty good thing because it means I can get 2 or 3 hours of use out of the battery instead of 20 minutes. This happens hundreds of times per second -- it sleeps for 2 milliseconds, wakes up to handle a keystroke, sleeps for another 2 milliseconds, wakes up to handle the calculations for an animation, sleeps a bit more, wakes to fill an audio buffer, etc. But it sometimes doesn't wake up quickly enough to buffer the next bit of audio. If it ever takes longer than 9 ms to wake up, there will be a glitch. This was a real problem when my laptop was new. Recent drivers have improved this a lot, but there's still a bit of scritch-scratch during some games or media.

As an experiment, I wrote a very simple application to prevent the motherboard from going to sleep. It starts a low-priority thread that does a simple busy wait in a low priority loop. A Sleep(1) loop didn't help -- it gave the motherboard a chance to go to sleep. While the busy wait makes my laptop get very hot, it also completely stops the glitching.

#include <windows.h>

#include <stdio.h>

 

// This probably doesn't really do anything. At such a low priority, the

// process usually terminates before the thread exits. But this is an easy

// way to avoid certain compiler warnings. Without it, some compilers warn

// that the "return 0" below is unreachable. If I remove the "return 0",

// other compilers warn that I don't return a value from DoNothingQuickly.

volatile BOOL g_stopNow = FALSE;

 

DWORD WINAPI DoNothingQuickly(LPVOID /* unused */)

{

      while (!g_stopNow)

      {

            // Sleep(1) didn't fix the glitching. Sleep(0) just spends all

            // the time context switching, which is probably as bad or

            // worse than a busy wait in terms of impact on the rest of

            // the system. So I'll just do a busy wait.

      }

      return 0; // Usually never reached.

}

 

int main()

{

      int returnCode;

      DWORD dwThreadId;

      HANDLE hThread;

 

      hThread = CreateThread(

            NULL,

            0,

            DoNothingQuickly,

            NULL,

            CREATE_SUSPENDED,

            &dwThreadId);

 

      if (hThread != NULL)

      {

            // We want to keep one CPU wide-awake and leave any other

            // CPU(s) idle.

            SetThreadAffinityMask(hThread, 1);

 

            // We don't want to get in the way of any useful work.

            SetThreadPriority(hThread, THREAD_BASE_PRIORITY_IDLE);

 

            ResumeThread(hThread);

            CloseHandle(hThread);

            printf("Caffeine: Now running. Press <Enter> to quit...");

 

            getchar();

            g_stopNow = TRUE; // Probably useless, but might as well...

            returnCode = 0;

      }

      else

      {

            printf("Caffeine: Unable to create thread. Exiting.\n");

            returnCode = GetLastError();

      }

 

      return returnCode;

}

Drivers seem to be a big part of the problem here -- they either spend too much time working, or they take too long to wake up after going into a sleep state. Hopefully this means that audio problems will go away as the drivers improve. Computer retailers like Dell and HP will probably ensure that their new hardware meets the Vista latency requirements before putting it on the market. Unfortunately, owners of older hardware might be out of luck.

Hindsight is 20/20. I've seen how these kinds of issues come up, and I've been involved in some mistakes myself, so I don't want to sound like I'm smarter than anybody on the Windows audio team. However, there is certainly some room for improvement in they way this issue has played out. While the changes in the audio stack are technically admirable and the problems can generally be blamed on drivers, that's little comfort to those enduring static on their speakers. Things work in XP and don't work in Vista. That sounds like a regression, not an improvement. It's getting better, but there really shouldn't have been a problem in the first place.

What's wrong? Well, Vista aimed for a technically superior audio experience. Latency has been significantly reduced in Vista -- when you fire your machine gun in your favorite game, you'll hear the sound effect a bit more quickly. For gamers and audio professionals, this reduction in latency can make a big difference. For people trying to listen to their MP3s, this probably doesn't matter much. The downside to reducing latency is that it reduces the margin for error. Vista cannot tolerate any delays longer than 5 or 10 milliseconds without glitching, while XP could usually tolerate a much longer delay with no problem. Assuming all of the drivers do their part, modern hardware actually has no problem meeting the deadlines. But if anything goes wrong on Vista, you can hear it.

What was the mistake? The core of the issue is that a change was made that was detrimental to some customers. In the long term, the change is probably a step (or two) in the right direction, but for many people, the change causes trouble and offers no immediate benefit. Obviously the severity of the problem was underestimated (contrary to popular belief, Windows developers do care about their customers and would never have done this had they known the outcome). I've never been a big fan of taking away without giving something in return.

What would have prevented the problem? I don't know how hard this would have been to implement, but I would love to have some kind of adjustment knob to control the amount of latency I want on my system. That would have sidestepped the whole issue by allowing the customer to pick their priorities, i.e. lower latency on my desktop where there aren't power issues and where I want my games to sound great, higher latency on my laptop where I want additional power savings, the drivers aren't as good (and are also optimized for power savings), and where I'm never using the audio stack for anything other than music or videos anyway. This would also have been a great mitigation for driver issues during the transition period.

 This is probably a good lesson for developers in general -- be sure to consider the transition period between the old system and the new system when designing the new system.

In the meantime, I've finally gotten my audio problems worked out. After the latest motherboard chipset upgrade, I no longer have to run caffeine.exe anymore, and I only run into minor static when running a few specific programs. Hopefully things are improving for everybody else, too.

Home-grown hash functions considered harmful...

About 7 years ago, when I was a high-minded computer science senior, a lowly computer science freshman buddy mentioned the trouble he was having with his homework. He had to design a hash table, and he was getting too many collisions for his design to be accepted for the assignment. I suggested that he always stick with a prime number of buckets. He tried that and -- like magic -- his collision rate went down dramatically. He asked me why it worked, and (being a member of the CS elite) I just scoffed. Isn't it obvious? Prime numbers are just better!

Now that I've been taken down a notch or two (six years of real industry experience will do that), I've learned that contrary to common practice, it really isn't obvious. I've also learned that magic solutions to hard problems should be examined with suspicion.

The rest of this post is probably pretty boring, so here's the quick summary:

1. If you have to write a hash function for something important (i.e. a .NET GetHashCode method or a C++ hash traits class), don't design your own. Steal one that has been well-tested. One of my favorites for speed, simplicity, and quality is the "Jenkins One-At-A-Time hash" (aka joaat hash - "one-at-a-time" refers to one byte hashed per iteration, though the algorithm is probably still mostly ok if you use a 16-bit char per iteration instead). You can find a good description of it and many others here. For more information, see the Wikipedia entry on hash tables.
2. If you see any locally-developed hash table implementation that requires a prime number of buckets, you might want to track down the author and suggest a better hash function that doesn't place a prime number constraint on the number of buckets. Prime numbers are so 20th century! (Keep in mind that the hash table author might be aware of better ways but is remaining backwards-compatible with previous releases or is protecting the clients of the hash table from their own bad hash functions.)

The Goal: Fast Lookup

(This is review for those who aren't familiar with hash tables.) 

A common task (in both real life and computer programming) is looking things up. Given input "A" (the "key"), I want to find a corresponding value "B" (the "value"). Think finding a word in a dictionary (given a word, I want to find the definition) or finding the page of a book given a page number.

If the key is easily enumerable (for the purpose of this discussion, enumerable means I am able to easily map each key onto a unique non-negative integer) and all valid keys are densely packed into a small range in the enumeration, a numbered list works quite well. For example, if the key is an integer, and valid keys are all in the range 200 to 300, and all possible keys from 200 to 300 are valid (have associated valies), then the input is easily enumerable and the enumeration is dense. For computer programs, the logical data structure for this situation might be an array or a vector, mapping each key (200..300) to an array index (0..100) by subtracting 200 and rejecting any key outside of the range 200 to 300.

If the key is not easy to enumerate or if the enumeration is not dense, looking up the value might be more difficult. If the key is enumerable but not dense (i.e. a string with up to 256 Unicode characters), you could theoretically create an array with indexes corresponding to all possible inputs, but unfortunately, most of the slots in the array will be empty and wasted. In the case of 256 Unicode characters, at one bit per value, your array of values will require more bits of storage than there are atoms in the known universe.

One good solution is to make a list of items sorted by the associated key. The list can then be searched using a binary search. This works quite well for a large class of problems, and assuming that the list allows for linear-time lookup of item a (where a is a number refering to the a'th item), finding an arbitrary item is O(log N) (where N is the number of items in the list). (To allow quick insertions and deletions, the list is typically implemented as a tree, but that's just an implementation detail.) The STL std::map class uses this method.

Another good solution is to split the set of values into many small groups or "buckets" based on the key. Each possible key always maps to the same bucket. Now if I want to find an item, I don't have to search the whole list -- I just have to search through the items in the correct bucket. Assuming a good mapping that evenly distributes items among buckets and a number of buckets proportional to the number of items, this method can allow us to find an item (or know that it is not present) in O(1) time. This method is often called the hash table.

The Challenge: Hash Functions

The mapping of input keys to bucket numbers is called the hash mapping. A good hash mapping will quickly map any input key A to an integer m from 0..M-1. It will do this in a way that evenly distributes the items in the hash table so that most of the buckets have about the same number of items. An ideal hash mapping will result in each bucket having the same number of items. "Perfect" hashing is where there are N items, N = M buckets, and each bucket contains exactly one item. In general, perfection is only possible when the items are known before the hash mapping is chosen.

A hash function is (for this discussion) a mapping of input keys to non-negative integers. This is an important step of a hash mapping. Given a hash function, the hash mapping can be completed by performing any mapping of non-negative integers onto the range 0..M-1. This is often done by dividing the result of the hash function by M and taking the remainder.

Assuming that we have to pick a hash function ahead of time, desirable qualities include speed (minimize the time spent turning a key its hash), simplicity (don't waste space in the memory of the computer, be easy to understand and debug for the benefit of the developer), quality (evenly distribute typical inputs into available buckets), and flexibility (work with any kind of input and any number of buckets).

Developing good hash functions is hard. In fact, if you have to pick a hash function before the items are known, it is provably impossible to avoid the worst-case scenario where all items end up in the same bucket and your search time becomes O(N). However, assuming that your inputs are not generated by a malicious attacker with knowledge of your hash function, it is possible to come up with some good hash functions that are fast, simple, flexible, and of high quality. It just isn't easy, especially because literature and common practice are full of examples of poorly designed hash functions.

Bad hash functions have persisted partly because it really doesn't matter much for many tasks. A fairly bad hash function might make your algorithm perform somewhat more slowly, but as long as your hash table correctly handles the collision cases, you might not even notice. In many cases where N is small or bounded, even the worst case of O(N) might not be a problem.

In addition, while good hash functions are hard and require careful analysis, in most cases, it is relatively easy to randomly pick some unsigned integer operations (set unsigned int x = something, then for each byte b of input set x = x (OP) b) and come up with a hash function that looks "pretty random". The problems don't show up right away, so the code gets checked in. In the rare case that the hash table ends up being a performance bottleneck, a liberal application of prime-number sauce makes the worst issues go away.

The Magic: Prime Numbers

A hash function designed "at random" without careful analysis will almost certainly have a very uneven distribution for the likely set of keys. Often there will be periodic patterns in the mapping of input to output. Inputs following a pattern will result in hash codes that follow some other pattern. The ideal hash function would evenly distribute all keys among all buckets (no matter how the keys might be related), so any common pattern leading to an uneven distribution is a flaw. Sometimes the flaw will go unnoticed, but sometimes the flaw will cause uneven bucket distribution leading to possible performance issues.

For example (strawman, I know, but not entirely far-fetched), assume I invent a hash function with the flaw that the result of the hash function is always a multiple of 48 if all inputs are ASCII digits (48..57). This might be ok for some item sets, but it suddenly becomes a problem when the items are "all zip codes in the US" with 96,000 buckets. Instead of O(1), the lookup becomes O(48) with 48 items in every 48th bucket and 0 items in all others.

So lets say I get a bug assigned to me to fix the performance issue. I determine that the problem could not possibly be with my hash algorithm -- I designed it at random, therefore the output must be perfectly random! (Not true, by the way.)

I play around with some data sets, and notice that the problem is really bad when the number of buckets is a nice round number, but seems to go away when I use a more "random" number of buckets. This is because given an input that is divisible by 48, the remainder when dividing by a nice round number is likely to preserve my hash function's distribution flaw:

M (the number of buckets) = 96000 = 48 x 2000 

m (the output of my hash function) = 59259216

m mod M = (48 x 1234567) mod (48 x 2000) = 48 x (1234567 mod 2000) = 48 x 567 = 27216. (The output of my hash mapping - still divisible by 48!)

On the other hand, dividing by a number that doesn't have any prime factors in common with the period of my distribution flaw (48 = 2x2x2x2x3) will do a nice job of hiding the flaw. Prime numbers don't have any prime factors other than themselves, so they magically hide a number of periodic hash function flaws.

Not really understanding the logic, I do a few searches through the available literature (i.e. Google) and see references to prime numbers in relation to hash functions. I try a few prime numbers for the bucket sizes, and it looks like all of the distribution issues magically go away. So I resolve the bug as "somebody else's fault", indicating that the client needs to use a prime number for the number of buckets.

This is inconvenient for the client, but it solves the problem, so it gets written into the documentation for my hash table. The prime-number-of-buckets idiom continues to propagate. (Oh my!)

The Right Way: Steal

While prime numbers smooth over a number of flaws, they really don't solve the problem. The problem is that poorly developed hash functions aren't well distributed. Using a prime number of buckets eliminates one class of issues (which seems to be the most common class), making the performance acceptable in more cases, but other issues remain. In addition, requiring a prime number of buckets causes some inconvenience -- the client now needs a table of prime numbers, hash computations require a division operation, hash table resizing becomes more complex, etc.

It turns out that with some careful design, it is possible to create hash functions that do not contain these periodic flaws. These high-quality hash functions are very good at producing even distributions over nearly any number of buckets given nearly any input. The result is that there need be no hash-function-induced constraint on the number of buckets.

Since careful design of hash functions is not something most developers (myself included) know how to do, the best advice I have is this: steal. The best code is the code you don't have to write yourself. There are many good hash algorithms out there that have undergone extensive analysis and have excellent distributions for nearly all kinds of input. Some are even extremely simple. All of them will almost certainly knock the socks off of anything you can develop on your own in terms of even distributions. Most of them will run more quickly than your home-grown solution. And they're free.

Here is a very simple hash function (Jenkins One-At-A-Time) that is better in almost every way than anything I saw in college (assume ub4 is a typedef for a 4-byte unsigned integer):

ub4 one_at_a_time(char *key, ub4 len, ub4 hash = 0)
{
  ub4   i;
  for (i=0; i<len; ++i)
  {
    hash += key[i];
    hash += (hash << 10);
    hash ^= (hash >> 6);
  }
  hash += (hash << 3);
  hash ^= (hash >> 11);
  hash += (hash << 15);
  return hash;
} 

You can easily use this for any size of hash table by dividing and taking the remainder. Even better, use it with power-of-two hash tables by masking off the top bits of the hash. You can hash multiple parts of a structure by calling the function repeatedly and chaining the result each time.

Hey, PB expert guy, I have a question.

Shoot.

Can I run PB 5.0 side-by-side with PB 6.0?

Short answer or long answer?

Um, short answer, please.

Kind-of.

What kind of answer is that? This is a yes-or-no question!

Ok. Then the answer is no.

That’s not what I wanted to hear.

Oh, sorry. The customer is always right, I forgot. Yes, yes, of course you can.

Are you lying to me?

Technically, no.

I want the truth.

You can’t handle the truth.

Ha ha. Very funny.

Well, you can run them side by side, but you may or may not be happy with the results.

Hmm. You’re weaseling out of the question, aren’t you?

Yup. Weaseling is what separates us from the animals. (Except the weasel.)

Ok, then the long answer please?

Sure. But first, recognize that the following information is offered without any warrantee or guarantee. You follow these instructions at your own risk. Neither Microsoft nor dcook accepts any responsibility for the use or misuse of these instructions. Use at your own risk. Back up your data first. I’m sharing this information because it has helped others, but it may or may not help you.

Yes, I accept. (click.)

Platform Builder 5.0 and 6.0 tools do not always work perfectly when both are installed on the same computer. (Note that this refers to the PB IDE and tools, not to the OS build tree. The build tree is fairly self-contained.) Most things work, but there are a few challenges. There are also a few steps you can take to minimize the challenges.

The first thing to know is that you must install PB 5.0 first. If you’ve already installed PB 6.0, I’m sorry, but you'll have to uninstall it. PB 5.0 broke some installation rules and will clobber some PB 6.0 settings. And there are a few things that PB 6.0 had to do that aren’t pretty, so a repair of PB 6.0 might not work either. If you’ve already installed PB 6.0 and want to install PB 5.0, your best bet is to uninstall PB 6.0 first. Here is the recommended order of installation:

1. Install PB 5.0.
2. Make a backup copy of all files in C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\bin. (Only the files in the bin folder need to be backed up. The subfolders do not need to be saved.)
3. Install Visual Studio 2005 and all associated service packs (as of this writing, SP1, and if you’re running Vista, the SP1-Vista-GDR).
4. Install PB 6.0 and all associated service packs (as of this writing, SP1).
5. Compare the current set of files in the Platman\bin folder with the set of files you backed up. Restore any missing files. (Do NOT overwrite any existing files.)
6. If you have any Connection Manager device settings that were created with PB 5.0, you’ll need to delete them and recreate them.

At this point, PB 5.0 and PB 6.0 should both be mostly working – or at least as well as can be expected.

What’s that supposed to mean?

Well, the above steps worked for me. But there are all kinds of things that could go wrong, and I may not have tested some aspect of PB that is important to you, so this may not work perfectly for everybody.

The largest trouble spots are with the x86 Emulator, the Remote Tools (especially PerfMon and CeCap), and with CoreCon (download and KITL transports).

Why is this such a problem in the first place? Why don’t you just fix this mess?

I would love nothing better than to fix this mess. Unfortunately, as long as we support cemgr.exe, we’re going to have some side-by-side troubles with the Platman\bin folder. Back in PB 4.0, when the best practices for MSI development were not nearly as well-known as they are today (and they still aren't very well-known), a few mistakes were made in the development of the PB 4.0 Platman install. The result is that if a file was part of the PB 4.0 Platman install in the Platman\bin folder, and we want that file to still exist after PB 6.0 is installed, we have to include that file in PB 6.0. Due to various security and legal issues, there are a few files that were part of PB 4.0 that we can no longer ship in PB 6.0. As a result, installing PB 6.0 causes these files to mysteriously disappear.

Any other issues?

Yeah. If you uninstall either PB 5.0 or PB 6.0, you’ll probably have to repair the remaining version of PB before it runs correctly (Add/Remove Programs, select PB, then select Repair). Certain registry settings for COM interfaces can't really be properly shared between versions of PB.

Also, the CoreCon datastore is a bit more fragile than I would have liked. Sometimes things go wrong with the datastore resulting in problems when you launch Connection Settings from PB or when you try to create a Visual Studio for Devices project. (You may also run into problems while installing PB 6.0 if your datastore is corrupt.) If you have trouble with the CoreCon datastore, try the following:

1. 1. You can safely delete your local (per-user) CoreCon datastore settings. (See http://msdn2.microsoft.com/en-us/library/ms184403(VS.80).aspx for details.) This sometimes fixes issues with launching Connection Settings or with creating VSD projects. Go to your user’s application data directory, navigate to the Microsoft folder, and delete the CoreCon directory. For example, 'rd /s "C:\Documents and Settings\YourUserName\Local Settings\Application Data\Microsoft\CoreCon" '. (Warning: DO NOT delete the CoreCon settings under All Users!) The next time you activate CoreCon, it will rebuild your per-user datastore. You will lose any devices that you may have configured, but it shouldn't be too hard to recreate them.
2. 2. If the above does not help, you may have a problem with your global (all users) CoreCon datastore settings. This is a hard problem to solve. These files are in the All Users application data area (i.e. C:\Documents and Settings\All Users\Application Data\Microsoft\CoreCon\1.0, or C:\ProgramData\Microsoft\CoreCon\1.0 on Vista). You can’t just delete these files and hope they come back (because they won’t). This might work:
1. Make a backup copy of the data in the CoreCon\1.0 folder.
2. No, seriously. Make a backup copy. If you lose the data in this folder, it may be quite difficult to get it back.
3. Rename the 1.0 folder to something else, like “1.0_original”.
4. If a friend or co-worker has a working installation with a similar set of programs (i.e. they successfully installed PB 5.0, VS 2005, and PB 6.0), try copying the data from the other computer to your computer. Ensure that you’ve deleted the per-user CoreCon data (step 1 above), then launch PB 5.0 or VS 2005 and try to open Connection Settings.
5. If this doesn’t work, rename this folder out of the way (i.e. rename it to 1.0_from_other_computer), then try a repair install of PB 5.0, then VS 2005, then PB 6.0.

Yikes!

Yeah. Tell me about it.

Some people have had better luck just installing PB 5.0 and 6.0 on separate machines, dual-booting, or even installing PB 5.0 into a Virtual PC image.

There are also ways to make PB 6.0 work with OS trees from CE 5.0, but that is a more complicated subject (and while it generally works, it is definitely unsupported by Microsoft).

In Visual C++ 7.1 and earlier, "catch(...)" would catch all exceptions, both C++ and SEH. The behavior has changed with Visual C++ 8.0. This has caused some confusion.

The details get a bit tricky, but the generally accepted wisdom among the C++ gurus that have advised me is:

1. try/catch is for C++ exceptions.
• Corollary: Don't catch C++ exceptions with __except.
2. __try/__except is for Windows Structured Exception Handling (SEH) exceptions.
• Corollary: Don't catch SEH exceptions with catch.
• Corollary: Don't use _set_se_translator. Use __except, then throw your C++ exception from the __except block.
• Corollary: Don't use /EHa. The only reason to use /EHa is to catch SEH exceptions with catch or via _set_se_translator, which you shouldn't be doing in the first place.
3. Don't use both C++ exception handling and SEH exception handling in the same function.
• Creating an instance of an object that has a destructor implicitly generates a try/catch block, so don't create destructable objects in a function that uses __try/__except or might directly raise an SEH exception.
4. Don't catch anything you don't know how to handle.
5. You don't know how to handle Access Violations.
• Corollary: Don't catch Access Violations. Ever.
6. It was always kind of weird (many would say horrible and bad) that the C++ catch would sometimes catch SEH exceptions. This was never dependable. Don't rely on this behavior.
7. It is a compiler implementation detail that __except can catch C++ exceptions. Don't rely on this behavior.
8. Visual C++ 8.0 changed the semantics of "catch(...)".
• catch(...) no longer catches all SEH exceptions. This is a good thing (see rules 4 and 5).
• If you were following the above rules, you didn't see any changes in your program's behavior.

In my previous post, I described two issues encountered after updating our build system to Nmake 8.0 (the version from Visual Studio 2005) from earlier versions. Both issues turned out to have essentially the same root cause.

Nmake's job is to execute a sequence of commands to bring targets up-to-date. Some of those commands do real work, such as "cl -c MyProgram.cpp" to run the compiler. Other commands just set things up, such as "set TARGETDIR=c:\obj". Some commands just output status information, such as "echo Starting compile".

In order to improve build speed (as well as to supply certain semantics expected by the developer), Nmake emulates some commands instead of actually executing them. For example, if Nmake were to run "cmd /c set TARGETDIR=c:\obj", nothing would happen (the environment of the new cmd.exe process would be modified, but then the process would exit and the change to the environment would be lost).

It seems that between Nmake 7.1 and Nmake 8.0, the mechanism for executing some of cmd.exe's internal commands was changed. Previously, "echo", "type" and other built-in commands were always executed with predictable semantics. (I'm guessing this is because they were emulated by Nmake instead of being passed to cmd.exe.) In Nmake 8.0, the "echo" and "type" commands are apparently executed exactly as if you typed them into the cmd.exe command line.

On the surface, this isn't such a big deal. Most of the time, this change is completely transparent. Once in a while...

In the first case described in the previous blog post, it turned out that "echo.exe" was a program on the user's path. This is a tool written to make the "echo" command in cmd.exe behave more like the "echo" command in Unix. Nmake was simply calling the user's echo.exe instead of using cmd.exe's built-in echo command.

In the second case, "type.exe" was a program on the user's path.

Around Microsoft, people talk about making things performant. They mean "fast" or "performs well".

It is a real word, but according to OED, it means a person who performs something.

In any case, I think it really isn't all that important (that is a "real word"). I know what they mean, they know what I mean, and isn't that the point?