One Step Back

I was more than surprised to find that Visual Studio 2010 (beta 1) has moved from “Any CPU” as default platform target to “x86”. In short, every application you create with Visual Studio 2010, will not run on 64-bit Windows without compatibility layer (WOW64).

While this may seem like a minor change, I consider it a major problem in 64-bit programming. When Visual Studio 2008 defaulted to Any CPU, that did caused whole range of bugs and errors. However, by resolving those errors, developer was at least somewhat introduced to problems with his code in 64-bit environment. If he could not resolve it, he would switch it manually to 32-bit.

This change just seems like allowing careless developers to stay careless. In short time, this will not cause too much problems, but in long run you will get bunch of code that requires 32-bit compatibility layer (32-bit Windows will not be with us forever).

MagiWOL and \"Program Too Large\"

It seems that there was error in uploading MagiWOL installation. Result of that was corrupted file and installation gave “Program too large” error on command line.

I re-uploaded file now and everything should be fine once again. I am truly sorry for any inconvenience.

Why Shouldn't I Sign My Code

While ago I talked about reasons for signing your executables. Now I will tell something about reasons against it.

Speed issues

In certain situations loading of .NET assemblies may be delayed. While usually this is not visible that much, it is something to keep in mind.

Not having trusted root certificate

If you don’t have one of trusted root certificates (e.g. VeriSign’s) you cannot count on Windows recognizing your signature. You will get same prompt as unsigned applications (on Windows Vista and 7). While your application may be signed, your users will not see that.

What do I do?

I do not sign my assemblies. I did try it for a while, but without proper certificate (expensive one), there is just no reason to do it.

However, I do strong-name my assemblies. This is not exactly same as signing them but it does provide you with integrity check which is only thing that I really need.

Last Access Time Under Windows 7

For a long time the easiest thing you could do in order to speed up your system was to disable recording of last access time on NTFS. Since time was updated on every directory listing, performance gains (especially on laptops) were great.

It seems that someone at Microsoft also saw how useless last access time information is and decided to disable it by default. Let just hope that it stays that way.