Sunday, 2 April 2006

A question for the mobile networks: when are you going to deploy EDGE?

Mobile data communications is starting to become a major business tool, for many logistics and distribution companies, and businesses who have a logistics or distribution component. Instead of downloading a whole batch of work to a handheld or other mobile computer, then uploading the results of the whole batch at the end of the working day, the business can get more timely information by having the mobile send its results as work is done. The business can also expose some of this information to its end customers, for applications like live package tracking. A system can even send live data updates of additional work required to the mobile computer, reducing requirements for the user to manually input job information.

For timely updates and responsive applications, it helps to have fast transfer speeds. The last generation of enterprise mobile handhelds, at least here in the UK, supported integrated GPRS. The new generation just coming on stream support EDGE – Enhanced Data rates for GSM Evolution (hmm, smells like an invented name to me). EDGE offers more bandwidth than GPRS, but is entirely compatible with GSM using the same basic radio format, unlike UMTS (3G). This enables existing GSM networks to be upgraded to support the higher data rates.

Unfortunately, on the whole, the UK networks haven’t. They’ve concentrated on 3G. Orange have recently announced some EDGE support, while (as far as I know) the others have made no such announcements.

The networks spent a huge amount of money on 3G licences, and the customers basically haven’t turned up (ok, Ian, I’m excepting you and your N90!) It shouldn’t matter where they recoup this investment – hell, it’s now a sunk cost. Recouping from the mass market of existing 2G customers, to me, makes more sense than trying to charge huge premiums on UMTS.

Adding EDGE would also improve bandwidth for 3G users outside the 3G coverage area, probably at a lower cost than expanding the 3G network, assuming that the user’s equipment also supports EDGE.

Now, I wonder if someone could ask this question for me?

Saturday, 1 April 2006

Race condition in eVC linker?

I’m not sure exactly why this happened. Yesterday I was trying to do a batch build for one of our most complex components – our Barcode Scanner Hardware Abstraction Layer (ScanHAL). This is a set of libraries which implement the same interface, to make our applications hardware independent with respect to the barcode scanner, making it possible to run more-or-less seamlessly on HHP Dolphin, Intermec and Symbol hardware, as well as on handhelds with no built-in barcode scanner (there’s a stub implementation). The clever bit (heh) is that all of the different libraries are included in the same CAB package, with a setup DLL which probes to decide which library is correct for the handheld it’s running on.

Anyway, the release process involves a batch build of everything, which rebuilds everything from source. For historical reasons the projects still support Pocket PC 2000, which ran on a bunch of different processor types (ARM, MIPS, SH3, x86 emulation). The build process currently builds both debug and release builds. For one particular customer, we made available a release build with debugging information, stripped of private symbol information using a tool by John Robbins called PrivateStrip – this means that they can tell us which function the program crashed on, if it does, but can’t easily disassemble the library. So in all there are about 20 different configurations of different libraries that need to be built.

Unfortunately since Wintellect reorganised their website, PrivateStrip is no longer available. I hope they’ll reinstate it.

Yesterday, the linker was repeatedly hanging in the last stage of building DLLs: it had just output the message about building the .LIB and .EXP files, but wasn’t completing the build. On a couple of occasions it did this on the last DLL – but it wasn’t consistently on any given DLL. My work machine is hyperthreading-capable, and this was happening with HT enabled. Turning HT off enabled me to complete the build.

I don’t know whether this would also happen on a dual-core or other multiprocessor machine.

You might need to be careful if you’re using older tools (eVC 3.0 and 4.0 both use modified versions of Visual C++ 6.0’s LINK.EXE) on a computer with more than one logical or physical processor.