Nice, With Crap

There is a trend to piggyback totally unrelated applications together in setup. Example that I faced recently was GOM Player bundled with AVG “security toolbar”.

I am surprised with two things here. AVG was quite reputable company for some time and they had quite a good free antivirus client. They do not seem like company that needs this kind of “distribution”.

Second thing is description that reads “set, keep and protect AVG secure search as my default …”. Frankly, that sounds like description of an toolbar that get installed when you visit naughty pages. Those toolbars also set, keep and protect their defaults. It is quite a fall from grace when security software and malware have exactly same description.

And, of course, standard installation includes all malware by default. You must actively make total of three clicks to remove it. It might not seem much but that also means that I cannot just Next/Next/Finish through installation. And that means that I cannot recommend this application to any inexperienced user. Explaining them how to remove crap would just take too much energy and I can bet that half of them would install everything.

Do not misunderstand me, I am fine (or even in favor) with piggybacking as long as other program has anything to do with program I am installing. Great example would be Wireshark including WinPcap. That is match that works. And that is software I trust.

When software goes on junkware route, there is only one thing to do. I will stop using GOM Player, like I stopped using BSPlayer before it. Irony is that I liked both of them and I am leaving them for same reason. Anybody has any decent (and junk-free) multimedia player to recommend?

PBKDF2 With SHA-256 (And Others)

.NET has built-in class handling all your PBKDF2 needs. It is called Rfc2898DeriveBytes and it works as long as you stick to SHA-1 HMAC. If your needs move in direction of SHA-256, you are out of luck.

Therefore I created Pbkdf2 class that takes any HMAC algorithm (e.g. SHA-1, SHA-256 or SHA-512) as input and allows you to derive key based on it.

using (var hmac = new HMACSHA256()) {
    var df = new Pbkdf2(hmac, password, salt, iterations);
    Console.WriteLine(BitConverter.ToString(df.GetBytes(32)));
}

Full code is available for download.

Who Uses Serial Mouse?

One pet project of mine is random number generator. It is actually quite simple: PIC generates random number from noise and then uses FT232RL to transfer it. On micro-controller side it is standard USART and to Windows it looks like it is USB-to-serial converter. To get random number, program just needs to read a byte from serial port. How hard can it be?

I tried device under Windows 7 and computer suddenly started shutdown. Not a crash mind you, proper shutdown. I checked event logs and everything pointed just to normal shutdown. I plugged device again and my mouse went wild. It started clicking, moving, re-sizing, cursing (ups, that was me). As soon as I pulled device out everything returned to normal. I plugged device back in and found no issues. For a while. And then mouse started going wild again. My guess is that it was this what did shutdown in first place. Mouse was just at the right place at the right time.

If I would open serial port as soon as device was plugged in, everything was normal. However, if device was left for a while, mouse dance would commence. I did remember that PS/2 could cause some similar issues but it didn’t quite match what I was seeing. What I was seeing seemed a lot like reports of serial GPS devices being treated as mouse. Actually it seemed totally same.

It seems that Windows will sample bytes from any connected serial device to check whether it is mouse on other side. Exact heuristics are not known to me but I bet that it checks whether data is sent all the time (like I do for my device) and whether data changes (like random numbers tend to). If both these requirements are satisfied it will search for some byte sequence to be sure. Since random number generator will (given enough time) create every sequence there is, I was fooling that check also.

Actual fix is rather simple. Under HKLM\SYSTEM\CurrentControlSet\Services\sermouse we change property Start from 0x03 to 0x04. That causes service start option to be changed from manual to disabled. That also means that there is no support for serial mice on your computer. That is, if you manage to find one anywhere…

As for my device, I have no idea what to do. Forcing everybody to change registry in order for it to work does not seem user friendly. Putting it in readme.txt seems like sure way for nobody to even know about issue. Waiting for command before generating random number kills simplicity. Converting all to hex kills bandwidth, simplicity and I cannot be sure that problem will not resurface later…

There is probably no ideal solution but I will not let small thing like that prevent me from trying to find it.

P.S. Registry file for disabling serial mouse is available for download.

Jelly-bean PIC

My first PIC was 16F84. Choice was easy. Not only that Microchip had relatively few models those days but almost all were of higher price. Yes, brave men would go for write-once chips, but that was pain for any kind of learning or development.

I considered this chip as pure jelly-bean part. I would always have few around. Whatever I designed it was around it (with some exceptions, of course). I probably ended-up using it in 90% of my projects. And I would never run out of it. If there wasn’t any in new parts bin, I would just pull one from old project. Good old days of DIP.

As time went by, there came much more powerful chips but I liked my old trusty 16F84. It took huge price increase from Microchip for me to look for replacement.

It was only natural to select 16F628. It was better chip (good bye USART bit-banging), it was cheaper and it was almost completely pin-compatible with 16F84. These days this is considered quite a modest chip. There is no ADC, no PWM, no I2C and price is rather high for what you actually get. Using it in new projects was just not a real option.

Since last year my default choice fell on 16F1826. It is decent device and it has all things that modern PIC should have. And it is cheap and stocked almost anywhere.

But when I contrast it with good old 16F84, I notice that I am nowhere near 90% usage. Somehow my projects always end-up using more pins that this little gem has or I need some more advanced functionality (e.g. LCD). I probably spend hours looking for micro-controller and then cross-referencing this data with stock in RS or DigiKey. And that is time I lose each time I start something new.

Not even jelly-bean components are what they used to be.

P.S. Yes, I am old and looking back toward good-old-days.

Resolving Embedded XML

One of my fetishes is including as much resources as possible within the executable. This is fairly easy to do with Visual Studio. Just select desired file and change Build Action property to Embedded Resource.

Biggest benefit is that you can count on file always being there. There is no need to add file to installer nor to do error handling. And, even when you need to have user-modifiable files, you can always tuck away safe defaults far out of reach of an inexperienced user.

When you have XML file stored as this, loading is as easy as it gets:

var doc = new XmlDocument();
var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("project.example.xml");
doc.Load(stream);

However, when you have that same file linked to it’s DTD (Document Type Definition) things get ugly. Only thing that we get with our function is FileNotFoundException with Could not find file 'C:\somepath\example.dtd'. Things do not change even when DTD is embedded next to XML. As you can see from exception, our XmlDocument is stubbornly reading DTD from disk instead from resources.

Easiest solution is to delete referring DOCTYPE from XML document. However, that is double-edged sword since that also means that you lose quite a good helping hand in detecting early errors. I will not even go into how (properly created) DTD can be huge help with intellisense during XML editing.

Better solution would be to use XmlDocument’s existing XmlResolver property. XmlResolver is what actually handles from where each stream is read. If we inherit that class we can make critical change to read DTD from resource stream instead from file system. And it all fits in single overridden function:

public override object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn) {
    var fileName = absoluteUri.Segments[absoluteUri.Segments.Length - 1];
    var resourceName = "project." + fileName;
    var resourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(resourceName);
    return resourceStream;
}

Code will just check which file name is required and return matching embedded resource stream. Loading XML stays almost same:

var doc = new XmlDocument();
doc.XmlResolver = MyResolver();
var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("project.example.xml");
doc.Load(stream);

P.S. Do notice that above are excerpts from little bit bigger code. Full sample is available for download.