Windows/Windows CE: Difference between revisions

From KDE Community Wiki
mNo edit summary
 
(40 intermediate revisions by 6 users not shown)
Line 1: Line 1:
== Introduction ==
== Introduction ==


This page describes a work in progress, there are no KDE Applications running on Windows Mobile (that I know of). It is only intended to give a starting point to developers for cross compilation and Windows CE related issues. Since Qt is already ported for Windows CE it should be possible to get some KDE applications running on that Platform.  
'''This page is mostly deprecated''' it was started for a Project to port Kdepim to Windows CE. All additional patches / cross compile techniques can be found in emerge from the KDE - Windows initative.
Binaries for Windows Mobile 6.5 and a source tarball of Kontact Touch (an optimized variant of KDEPIM software for Touch enabled devices) can be found at:
http://files.kolab.org/local/windows-ce/Kontact-Mobile/testing/latest/


== Building Qt for Windows CE with MSVC ==
=====Windows CE / Windows Mobile=====
Although Windows CE (officially called Windows Embedded CE) is part of the Windows Embedded family there is a large difference between Windows Embedded CE and other Windows Embedded products. Most importantly Windows CE is not Windows. It has a different Kernel then any other Windows Operating System. And while other embedded products like Windows Embedded Standard or Windows Embedded Enterprise (which are sized down versions of Windows XP) will run Windows applications without problems, Windows CE applications require porting even from Windows.<br>
Windows Mobile then is based on Windows CE (CE has no official meaning) and it's current Versions Windows Mobile 6.1 (and 6.5) are based on Windows CE 5.2 so we will be talking about developing for Windows CE 5.2 when we are talking about developing for Windows Mobile 6.1 or 6.5.
It is confusing but Windows Mobile 6 is '''not''' based on Windows CE 6 so it still has the limitations of Windows CE 5. For example the process address space is still limited to 32 MiB and the maximum Number of processes can not exceed 32.


==== Setting up Visual Studio<br> ====


First thing you need is Visual Studio professional or standard edition (preferably with service pack 1).
===Process limit===
Be aware that the express editions are explicitly not supported for Windows CE development.<br>
Confirmed on HTC Touch Pro (Wimo6.5 CE 5.2.21854)
(You could use [http://www.microsoft.com/downloads/details.aspx?FamilyId=1DACDB3D-50D1-41B2-A107-FA75AE960856&displaylang=en%20 Microsoft Embedded VC] which is cost-free, but depreciated and not supported by Qt) <br>Next thing you need is a Microsoft Windows Mobile Platform SDK corresponding to your target platform. Just search the Microsoft download pages or get the Windows Mobile 6 SDK from [http://www.microsoft.com/downloads/details.aspx?FamilyID=06111A3A-A651-4745-88EF-3D48091A390B&displaylang=en here] (You should take a loot at the System Requirements)<br>If everything is set up correctly you should now be able to create a “Visual C++ smart device" project in Visual Studio.<br>
running:
      for(i=0;i<32;i++){
          if(CreateProcess(L"test1.exe",(LPCWSTR)cptr,0,0,0,0,0,0,0,&procinf))
            fprintf(file,"Process Nr.%i ID: %u started\n",i,procinf.dwProcessId);
          else
            fprintf(file,"Creation failed after %i processes\n",i);
      }
I was able to create 16 processes at most after a fresh boot. (32 alltogether, including kernel thread)


===Memory limit===
The Memory limitations on Windows CE < 6 are a serious Problem. Additionally to the limitations that are normal for embedded development, you have to deal with limitations on the address room.
There is a very good Article about Windows CE < 6 Memory management and how to deal with the limitations at:
http://msdn.microsoft.com/en-us/library/ms836325.aspx
The same author wrote a blog entry about changes in Windows Mobile 6.1:
http://bolingconsulting.com/blog/?p=4
===Known Folders===
The following program outputs the known folders:
<syntaxhighlight lang="text">
#include <windows.h>
main()
{
  wchar_t b[64];
  int    i;
  char    *s[64];
  for (i=0; i<65536; i++) {
    if (SHGetSpecialFolderPath(0, b, i, 0)) {
      wcstombs(s, b, 64);
      if (s[0] != '\0')
        printf("%d - [%s]\n", i, s);
    }
  }
}
</syntaxhighlight>
Output:
<pre>
0 - [\My Documents]
2 - [\Windows\Startmen�\Programme]
5 - [\My Documents]
6 - [\Windows\Favoriten]
7 - [\Windows\AutoStart]
11 - [\Windows\Startmen�]
13 - [\My Documents\Musik]
14 - [\My Documents\Videos]
20 - [\Windows\Schriftarten]
21 - [\My Documents\Vorlagen]
22 - [\Windows\Favoriten]
26 - [\Application Data]
36 - [\Windows]
38 - [\Programme]
39 - [\My Documents\Eigene Bilder]
</pre>
=== Further differences ===
CreateProcess must get both first arguments, name and cmdline.  In contrast to Windows NT (and Unix), cmdline must not repeat the name of the executable as argv[0].  Instead, argv[0] is filled in from the module name, and cmdline fills the arguments starting from argv[1].
The only handles that can be duplicated to other processes are Mutexes, Semaphores and Events. These can also simply be opened by their name from different processes for a similar effect.  No way to pass File or other handles from one process to another!  Must use socketpair (named object by port) or custom device driver (named object by device).
ExitProcess is missing.  ExitThread from main thread terminates the whole process!
== Device Setup for Windows Mobile for Development ==
Getting started with development for Windows Mobile you may want to install some additional Software, enabling you to get more control over your System then the standard UI of Windows Mobile provides.
==== Task Manager ====
''' This should be your first step '''
Without this tool (or something similar) it is impossible to even kill processes or start programs with command line Arguments. It should be the first thing you install because you need it (or something similar) to install and work with the other Tools.
You can download a CAB-Installer at http://www.dotfred.net/TaskMgr.htm
It is a good working task manager for Windows CE/Mobile it includes: A Process manager, CPU usage, Application Manager, Service Manager, Device Manager, Windows Manager, Notification Manager, IP Config utility, Ping utility, Net Stats utility, Registry Editor, Run program utility.
It allows you to get a detailed look into your System (which process uses which Dlls, what services are started and so on)
Most importantly though, you can use it to kill processes instead of just reseting the device.
==== SSH Server ====
There is a existing Port for OpenSSH available at
http://www.codeplex.com/wikipage?projectname=CESSH
The Project self appears to be dead and was originally intended to use as an
extension for the Microsoft Platform builder, which makes installation on
Windows Mobile a bit difficult since there are some hard coded paths included.
There is a CAB-Installer for the CeSSH OpenSSH port available,
download it
[http://files.intevation.de/incoming/aheinecke/cab_files/OpenSSH.cab here].
* Download the CAB-File and install it
For pubkey authentification:
* copy your RSA public ID to /authorized_keys
For password authentification:
* Taskmgr->Menu->Action->Run the adduser program and specify "username password" in the extra arguments input field
* Run either /Programme/OpenSSH/sshd.exe or the Shortcut from your Start Menu/System
Or if you want to install the SSH-Server manually:
* Download the [http://cessh.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=1354#DownloadId=4858 Binaries]
* Extract/Copy them onto the device
* Create a folder /Hard Disk on the device
* Generate the Host Keys
* Edit the sample sshd_config for your purposes
* Copy SocketToFile.dll, stftp.exe, scp.exe to the system base dir
* Taskmgr->Menu->Action->Run the adduser program and specify "username password" in the extra arguments input field
* Run sshd.exe
Now you should be able to connect to your device, using the Task Manager you
can look if OpenSSH is running and terminate it. It also allows you to find out
the IP-Address of your device.
You can now use SSH to execute commands on your device or to copy files to it.
    ssh DEVICE /path/to/cmd.exe
    scp FILE DEVICE:/Speicherkarte
''Notes:''
* The first time you execute something do these, you may need to confirm
  (on the device's screen) that running the unsigned programs from unknown
  publisher is allowed.  So watch your device screen in case of problems!
* If you do not have a console activated you will not see any output or startup
  notifications of sshd.
* If you remotely executed a program it's output may be truncated or even
  completely "swallowed" by sshd if the program terminates before the output is
  sent.
* You can edit the path's to the authorized_keys file in /Hard Disk/sshd_config
  and move them to a different location then / but that will prevent them from
  being uninstalled properly.
The original documentation for the SSH-Port can be found at:
http://cessh.codeplex.com
==== Console ====
For the Pocket PC 2003 platform Microsoft offers a console application, it is
barely usable on Windows Mobile 6.5 but it works good enough to view output or
Debug information. The command line interpreter included in this is not able
to get text input if T9 is disabled, so the best option to call commands appear
to be SSH and the before-mentioned Task Manager.
To install the console:
    Download and install (in Windows!) the
[http://www.microsoft.com/downloads/details.aspx?familyid=74473FD6-1DCC-47AA-AB28-6A2B006EDFE9&displaylang=en Microsoft Windows Mobile Developer Power Toys]
    Copy cmd.exe, console.dll, shell.exe in \windows on device
    Set HKEY_LOCAL_MACHINE/Drivers/Console/OutputTo to 0
'''Note:''' To let the registry changes take effect you must restart the device
You can modify the registry using the before-mentioned Task Manager.
'''Warning''': Setting Console OutputTo 0 will spawn Console Windows every time
a program writes to stdout or stderr and my heavily impact your performance.
Especially HTC TouchFlow is known to slow down your device heavily when a
console is activated.
There was also another console application for Windows CE but it is
also only for PocketPC 2003 and the company that developed it has vanished
from the internet. It has many problems, you can not use it over SSH for example.
But is just mentioned here because you can use it to enter commands directly
on the device, something that the Microsoft console lacks.
For Download and installation instructions, see:
http://www.walkingrandomly.com/?p=22
==== Security Configuration Manager ====
To control the security configuration for your device there is a tool from
Microsoft: [http://www.microsoft.com/downloads/details.aspx?FamilyID=7e92628c-d587-47e0-908b-09fee6ea517a&DisplayLang=en
Device Security Manager PowerToy for Windows Mobile 5.0]
It allows you to view and change installed certificates and the general
security configuration on your device, so you can disable them for development.
You have to install it on a Windows machine with Active-Sync connection, though.
==== Registry Editor ====
http://ceregeditor.mdsoft.pl/ is a good choice when you want to  worked for me, although it is not Open Source it is small, clean, free of charge and does the job. It connects with the device and allows you to edit and search the Registry remotely from a Windows Machine.
A small, on device, registry editor is also included in the Task Manager.
== Building Qt for Windows CE with MSVC  ==
==== Setting up Visual Studio<br>  ====
First thing you need is Visual Studio professional or standard edition (preferably with service pack 1). Be aware that the express editions are explicitly not supported for Windows CE development.<br> (You could use [http://www.microsoft.com/downloads/details.aspx?FamilyId=1DACDB3D-50D1-41B2-A107-FA75AE960856&displaylang=en%20 Microsoft Embedded VC] which is cost-free, but deprecated and not supported by Qt) <br>Next thing you need is a Microsoft Windows Mobile Platform SDK corresponding to your target platform. Just search the Microsoft download pages or get the Windows Mobile 6 SDK from [http://www.microsoft.com/downloads/details.aspx?FamilyID=06111A3A-A651-4745-88EF-3D48091A390B&displaylang=en here] (You should take a loot at the System Requirements)<br>If everything is set up correctly you should now be able to create a “Visual C++ smart device" project in Visual Studio.<br>
Note on Version-Naming: Standard means without touchscreen, Professional means with Touchscreen and Classic means Windows Mobile without mobile phone capabilities<br>
More about Visual Studio and Windows Mobile development: http://msdn.microsoft.com/en-us/library/dd721907.aspx
<br>
<br>


==== Building Qt<br> ====
==== Building Qt ====


Download the Qt libraries for Windows CE from http://qt.nokia.com/downloads/win-ce-cpp and extract it, you may want to make sure that your path contains no blanks to avoid some problems.<br>Now you should add your <qt-directory>\bin to your Windows PATH environment variable (which can be done from “''Control Panel → System → Advanced →Environment variables''” )
Download the Qt libraries for Windows CE from http://qt.nokia.com/downloads/win-ce-cpp and extract it, you may want to make sure that your path contains no blanks to avoid some problems.


Next get up your Visual Studio Command Prompt which should be accessible from the Windows Start Menu. Change the working directory to qt-directory and start the configuration. There should be a configuration.exe in your qt-directory with the usual options, (configure.exe -help for more info) for cross compiling you need to give at least the -platform parameter with your host system and -xplatform with your cross-compile target. Supported platforms are listed in the README file. e.g.:
Now you should add your <tt>&lt;qt-directory&gt;\bin</tt> to your Windows <tt>PATH</tt> environment variable (which can be done from “''Control Panel → System → Advanced →Environment variables''”, user and system <tt>PATH</tt>s are merged by Windows).


configure.exe -platform win32-msvc2008 -xplatform wincewm60standard-msvc2008
Next get up your Visual Studio Command Prompt which should be accessible from the Windows Start Menu. Change the working directory to qt-directory and start the configuration. There should be a <tt>configure.exe</tt> in your qt-directory with the usual options, (<tt>configure.exe -help</tt> for more info) for cross compiling you need to give at least the <tt>-platform</tt> parameter with your host system and <tt>-xplatform</tt> with your cross-compile target. Supported platforms are listed in the <tt>README</tt> file. e.g.:


Now that your configuration is set you can start the cross compilation. To switch from your “normal” build environment to the wince target Qt has a nice script included in the /bin directory (which should be in your PATH) just try calling setcepaths and provide your target configuration.<br>setcepaths wincewm60standard-msvc2008<br>With nmake (Visual Studio version of make) you can now build Qt for your target system.
  configure.exe -platform win32-msvc2008 -xplatform wincewm65professional-msvc2008  


Now that your configuration is set you can start the cross compilation. To switch from your “normal” build environment to the wince target Qt has a nice script included in the <tt>/bin</tt> directory (which should be in your <tt>PATH</tt>): just try calling <tt>setcepaths</tt> and provide your target configuration.
  setcepaths wincewm65professional-msvc2008
(if this complains that it cannot find <tt>checksdk.exe</tt>, you are building out-of-source (shadow builds in Qt lingo) and you need to add <tt>&lt;builddir&gt;\bin</tt> to <tt>PATH</tt>, too, then re-run the script).
With <tt>nmake</tt> (Visual Studio version of make) you can now build Qt for your target system.


== Building Qt for Windows CE with CeGCC  ==


== Building Qt for Windows CE with CeGCC ==
==== Getting CeGCC ====


==== Getting CeGCC ====
[http://cegcc.sourceforge.net/ CeGCC] (http://cegcc.sourceforge.net/) is a free cross-development environment for ARM-based systems running Windows CE. It is not officially supported by Qt and work with it is highly experimental, but given some work it could be possible to use it to build KDE-applications for Windows Mobile.


[http://cegcc.sourceforge.net/ CeGCC] (http://cegcc.sourceforge.net/) is a free cross-development environment for ARM-based systems running Windows CE. It is not officially supported by Qt and work with it is highly experimental, but given some work it could be possible to use it to build KDE-applications for Windows Mobile.
You should build cegcc from source, see: http://cegcc.sourceforge.net/docs/build-toolchain.html the current release 0.59 has some major bugs which were fixed since.  


You can get CeGCC here: http://sourceforge.net/projects/cegcc/files/cegcc/0.59.1/mingw32ce-0.59.1.tar.bz2/download <br>
<br>  
Or to build the latest Version yourself see:
http://cegcc.sourceforge.net/docs/build-toolchain.html


==== Building Qt  ====


==== Building Qt ====
Maurice Kalinowski at Nokia did some work on this and provided a working Qt-Version with make specs for mingw32ce that make it possible to build most of the Qt parts. The original mailing-list thread discussing this can be found here: http://lists.trolltech.com/pipermail/qt-wince-interest/2009-November/000764.html


Maurice Kalinowski at Nokia did some work on this and provided a working Qt-Version with make specs for mingw32ce that make it possible to build most of the Qt parts.
Link to the gitorious repository: http://gitorious.org/+qt-developers/qt/ce-gcc
The original mailing-list thread discussing this can be found here:
http://lists.trolltech.com/pipermail/qt-wince-interest/2009-November/000764.html


Link to the gitorious repository:
After downloading you should take a look at the cegcc_configure script, maybe change the installation prefix there and then execute it. If your configuration fails make sure that your environment is not yet set for cross-compiling.
http://gitorious.org/+qt-developers/qt/ce-gcc


After downloading you should take a look at the cegcc_configure script, maybe change the installation prefix there and then execute it.
When configuration is complete you can build the host-tools, just go into your checkout and execute: <br> {
If your configuration fails make sure that your environment is not yet set for
cross-compiling.


When configuration is complete you can build the host-tools, just go into your checkout and execute: <br>
{
         QTCEDIR=$(pwd)
         QTCEDIR=$(pwd)
         folders="bootstrap moc uic rcc"
         folders="bootstrap moc uic rcc"
         for f in $folders; do
         for f in $folders; do
             cd $QTCEDIR/src/tools/$f && $QTCEDIR/bin/qmake -spec $QTCEDIR/mkspecs/linux-g++ && make && cd $QTCEDIR || return
             cd $QTCEDIR/src/tools/$f &amp;&amp; $QTCEDIR/bin/qmake -spec $QTCEDIR/mkspecs/linux-g++ &amp;&amp; make &amp;&amp; cd $QTCEDIR || return
         done
         done
}


If the tools were built you now need to set up your environment for cross-compiling.
}
 
If the tools were built you now need to set up your environment for cross-compiling.  
 
         export MINGWPATH=/opt/mingw32ce
         export MINGWPATH=/opt/mingw32ce
         export INCLUDE=$MINGWPATH/arm-mingw32ce/include:$MINGWPATH/include:$INCLUDE
         export INCLUDE=$MINGWPATH/arm-mingw32ce/include:$MINGWPATH/include:$INCLUDE
         export LIB=$MINGWPATH/arm-mingw32ce/lib:$MINGWPATH/lib:$LIB
         export LIB=$MINGWPATH/arm-mingw32ce/lib:$MINGWPATH/lib:$LIB
         export PATH=$MINGWPATH/bin:$MINGWPATH/arm-mingw32ce/bin:$MINGWPATH/libexec/gcc/arm-mingw32ce/4.4.0:$PATH
         export PATH=$MINGWPATH/bin:$MINGWPATH/arm-mingw32ce/bin:$MINGWPATH/libexec/gcc/arm-mingw32ce/4.4.0:$PATH
Of course you have to change MINGWPATH according to your installation.


Now all that is left to do is to build Qt for the target system, to do that (again from your checkout directory) execute:<br>
Of course you have to change MINGWPATH according to your installation.
{
 
Now all that is left to do is to build Qt for the target system, to do that (again from your checkout directory) execute:<br> {
 
         QTCEDIR=$(pwd)
         QTCEDIR=$(pwd)
         folders="winmain corelib gui"
         folders="winmain corelib gui"
         for f in $folders; do
         for f in $folders; do
             cd $QTCEDIR/src/$f && $QTCEDIR/bin/qmake && make && make install && cd $QTCEDIR || return
             cd $QTCEDIR/src/$f &amp;&amp; $QTCEDIR/bin/qmake &amp;&amp; make &amp;&amp; make install &amp;&amp; cd $QTCEDIR || return
         done
         done
}


} This will build the qtcore and qtgui, you can try building more parts, of course.


'''Notes:'''  
<br> '''Notes:'''  


- in case of pch errors delete .pch/release-static-emb-windowsce/qt_gui_pch.h.gch directory  
- in case of pch errors delete .pch/release-static-emb-windowsce/qt_gui_pch.h.gch directory  


- when you are compiling your application outside of the Qt tree, you might get into trouble related to mkspecs and include dirs.
- when you are compiling your application outside of the Qt tree, you might get into trouble related to mkspecs and include dirs.  


- for deployment you need to copy these files also to the same directory on the device:  
- for deployment you need to copy these files also to the same directory on the device:  
Line 86: Line 283:
     libstdc++-6.dll
     libstdc++-6.dll
   which are located inside the arm-mingw32ce directory
   which are located inside the arm-mingw32ce directory
- Currently Windows Mobile > 6.0 does not load the libgcc_s_sjlj-1.dll libstdc++-6.dll properly, but a fix is in the works, see:
http://www.mail-archive.com/[email protected]/msg02699.html


<br>  
<br>  
Line 96: Line 288:
== Packaging:  ==
== Packaging:  ==


=== Deploying Qt Windows Mobile Applications using LCAB ===
=== Deploying Qt Windows Mobile Applications using LCAB ===


LCAB is a free software utility, that has the ability to create Microsoft CAB archives. You can get it on ( http://packages.debian.org/lenny/lcab )or as a Debian package.  
LCAB is a free software utility, that has the ability to create Microsoft CAB archives. You can get it on ( http://packages.debian.org/lenny/lcab )or as a Debian package.  


Now that you can create cabinet files, the question is how to get Windows Mobile to recognize them as install packages. Thanks to Shaun Jackman this, also is no Problem. He wrote a Perl script to add the needed manifest and setup configuration file. You can find it under ( http://files.intevation.de/incoming/aheinecke/cab_files/pocketpc-cab.pl ) There is also a pocketpc-cab Debian packet out there, which does not support registry entries or the creation of shortcuts.
With the creation of cabinet archives as a prerequisite, the question is how to get Windows Mobile to recognize them as install packages. Its basically a way in which the files have to be ordered and named inside the archive combined with a setup.xml file with installation instructions. There is a Perl script to add the needed manifest and setup configuration file. You can find it under ( http://files.intevation.de/incoming/aheinecke/cab_files/pocketpc-cab.pl )  


This script needs a configuration file, like Cabwiz but it is much more simple then the Cabwiz variant. Simply write down for every file you want to package:  
This script needs a configuration file (two if you want to install registry keys, also), but it is much more simple and straightforward then the Cabwiz variant. Simply write down for every file you want to package a line a file:  


Filename Target-Directory [Shortcut Name] [Shortcut Folder] for example the Qt widget collidingmice: collidingmice.exe&nbsp;%CE1%/Colliding_Mice "Colliding Mice"&nbsp;%CE11% msvcr90.dll&nbsp;%CE2% QtCore4.dll&nbsp;%CE2% QtGui4.dll&nbsp;%CE2%  
    Filename Target-Directory [Shortcut Name] [Shortcut Folder]  
for example:  
    collidingmice.exe %CE1%/Colliding_Mice "Colliding Mice" %CE11%  
    msvcr90.dll %CE2%  
    QtCore4.dll %CE2%  
    QtGui4.dll %CE2%  


This installs collidingmice.exe to Program Files/Colliding_Mice , places a shortcut in the Start Menu folder and copies the libraries into the Windows directory.  
This installs collidingmice.exe to Program Files/Colliding_Mice , places a shortcut in the Start Menu folder and copies the libraries into the Windows directory.  


==== CE Variables ====
==== CE Variables ====


Here are some predefined Windows CE variables which can be used to identify a path on a Windows CE device.
Here are some predefined Windows CE variables which can be used to identify a path on a Windows CE device.  


      %CE1% \Program Files
      &nbsp;%CE1% \Program Files
      %CE2% \Windows
      &nbsp;%CE2% \Windows
      %CE4% \Windows\StartUp
      &nbsp;%CE4% \Windows\StartUp
      %CE5% \My Documents
      &nbsp;%CE5% \My Documents
      %CE6% \Program Files\Accessories
      &nbsp;%CE6% \Program Files\Accessories
      %CE7% \Program Files\Communication
      &nbsp;%CE7% \Program Files\Communication
      %CE8% \Program Files\Games
      &nbsp;%CE8% \Program Files\Games
      %CE11% \Windows\Start Menu\Programs
      &nbsp;%CE11% \Windows\Start Menu\Programs
      %CE12% \Windows\Start Menu\Programs\Accessories
      &nbsp;%CE12% \Windows\Start Menu\Programs\Accessories
      %CE13% \Windows\Start Menu\Programs\Communications
      &nbsp;%CE13% \Windows\Start Menu\Programs\Communications
      %CE14% \Windows\Start Menu\Programs\Games
      &nbsp;%CE14% \Windows\Start Menu\Programs\Games
      %CE15% \Windows\Fonts
      &nbsp;%CE15% \Windows\Fonts
      %CE17% \Windows\Start Menu
      &nbsp;%CE17% \Windows\Start Menu


=== Deploying Qt Windows Mobile Applications using Cabwiz ===
=== Deploying Windows Mobile Applications using Cabwiz ===


Maybe in some situations Cabwiz has its relevance, (e.g. you only want to build from windows) but even then i would suggest to directly edit the setup.xml that is included in the Cabinet file. This should be easier then working with Cabwiz to generate the setup.xml
Maybe in some situations Cabwiz has its relevance, (e.g. you only want to build from windows) but even then i would suggest to directly edit the setup.xml that is included in the Cabinet file to suit your needs.
Before i found lcab i wrote a guide on [http://files.intevation.de/incoming/aheinecke/cab_files/creating_cab_files.odt how to Package a simple Qt-Application with cabwiz]


Microsoft [http://msdn.microsoft.com/en-us/library/aa448616.aspx Cabwiz] is part of Microsofts Windows Mobile SDKs
== Building KDE-Apps for Windows CE using MSVC  ==
'''Note:'''
''It has not yet been done, these are just some ideas.''


I will try to demonstrate the usage of Cabwiz and the inf file format by creating a small configuration example to install the Qt example [http://doc.trolltech.com/4.5/widgets-tetrix.html Tetrix], which comes as part of the Qt package, on a Windows Mobile Device.
Entry points for CE CRT:
      '''Your entrypoint      CRT entrypoint'''
        main                  mainACRTStartup
        wmain                mainWCRTStartup
        WinMain              WinMainCRTStartup
        wWinMain              wWinMainCRTStartup
        DllMain              _DllMainCRTStartup


If you built Qt using msvc you need to deploy 4 files to the Windows CE device:
=== Problems with MSVC ===
        Tetrix.exe      ; the program <yourqtdir>\examples\widgets\tetrix\release     
        QtCore4.dll  ; shared Qt library <yourqtdir>\lib
        QtGui4.dll    ; shared Qt library <yourqtdir>\lib
        msvcr90.dll  ; choose the MS Visual C runtime according to your developing environment


The goal is to get the installer to install the program to \Program Files\Tetrix and copy the shared libraries into the Windows folder, so other applications can find them as well, with also inserting a link in Start Menu\Games to our Tetrix.exe.
If you try to port native code from Linux to Windows CE or even from Windows to Windows CE you will soon run into walls because Microsoft does not provide you with a C-Library that is in following any standards. This is ugly when some parts are missing like errno, fcntl, types, stat, ... but gets even more ugly when there are the headers, but not the library functions.


To use Cabwiz for that, you need to provide it with an [information file Information file documentation: http://msdn.microsoft.com/en-us/library/aa924371.aspx] which details the configuration of the deployment package and which files there are to Include.
=== Compatibility Libraries  ===


An inf file consist of different Sections you have to provide, the first one of those is CEStrings which defines the Application Name and the InstallDir where the files are to be placed.
The idea is not to port the software to Windows CE/Mobile, but to instead to expand the Windows CE SDK in a way that it supports most of the functions Windows does. Although Windows Mobile SDK's still are a subset af the Windows libraries they came a long way in the last years, and most of the functions that are missing seem to be on a basic level. Maybe it is more of an annoyance then an actual problem.  
      [CEStrings]
      AppName="Tetrix"
      InstallDir=%CE1%\%AppName%
With the % tags we tell the interpreter that AppName and CE1 are variables. CE1 is defined by Windows Mobile and stands for the Program Files directory.  


Next the Version section:
=== CELIB ===
      [Version]
      Signature="$Windows NT$"
      CESignature="$Windows CE$"
      Provider=”Cabwiz”
Provider is meant for the creator of the application and is used to help identify the program if you leave it at Cabwiz WinCE will refer to your program as “Cabwiz Tetrix”.


To create a shortcut that is later inserted into the start menu:
With all the Problems there are with Windows CE C-Libraries it was actually much worse in older Windows CE versions. Rainer Keuchel did a lot of porting back in 2003 ( http://www.rainer-keuchel.de/software.html ) and wrote [http://www.rainer-keuchel.de/wince/celib.html celib] which provides many of the functions Windows CE is lacking. Sadly, this project died and has not been maintained to fit current Windows Versions. But maybe it can help with some ideas for workarounds or to cannibalize some parts.
      [Shortcuts]
      %AppName%,0,”tetrix.exe”
AppName is the name for our shortcut, 0 means its a file (1 would mean its a folder), and “tetrix.exe” is the executable. The path used for the shortcut is taken from InstallDir by default


Now to the files. First you have to tell Cabwiz where it can find the files you want to include in the cab file. So for each directory you have to create a name in the SourceDiskNames Section. To keep it simple all the files in this example are in c:\tetrix
=== wcelibcex ===
      [SourceDisksNames]
      1=,"arm files",,c:\tetrix


To declare the SourceFiles, the files to include in the cabinet file:
Wcelibcex supplements the Windows CE C-library with functions and workarounds for porting applications from Unix and Windows to Windows CE. Originally, the WCELIBCEX development was founded by Taxus SI Ltd. and in 2005 released as an Open Source Software project. The WCELIBCEX project is currently maintained by Mateusz Łoskot. ( http://wcelibcex.sourceforge.net/ )
      [SourceDisksFiles]
      tetrix.exe=1
      QtCore4.dll=1
      QtGui4.dll=1
      msvcr90.dll=1
Those files all are in c:\tetrix defined in section SourceDiskNames as 1.


Since the goal is to put the shared libraries in the Windows directory and the Tetrix.exe under Program files Cabwiz has to be made aware that they are different. For this reason you can create “copyfile sections” that you can name yourself. For example the two sections:
At a first glance this project is still active, at least the SVN Version is updated now and then. I've had some success using it but it also is not as complete as one would hope. There are some interesting ideas implemented, like managing the environment through the Windows registry. There would is still a lot to include if we wanted to build without modifying the public libraries but it would give a good starting point.
      [ProgramFiles]
      tetrix.exe
=====Installing wcelibcex=====
As mentioned the release Version is outdated, so get you should get wcelibcex from svn
        c:\>svn co https:/ / wcelibcex.svn.sourceforge.net/svnroot/wcelibcex/trunk wcelibcex
Open it in Visual Studio, select your target configuration and build. Make sure to include wcelibcex in your include and lib paths when you want to use it.  


      [SharedLibs]
      QtCore4.dll,,,0xA0000000
      QtGui4.dll,,,0xA0000000
      msvcr90.dll,,,0xA0000000
Only the file name is mandatory here, the arguments are optional. With the flag 0xA0000000 you tell the installer that those files are shared, and should only be replaced if they are newer then files that may be already on the device. For more on that see: http://msdn.microsoft.com/en-us/library/aa924416.aspx
Two sections are left which are needed to create a .cab file, DefaultInstall and DestinationDirs:
      [DefaultInstall]
      CeShortcuts=Shortcuts
      CopyFiles=ProgramFiles,SharedLibs
DefaultInstall just declares how the shortcuts and file lists are named.
Finally, to declare where everything should be copied to:
      [DestinationDirs]
      Shortcuts=,%CE14%
      ProgramFiles=,%InstallDir%
      SharedLibs=,%CE2% 
Notice again the CE variables, for more information see the Mobile SDK help files.
Thats it, now all you have to do is to start Cabwiz from the command line and provide the .inf file.
for a more detailed reference see: http://www.osronline.com/ddkx/install/create-inf_4l47.htm
or just use lcab.
''Tetrix.inf:''
      [CEStrings]
      AppName="Tetrix"
      InstallDir=%CE1%\%AppName%
      [Version]
      Signature="$Windows NT$"
      CESignature="$Windows CE$"
      Provider=”Company”
      [Shortcuts]
      %AppName%,0,”tetrix.exe”
      [SourceDisksNames]
      1=,"arm files",,c:\tetrix
      [SourceDisksFiles]
      tetrix.exe=1
      QtCore4.dll=1
      QtGui4.dll=1
      msvcr90.dll=1
      [ProgramFiles]
      tetrix.exe
      [SharedLibs]
      QtCore4.dll,,,0xA0000000
      QtGui4.dll,,,0xA0000000
      msvcr90.dll,,,0xA0000000
      [DefaultInstall]
      CeShortcuts=Shortcuts
      CopyFiles=ProgramFiles,SharedLibs
      [DestinationDirs]
      Shortcuts=,%CE14%
      ProgramFiles=,%InstallDir%
      SharedLibs=,%CE2%
== Building KDE for Windows CE using MSVC ==
=== Problems with MSVC ===
Who needs standard C when he can have "Visual" C seems to be the reasoning.
If you try to port native code from Linux to Windows CE or even from Windows to Windows CE you will soon run into walls because Microsoft does not provide you with a C-Library that is in any way complete or following standards.
This is ugly when some parts are missing like errno, fcntl, types, stat, ...
but gets even more ugly when there are the headers, but not the library functions like Microsoft's complete string.h is the line: 
      #include <stdlib.h>
nothing more.
Maybe the best way to go here would be to delete those "dummy files" or reroute them to a compatibility library?


<br>


=== Compatibility Libraries ===
=== Dependencies  ===
===CELIB===
With all the Problems there are with Windows CE C-Libraries it was actually much worse in older Windows CE versions. Rainer Keuchel did a lot of porting back in 2003 ( http://www.rainer-keuchel.de/software.html ) and wrote [http://www.rainer-keuchel.de/wince/celib.html celib] which provides many of the functions Windows CE is lacking. Sadly, this project died and has not been maintained to fit current Windows Versions. But maybe it can help with some ideas for workarounds or to cannibalize some parts.


===wcelibcex===
Following the [[../Build/Building DBus]] guide we need at least the following libraries.  
Wcelibcex supplements the Windows CE C-library with functions and workarounds for porting applications from Unix and Windows to Windows CE.
Originally, the WCELIBCEX development was founded by Taxus SI Ltd. and in 2005 released as an Open Source Software project.
The WCELIBCEX project is currently maintained by Mateusz Łoskot.
( http://wcelibcex.sourceforge.net/ )


At a first glance this project is still active, at least the SVN Version is updated now and then. I've had some success using it but it also is not as complete as one would hope. There are some interesting ideas implemented, like managing the environment through the Windows registry. There would is still a lot to include if we wanted to build without modifying the public libraries but it would give a good starting point.
=== Dependencies ===
Following the [[Getting_Started/Build/KDE4/Windows/Building_DBus]] guide we need at least the following libraries.
 
     * aspell   
     * aspell   
     * boost-headers
     * boost-headers
Line 281: Line 383:
     * kdewin32
     * kdewin32
     * libintl
     * libintl
     * libpng
     * libpng ( [http://www.tenik.co.jp/~adachi/wince/lpngce/index.html ported V 1.2.3] )
     * libxml2
     * libxml2
     * libxslt
     * libxslt
     * openldap
     * openldap
     * openslp
     * openslp
     * openssl
     * openssl ( [http://www.it.uc3m.es/pervasive/wce_lite_compat/ ported 0.9.8a] )
     * pcre
     * pcre
     * qca2
     * qca2
Line 296: Line 398:
     * update-mime-database
     * update-mime-database
     * windbus
     * windbus
     * zlib  
     * zlib ( [http://www.tenik.co.jp/~adachi/wince/zlibce/index.html ported V 1.1.4] )
 
===Building Library Dependencies===
This part now really becomes 'read at own risk' at this point I have no idea if this is the best way to build or the easiest way to build or even a slightly sane one. My goal was to come up with a way to compile free software that has been ported for Windows to Windows CE without changing the code but rather by finding workarounds for all the portability issues. I used the before-mentioned wcelibcex to try to get some libraries to run on my Windows Mobile device.
For building i used nmake makefiles and no Visual Studio Project files to have more control over the build.
 
 
====Setting up the Environment====
To Cross-Compile with the MSVC compiler you should write yourself a script to set up your environment, if you don't want to set your system wide variables you'd have to enter really long commands every time you open a new console by hand.
It could be looking like this (in a standard installation):
      @echo off
      call setcepaths wincewm60standard-msvc2008
      set INCLUDE=%INCLUDE%;C:\wcelibcex\src
      set LIB=%LIB%;C:\wcelibcex\msvc90\Windows Mobile 6 Standard SDK (ARMV4I)\Release
      set _CL_=/DWIN32 /D_WIN32 /D_WIN32_ /D_WINDOWS /D_WIN32_WCE#0x502 /DUNDER_CE#0x502 /DWINCE <br>/DARMV4I /D_ARMV4I_ /D_ARM_ /D_M_ARM /DARM /D__arm__ /D_UNICODE /DUNICODE
      set _LINK_=corelibc.lib coredll.lib wcelibcex.lib
      set LINK=/entry:"_DllMainCRTStartup" /nodefaultlib:oldnames.lib subsystem:WINDOWSCE
 
Qt offers a script for most of the INCLUDE, LIB, and PATH variables, called setcepaths, in this example i used it to get the cross-compile paths initialized. Please note the 0x502 Version Numbers are intentional when developing for Windows Mobile 6 we are compiling for Windwos CE 5.2 See: [http://techbase.kde.org/Windows_CE#Windows_CE_.2F_Windows_Mobile Windows CE/Windows Mobile]<br>
The # character replaces = for the Windows Environment variables.
As you can see I also included wcelibcex since I want to demonstrate how to use the wceex-functions and need it for errno.h.
 
CL,_CL_,LINK,_LINK_ are MSVC variables to control cl.exe and link.exe CL is prepend to all options when cl.exe is called,_CL_ is appended, same goes for link.exe and its variables.
Note: When using defines cl.exe always uses the last definition it got. So with _CL_ you could override defines from any cl call (e.g. a makefile).
 
 
==== Building libiconv ====
The last version I have found with msvc Makefiles for iconv was 1.11.1 for a first try to get it working I used that version to have it easier.<br>
get it at: http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.1.tar.gz
extract and then run:
            set CL=/Dabort#wceex_abort /Dperror(...)#printf(...) /Dstrdup#_strdup /Dstrerror#wceex_strerror
edit the config.h.msvc (or just put #undefs at the end of the file):
            #define HAVE_ENVIRON_DECL 1 to #undef HAVE_ENVIRON_DECL
            #define HAVE_SETLOCALE 1 to #undef HAVE_SETLOCALE
now run
            nmake -f Makefile.msvc NO_NLS=1 DLL=1 MFLAGS=-MD
            nmake -f Makefile.msvc NO_NLS=1 DLL=1 MFLAGS=-MD install
Explanation:
The CL defines reroute some function calls. We don't have decent error handling on Windows CE so in my opinion we could just print out error messages or numbers to a console we also don't have (but maybe later find a way to reroute to a file or so) anyways. wceex_abort just terminates the process _strdup is the WinCE equivalent of strdup, MS already provided it. I did not use more configuration Options in config.h because in most cases the workarounds they provide don't help either for Windows CE.
NO_NLS=1 stands for building without libintl, since libintl needs iconv to build.
 
 
====Building gettext-runtime====
With gettext I again used a release with msvc makefiles, version 0.14.5 http://ftp.gnu.org/pub/gnu/gettext/gettext-0.14.5.tar.gz  <br>
 
If you have installed libiconv in the default location you can also use defaults with gettext, otherwise make sure to provide the same prefix you used with libiconv.
To avoid confusing errors, you may want to edit the makefile to only build the gettext-runtime. 
Now in the gettext-runtime directory append to the config.h.msvc again:
      #undef HAVE_ENVIRON_DECL
      #undef HAVE_SETLOCALE
and change CL to:
      CL=/Dabort#wceex_abort /Dperror(...)#printf(...) /Dstrdup#_strdup /Dstrerror#wceex_strerror <br>/Dgetenv#wceex_getenv /Dclose#wceex_close /Dread#wceex_read <br>/Dfstat#wceex_fstat /Dopen#wceex_open /Dbsearch#wceex_bsearch /Draise#wceex_raise /Dgetcwd#wceex_getcwd <br>/DGetThreadLocale#GetUserDefaultLCID
 
''loadmsgcat needs close read write fstat open bsearch and raise. Since there were no implementations or workarounds for close read fstat and open in wcelibcex I wrote them myself using fopen fclose. For wceex_raise I took parts from Rainer Keuchel's celib. I'll try to do some decent testing and getting them upstream. But if you have an idea how not to use them please make an edit. '' 
 
Now you should be able to build:
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD install
If you get errors make sure that you do not try to build the tools, which are another problem.
 
====Building libiconv with libintl ====
Go back to your libiconv directory
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD clean
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD install
should run smoothly and link against libintl.
If not, make sure that you still have the preprocessor macros defined in CL.
 
==== libxml2 with iconv ====
Building libxml2 for WinCE is fairly easy for us, because the official release already was ported to Windows CE, my problem was that I could not convert the EVC project files to my VS installation so I used the Win32 makefile.
Checkout libxml2
      git clone git://git.gnome.org/libxml2
Although a port exists it was apparently done some time ago so you have to modify some things, the file include\wsockcompat.h includes winsock.h instead of winsock2.h for _WIN32_WCE. That is no longer needed we have winsock2 on Windows Mobile 6, so change that to winsock2.h<br>
Copy the two files wincecompat.h and wincecompat.c from win32\wince into your main src directory in those all the functions needed for compatibility are declared.
To avoid conflicts make sure your CL variable is not still set with all the function replacements.
Since the original port used EVC-Project files we have to edit the win32\Makefile.msvc to avoid linker errors.
      In line 69 replace wsock32.lib ws2_32.lib with ws2.lib
      In line 81 replace kernel32.lib with coredll.lib
      Add $(XML_INTDIR)\wincecompat.obj to the XML_OBJ list.
Now from the win32 subdirectory you should run:
      cscript configure.js help
and configure according to your setup. Make sure to set the inc/lib vars pointing to your iconv installation.
      nmake /f win32\Makefile libxml libxmla libxmladll
should build. Only some utils are still going to make problems.
 
 
== Miscellaneous ==
 
=== Accessing Pocket Outlook ===
Similar to the Outlook Object Model for the Desktop Outlook, Microsoft offers the Pocket Outlook Object Model ([http://msdn.microsoft.com/en-us/library/aa914277.aspx POOM]) The related library is called pimstore and part of the Windows Mobile SDK.
You can use it to access the pim.vol file which is located in the Windows Mobile root directory. It contains Contacts, Tasks, Calendar entries and the infrared folder. To access messages you have to use the [http://msdn.microsoft.com/en-us/library/bb446118.aspx Messaging API.]
 
Establishing a connection is straightforward COM, you have to initialize the COM library find out the COM identifier of PocketOutlook, then create an application class COM server object and logon to the COM server object using the [http://msdn.microsoft.com/en-us/library/aa913088.aspx IPOutlookApp COM interface]
 
For example:
    CLSID clsid;  // The COM Identifier
    CComQIPtr<IPOutlookApp,&__uuidof(IPOutlookApp)> ipOutlookAppPtr; // managed COM interface pointer
   
    CoInitializeEx(0,0); // Initialize the COM library
    CLSIDFromProgID(L"PocketOutlook.Application", &clsid); // Lookup the ID in the registry
    ipOutlookAppPtr.CoCreateInstance(clsid, NULL, CLSTX_INPROC_SERVER); // Create the server object
    ipOutlookAppPtr->Logon(NULL); // Logon
 
After you have established the connection you can use the IPOutlook interface methods to retrieve or manipulate the data.
I have written a small program that exports all the Contact data on a device into a CSV file. [http://files.intevation.de/incoming/aheinecke/POutlookExport.zip POutlookExport.zip]


I don't know which versions are minimal which could become a litte problem since newer versions of GNU libraries no longer support MSVC makefiles, it should not be a large problem to adopt the old ones though, maybe even with some kind of automation in mind.  
Further Reading:
[http://msdn.microsoft.com/en-us/library/bb446118.aspx MSDN Messaging Reference]
[http://msdn.microsoft.com/en-us/library/aa914277.aspx MSDN POOM Reference]


=====libXML2=====
=== Debugging with emerge ===
built, not tested yet
=====iconv=====
built, not tested yet
=====gettext=====
built, not tested yet

Latest revision as of 14:58, 18 March 2016

Introduction

This page is mostly deprecated it was started for a Project to port Kdepim to Windows CE. All additional patches / cross compile techniques can be found in emerge from the KDE - Windows initative. Binaries for Windows Mobile 6.5 and a source tarball of Kontact Touch (an optimized variant of KDEPIM software for Touch enabled devices) can be found at: http://files.kolab.org/local/windows-ce/Kontact-Mobile/testing/latest/

Windows CE / Windows Mobile

Although Windows CE (officially called Windows Embedded CE) is part of the Windows Embedded family there is a large difference between Windows Embedded CE and other Windows Embedded products. Most importantly Windows CE is not Windows. It has a different Kernel then any other Windows Operating System. And while other embedded products like Windows Embedded Standard or Windows Embedded Enterprise (which are sized down versions of Windows XP) will run Windows applications without problems, Windows CE applications require porting even from Windows.
Windows Mobile then is based on Windows CE (CE has no official meaning) and it's current Versions Windows Mobile 6.1 (and 6.5) are based on Windows CE 5.2 so we will be talking about developing for Windows CE 5.2 when we are talking about developing for Windows Mobile 6.1 or 6.5. It is confusing but Windows Mobile 6 is not based on Windows CE 6 so it still has the limitations of Windows CE 5. For example the process address space is still limited to 32 MiB and the maximum Number of processes can not exceed 32.


Process limit

Confirmed on HTC Touch Pro (Wimo6.5 CE 5.2.21854) running:

      for(i=0;i<32;i++){
         if(CreateProcess(L"test1.exe",(LPCWSTR)cptr,0,0,0,0,0,0,0,&procinf))
            fprintf(file,"Process Nr.%i ID: %u started\n",i,procinf.dwProcessId);
         else
            fprintf(file,"Creation failed after %i processes\n",i);
      }

I was able to create 16 processes at most after a fresh boot. (32 alltogether, including kernel thread)

Memory limit

The Memory limitations on Windows CE < 6 are a serious Problem. Additionally to the limitations that are normal for embedded development, you have to deal with limitations on the address room.

There is a very good Article about Windows CE < 6 Memory management and how to deal with the limitations at:

http://msdn.microsoft.com/en-us/library/ms836325.aspx

The same author wrote a blog entry about changes in Windows Mobile 6.1: http://bolingconsulting.com/blog/?p=4

Known Folders

The following program outputs the known folders:

#include <windows.h>
main()
{
  wchar_t b[64];
  int     i;
  char    *s[64];
  for (i=0; i<65536; i++) {
    if (SHGetSpecialFolderPath(0, b, i, 0)) {
      wcstombs(s, b, 64);
      if (s[0] != '\0')
        printf("%d - [%s]\n", i, s);
    }
  }
}

Output:

0 - [\My Documents]
2 - [\Windows\Startmen�\Programme]
5 - [\My Documents]
6 - [\Windows\Favoriten]
7 - [\Windows\AutoStart]
11 - [\Windows\Startmen�]
13 - [\My Documents\Musik]
14 - [\My Documents\Videos]
20 - [\Windows\Schriftarten]
21 - [\My Documents\Vorlagen]
22 - [\Windows\Favoriten]
26 - [\Application Data]
36 - [\Windows]
38 - [\Programme]
39 - [\My Documents\Eigene Bilder]

Further differences

CreateProcess must get both first arguments, name and cmdline. In contrast to Windows NT (and Unix), cmdline must not repeat the name of the executable as argv[0]. Instead, argv[0] is filled in from the module name, and cmdline fills the arguments starting from argv[1].

The only handles that can be duplicated to other processes are Mutexes, Semaphores and Events. These can also simply be opened by their name from different processes for a similar effect. No way to pass File or other handles from one process to another! Must use socketpair (named object by port) or custom device driver (named object by device).

ExitProcess is missing. ExitThread from main thread terminates the whole process!

Device Setup for Windows Mobile for Development

Getting started with development for Windows Mobile you may want to install some additional Software, enabling you to get more control over your System then the standard UI of Windows Mobile provides.

Task Manager

This should be your first step Without this tool (or something similar) it is impossible to even kill processes or start programs with command line Arguments. It should be the first thing you install because you need it (or something similar) to install and work with the other Tools.

You can download a CAB-Installer at http://www.dotfred.net/TaskMgr.htm

It is a good working task manager for Windows CE/Mobile it includes: A Process manager, CPU usage, Application Manager, Service Manager, Device Manager, Windows Manager, Notification Manager, IP Config utility, Ping utility, Net Stats utility, Registry Editor, Run program utility. It allows you to get a detailed look into your System (which process uses which Dlls, what services are started and so on) Most importantly though, you can use it to kill processes instead of just reseting the device.


SSH Server

There is a existing Port for OpenSSH available at http://www.codeplex.com/wikipage?projectname=CESSH The Project self appears to be dead and was originally intended to use as an extension for the Microsoft Platform builder, which makes installation on Windows Mobile a bit difficult since there are some hard coded paths included.

There is a CAB-Installer for the CeSSH OpenSSH port available, download it here.

  • Download the CAB-File and install it

For pubkey authentification:

  • copy your RSA public ID to /authorized_keys

For password authentification:

  • Taskmgr->Menu->Action->Run the adduser program and specify "username password" in the extra arguments input field
  • Run either /Programme/OpenSSH/sshd.exe or the Shortcut from your Start Menu/System

Or if you want to install the SSH-Server manually:

  • Download the Binaries
  • Extract/Copy them onto the device
  • Create a folder /Hard Disk on the device
  • Generate the Host Keys
  • Edit the sample sshd_config for your purposes
  • Copy SocketToFile.dll, stftp.exe, scp.exe to the system base dir
  • Taskmgr->Menu->Action->Run the adduser program and specify "username password" in the extra arguments input field
  • Run sshd.exe


Now you should be able to connect to your device, using the Task Manager you can look if OpenSSH is running and terminate it. It also allows you to find out the IP-Address of your device.

You can now use SSH to execute commands on your device or to copy files to it.

    ssh DEVICE /path/to/cmd.exe
    scp FILE DEVICE:/Speicherkarte

Notes:

  • The first time you execute something do these, you may need to confirm
 (on the device's screen) that running the unsigned programs from unknown
 publisher is allowed.  So watch your device screen in case of problems!
  • If you do not have a console activated you will not see any output or startup
 notifications of sshd.
  • If you remotely executed a program it's output may be truncated or even
 completely "swallowed" by sshd if the program terminates before the output is
 sent. 
  • You can edit the path's to the authorized_keys file in /Hard Disk/sshd_config
 and move them to a different location then / but that will prevent them from
 being uninstalled properly. 

The original documentation for the SSH-Port can be found at: http://cessh.codeplex.com


Console

For the Pocket PC 2003 platform Microsoft offers a console application, it is barely usable on Windows Mobile 6.5 but it works good enough to view output or Debug information. The command line interpreter included in this is not able to get text input if T9 is disabled, so the best option to call commands appear to be SSH and the before-mentioned Task Manager.

To install the console:

   Download and install (in Windows!) the

Microsoft Windows Mobile Developer Power Toys

   Copy cmd.exe, console.dll, shell.exe in \windows on device
   Set HKEY_LOCAL_MACHINE/Drivers/Console/OutputTo to 0 

Note: To let the registry changes take effect you must restart the device


You can modify the registry using the before-mentioned Task Manager.

Warning: Setting Console OutputTo 0 will spawn Console Windows every time a program writes to stdout or stderr and my heavily impact your performance. Especially HTC TouchFlow is known to slow down your device heavily when a console is activated.


There was also another console application for Windows CE but it is also only for PocketPC 2003 and the company that developed it has vanished from the internet. It has many problems, you can not use it over SSH for example. But is just mentioned here because you can use it to enter commands directly on the device, something that the Microsoft console lacks. For Download and installation instructions, see: http://www.walkingrandomly.com/?p=22


Security Configuration Manager

To control the security configuration for your device there is a tool from Microsoft: [http://www.microsoft.com/downloads/details.aspx?FamilyID=7e92628c-d587-47e0-908b-09fee6ea517a&DisplayLang=en Device Security Manager PowerToy for Windows Mobile 5.0]

It allows you to view and change installed certificates and the general security configuration on your device, so you can disable them for development. You have to install it on a Windows machine with Active-Sync connection, though.

Registry Editor

http://ceregeditor.mdsoft.pl/ is a good choice when you want to worked for me, although it is not Open Source it is small, clean, free of charge and does the job. It connects with the device and allows you to edit and search the Registry remotely from a Windows Machine.

A small, on device, registry editor is also included in the Task Manager.


Building Qt for Windows CE with MSVC

Setting up Visual Studio

First thing you need is Visual Studio professional or standard edition (preferably with service pack 1). Be aware that the express editions are explicitly not supported for Windows CE development.
(You could use Microsoft Embedded VC which is cost-free, but deprecated and not supported by Qt)
Next thing you need is a Microsoft Windows Mobile Platform SDK corresponding to your target platform. Just search the Microsoft download pages or get the Windows Mobile 6 SDK from here (You should take a loot at the System Requirements)
If everything is set up correctly you should now be able to create a “Visual C++ smart device" project in Visual Studio.
Note on Version-Naming: Standard means without touchscreen, Professional means with Touchscreen and Classic means Windows Mobile without mobile phone capabilities

More about Visual Studio and Windows Mobile development: http://msdn.microsoft.com/en-us/library/dd721907.aspx

Building Qt

Download the Qt libraries for Windows CE from http://qt.nokia.com/downloads/win-ce-cpp and extract it, you may want to make sure that your path contains no blanks to avoid some problems.

Now you should add your <qt-directory>\bin to your Windows PATH environment variable (which can be done from “Control Panel → System → Advanced →Environment variables”, user and system PATHs are merged by Windows).

Next get up your Visual Studio Command Prompt which should be accessible from the Windows Start Menu. Change the working directory to qt-directory and start the configuration. There should be a configure.exe in your qt-directory with the usual options, (configure.exe -help for more info) for cross compiling you need to give at least the -platform parameter with your host system and -xplatform with your cross-compile target. Supported platforms are listed in the README file. e.g.:

 configure.exe -platform win32-msvc2008 -xplatform wincewm65professional-msvc2008 

Now that your configuration is set you can start the cross compilation. To switch from your “normal” build environment to the wince target Qt has a nice script included in the /bin directory (which should be in your PATH): just try calling setcepaths and provide your target configuration.

 setcepaths wincewm65professional-msvc2008

(if this complains that it cannot find checksdk.exe, you are building out-of-source (shadow builds in Qt lingo) and you need to add <builddir>\bin to PATH, too, then re-run the script). With nmake (Visual Studio version of make) you can now build Qt for your target system.

Building Qt for Windows CE with CeGCC

Getting CeGCC

CeGCC (http://cegcc.sourceforge.net/) is a free cross-development environment for ARM-based systems running Windows CE. It is not officially supported by Qt and work with it is highly experimental, but given some work it could be possible to use it to build KDE-applications for Windows Mobile.

You should build cegcc from source, see: http://cegcc.sourceforge.net/docs/build-toolchain.html the current release 0.59 has some major bugs which were fixed since.


Building Qt

Maurice Kalinowski at Nokia did some work on this and provided a working Qt-Version with make specs for mingw32ce that make it possible to build most of the Qt parts. The original mailing-list thread discussing this can be found here: http://lists.trolltech.com/pipermail/qt-wince-interest/2009-November/000764.html

Link to the gitorious repository: http://gitorious.org/+qt-developers/qt/ce-gcc

After downloading you should take a look at the cegcc_configure script, maybe change the installation prefix there and then execute it. If your configuration fails make sure that your environment is not yet set for cross-compiling.

When configuration is complete you can build the host-tools, just go into your checkout and execute:
{

       QTCEDIR=$(pwd)
       folders="bootstrap moc uic rcc"
       for f in $folders; do
           cd $QTCEDIR/src/tools/$f && $QTCEDIR/bin/qmake -spec $QTCEDIR/mkspecs/linux-g++ && make && cd $QTCEDIR || return
       done

}

If the tools were built you now need to set up your environment for cross-compiling.

        export MINGWPATH=/opt/mingw32ce
        export INCLUDE=$MINGWPATH/arm-mingw32ce/include:$MINGWPATH/include:$INCLUDE
        export LIB=$MINGWPATH/arm-mingw32ce/lib:$MINGWPATH/lib:$LIB
        export PATH=$MINGWPATH/bin:$MINGWPATH/arm-mingw32ce/bin:$MINGWPATH/libexec/gcc/arm-mingw32ce/4.4.0:$PATH

Of course you have to change MINGWPATH according to your installation.

Now all that is left to do is to build Qt for the target system, to do that (again from your checkout directory) execute:
{

       QTCEDIR=$(pwd)
       folders="winmain corelib gui"
       for f in $folders; do
           cd $QTCEDIR/src/$f && $QTCEDIR/bin/qmake && make && make install && cd $QTCEDIR || return
       done

} This will build the qtcore and qtgui, you can try building more parts, of course.


Notes:

- in case of pch errors delete .pch/release-static-emb-windowsce/qt_gui_pch.h.gch directory

- when you are compiling your application outside of the Qt tree, you might get into trouble related to mkspecs and include dirs.

- for deployment you need to copy these files also to the same directory on the device:

   libgcc_s_sjlj-1.dll
   libstdc++-6.dll
 which are located inside the arm-mingw32ce directory


Packaging:

Deploying Qt Windows Mobile Applications using LCAB

LCAB is a free software utility, that has the ability to create Microsoft CAB archives. You can get it on ( http://packages.debian.org/lenny/lcab )or as a Debian package.

With the creation of cabinet archives as a prerequisite, the question is how to get Windows Mobile to recognize them as install packages. Its basically a way in which the files have to be ordered and named inside the archive combined with a setup.xml file with installation instructions. There is a Perl script to add the needed manifest and setup configuration file. You can find it under ( http://files.intevation.de/incoming/aheinecke/cab_files/pocketpc-cab.pl )

This script needs a configuration file (two if you want to install registry keys, also), but it is much more simple and straightforward then the Cabwiz variant. Simply write down for every file you want to package a line a file:

   Filename Target-Directory [Shortcut Name] [Shortcut Folder] 

for example:

   collidingmice.exe %CE1%/Colliding_Mice "Colliding Mice" %CE11% 
   msvcr90.dll %CE2% 
   QtCore4.dll %CE2% 
   QtGui4.dll %CE2% 

This installs collidingmice.exe to Program Files/Colliding_Mice , places a shortcut in the Start Menu folder and copies the libraries into the Windows directory.

CE Variables

Here are some predefined Windows CE variables which can be used to identify a path on a Windows CE device.

      %CE1%	\Program Files
      %CE2%	\Windows
      %CE4%	\Windows\StartUp
      %CE5%	\My Documents
      %CE6%	\Program Files\Accessories
      %CE7%	\Program Files\Communication
      %CE8%	\Program Files\Games
      %CE11%	\Windows\Start Menu\Programs
      %CE12%	\Windows\Start Menu\Programs\Accessories
      %CE13%	\Windows\Start Menu\Programs\Communications
      %CE14%	\Windows\Start Menu\Programs\Games
      %CE15%	\Windows\Fonts
      %CE17%	\Windows\Start Menu

Deploying Windows Mobile Applications using Cabwiz

Maybe in some situations Cabwiz has its relevance, (e.g. you only want to build from windows) but even then i would suggest to directly edit the setup.xml that is included in the Cabinet file to suit your needs. Before i found lcab i wrote a guide on how to Package a simple Qt-Application with cabwiz

Building KDE-Apps for Windows CE using MSVC

Note: It has not yet been done, these are just some ideas.

Entry points for CE CRT:

     Your entrypoint      CRT entrypoint
        main                  mainACRTStartup
        wmain                 mainWCRTStartup
        WinMain               WinMainCRTStartup
        wWinMain              wWinMainCRTStartup
        DllMain               _DllMainCRTStartup

Problems with MSVC

If you try to port native code from Linux to Windows CE or even from Windows to Windows CE you will soon run into walls because Microsoft does not provide you with a C-Library that is in following any standards. This is ugly when some parts are missing like errno, fcntl, types, stat, ... but gets even more ugly when there are the headers, but not the library functions.

Compatibility Libraries

The idea is not to port the software to Windows CE/Mobile, but to instead to expand the Windows CE SDK in a way that it supports most of the functions Windows does. Although Windows Mobile SDK's still are a subset af the Windows libraries they came a long way in the last years, and most of the functions that are missing seem to be on a basic level. Maybe it is more of an annoyance then an actual problem.

CELIB

With all the Problems there are with Windows CE C-Libraries it was actually much worse in older Windows CE versions. Rainer Keuchel did a lot of porting back in 2003 ( http://www.rainer-keuchel.de/software.html ) and wrote celib which provides many of the functions Windows CE is lacking. Sadly, this project died and has not been maintained to fit current Windows Versions. But maybe it can help with some ideas for workarounds or to cannibalize some parts.

wcelibcex

Wcelibcex supplements the Windows CE C-library with functions and workarounds for porting applications from Unix and Windows to Windows CE. Originally, the WCELIBCEX development was founded by Taxus SI Ltd. and in 2005 released as an Open Source Software project. The WCELIBCEX project is currently maintained by Mateusz Łoskot. ( http://wcelibcex.sourceforge.net/ )

At a first glance this project is still active, at least the SVN Version is updated now and then. I've had some success using it but it also is not as complete as one would hope. There are some interesting ideas implemented, like managing the environment through the Windows registry. There would is still a lot to include if we wanted to build without modifying the public libraries but it would give a good starting point.

Installing wcelibcex

As mentioned the release Version is outdated, so get you should get wcelibcex from svn

       c:\>svn co https:/ / wcelibcex.svn.sourceforge.net/svnroot/wcelibcex/trunk wcelibcex

Open it in Visual Studio, select your target configuration and build. Make sure to include wcelibcex in your include and lib paths when you want to use it.



Dependencies

Following the Windows/Build/Building DBus guide we need at least the following libraries.

   * aspell  
   * boost-headers
   * bzip2
   * cyrus-sasl
   * expat
   * giflib
   * gpgme
   * iconv
   * jasper
   * jpeg
   * kdewin32
   * libintl
   * libpng ( ported V 1.2.3 )
   * libxml2
   * libxslt
   * openldap
   * openslp
   * openssl ( ported 0.9.8a )
   * pcre
   * qca2
   * qimageblitz 
   * redland
   * strigi
   * soprano
   * tiff
   * update-mime-database
   * windbus
   * zlib ( ported V 1.1.4 )

Building Library Dependencies

This part now really becomes 'read at own risk' at this point I have no idea if this is the best way to build or the easiest way to build or even a slightly sane one. My goal was to come up with a way to compile free software that has been ported for Windows to Windows CE without changing the code but rather by finding workarounds for all the portability issues. I used the before-mentioned wcelibcex to try to get some libraries to run on my Windows Mobile device. For building i used nmake makefiles and no Visual Studio Project files to have more control over the build.


Setting up the Environment

To Cross-Compile with the MSVC compiler you should write yourself a script to set up your environment, if you don't want to set your system wide variables you'd have to enter really long commands every time you open a new console by hand. It could be looking like this (in a standard installation):

     @echo off
     call setcepaths wincewm60standard-msvc2008
     set INCLUDE=%INCLUDE%;C:\wcelibcex\src
     set LIB=%LIB%;C:\wcelibcex\msvc90\Windows Mobile 6 Standard SDK (ARMV4I)\Release
     set _CL_=/DWIN32 /D_WIN32 /D_WIN32_ /D_WINDOWS /D_WIN32_WCE#0x502 /DUNDER_CE#0x502 /DWINCE 
/DARMV4I /D_ARMV4I_ /D_ARM_ /D_M_ARM /DARM /D__arm__ /D_UNICODE /DUNICODE set _LINK_=corelibc.lib coredll.lib wcelibcex.lib set LINK=/entry:"_DllMainCRTStartup" /nodefaultlib:oldnames.lib subsystem:WINDOWSCE

Qt offers a script for most of the INCLUDE, LIB, and PATH variables, called setcepaths, in this example i used it to get the cross-compile paths initialized. Please note the 0x502 Version Numbers are intentional when developing for Windows Mobile 6 we are compiling for Windwos CE 5.2 See: Windows CE/Windows Mobile
The # character replaces = for the Windows Environment variables. As you can see I also included wcelibcex since I want to demonstrate how to use the wceex-functions and need it for errno.h.

CL,_CL_,LINK,_LINK_ are MSVC variables to control cl.exe and link.exe CL is prepend to all options when cl.exe is called,_CL_ is appended, same goes for link.exe and its variables. Note: When using defines cl.exe always uses the last definition it got. So with _CL_ you could override defines from any cl call (e.g. a makefile).


Building libiconv

The last version I have found with msvc Makefiles for iconv was 1.11.1 for a first try to get it working I used that version to have it easier.
get it at: http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.11.1.tar.gz extract and then run:

           set CL=/Dabort#wceex_abort /Dperror(...)#printf(...) /Dstrdup#_strdup /Dstrerror#wceex_strerror

edit the config.h.msvc (or just put #undefs at the end of the file):

            #define HAVE_ENVIRON_DECL 1 to #undef HAVE_ENVIRON_DECL
            #define HAVE_SETLOCALE 1 to #undef HAVE_SETLOCALE

now run

            nmake -f Makefile.msvc NO_NLS=1 DLL=1 MFLAGS=-MD
            nmake -f Makefile.msvc NO_NLS=1 DLL=1 MFLAGS=-MD install

Explanation: The CL defines reroute some function calls. We don't have decent error handling on Windows CE so in my opinion we could just print out error messages or numbers to a console we also don't have (but maybe later find a way to reroute to a file or so) anyways. wceex_abort just terminates the process _strdup is the WinCE equivalent of strdup, MS already provided it. I did not use more configuration Options in config.h because in most cases the workarounds they provide don't help either for Windows CE. NO_NLS=1 stands for building without libintl, since libintl needs iconv to build.


Building gettext-runtime

With gettext I again used a release with msvc makefiles, version 0.14.5 http://ftp.gnu.org/pub/gnu/gettext/gettext-0.14.5.tar.gz

If you have installed libiconv in the default location you can also use defaults with gettext, otherwise make sure to provide the same prefix you used with libiconv. To avoid confusing errors, you may want to edit the makefile to only build the gettext-runtime. Now in the gettext-runtime directory append to the config.h.msvc again:

     #undef HAVE_ENVIRON_DECL
     #undef HAVE_SETLOCALE

and change CL to:

     CL=/Dabort#wceex_abort /Dperror(...)#printf(...) /Dstrdup#_strdup /Dstrerror#wceex_strerror 
/Dgetenv#wceex_getenv /Dclose#wceex_close /Dread#wceex_read
/Dfstat#wceex_fstat /Dopen#wceex_open /Dbsearch#wceex_bsearch /Draise#wceex_raise /Dgetcwd#wceex_getcwd
/DGetThreadLocale#GetUserDefaultLCID

loadmsgcat needs close read write fstat open bsearch and raise. Since there were no implementations or workarounds for close read fstat and open in wcelibcex I wrote them myself using fopen fclose. For wceex_raise I took parts from Rainer Keuchel's celib. I'll try to do some decent testing and getting them upstream. But if you have an idea how not to use them please make an edit.

Now you should be able to build:

      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD install

If you get errors make sure that you do not try to build the tools, which are another problem.

Building libiconv with libintl

Go back to your libiconv directory

      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD clean
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD
      nmake /f Makefile.msvc DLL=1 MFLAGS=-MD install

should run smoothly and link against libintl. If not, make sure that you still have the preprocessor macros defined in CL.

libxml2 with iconv

Building libxml2 for WinCE is fairly easy for us, because the official release already was ported to Windows CE, my problem was that I could not convert the EVC project files to my VS installation so I used the Win32 makefile. Checkout libxml2

     git clone git://git.gnome.org/libxml2

Although a port exists it was apparently done some time ago so you have to modify some things, the file include\wsockcompat.h includes winsock.h instead of winsock2.h for _WIN32_WCE. That is no longer needed we have winsock2 on Windows Mobile 6, so change that to winsock2.h
Copy the two files wincecompat.h and wincecompat.c from win32\wince into your main src directory in those all the functions needed for compatibility are declared. To avoid conflicts make sure your CL variable is not still set with all the function replacements. Since the original port used EVC-Project files we have to edit the win32\Makefile.msvc to avoid linker errors.

     In line 69 replace wsock32.lib ws2_32.lib with ws2.lib
     In line 81 replace kernel32.lib with coredll.lib 
     Add $(XML_INTDIR)\wincecompat.obj to the XML_OBJ list. 

Now from the win32 subdirectory you should run:

     cscript configure.js help

and configure according to your setup. Make sure to set the inc/lib vars pointing to your iconv installation.

     nmake /f win32\Makefile libxml libxmla libxmladll

should build. Only some utils are still going to make problems.


Miscellaneous

Accessing Pocket Outlook

Similar to the Outlook Object Model for the Desktop Outlook, Microsoft offers the Pocket Outlook Object Model (POOM) The related library is called pimstore and part of the Windows Mobile SDK. You can use it to access the pim.vol file which is located in the Windows Mobile root directory. It contains Contacts, Tasks, Calendar entries and the infrared folder. To access messages you have to use the Messaging API.

Establishing a connection is straightforward COM, you have to initialize the COM library find out the COM identifier of PocketOutlook, then create an application class COM server object and logon to the COM server object using the IPOutlookApp COM interface

For example:

   CLSID clsid;  // The COM Identifier 
   CComQIPtr<IPOutlookApp,&__uuidof(IPOutlookApp)> ipOutlookAppPtr; // managed COM interface pointer
   
   CoInitializeEx(0,0); // Initialize the COM library
   CLSIDFromProgID(L"PocketOutlook.Application", &clsid); // Lookup the ID in the registry
   ipOutlookAppPtr.CoCreateInstance(clsid, NULL, CLSTX_INPROC_SERVER); // Create the server object
   ipOutlookAppPtr->Logon(NULL); // Logon

After you have established the connection you can use the IPOutlook interface methods to retrieve or manipulate the data. I have written a small program that exports all the Contact data on a device into a CSV file. POutlookExport.zip

Further Reading: MSDN Messaging Reference MSDN POOM Reference

Debugging with emerge