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.

How Big Is Int

When I started programming, I was told that C++ integer (int) is always as wide as processor. On 16-bit processors it was two bytes, on 32-bit processors it was four bytes. Reason was optimization. This was very simplified view since C++ only said short <= int <= long. However, it was true enough.

Currently there is not one but few 64-bit data models in use. You as developer do not have say on which model to use. Choice is made once you decide on which operating system your application is to be executed. If you use Windows you will use LLP64 data model (16-bit short, 32-bit int, 32-bit long, 64-bit pointer). With Linux as platform of your choice LP64 is used (16-bit short, 32-bit int, 64-bit long, 64-bit pointer). Difference is small, but it can make life difficult if you develop for multiple platforms.

Fortunately in most of modern managed environments (e.g. .NET, Java…) data type size is fixed. I find this much better.

Service Triggers

In order to speed up booting and avoid unnecessary hog on resources, Windows 7 gave us possibility of running services only when some preconditions are being met. Currently those preconditions include change of IP address, joining a domain, firewall changes, USB device insertion and few others.

This is great for services that need to perform some action when that precondition is met and spend most of time waiting (e.g. update some settings on IP change).

Currently there is no graphical interface to view/change settings so everything needs to be set through application’s code (or command-line). Since service (and it’s installer) are in best position to know when activation is needed, I do not find this a big limitation. Those programming in .NET will need some P/Interop in order to use it.

You can check this video for more details.