Watermark rendering bug in ListView

Or at least, in the ‘My Pictures’ folder in Windows XP Explorer. Try it yourself – ensure the watermark is enabled. Then right click and select ‘New Text Document’. Click to remove the rename highlight. Then select it again and press Shift+Del. Hit Yes.

If this reproduces on your computer, you’ll see something like this:

I guess the ListView code simply calls ScrollWindowEx to move any remaining lines up, but doesn’t take account of the watermark.

New technology plug: since Avalon is a stored graph system, it should handle this kind of thing for you. That is, you tell it what components make up your rendering – it renders the appropriate parts as required.

More Mobile Developer Shafting: Compact Framework 2.0 won't run on CE 4.x

I downloaded the Compact Framework 2.0 Redistributable yesterday as well, planning to do a little testing with one of our CF 1.0 apps. (I need to discover how to force using 2.0 if both are installed). In doing so I discovered that CF 2.0 only supports Pocket PC 2003 and Smartphone 2003, Windows CE 5.0 custom platforms, and Windows Mobile 5.0 (for Pocket PC and Smartphone).

That means that new devices, introduced this year, like Symbol’s MC3000 which runs a custom CE 4.2 platform, are not supported. Why aren’t Symbol using CE 5.0? Who knows. Maybe they didn’t want to revalidate all their components on the new OS yet.

Yesterday I was at the London Eye. They appear to use PPT 2800s with the optional trigger handle to scan the barcoded tickets. This device runs Pocket PC 2002.

Customers often want upgrades and/or new applications to run on existing hardware. We’d like to be able to use the newer tools to implement those upgrades or new applications. But we can’t, because those tools won’t run on the old hardware.

The full framework is compatible back to Windows 98. We can’t get three years’ worth of backwards compatibility in the mobile world.

.NET Framework 2.0 Compatibility

Brad Abrams: Take the .NET Framework 2.0 Compatibility Challenge.

I was at a slightly loose end yesterday afternoon, so I took advantage of that time to check that Meteor Server, and the price checking/stock availability application we wrote for a large deployment at a UK retailer, still work correctly under .NET Framework 2.0 Beta 2.

Meteor Server itself is mostly VB6 components – a server executable, an application-host component executable (ActiveX EXE in VB6 terminology), a few application-interface components which have strict binary-compatibility requirements – with a few bits of C++ where the VB6 environment really ran out of steam (TCP/IP printing, since TCP is a pain with the Winsock control, and a ‘callback’ component which replaces the use of minimum-delay timers). Applications are written as COM components. Recently – in the last couple of years – we’ve been writing new applications in VB.NET or C#. We’ve generally found that more productive than VB6. To do this we’ve built Primary Interop Assemblies [PIAs] for the application-interface components.

Meteor Server isn’t really .NET-aware. We do ship configuration files for the server and application-host executables, to force the latest version of the PIAs to be used. This allows older applications to run on a newer version of the server, without having to distribute the PIAs with each app, or all versions that have ever existed with Meteor itself. Remember that .NET binds to a specific version of an assembly, not to the most recently installed. We did try using Publisher Policy but had problems with it – sometimes the Framework would fail to load an application object, often crashing with an Access Violation in fusion.dll. Due to a misunderstanding in version numbers we had to ship multiple policy DLLs when using that scheme – one for every major.minor version of the PIAs we’d released.

Using explicit configuration reduces the frequency of this problem, but not to zero – we still occasionally see this in deployment, with Framework 1.1 SP1. It’s something of a heisenbug – it never happens when you’re looking for it. And a particular nightmare when dealing with VB6 code, because the VB6 debugger does not run your code as it will be run in deployment. Instead it hosts it in-process in the VB6 environment. You’re not even running the compiled code, I believe it translates the code to p-code and interprets that. While you can turn on PDB generation and debug with VS.NET or another native code debugger such as WinDbg, the generated PDBs are poor quality and don’t, for example, often include your local variables or globals properly.

Since it’s not really .NET-aware, the default behaviour of the Framework when loading into an unmanaged host applies – the most recent version of the Framework is loaded. We support loading alternate applications under application control in the newest versions of Meteor (I think the version currently available on our website is very out-of-date). The aforementioned price-checking application is actually implemented as four applications: a menu application which loads the others, the price-check application, the stock-availability application, and a head-office application which has testing features. This does mean that all applications will need to support the latest version of Framework, or the admin will need to tweak the config files to force all applications to bind to the older runtime.

Anyway, I’m pleased to report that there were no obvious problems using Framework 2.0 with any of these applications.

StarCraft: Ghost

How long have we been waiting for Blizzard’s StarCraft: Ghost? I can’t recall – I think they first announced it in 2001.

This week at E3 Blizzard have published new trailers and gameplay movies. I can’t help thinking it might be too little too late. What blew us away three or four years ago now looks a bit, well, ordinary. Halo 2 seriously raised the bar.

What’s been taking so long? I don’t know, but it looks like Blizzard have ditched their original partner Nihilistic Software, bought up a console developer, and brought the game back in-house.

The question for Blizzard: can they release this game before the next generation of hardware arrives and they look completely stupid?

Xbox Backwards Compatibility

Xbox Backwards Compatibility

Now that it's been announced at E3, I can finally reveal that the Xbox 360 feature I work on is... Xbox backwards compatibility!

Yes, it's real. It's been fun to watch all the wild speculation over the past year or so as to whether the Xbox 360 would or wouldn't be backwards compatible. And all the wild ideas about how hard or easy it would be. It's clear that a lot of people have very little understanding of how these things work.

Were I forced to speculate, I’d expect some kind of JIT-compiler like the x86–on-Itanium IA32EL or the x86–on-Alpha FX!32 is involved. I can’t remember the old rule-of-thumb for emulation – was it that you should have a processor ten times as powerful as the emulated processor to reach parity? Of course that was for state-machine-based emulators, where essentially each instruction was executed in turn by emulating instruction fetch, decode, execute, retire.

Whether a particular Xbox game runs on Xbox 360 will depend on just how closely the assumed-JIT and its library emulate the original processor and, of course, GPU. Hopefully the fact that Jet Set Radio Future was a launch title and was bundled with some consoles (e.g. mine!) will be taken into consideration!

Dammit, more incompatibilities

From Windows Mobile Platform Migration FAQ for Developers:

Starting with Windows Mobile 5.0, only one instance of the installer (wceload.exe) can be running at a time on Pocket PC devices. This restriction has always been in place on Smartphone. As a result, CAB files that start other CAB files from a custom setup DLL may not work on Windows Mobile 5.0. The workaround for this is to have a small executable in the CAB that a custom setup.dll starts in its Install_Exit entry point. This executable can get a handle to the running wceload.exe process, wait for wceload.exe to exit, and then restart wceload.exe on the additional CABs.

We have a pretty clever (says he who wrote it) technique of packing multiple CABs into one wrapper CAB file, which enables us to install Compact Framework, SQL CE, our barcode scanner hardware abstraction layer (ScanHAL), our simple large-key input method, and the application itself, all in one go. Looks like I’ll need to rewrite it slightly at the install-to-RAM stage.

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.