Flicker-free Paint on Windows Mobile

On our desktop systems answer to flickering in Paint event was to use double buffering. .NET Framework supports it out of box and if you do not like built-in solution, there is quite a few solutions out there. Most of them use SetStyle method in order to inform Form that custom draw will be performed.

If you try that in Windows Mobile, you have a problem. Not only that there is no SetStyle, but you must remember that your application needs to work when rotated (all mobiles with keyboard need rotation too).

Solution is to create your own double-buffered class. Whole idea is rather simple, create bitmap with size of control (client area only) and draw everything to it. Once you have drawn everything you need, paint this bitmap over your control. Since this will be done in single operation, no blinking will occur. Be sure to override PaintBackground method also. If you forget that, you will still have flicker since painting will be done in two passes. First pass will be erasing background - usually in white, and second pass is drawing your buffer. Such sudden changes between white and non white tend to be noticeable.

Here is sample code that I usually use.

Finding Differences

I often have need to compare two files. Usually, I just use PSPad compare, but that tool can be quirky at best.

I tried lot of stand-alone freeware programs for that purpose, but SourceGear’s DiffMerge was one I selected. It just works (and it works fast). Along standard features for such programs, there are two features that made it special to me.

First one that I liked a lot is capability to show changes within line. It will show you exactly which characters were changed. You can quickly see what was really changed and what was just small correction. Another one is integration inside Windows Explorer. While most programs do this, this one does it properly even on 64-bit systems. That was problem for all others I tried.

If you are looking for file compare program, try this one. There are lot of features inside that I didn’t mention and program is really easy to use.

Creating Self-signed Certificate

There are lot of providers of code signing certificates out there. But they all share same problem - they are not cheap. Certificate will cost you in range of 400 € (that is per year). Why pay that money when we can make our own free self-signed certificate? Yes, Windows will not recognize it as trusted, but it still can be used for file integrity purposes.

In order for this to work, prerequisite is having Microsoft Windows SDK installed (here is Windows Vista and Windows 7 link). All our work will be done in “C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin” (for Windows 7 or something similar for Vista).

First we need to create certificate with private key:

makecert.exe -pe -n "CN=Example;E=example@example.com" -sv example.pvk -a sha1 -r -eku 1.3.6.1.5.5.7.3.3 example.cer
Succeeded

Window will pop-up and ask for password. You can leave it empty - we can delete private key after we finish. Notice that we are creating code signing only certificate here (-eku 1.3.6.1.5.5.7.3.3). If you wish certificate for all purposes, just omit that argument. Notice that CN and E parameters are ones that you would want to change.

Since with certificate alone we cannot do anything, we need to go through hoops in order to get pfx (PKCS #12) file:

cert2spc.exe example.cer example.spc
Succeeded

pvk2pfx.exe -pvk example.pvk -spc example.spc -pfx example.pfx

PFX file can be imported. Just double-click it to get to Certificate import wizard and continue clicking until it is done.

This whole game caused our certificate to get imported to current user’s personal certification store. We can now safely delete all intermediate files (four of them: .pvk .cer .spc .pfx) since everything we need is in our user account. Smart idea would be to make backup of example.pfx before deleting (e.g. just in case Windows need reinstall) or we can just export it from certificate store at later time.

Code signing itself is lot easier. Just one command is needed:

signtool.exe sign /s "My" /n "Example" /v "test.exe"
The following certificate was selected:
Issued to: Example
Issued by: Example
Expires:   1.1.2040. 0:59:59
SHA1 hash: 740F9468A344BF7BB4DC338C2870BD73BB8797C3
Attempting to sign: test.exe
Successfully signed: test.exe
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

Take care that this “Example” is same one you used after CN= (a.k.a. common name) in first command.

There it is, you have signed your executable.

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.