Well, I hope it takes a while before devices appear

Today, Microsoft announced Windows Mobile 5.0 (codenamed ‘Magneto’). They’ve made two bone-headed decisions from a development perspective:

• ActiveSync 4.0 no longer supports TCP/IP synchronisation
• According to this page, eVC 4.0 cannot be used to develop for Windows Mobile 5.0. You must use Visual Studio 2005.
• Also, it seems you can’t use VS.NET 2003 to develop Compact Framework applications for WM5. Likewise, you must use VS2005.

The first can be worked around – you don’t need to use the ActiveSync transport or startup server for Platform Manager, but it’s a heck of a lot more convenient than using the TCP/IP Transport with the Manual startup server. With that combination you need to enter a horribly long command line (example: CEMGRC.EXE /T:TCPIPC.DLL /Q  /D:192.168.1.2:5913) on the device. VS.NET 2003 and 2005 do not use Platform Manager, though – trying to get both hooked up to the same device – as I tried to do today to actually view the contents of a memory block allocated in C# code, because opening the debugger memory window kills the debugging session – is highly problematic.

The second and third are idiotic. Hint to MS: VS2005 is not yet released! Yes, there’s a beta. No, I wouldn’t trust it for production development.

And there’s a new development. Mobile device development is a feature in the Standard Edition and above. It is not a feature of the Express Editions. Microsoft claim that there will be a Compact Framework SDK. Previously eVC was free. This made a big difference.

It’s not as if you can mix-and-match that well, either, because the current VS2005 beta apparently requires ActiveSync 4.0 – not actually released yet – in order to deploy to a device. Gee, thanks </sarcasm>.

Yup. Mobile developers get the shaft again. I’ve spent some time today trying to work out a way of avoiding getting blocked when calling InternetCloseHandle when a dial-up networking link has gone down. We seem to have the choice of either rebooting when blocked (enterprise app, so not completely out-of-bounds but undesirable, especially when the hardware cold boots when it was supposed to warm boot) or leaking handles, or rewriting to use WinInet asynchronously. WinInet isn’t well documented for the synchronous case, for the async case it’s downright abysmal.