Not Too Unique

My personal favorite when it comes to databases is Microsoft SQL Server. However, reality dictates that I sometime have to use different database. Actually quite often I need to have one application supporting different database servers. I might need application to work on SQL Server, PostgreSQL and (god forbid) Oracle.

With time I got used to prefer standardized parts of SQL. It makes life a lot simpler and SQL Server is usually ok with that plan. Except when it comes to NULLs where things can get little bit quirky. Setting ANSI_NULLS to true does sort most of issues but one.

If you have unique index on nullable column, SQL compliant behavior is to force uniqueness on all values except null ones. That means that having "a", "b", null, null is valid scenario. In SQL Server that second null will not be allowed under premise that such value already exists and thus violates unique index. That “feature” is part of SQL Server since it’s very first days and it is very unlikely that it will be changed in the future. Compatibility is a bitch sometime.

Fortunately there is a workaround since SQL Server 2008 in form of filtered indexes. That enables unique index on only some values. In our scenario we just need to ignore nulls and standard behavior here we come:

CREATE UNIQUE INDEX UX_MyIndex ON MyTable(MyColumn) WHERE MyColumn IS NOT NULL;

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.