January 2010 Archives

This advice is for Microsoft Virtual PC. When you use software like VMWare, it automatically allows the host to connect directly to the client using the virtual interfaces that have been created.

Most of the recommendations with regard to connection to/from the Virtual PC client recommend configuring the connection to share/bridge one of the network connections.

All very good and well when you're on a network. I regularly use the system when I have no network available - i.e. I'm completely disconnected. Most of the connection sensing code for network adaptors prevent you from using it while it's not active, plus I don't like having to configure the connection manually and then reconfigure it when I've got a real network.

The simple solution is to add a Microsoft Loopback Adaptor to the host machine, then create a second network interface on the Virtual PC that uses this interface. Manually configure the IP addresses to be on the same private network, making sure that you don't accidentally configure it to use an IP address range that you may end up using for a VPN connection.

1. Add the Network Adaptor: XP, Vista, Windows 7
2. Configure the IP address manually. Use a Private Address Range. I chose an IP address of 10.125.1.1 with a netmask of 255.255.255.0 for the host, then chose 10.125.1.2 for the Virtual machine. XP, Vista, Windows 7 - Use the instructions for Vista.
3. Shutdown the Virtual Machine, Don't hibernate as you can't add the second network interface.
4. Edit the properties of the virtual machine (in the Virtual Machines folder). Either Right Click on the Virtual Machine Icon, or use the Settings Option in the menu bar.
   
5. Configure the network to have 2 interfaces, one of which is linked to the 'Microsoft Loopback Adaptor'
   
6. Boot up the virtual machine, and follow the instructions for manually configuring the IP address of this new network interface.

Direct connections to the IP address of the client virtual machine now work, and you can use it for anything you want.

Following the instructions here, even if they're confusing, once you add a dword key called '*NdisDeviceType', with a value of 1, you don't see the connection as an unknown connection; thus enabling sharing and other features in Vista, Win 7.

It's not difficult to set environment variable in Windows. System level variables are stored in HKLM/System/CurrentControlSet/Control/Session Manager/Environment. User level variables are stored in HKCU/Environment. They are either REG_SZ or REG_EXPAND_SZ variables. REG_EXPAND_SZ values use other environment variables to get their ultimate value, while REG_SZ values are considered 'final destination' variables.

The issue arises when you programmatically change the value and want it reflected in new programs that are launched. You make your changes in the registry, but none of the newly launches applications notice the change. You need to inform all the running applications that the settings have been changed. To do this you send a WM_SETTINGCHANGE message to all the running applications.

The logic is to issue a SendMessage(HWND_BROADCAST, WM_SETTINGCHANGE, 0, (LPARAM)"Environment"). As the meerkat in the advertisement says 'Seemples'. Unfortunately, I have a couple of applications with badly written message processing loops which don't defer to DefWndProc if they don't handle the message, which causes this function to hang.

The more sensible logic is to use a SendMessageTimeout call, which has 2 extra parameters, one of which is a flag and the other is a timeout in milliseconds. The timeout is a maximum per window, which means that if there are 10 windows causing timeouts and you're issuing it with a 1000 milli-second (1 second) timeout, then you will be stalled for 10 seconds. You have been warned. Most applications should respond in < 100 milli-seconds, and typically there are only a few badly behaved applications.

This brings us to the code. It's short, and it's C and it doesn't do anything fancy at all. Compiled using MinGW as gcc -mwindows settings.c -o settings.exe

#include <windows.h>

int APIENTRY WinMain(HINSTANCE hInstance,
  HINSTANCE hPrevInstance,
  LPSTR lpCmdLine,
  int nCmdShow)
{
    DWORD output;
    SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, 0,
      (LPARAM)"Environment", SMTO_BLOCK, 100, &output);
    return (0);
}

Set a variable in the registry. Pop up a cmd window and issue a set command and the change is not reflected in the window. Close the window, run the settings program compiled above, then launch another cmd window and it will now reflect the change to the environment you made in the registry.

The message causes Explorer to re-read the environment, which is why newly launched programs see the changes. You are launching your applications from explorer (the start menu, icons on the desktop, the run menu) for the most part.

It looks like all the built-in iPhone apps support 'instant resume' - which means that when you swap applications you get exactly where you were previously.
This is the palm ethos - kill the application when switching. It's pretty efficient. Memory use is reduced because you can reclaim memory from the terminated applications.
On the original Palm platform, there was no memory protection - the processor didn't support it. When the system migrated to the ARM processor, it was emulating the original m68k processor, but with added features like improved speed and optional hardware specific acceleration.
You were exhorted in the development guides for the palm platform to ensure that when a user returned to your application it was in exactly the same state as when you left it.
The problem seems to be that an awful lot of applications on the Apple platform do not implement this feature. As a result when you use applications you seem to get kicked to the start of your workflow when you restart it, which is really annoying.
Until applications can actually implement the palm ethos, then people will continue to cry for multi tasking.
Honestly, I think there is a place for push/pull based background tasks that would operate on a scheduled basis - that way you could run them all at a burst, consuming only a small amount of power for the entire set of jobs. This is something that is implemented in Windows 7 (see Extending battery life with energy efficient applications). By keeping the overall CPU utilization down energy consumption is kept down.
Scheduled tasks anyone?