Why Should I Sign My Code

I see lot of developers failing to sign their code. Here I want to go through some benefits of that simple procedure.

Integrity check

Once you sign your code, every time you run it you get free integrity check. If you sign code at your end, you can be sure that your customer received same version. Although this will not safeguard you against somebody who wants to change code on purpose (he will just remove signature), it will guard you against accidental errors. Sometimes it will prolong loading time of an assembly, but it is usually worth the effort.

Nicer prompts

If you sign your code, it will give much nicer prompts whenever security is involved (e.g. UAC). Notice that for this to work, you cannot use self-signed certificate. You need certificate from one that Windows trusts (e.g. VeriSign). Since those certificates are not cheap (few hundred dollars per year), you can omit it if you are creating small applications or applications that will be used by small number of people. If you distribute your application to large number of people, it would be easier to buy it - that way you will avoid e-mails asking you whether it is safe to install your software.

Easier administration

In one step you can allow (or disallow) all applications from single publisher. I personally used this a lot in order to allow execution of .NET applications over local share. Since .NET Framework 3.5 came out, there is no longer need for this particular case, but some other case may apply to you.

Creating drivers

If you need to write driver, you must sign it. Although it will work without signing on 32-bit Windows, 64-bit version requires trusted signature in order to load it. There are some workarounds, but your customer will not be happy.

Last 32-Bit Windows

When Vista was announced, it was said that it will be last 32-bit operating system from Microsoft. With Windows 7, they changed their mind since Windows 7 will come in both 32-bit and 64-bit flavors.

Server platform took different approach and Windows Server 2008 R2 will come only in 64-bit variant. There will be support for 32-bit applications (WOW64) but underlying system and hardware will work only in 64-bit space.

Once server goes that path, client platform will follow. Windows 7 may be known as last 32-bit Windows.

Keeping Backlight on

Some applications for mobile phone need to be seen. One example that immediately comes to mind is Google Maps. What is use of maps if your mobile fades away after less than a minute of inactivity. It may prove to be rather distracting to press a button or two every ten seconds while driving.

Fortunately there is a way of changing this behavior. But take great care. Backlight is turned off for a reason. Having it on all the time isn’t kind to battery.

Whole secret lies inside of SetPowerRequirement function. This function, when called, switches selected device to one of D states with D0 being full power and D4 being full sleep. Since this change is made on system level, be sure to call ReleasePowerRequirement as soon as you are done. If you fail to call that function (e.g. your program crashes), there is no way to return it to lower power state other than rebooting your machine. Notice also that if your program specifies that D3 is needed and other program specifies D0, device will go in D0 mode - when conflicting modes are selected, higher power always wins.

In example we will just set backlight, but this function can be used for other devices too (first check their name in registry at HKLM\Drivers\Active with MobiReg).

Here is code sample in C#.

Code Samples

Blogger is fine service, but if you want to write some source code inside of post, you are on your own. However there is solution in form of SyntaxHighlighter [2010-12-31: I swithed to it is WordPress’ SyntaxHighlighter Evolved].

From now on you can see code like this:

void Main() {
  Console.WriteLine("Hello world.");
}

Plain text samples are also allowed.
Some lines may be highlighted.
But not all need to.

<xmlPart param1="value1" paramX="valueX">
  <sub>Test</sub>
  <sub>Test 2</sub>
  ...

This looks great if you have JavaScript enabled.

P.S. This post may change from while to while since I will be using it as testing ground. Unfortunately, you can see how exactly code looks only once you publish post.

Is It Byte or Is It Octet

If you read RFC for some network protocol, you will notice that word octet is used quite a lot. I hear quite a lot that they should write byte instead. However, there is subtle difference here.

Octet is always eight bits. Although one may argue that byte is also eight bits, but not so long ago one byte had seven bits of data (remember ASCII). If you go even before that, there were some machines that used lower or higher number of bits to represent one byte (6-bit, 10-bit…). At that time, byte was smallest accessible data unit - no matter how many bits it had. Only with very popular IBM/360, everyone moved toward eight bit bytes.

When writing specification of something on really low level (like RFCs do) with need to communicate across different generations of equipment, this difference is important.

Since byte (at current time) is always eight bits, whole argument seems purely academic, but tradition and precision is important. That is why RFC will never use byte when octet is needed.