Sunday, June 26, 2005

Why WTL?

When researching for a small article that lists WTL resources for Pocket PC native code develores, I found a very interesting piece of information that compares the performance of MFC and ATL (WTL builds on the ATL windowing classes): Oleg Pudeyev's MFC vs ATL. Now, the message processing performance issue is clearly explained. MFC degrades with the number of managed window handles due to its linear search method when mapping an HWND to a function pointer. With ATL's thunking mechanism this is instantaneous.

WTL rocks!

Wednesday, June 22, 2005

Another bug in SQL CE Console (cont.)

The comments I have just made below refer to the DesktopSqlCe assembly that supports SQL CE Console, not to the .NET classes. Thanks to Alberto Silva for pointing this out!

Another bug in SQL CE Console

I'm still banging my head on the wall. Real hard.

SQL commands (SqlCeCmd objects) may be executed either as queries (when they return a SqlCeRowset object) or as simple commands with no data returned (only status info). Interestingly, version 1.0.17 is incorrectly reporting an out of memory condition after a non-query SQL command is executed. Brilliant. So how useful is a tool like SCC when you cannot even create a table???

The version 1.0.18 is out now, with my apologies.

Friday, June 17, 2005

Diving into WTL

I finally decided to adopt WTL as my framework of choice to develop native applications. After a few years of working with MFC I got fed up with it. My first tests showed me that WTL is faster than MFC handling the GUI (the thunking mechanism makes it very fast to dispatch messages from the window procedure to the class). Also, WTL does not carry with it all the cargo I don't use in MFC, such as views and documents (they always seemed to be getting in the way, and not really helping).

Too bad we don't get all the code-generation support that eVC has for MFC, but I'm getting over it pretty fast.

Monday, June 13, 2005

MEDC UK - The aftermath

I'm a bit disappointed. Next year I'll try to attend the US event. Enough said.

On another note: London rocks!

Thursday, June 09, 2005

Off to London

In a couple of hours I will leave to London to attend the MEDC UK. Cool!

Friday, June 03, 2005

Why I still use eVC3

Besides being a very stable development environment, it is still the only game in town for addressing all Pocket PC platforms. Don't just take my word for it, read what the Windows Mobile Team Blog has to say about this.

eVC3 rocks!

Wednesday, June 01, 2005

SQL CE Console 1.0.17 Released

I fixed some vexing bugs on the application and tried for the first time to obfuscate it. It is an interesting concept (and old, very old - remember the "C Shroud" product?) but needs some tweaking. After obfuscating your assemblies, make sure you test them thoroughly. Failing to do so may lead to some very nasty surprises. Anyway, I'm actually thinking about moving more code down to the C++ DLL and actually publishing the wrapper C# code, so obfuscation will be less of a problem.

Monday, May 30, 2005

Pocket Access - V

I got it wrong, let me tell you. After finishing the CEDB .NET code, I started to write the Pocket Access layer for .NET CF and realized how some of my early assumptions were simply wrong.

The CEDB code implements a record containing a collection of properties. Each property maps to a CEPROPVAL structure directly, meaning that the contained value is accessed through bit conversion methods. This is pretty stupid. My early reasoning was that this would make it so much easier to read and write the binary info to and from the database.

When I tried to fill a DataTable object using this approach, I was surprised with the poor speed. At first I blamed the DataGrid but realised that, although it is a slow loader, the bulk of the time was being spent loading the DataTable. I turned my attention to the DataTable and applied all the tricks of the trade to make it load faster. Nah... no way.

But wait! Could it be...? Was it in my code to load the records? Like Michael Abrash used to say: "Assume nothing: Test everything".

Bingo! As any Scorpio worth his salt, I rewrote the whole thing. Upon loading, the record now converts all its properties to boxed values or string references (blobs are just byte arrays, but references as well). These are all packed into an object array which makes it a breeze to load into a DataRow. Buffers are reused to avoid heap fragmentation and the undesirable visit of our friend the garbage collector.

The Suppliers table of the converted Northwind database now gets loaded into a brand-new DataTable object in under 200 ticks on my iPAQ 3850 (I cannot get enough of this machine...), down from almost 600 ticks using the old code. Impressive, huh?

Optimization rocks!

Tuesday, May 24, 2005

SqlCeSpy .NET

I'm starting to publish the full source code for SqlCeSpy, a SQL CE 2.0 database viewer / editor based on the FastSqlCe assembly and the fssce.dll DLL. All managed code is being published for review but not the C++ code. The project file can be found here (Zip 352KB). By opening and using this code, you acknowledge that this code was written by me and that I am the only one to blame for any errors that you may find there (hehehe).

Before you deploy the project to the device, make sure that the fssce.dll file is copied to either the target project folder or to the \Windows folder.

Functionality is now limited to browsing the database structure and to renaming tables, something that seems to be deprecated on SQL Mobile. By the way - what does "deprecated" mean? I'm feeling linguistically challenged here: does it mean that the feature is not supported or that it is supported but should not be used? Comments are welcome.

Monday, May 23, 2005

Debugging over WiFi in VS2005

After all, it seems like we will be able to debug Windows CE 5.0 applications over WiFi in VS 2005. This workaround takes ActiveSync 4.0 out of the way and enables true WiFi debugging. Great news!

Friday, May 20, 2005

Installing a MAPI filter

I recently came across the challenge of writing an application that processed SMS messages. The MAPIRULE sample of the Pocket PC 2003 was duly studied, successfully modified and used. The real challenge came when I needed to cleanly install it and uninstall it. Installing is simple: you just copy the DLL to the \Windows folder, register it (the setup can do this for you) and then you have to soft-reset the device (a setup DLL is required for this). This is quite simple and a sample of soft-reset code can be found here.

Uninstalling calls for a different approach. First, you have to make sure that the DLL is not being used by the SMS-handling process. My answer to this is to shut down the tmail.exe process. Here is some code:

BOOL KillProcess(LPCTSTR pszProcName)
{
HANDLE hSnapshot;
BOOL bRet = FALSE;

hSnapshot = CreateToolhelp32Snapshot(
TH32CS_SNAPPROCESS, 0);
if((int)hSnapshot != -1)
{
BOOL bOk;
PROCESSENTRY32 pe;
DWORD dwID = 0;
HANDLE hProcess;

pe.dwSize = sizeof(PROCESSENTRY32);

for(bOk = Process32First(hSnapshot, &pe);
bOk;
bOk = Process32Next(hSnapshot, &pe))
{
if(!wcsicmp(pe.szExeFile, pszProcName))
dwID = pe.th32ProcessID;
}
CloseToolhelp32Snapshot(hSnapshot);

if(dwID != 0)
{
// Kill the process
hProcess = OpenProcess(0, FALSE, dwID);
if(hProcess != INVALID_HANDLE_VALUE)
{
bRet = TerminateProcess(hProcess, 0);
CloseHandle(hProcess);
}
}
}
return bRet;
}


After killing the process, you have to unregister the DLL (sample code here) and finally soft-reset the device.

A sample setup dll project is available on demand.

Tuesday, May 17, 2005

The New Emulator

The Microsoft Device Emulator 1.0 Community Preview is now available for download (just follow the link). Yes, this is the much expected ARM native emulator. You can actually install retail products on the emulator, run them and even better, develop against it using eVC4 SP4. How cool can this get?

Monday, May 16, 2005

Native is Faster

I couldn't help linking this in:
A .NET Loss

What is strange is presumably they had tried out .NET 2 which would seem to have a more compelling story than .NET 1, but found that lacking as well.

I wonder why...

Data Port ActiveX

I finally managed to write an ActiveX component for the Data Port Component. Instead of using a rocket-science C++ approach, I turned to the venerable Visual Basic 6 to do the job for me. The result of this work is now available online and is made out of two parts. First, you need to download the newest version of dplib.dll (Zip 1.45 MB). You get both the release and debug versions as well as the debug symbols and the map file. Second, you need to download the Vb6DataPort project (Zip 293 KB) that includes both the ActiveX project (DataPortX) and the consuming application with the same name as the Zip file.

This project shows how the Data Port Component must be used from VB6 and uses new code (the dplib.dll is now on version 1.1.25) that is not yet compatible with the published C# wrapper. The C# wrapper will be updated to comply with the changes and will also be published with the source code (it's a very thin wrapper, really).

To make things work reliably, you should put the dplib.dll in the search path or you risk getting a run-time error from VB...

Sunday, May 15, 2005

Windows Mobile Platform Migration FAQ for Developers

The new version of the Windows Mobile Platform Migration FAQ for Developers is now online (just follow the link).

Check out the "Recent Updates" list next to the May 2005 entry: they're about Windows Mobile 5.

Saturday, May 14, 2005

CeDbgView32

Here is an interesting tool from Laurent Docquir to help us in debugging Windows CE processes: CeDbgView32. Cool stuff!

Friday, May 13, 2005

Robert Burdick's Blog

I've just added Robert Burdick's Blog to my list of links. His latest post teaches you how to programmatically turn on or off the Pocket PC WLAN adapter in a device-independent fashion. Great stuff!

Wednesday, May 11, 2005

News for us, Native Fellas

Nishan Jebanasam just posted an article on MSDN on What's New in Visual Studio 2005 for Native Developers. Although some image links are still broken as I write this, it is definitely an interesting read.

There is also another one, also by Nisham, on Migrating Microsoft eMbedded Visual C++ Projects to Visual Studio 2005 where he discusses the Upgrade Wizard and other issues.

Data Port and VB6

I finally managed to make VB6 work with the Data Port Component (or the other way around). Why VB6? Although Microsoft killed it, a lot of people out there is still using it and will continue to do so in the foreseeable future. Interestingly, I recieved a lot of requests to develop a Component wrapper in VB6 from the UK. Being an almost complete ignorant, I shied away from this until one of my customers actually started the project.

At first it seemed quite straightforward. First, I had to change all __cdecl exported functions to __stdcall. The need for the second change was very hard to detect. The supporting DLL was designed to either be P/Invoked from .NET or to be directly consumed by a C++ application. This meant shielding all database-related functions with COM initialization code. This also meant exit exceptions when the DLL was consumed by VB6, either on the IDE or on the standalone runtime. After discovering this, there was the threading issue. Apparently one cannot safely call back into VB6 from an external thread, something that is safe in C++ and even on the .NET framework (that is how the C# sample works). The final solution is to start a timer to poll the import or export progress data. A kludge, but it works.

The nice thing about the whole process is that I had to instrument the whole code just to make sure there were no memory leaks or invalid pointers. A typical case of spring cleaning...