"It was a blazing hot day in August. Baker Street was like an oven, and the glare of the sunlight upon the yellow brickwork of the house across the road was painful to the eye. It was hard to believe that these were the same walls which loomed so gloomily through the fogs of winter." I don't live in Baker Street actually, but the weather here has been similar to Watson's description from Sir Arthur Conan Doyle's The Adventure Of The Cardboard Box, collected in His Last Bow. Excellent reading for when it's too hot to do anything that requires more than turning a page now and then. Fortunately, like Holmes in the story, there's also been some time for me to do an investigation.
I'm still working on software related to the serial communications described in my previous post and when testing I ran into something strange. The drivers that come with the 3Com 3CREB96B Bluetooth device add some entries to the hkey_local_machine\hardware\devicemap\serialcomm key. Basically a bunch of virtual serial ports. In turn, I enumerate the entries in this key to find the available serial ports for use in my application. I use Microsoft.Win32.Registry.LocalMachine.OpenSubKey to get a RegistryKey object and then query it using its GetValues and GetValue methods.
Nothing out of the ordinary so far. However, on one of the machines that was tested on, the Bluetooth's drivers' COM3 to COM7 showed up all with a 0 suffixed, i.e. COM30 to COM70. When looking closer I discovered that this behaviour is related to the order that values are returned from the registry: if there was a COM10 returned before the 3Com values, the problem would occur. If there was a COM100 (created to see if my assumption was correct) the values would come back as COM300 to COM700.
So then I had a look at the registry. It turns out the values inserted by the 3Com driver are not zero-terminated. So what's probably happening is that in the Win32-implementation of the .NET registry API I'm using, the buffer to hold values coming out of the registry is reused and there are no zero-terminator checks (or not correct ones anyway). I'm not sure if it's appropriate to do those checks there though so I'm not saying that's a bug. However, when looking at the Win32 documentation for writing to the registry, I noticed that going from the original RegSetValue to the new RegSetValueEx function, cbData's requirement for including the terminator in the length has changed (in the former it should be excluded and in the latter included). Perhaps someone at 3Com has been a bit sloppy porting from the old to the new?