Windows CE Development Notes

From Free Pascal wiki
Jump to navigationJump to search

Debugging your applications

General infos are here Windows_CE_Interface#Debbuging Windows CE software on the Lazarus IDE

  • Sometimes gdb will crash,nothing to worry,just reset debugger and start again.
  • If you have an open call stack window it will take lots of time each time you trace/debug your program and sometimes crashes the debugger,so use it only when needed.
  • Always put breakpoints where needed you can not/or hardly can pause your program or even stop/reset it.
  • You can strip your program with --only-keep-debug which save you around 1mg.There are some issues with strip utility,somethimes it makes your program not executable,So i generally dont recommend using it.
  • Somethimes stepping takes lots of time,just be patinent,i've experienced once a simple assignment took 1min for debugger to execute that code.

Alignment problems

Using ARM processors, some times you may get a EBusError exception with a message about misaligned data access. The following section explains what this is and how to fix it.


What is misaligned data access?

Suppose a CPU has a 8bit data bus to memory and you want to read a byte. Since you have a 8bit bus, you are able to adress all individual bytes, so reading is not a problem. Now imagine a CPU with a 32bit databus and reading a byte. Data is read in chuncks of 32bits (=4 bytes) and it is adressed by multiples of 4. For getting the exact byte, the CPU "shifts" the right byte.


Now we do the same for reading a 32bits integer. On a 8 bit cpu, you have to read 4 times one byte and then you have the integer. On a 32bits CPU it can be read in one go if the adress is aligned to 4 bytes. If not, it has to be read in 2 halves and then combined to one integer. The x86 supports reading like this, alltough it is inefficient. The SPARC and some implementations of the ARM (*) don't support this and raise a buserror if you read data like this.


(*) there are extentions to the ARM core which can handle it, but this depends on what functionality the manufacturer of a specific core has implemented.


How to solve this?

Use typecasts of pointers very carefully. 16-bit and 32-bit values need to be 4-byte aligned in memory. Otherwise bus error will occur. Or use newly added "unaligned" keyword before using them. You can use unaligned keyword both in left or right side of your assignments.

Examples:

var
p1:^Longint;
l:longint;
begin
p1^:=20;  //might cause error if p points to an unaligned memory,ie not 4-byte aligned.
unaligned(p1^):=20;  //it is ok 
l:=pl^;  //this can also generate error
l:=unaligned(pl^);  //it is ok 
end.

When using Pack records,compiler automatically generates all access to the record members as unaligned access.Currently there are some small issues which somethimes with nested pack records compiler does not generate the required code.You just have to use unaligned keyword. But note that using packed records will influence speed a lot as all of its members are treated as unaligned. So use them only if needed.

Known Issues and bugs

SetProp - GetProp - RemoveProp APIs

Windows CE does not have SetProp and GetProp apis which is used a lot.So I have created/emulated those myself. The current implementation is not exactly as win32 apis.In win32 you can set multiple properties with diffrent names to each window but here i ignore names so we can only have one kind of property assigned to each control.(it is easy to implement that, but i find it currently of no use). Also removeprop is not called yet! So a memory leak happens each time you exist the program.(i dont know if wince also frees memory itself or not when window handles are destroyed).Should be implemented soon.

Exiting Programs

After you clicked the X exit button,you have to do something -like clicking somewhere-to make program exit. Reason not yet known.

LCLControlSizeNeedsUpdate LCLBoundsToWin32Bounds LCLFormSizeToWin32Size GetLCLClientBoundsOffset GetLCLClientBoundsOffset

I havent even bothered myself to know are these woking or not.I also dont think we need them as they exist in win32.So might require some redesigning.For example in TWinCEWSWinControl.SetBounds i had to remove movewindow becouse it moved it to nowhere.

Brushes

We dont have them as they are in win32,i've mapped CreateBrushIndirect to CreateSolidBrush and CreateDIBPatternBrushPt,other flags-if used in lcl(not seens so far)-will fail.

Other Stuff

Well i dont know what call the following but these are things i know,and i thought you might know too!

External signal(?) error

From time to time you might see this from debugger.It is misaligned datatype error,which in normal cases you shouldnt see. You can solve this problem by adding unaligned keyword to the code that generates this error. This error can happen everywhere that memory access is likely to be done.


Menues

They require some extensive work.Need a little more background on how lcl handle menus and maybe some modifications to that too!


For Future

Copy-pasted win32 code

Well yes wince interface is working,with not that much known bugs,but i think by removing and changing lots of current codes we can make wince interface faster and better. Also make sure to state descriptions of winapi from wince,currently it is same as win32,but sometimes they differ.


Currently programs compiled with Lazarus and WinCE Interface is optimized and expect to work only on PocketPC Devices.


Links

Here are some links that migh be usefull for creating windows ce interfaces

How to Port Your Win32 Code to Windows CE

Old but usefull article show flags required for creating wince controls

Page with nice descriptions of lots of flags

Adapting Application Menus to the CE User Interface

Differences between normal Win32-API and WindowsCE (old wince)

Resource-Definition Statements

GUI Control Styles

Developing Orientation and dpi Aware Applications

Developing Screen Orientation-Aware Applications

Introduction to User Interface Controls in a Windows Mobile-based Smartphone