Finally: One language, three worlds.

Eureka. At last. With the release of the System.Windows.Forms assembly for Mono a dream comes true. Well, this sounds a little over the top but it felt like that the first time I got my 'SimpleTerm' application running on Ubuntu. SimpleTerm is C# application for serial port (RS232) communication that I originally created for the PocketPC using SharpDevelop. By using only CLR functions that are available in the Compact Framework I could build an application that runs on a PDA and a desktop, unchanged!. So it was exactly the same bytecode on both platforms. Now this does not work on the Mono platform (although there seems to be a way to patch the bytecode itself) but after I imported the project into MonoDevelop and just compiled it, it actually worked ! Which could be considered as a breakthrough merely for the fact that it supports serial communication !. So it's not just a 'Hello World window' with an OK button but its a real application that even supports the most underappreciated form of digital communication. And I say 'underappreciated' because the RS232 specification was established in 1969 and it has been the main form of communication between computers for over 35 years. But it is only since the release of System.IO.Serialport in version 2 of the CLR that serial communication is really supported out of the box in a mainstream development framework. I know this is not an issue for most people, but if you are working with instruments and microcontrollers whose only means of communication is still plain RS232 it is a real revelation.
The image shown here is a combination of three screenshots, one of a PocketPC emulator, one from an Ubuntu system running within a virtual machine and one from a 'standard' Windows XP computer. The text in the main window of the application shows the result of a call to 'Environment.OSVersion' which indeed reports the operating system and version on all three systems.

Serial Communication Trouble

Ever since the 'real' serial comport (the hardwired connector on the rear of your PC) has been replaced with all types of 'virtual' alternatives like IR ports or Serial to USB devices, it has been a cause for all kind of trouble. And I've seen many of them, but the one I found this morning was new to me. Suddenly one of the programs I've written myself showed 18 comports to choose from. Now the program uses a dedicated function to enumerate the available ports, so obviously I thought it had something to do with a bug in my software. Also because the 'Hardware manager' of the PC only showed the two comports that are actually available. On the other hand I found that some other software that uses serial ports showed the same behaviour.
So I looked at the registry ( HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM) to find out which port were actually registered. And this showed all 18 as \Device\VComxx, where xx is the port number. So obviously something was creating virtual serial com ports. But what? I did not add any hardware to my PC that could cause this, nor did I install any serial com port related software or drivers.
So finally I located in the System Properties -> Device manager under 'System Devices' two suspicious entries: 'NCF Virtual serial bus enumerator' and 'VXCOM port'. The first turned out to be the 'Nokia Communication Framework', something I installed long ago in an attempt to communicate with my Nokia phone. After searching on the web for the second one, I found only a few entries, but it seems this one is related to the Windows Mobile 6 SDK, which I indeed installed last week. And when I disabled this driver, the problem was gone.
Apparently VXCOM is a virtual com driver used for the SmartPhone emulator. Why it reserves 18 ports at startup, even though I never used this emulator is a mystery to me...