Chapter 1

ARM data alignment rules are strict; x86 alignment rules are more relaxed. If you need
alignment, copy potentially unaligned data byte by byte into an aligned area. For example,
TBuf8 buffer;
TInt index = 39; // not a multiple of 4!!
TInt* p = (TInt*)(buffer.Ptr() + index);
TInt i = *p;
The cast ought to be a warning of trouble; this code is platform dependent. It happens to
work on x86, but not on ARM, where it generates an alignment fault. You need to use code
like:
TBuf8 buffer;
TInt index = 39; // not a multiple of 4!!
TInt i;
Mem::Copy(&i, buffer.Ptr() + index, 4);
On a target phone, each application and server is a separate process, with its own .exe. On
the emulator, there is only one process, so applications use apprun.dll instead of
apprun.exe and most servers are delivered as DLLs. There are established patterns for
working around these issues; they affect very few lines of Symbian OS code. For
applications, the issue is addressed for you, so you don't need to worry. If you write a server,
you'll need to copy one of the standard patterns, such as the one in Chapter 19.
On the emulator, all Symbian OS threads run in the same PC address space. Standard
Symbian OS programming uses active objects and the client-server architecture, which
means that deliberate use of shared memory is very rare. So very few programs are by
nature difficult to debug because of differences between the emulator and target machines.
Some very obscure and awkward bugs can result, however, whereby code with random
reads or writes appears to work under the emulator, but crashes quickly on a target
machine.
The emulator builds on top of Win32 APIs; real Symbian OS builds on a microkernel,
hardware, and device drivers. If you're programming these, then the emulator won't help;
you need the real hardware. Likewise, the emulator is of less help if you're working with
communications in which there are always device-specific issues. Timing resolution is
different on the real hardware and on a PC. This makes a big difference when implementing
anything that is timer-driven, particularly any communications software. On the real
hardware, the timing resolution is finer (typically 1/64 s compared with 1/10 s on the PC), so
fast timers can be very slow on the PC. This makes it especially important to test
communications software on the real hardware as early as possible.
On target phones, Symbian OS controls the executable image format and has incorporated
UIDs into it. On the emulator, Symbian OS clearly doesn't control the executable image
format, so we use the stub.uid.cpp file to generate UIDs into the .E32_UID data
segment. Files on the emulator are recognized as such by the application architecture, but
aren't checked by the Windows loader as they are on a target machine.
For some projects, you can build for the emulator only, until the day before you ship. A
simple rebuild, and you're up and running on the target hardware and everything's fine. But it
would be unwise to think all projects are like that, even all those that 'ought to be'. Any of the
issues I mentioned above could be a factor in your project. The best way to tackle issues is
to see them a long way in advance. Build periodically for the real hardware. Check for
obvious bugs, UI considerations, and performance. Take action early on, while you can still
make a difference.