Byte Alignment Bites
We are so spoiled when developing for the Windows platform. It is polite enough to allow us to access mis-aligned data (data which is not aligned on machine word boundaries). I have been tinkering around with some ActiveSync code on a Compaq Aero and just finished getting a fresh reminder that non-aligned data can and does result in worse than sub-optimal performance.
In particular, the data exchange occurs within the GetPacket and SetPacket methods of the IReplObjHandler interface. This interface is implemented on both the desktop and the device. I have written the desktop bits in Delphi and the device bits are in Embedded Visual C++ 3.0. Normal thought processes suggest minizing the volume of data passing over the link (especially when it is serial 19200-56000). So, as is typical,I immediately packed the structures for all text content. Basically it is just a fixed header with a variable portion followed by one or more variable length property entities. This format permits me to send just about anything and is relatively robust except for the overhead associated with the property names travelling in each packet exchange. But that is getting a bit off topic (as I am permitted to at this time of night).
All was fine with marshalling the data on the desktop (where you can debug, have a good tool, etc.) but the ActiveSync connection would literally drop and there was nothing logged as to the failure other than a NAK (obscure at best). With some heavy injection of file based debug statements in the code in question I found that the system simply stopped when trying to access the second property header. For whatever reason as soon as I saw what was happening it just sort of turned on a light bulb for me (gotta love that on those rare instances). So, now the marshalling code does four byte alignment on strings that it passes along. It was quite easy since the data lengths were already being used so I was pretty lucky in terms of length of time to finding the bug and fixing it. Now I can get on with the rest of the tinkering.
So, the lesson, remember that all platforms are not created equal and you still need to know something about what is underneath. Happy coding.
In particular, the data exchange occurs within the GetPacket and SetPacket methods of the IReplObjHandler interface. This interface is implemented on both the desktop and the device. I have written the desktop bits in Delphi and the device bits are in Embedded Visual C++ 3.0. Normal thought processes suggest minizing the volume of data passing over the link (especially when it is serial 19200-56000). So, as is typical,I immediately packed the structures for all text content. Basically it is just a fixed header with a variable portion followed by one or more variable length property entities. This format permits me to send just about anything and is relatively robust except for the overhead associated with the property names travelling in each packet exchange. But that is getting a bit off topic (as I am permitted to at this time of night).
All was fine with marshalling the data on the desktop (where you can debug, have a good tool, etc.) but the ActiveSync connection would literally drop and there was nothing logged as to the failure other than a NAK (obscure at best). With some heavy injection of file based debug statements in the code in question I found that the system simply stopped when trying to access the second property header. For whatever reason as soon as I saw what was happening it just sort of turned on a light bulb for me (gotta love that on those rare instances). So, now the marshalling code does four byte alignment on strings that it passes along. It was quite easy since the data lengths were already being used so I was pretty lucky in terms of length of time to finding the bug and fixing it. Now I can get on with the rest of the tinkering.
So, the lesson, remember that all platforms are not created equal and you still need to know something about what is underneath. Happy coding.
Labels: Mobile
