Windows Mobile Build Instructions
work in progress - things are changing as we speak, er.. as you read this
Overview
This page covers building the latest version of the Windows Mobile XULRunner and Fennec applications using either Visual Studio 2005 or Visual Studio 2008 and the MozillaBuild environment.
These instructions are changing frequently.
The Windows Mobile build of XULRunner and Mobile Fennec is undergoing major improvements and bug fixes. Do not be surprised if your attempt to build and/or run do not immediately work.
People focused on the Windows Mobile build are currently using the #wince channel to communicate about Windows Mobile build-specific issues.
Did we mention that things are changing frequently?
Big Picture
These build instructions are broken down into three parts:
(1) Preparing To Build XULRunner and Fennec, or what to do before pulling down a single bit of code
(2) Actual Building of XULRunner and Fennec, or how to pull down, prepare, and compile the XULRunner and Fennec code
(3) Debugging XULRunner and Fennec, also known as 'Now that I have it built, what next?'
(4) Device Specific Testing Information, which is information about specific devices that people have tested and their issues
Overview (OLD)
This page describes the commands for building the latest version of the Windows Mobile XULRunner application using either Visual Studio 2005 or Visual Studio 2008 and the MozillaBuild environment.
These instructions are changing frequently. The Windows Mobile build of XULRunner and Mobile Fennec is undergoing major improvements and bug fixes. Do not be surprised if your attempt to build and/or run do not immediately work.
People focused on the Windows Mobile build are currently using the #wince channel to communicate about Windows Mobile build-specific issues.
Did we mention that things are changing frequently?
Smaller Big Picture
Here is a big-picture view of the steps needed to prepare a new PC for debugging the Windows Mobile Fennec and/or a Windows Mobile ZULRunner application.
- One-Time Setup, including:
- Install Visual Studio 2008 Professional (VS9) or Visual Studio 2005 Professional (VS8)
- Install Windows Mobile 6 Professional SDK
- Install Windows Mobile 6.1 Localized Emulator Images
- Install Mozilla Build Tools
- [Optional] Download and Install Latest Mercurial
- Prepare To Build
- Download (or update) Sources and Patch Queue
- Download and/or Create Your MOZCONFIG File
- Build
- Debugging
- Prepare for Debugging
- Start Debugging
Still interested? OK, let's get started.
One-Time Setup
You will only have to do this setup once.
Only Visual Studio 2005 (also known as Visual Studio 8, or VS8) and Visual Studio 2008 (also known as Visual Studio 9, or VS9) are currently supported.
Visual Studio 2008 Express Edition does NOT work for building, because the Windows Mobile SDK Installer will not successfully complete with only Visual Studio 2008 Express installed.
You will need to install your Visual Studio version before continuing with these instructions.
Follow the instructions here to setup a windows development environment.
Because the Windows Mobile build uses a patch queue, you must turn on the mercurial queues extension.
Then you need to install the Windows Mobile 6 Professional SDK (WM6 Pro SDK). To resolve dependencies in the installation of the Windows Mobile 6 Professional SDK, you might need to install some extra software. In this case, the WM6 Pro SDK Installation program will tell you what software you need to install.
You will also need to download and install the Windows Mobile 6.1 Professional Localized Emulator Images.
WM6.1 Emulator Images IMPORTANT NOTE
(by wolfe in #wince IRC)
You NEED to install the WM6.1 Emulator Images, because Microsoft fixed something in between 6.0 and 6.1 - so now the specification of memory size via the Emulator Options dialog box works.
You will need to increase the amount of memory available in your chosen 6.1 Emulator (BEFORE you run the chosen 6.1 Emulator for the first time). Otherwise you'll receive "(e)", or "not enough storage is available to complete this operation".
You can increase the amount of memory in your emulator by using the VS8 tools menu, options dialog box.
Find the device tools | devices section, select your desired emulator, click on the properties... button, then press the Emulator Options... button
Once you are looking at the Emulator Options dialog box, check the Specify RAM Size check box - and enter in 256 - the acceptable range for this number is from 1 to 256.
BUT - BUT - BUT - The Emulator built into Visual Studio 2005 / VS8 does not work for mapping a local directory on your PC into the Emulator's \Storage Card (or \Storage Card2).
I have been told that the WM6.1 Emulator Images install fixes BOTH VS8's and VS9's mapping of a local directory into your Emulator as a Shared Directory.
SO - If you want to debug via Emulator, you NEED the Windows Mobile 6.1 Emulator Images.
If you use VS9, you need a minimum of the Visual Studio 2008 Professional version, because the VS9 Express version does not allow the WinMobile 6 SDKs to be installed.
Bottom Line - use VS8 Pro or VS9 Pro AND WM6.1 Emulator Images.
Prepare To Build
These directions assume you have created a c:\mozilla-build directory, created by downloading and installing the [Windows Mozilla Build Setup version 1.3].
Mercurial Version In Mozilla-Build version 1.3
NOTE: As of 20-Nov-2008, Mozilla Build Setup version 1.3 includes a slightly stale version of Mercurial (version 1.0.1+20080525). The latest Mercurial has a version number of 1.1+20081203. The latest Mercurial is downloadable directly from Selenic's Web Site.
In order to use the latest Mercurial, you have two basic choices:
(1) Remove the c:/mozilla-build/hg directory, and replace it with the contents of C:/Program Files/Mercurial after you have installed the latest download from Selenic.
(2) Go into c:/mozilla-build/msys/etc/profiles.d/profile-extrapaths.sh and modify the /c/mozilla-build/hg directory to say /c/Program Files/Mercurial
You can try updating to the latest version of Mercurial if you have troubles with hg.exe
Downloading The Sources And Patch Queue
Run the batch file from the Mozilla-Build directory to open a shell: For VS9 use: C:\mozilla-build\start-msvc9.bat For VS8 use: C:\mozilla-build\start-msvc8.bat NOTE: This will setup and open a MingW32 command prompt. All further commands are to be run inside MingW32. NOTE: Let us assume you have created /c/hg/ for your mozilla source tree $ cd /c/hg $ hg clone http://hg.mozilla.org/mozilla-central $ cd mozilla-central $ hg clone http://hg.mozilla.org/mobile-browser mobile $ wget http://people.mozilla.org/~blassey/mozconfig $ cd .hg $ hg clone http://hg.mozilla.org/users/blassey_mozilla.com/wince-m1 patches $ cd ..
CRUD - The Clone of Mozilla-Central Freezes
Several people have reported that the cloning of mozilla-central as described above freezes and does not complete.
If your clone of mozilla-central is taking more than an hour to complete, you may be in this same situation. Basically, this can be caused by a number of different situations:
- The Mozilla hg repository is overloaded,
- The Internet Connection you have is very slow and times out
- The Internet Connection you have drops enough packets that HG gets confused
As a point of reference, John Wolfe has a very fast RCN cable modem connection at home. However, he found out a while ago that RCN considers a 7% data loss to be within acceptable limits for customer service. 7% Data Loss (tested via pinging from an internal-to-RCN server to John Wolfe's cable modem) means that 7 out of every 100 packets gets lost' within the RCN internal network.
This means that when RCN gets busy (nights and weekends, for instance), it is almost guaranteed that John Wolfe will not be able to do a full HG clone operation on the mozilla-central repository.
Here is what you can do to get around HG freezing when cloning mozilla-central:
# Download a recent HG bundle (made on 26-Nov-08 after a new clone operation on mozilla-central) # Run the batch file from the Mozilla-Build directory to open a shell: For VS9 use: C:\mozilla-build\start-msvc9.bat For VS8 use: C:\mozilla-build\start-msvc8.bat NOTE: This will setup and open a MingW32 command prompt. All further commands are to be run inside MingW32. NOTE: Let us assume you have created /c/hg/ for your mozilla source tree # Create a new, empty mozilla-central repository: $ cd /c/hg $ hg init mozilla-central # Un-bundle the real mozilla-central changes to that repository: $ cd mozilla-central; $ hg unbundle /path/to/mozilla-central.bundle/tip.tar.bz2 # Tell mercurial where you normally want to pull from by copying the following content into your mozilla-central/.hg/hgrc file: [paths] default = http://hg.mozilla.org/mozilla-central/ # Pull any changes that happened since the bundle was created: $ hg pull # Update your working directory to the latest change: $ hg update
NOTE: You will want to do two seperate operations for pulling then updating, as some versions of HG have a bug in their hg pull -u command. I forget exactly what the bug is - but the work-around is to do these two seperate operations.
Thanks go out to Benjamin Smedbergs for this solution - Original Blog Posting Here
Updating The Sources And Patch Queue
# Run the batch file from the Mozilla-Build directory to open a shell: For VS9 use: C:\mozilla-build\start-msvc9.bat For VS8 use: C:\mozilla-build\start-msvc8.bat NOTE: This will setup and open a MingW32 command prompt. All further commands are to be run inside MingW32. NOTE: Let us assume you have created /c/hg/mozilla-central as your source tree Run the batch file C:\mozilla-build\start-msvc8.bat (or C:\mozilla-build\start-msvc9.bat) NOTE: This will setup and open a MingW32 command prompt. All further commands are to be run inside MingW32. This assumes you have a c:\hg\mozilla-central directory $ cd /c/hg/mozilla-central $ hg qpop -a $ hg pull;hg update; $ cd mobile $ hg pull;hg update; $ cd ../.hg/patches $ hg pull;hg update; $ cd ../.. $ hg qpush -a
Setting Up Your MOZCONFIG File
Building options are controlled by mozconfig, a master file within your top source directory (in our case, /c/hg/mozilla-central/mozconfig).
You need to create a MOZCONFIG file, since one is not included in the source code repositories. There are four options for Windows Mobile 6 development:
(1) Visual Studio 9 Debug Build (2) Visual Studio 9 Release Build (3) Visual Studio 8 Debug Build (4) Visual Studio 8 Release Build
VS9 Debug Build MOZCONFIG
Here is our current VS9 mozconfig for building a Debug XULRunner and Fennec for WinMobile:
# Options for client.mk. mk_add_options MOZ_BUILD_PROJECTS="xulrunner mobile" # Uncomment this line to do parallel make jobs # -jN, where N=2 works best on MacBook Pro Dual Processors # mk_add_options MOZ_MAKE_FLAGS=-j2 # Options for VS8 verses VS9 / Debug verses Release # Debug/Non-Opt = ~28 MByte XUL.dll # Debug/Opt = ~20 MByte XUL.dll # Release/Opt = ~12 MByte XUL.dll ac_add_options --enable-debug #ac_add_options --disable-optimize mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-wm6-dbg # mobile options ac_add_app_options mobile --enable-application=mobile ac_add_app_options mobile --with-libxul-sdk=../xulrunner/dist # Disabling tests due to bug 454881 ac_add_options --disable-tests #WINCE specific options ac_add_options --disable-javaxpcom ac_add_options --disable-plugins ac_add_options --disable-accessibility ac_add_options --disable-printing ac_add_options --disable-oji ac_add_options --disable-vista-sdk-requirements ac_add_options --disable-updater ac_add_options --disable-installer ac_add_options --disable-xpinstall ac_add_options --enable-image-decoders="png gif jpeg" ac_add_options --disable-dbm CROSS_COMPILE=1 MIDL=/c/Program\ Files/Microsoft\ Visual\ Studio\ 9.0/VC/ce/bin/x86_arm/midl.exe ac_add_options --target=arm-wince ac_add_options --enable-win32-target=WINCE ac_add_options --enable-default-toolkit=cairo-windows ac_add_options --with-wince-sdk="c:/program files/windows mobile 6 sdk/pocketpc"
VS9 Release Build MOZCONFIG
Here is our current VS9 mozconfig for building a non-debug XULRunner for WinMobile:
# Options for client.mk. mk_add_options MOZ_BUILD_PROJECTS="xulrunner mobile" # Uncomment this line to do parallel make jobs # -jN, where N=2 works best on MacBook Pro Dual Processors # mk_add_options MOZ_MAKE_FLAGS=-j2 # Options for VS8 verses VS9 / Debug verses Release # Debug/Non-Opt = ~28 MByte XUL.dll # Debug/Opt = ~20 MByte XUL.dll # Release/Opt = ~12 MByte XUL.dll #ac_add_options --enable-debug ac_add_options --enable-optimize mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-wm6-rel # mobile options ac_add_app_options mobile --enable-application=mobile ac_add_app_options mobile --with-libxul-sdk=../xulrunner/dist # Disabling tests due to bug 454881 ac_add_options --disable-tests #WINCE specific options ac_add_options --disable-javaxpcom ac_add_options --disable-plugins ac_add_options --disable-accessibility ac_add_options --disable-printing ac_add_options --disable-oji ac_add_options --disable-vista-sdk-requirements ac_add_options --disable-updater ac_add_options --disable-installer ac_add_options --disable-xpinstall ac_add_options --enable-image-decoders="png gif jpeg" ac_add_options --disable-dbm CROSS_COMPILE=1 MIDL=/c/Program\ Files/Microsoft\ Visual\ Studio\ 9.0/VC/ce/bin/x86_arm/midl.exe ac_add_options --target=arm-wince ac_add_options --enable-win32-target=WINCE ac_add_options --enable-default-toolkit=cairo-windows ac_add_options --with-wince-sdk="c:/program files/windows mobile 6 sdk/pocketpc"
VS8 Debug Build MOZCONFIG
Here is our current VS8 mozconfig for building a Debug XULRunner and Fennec for WinMobile:
# Options for client.mk. mk_add_options MOZ_BUILD_PROJECTS="xulrunner mobile" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-wm6-dbg # Uncomment this line to do parallel make jobs # -jN, where N=2 works best on MacBook Pro Dual Processors # mk_add_options MOZ_MAKE_FLAGS=-j2 # Options for VS8 verses VS9 / Debug verses Release # Debug/Non-Opt = ~28 MByte XUL.dll # Debug/Opt = ~20 MByte XUL.dll # Release/Opt = ~12 MByte XUL.dll ac_add_options --enable-debug #ac_add_options --enable-optimize mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-wm6-dbg-vs8 # mobile options ac_add_app_options mobile --enable-application=mobile ac_add_app_options mobile --with-libxul-sdk=../xulrunner/dist # Disabling tests due to bug 454881 ac_add_options --disable-tests #WINCE specific options ac_add_options --disable-javaxpcom ac_add_options --disable-plugins ac_add_options --disable-accessibility ac_add_options --disable-printing ac_add_options --disable-oji ac_add_options --disable-vista-sdk-requirements ac_add_options --disable-updater ac_add_options --disable-installer ac_add_options --disable-xpinstall ac_add_options --enable-image-decoders="png gif jpeg" ac_add_options --disable-dbm CROSS_COMPILE=1 MIDL=/c/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC/ce/bin/x86_arm/midl.exe ac_add_options --target=arm-wince ac_add_options --enable-win32-target=WINCE ac_add_options --enable-default-toolkit=cairo-windows ac_add_options --with-wince-sdk="c:/program files/windows mobile 6 sdk/pocketpc"
VS8 Release Build MOZCONFIG
Here is our current VS8 mozconfig for building a non-debug XULRunner for WinMobile:
# Options for client.mk. mk_add_options MOZ_BUILD_PROJECTS="xulrunner mobile" # Uncomment this line to do parallel make jobs # -jN, where N=2 works best on MacBook Pro Dual Processors # mk_add_options MOZ_MAKE_FLAGS=-j2 # Options for VS8 verses VS9 / Debug verses Release # Debug/Non-Opt = ~28 MByte XUL.dll # Debug/Opt = ~20 MByte XUL.dll # Release/Opt = ~12 MByte XUL.dll #ac_add_options --enable-debug ac_add_options --enable-optimize mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-wm6-rel-vs8 # mobile options ac_add_app_options mobile --enable-application=mobile ac_add_app_options mobile --with-libxul-sdk=../xulrunner/dist # Disabling tests due to bug 454881 ac_add_options --disable-tests #WINCE specific options ac_add_options --disable-javaxpcom ac_add_options --disable-plugins ac_add_options --disable-accessibility ac_add_options --disable-printing ac_add_options --disable-oji ac_add_options --disable-vista-sdk-requirements ac_add_options --disable-updater ac_add_options --disable-installer ac_add_options --disable-xpinstall ac_add_options --enable-image-decoders="png gif jpeg" ac_add_options --disable-dbm CROSS_COMPILE=1 MIDL=/c/Program\ Files/Microsoft\ Visual\ Studio\ 8/VC/ce/bin/x86_arm/midl.exe ac_add_options --target=arm-wince ac_add_options --enable-win32-target=WINCE ac_add_options --enable-default-toolkit=cairo-windows ac_add_options --with-wince-sdk="c:/program files/windows mobile 6 sdk/pocketpc"
Build
Now you can build xulrunner (and the mobile fennec code) using these commands:
$ cd /c/hg/mozilla-central $ hg qpush -a $ make -f client.mk build
Copy MOZCE_SHUNT.DLL To BIN - OBSOLETE
NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED. NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED. NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED.
For Visual Studio 2005 (VS8), you can find the shunt DLL at:
/c/hg/mozilla-central/build/wince/shunt/build/vs8/mozce_shunt.dll
For Visual Studio 2008 (VS9), you can find the shunt DLL at:
/c/hg/mozilla-central/build/wince/shunt/build/vs9/mozce_shunt.dll
To debug fennec using VS8/9, you will have to copy mozce_shunt.dll into:
$OBJDIR\mobile\dist\bin\xulrunner
so that the .dll file is in the same directory as where xulrunner.exe is in.
Otherwise, you will receive a
- Could not find 'XULRunner' (or one of its components). Make sure that the path and filename are correct and that all the required libraries are available.
or
- The file 'xulrunner' cannot be opened. Either it is not signed with a trusted certificate, or one of its components cannot be found. If the problem persists, try reinstalling or restoring this file.
error dialog if you try to run XULRunner.exe from a File Explorer.
The VS8 IDE will say that it is Unable to start program '\Storage Card\bin\xulrunner.exe'. An error occurred that usually indicates a corrupt installation (code 0x8007007e). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel.
Both of these rather cryptic messages try to tell you that an executable file (EXE or DLL) depends upon a DLL, and that DLL could not be found.
Debugging
Debugging Fennec
NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED. NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED. NOTE: As of 20-Jan-2009, this step is NO LONGER REQUIRED.
There is a bug in the way that Windows CE searches for executable files that means WinMobile can not search correctly for DLLs desired by xulrunner when launched by fennec.
There are three work-arounds to this problem, and you can select which work-around appeals to you the most:
(1) Copy all xulrunner files to the same directory as the fennec executable (NOTE: You should copy all files including subdirectories of xulrunner but some files like chrome/en-US.jar are already exists in the fennec directory. You should rename and edit them properly)
(2) Create shortcut of xulrunner "fennec.lnk" containing:
- 67#"\Storage Card\bin\xulrunner\xulrunner.exe" -app ..\application.ini
Of course you should chnage path according to your install path. NOTE: First number '67' is the bytes of following command line.
(3) Copy all xulrunner files to the \Windows directory on your device (NOTE: does not work unless your Windows Mobile device has a LOT of space - i.e. HTC Touch Diamond, GTC Touch Pro, others with > 192 MByte)
(4) Change your Registry's OEM Search Path string to add your xulrunner's bin directory. Further information for this option is available [via Microsoft DevNetwork]. Note that you will have to reboot your WinMobile device for a changed OEM Search Path to take effect.
Visual Studio 2005 / Visual Studio 8 Debugging
Visual Studio 2005 (VS8) has the following issues when debugging:
- VS8 is available for free from Microsoft, with is a great thing for part-time hackers.
- You can compile xulrunner and fennec, then copy the executables to a device and try running the executables.
- The main people working on WinMobile are using VS9 for compiling and debugging.
- VS8 Emulator's shared-directory driver does not work properly. If you try to use the Emulator supplied with VS8, you will receive LOTS of random errors and faults. You might be able to eventually get a good run of the xulrunner application, but you will also get very frustrated at the same time.
- To run / debug within a VS9 Emulator, you NEED to download and install the [Microsoft Windows Mobile 6.1 Emulator Images]
- Installing Windows Mobile 6.1 Professional Localized Emulator Images fixes the issue with Emulator Shared Directory use, allowing you to point your Emulator at your BIN directory for running your executables without needing to copy the executables.
- The WinMobile 6.1 Emulator Images installation also fixes a bug with setting the amount of memory within an Emulator Image.
Visual Studio 2008 / Visual Studio 9 Debugging
Visual Studio 2008 (VS9) has the following issues when debugging:
- If the Mozilla WinCE Shunt Library fails compiling with an error message about a missing CeGetCanonicalPathName() function, you will need to select the "Windows Mobile 6 Professional" platform in the VS9 IDE platform selection drop-down list box. On a brand-newly cloned source tree, VS9 selects a platform of Windows Mobile 2003.
- To run / debug within a VS9 Emulator, you NEED to download and install the [Microsoft Windows Mobile 6.1 Emulator Images]
- The WinMobile 6.1 Emulator Images installation updates the VS9 Emulator, fixing a bug with setting the amount of memory within an Emulator Image.
- The main people working on WinMobile use VS9 to run / debug in the emulator / debug on-device.
Emulator Images
To run / debug xulrunner and fennec, you will need to increase the amount of memory available to the WinMobile 6.1 Emulator Image in which you are running.
To increase the amount of memory available to your Windows Mobile 6.1 Localized Emulator Image, do the following within VS9:
- Pull down the Tools menu
- Select the Options... menu item
- Find the Device Tools section in the list on the left hand side
- Find and select the Devices sub-section
- Find and select the desired Emulator Image
- Press the Properties... button
- Press the Emulator Options... button
- Check the Specify RAM Size checkbox
- Enter a number greater than 192 (and less than or equal to 256) into the edit box.
- Press OK to close the Emulator Properties dialog box
- Press OK to close the Emulator Image dialog box
- Press OK to close the Options dialog box
- When you start up your Emulator Image, verify that you have the RAM you specified in the Emulator Properties dialog box.
- If your Emulator Image does not have the RAM you specified, you may need to make a new copy of the Emulator in order to correctly specify the RAM size available to your Emulator Image.
On-Device Debugging
Some devices ship with security settings turned on. All devices need to have development certificates loaded onto them before debugging.
Putting Development Certificates On Your Device
To set the development certificates into your device, copy the file C:\Program Files\Windows Mobile 6 SDK\Tools\Security\SDK Development Certificates\Certs.cab onto your device. Locate and run this CAB file using the device's File Explorer. Once this CAB file has been installed into your device, the device will be able to run all of the Visual Studio devlopment tools.
Enabling RAPI Commands On Your Device
To allow all RAPI (Remote API function calls from the desktop to your tethered, or connected, device) function calls to succeed, you may need to run a command from a DOS box on your PC. Run these commands once your device has the development certificates installed and you have your device connected to your PC:
C:\> cd "C:\Program Files\Windows Mobile 6 SDK\Tools\Smartphone\RapiSecurity" C:\> RapiConfig.exe /P /M RapiAllowed.xml
Instead of running the RapiConfig.exe program, you can copy a Certificate Provisioning File (.CPF) to your device, and run the .CPF file just like you ran the Certs.cab file. Copy the file C:\Program Files\Windows Mobile 6 SDK\Tools\Smartphone\RapiSecurity\RapiAllow.cpf file onto your device. Locate and run this .CPF file using the device's File Explorer.
Security Powertoy
Microsoft provides a Security Powertoy application which allows mere mortals to manipulate the security settings on a device from a semi-friendly GUI.
WARNING: The Security Powertoy has the ability to completely mess up your device. Use this tool with extreme caution.
To use the Security Powertoy, run the "C:\Program Files\Windows Mobile 6 SDK\Tools\Security\Security Powertoy\SecCfgMgr.msi" installer. Once the installer has finished, there will be a shortcut created in your PC's Start Menu named "Security Configuration Manager".
Putting XULRunner on a Device
Thanks to Tim Zander for pointing out that no one ever explains how to get XULRunner onto a device.
NOTE: DO NOT FORGET to copy a mozce_shunt.dll executable from the TOPSRCDIR/build/wince/shunt/build/vs8 or TOPSRCDIR/build/wince/shunt/build/vs9 directory into the OBJDIR/dist/bin directory BEFORE copying the whole directory onto a external card or directly onto your device.
You currently (as of 10-Dec-2008) have two options for getting XULRunner on to a device:
(1) If your device takes a plug-in expansion card, copy the OBJDIR/dist/bin directory on to a expansion card from your PC, then place that expansion card into your device.
(2) If your device has a LOT of internal storage (i.e., the HTC Touch Diamond has 4GBytes of internal storage), then you can teather your device to your PC, and use ActiveSync's File Explorer to copy the OBJDIR/dist/bin directory onto your device.
On my PC, the OBJDIR/dist/bin directory is located at c:\hg\mozilla-central\objdir-wm6-dbg\xulrunner\dist\bin, and is approximately 32 MBytes large.
Once you have the executables on your device, you can launch the executables via:
(A) The Visual Studio IDE (for debugging) (B) Via RAPI remote execute command (C) Via File Explorer on the device (D) Via specially-created shortcut
Creating Shortcut for XULRunner
You can make a shortcut link to execute the command you want under Windows Mobile / WinCE. Here is how:
A Shortcut Link File is a text file with an extension .LNK with one line in a very particular format:
NN#THE_COMMAND_LINE_GOES_HERE Where: NN: Number of characters in the whole command line THE_COMMAND_LINE_GOES_HERE: The actual command you would execute (as if you were running in a DOS box on WinXP) Some things to watch out for: (1) It is a LOT safer to use a full path to your executable (2) If the full path to your executable contains any spaces, you HAVE to wrap the full path to your executable with double-quotes (3) Any space not wrapped inside a double-quote will signal the OS that an argument has ended and another argument is beginning (4) If your arguments have spaces in them, again wrap the whole single argument in double-quotes Here is an example: 64#"\Program Files\MyDir\MyExe.exe" "First Argument" SecondArgument
There is also an app that you can use called Shortcut Creator.
Place your newly created shortcut in \Windows\Start Menu\Programs (or one of its sub-folders). You MAY want to place your shortcut in the \Windows\Start Menu\Programs\Games folder, because WinMobile 6 does not automatically update the Start Menu's contents until its next reboot. However, each sub-directory of the Start menu is re-evaluated every time you open the corresponding folder in the Start menu.
Suppose you have your fennec dist directory installed to \Internal Storage\Program Files\Fennec Your shortcut to directly launch XULRunner with the Fennec app is: 83#"\Internal Storage\Program Files\Fennec\xulrunner\xulrunner.exe" ..\application.ini
Now suppose you have your fennec dist directory installed to \Program Files\Fennec Your shortcut to directly launch XULRunner with the Fennec app is: 66#"\Program Files\Fennec\xulrunner\xulrunner.exe" ..\application.ini
Setting Up MyBrowser
A simple XULRunner application, MyBrowser, is used to test the XULRunner code.
Download the MyBrowser Application using this link.
The XULApp file is a ZIP file with a number of files and directories. Further explanation of XULRunner and the XULApp format can be found here.
rename mybrowser-0.2.2.xulapp mybrowser-0.2.2.xulapp.zip Unzip mybrowser-0.2.2.xulapp.zip into its own subdirectory, while preserving it's ZIP file directory structure. rename mybrowser-0.2.2.xulapp mybrowser Edit mybrowser\application.ini file, replacing: MaxVersion=1.8.0.* with: MaxVersion=1.9.*.* copy -r mybrowser c:\mozilla\unicode\objdir-wm6-debug\dist\bin
Setting Up Debugging of MyBrowser
You can debug the MyBrowser XULapp from within Visual Studio by using the WinCE shunt Visual Studio Project, and adjusting the deployment device and executable to be run.
1. Open Visual Studio 2005 (Visual Studio 8) Integrated Development Environment (IDE) 2. Open the solution c:\mozilla\unicode\build\wince\shunt\build\vs8\mozce_shunt_static.sln 3. In the Solution Explorer, right mouse click on the mozce_shunt_static project 4. Select the Properties pop-up menu item 5. Under the configuration properties, highlight the Deployment section 6. Make the selected Deployment Device be "Windows Mobile 6 Standard Emulator" 7. Press the Apply button if necessary to save your new selection 8. Under the configuration properties, highlight the Debugging section 9. For Remote Executable, enter \Storage Card\bin\xulrunner.exe 10. For Command Arguments, enter -app mybrowser\application.ini 11. Press the Apply button if necessary to save your new selection 12. Close the Project Properties dialog box
Actual Debugging
You are now ready to begin debugging your XULRunner build.
1. From the Visual Studio 2005 Build menu, select the Deploy Solution menu item 2. Wait for your chosen Emulator to start 3. In the Emulator's File menu, select the Configure... menu item 4. Press the ... button for the Shared Folder edit box 5. Select the c:\mozilla\unicode\objdir-wm6-debug\dist directory 6. Close the Emulator Properties dialog box by pressing the OK key 7. In the Visual Studio 2005's Debug menu, select the Start Debugging menu item
You should now see the Visual Studio begin a debugging session of XULRunner loading the MyBrowser XULApp.
Other Tips
1. Color scheme for MingW32 Command Line Prompt
I hated the default color scheme for the command prompt under MingW32 - so I changed it. Find the file c:\mozilla-build\msys\etc\profile, and edit the lines (toward the bottom) which export PS1, and make them say:
export PS1='\[\033]0;$MSYSTEM:\w\007 \033[34m\]\u@\h \[\033[31m\w\033[0m\] $ '
This changed the directory color to something I could actually see against a white background.
3. Further Setting Up MingW32 Path
I get annoyed with continually adding the path to the Mercurial HG.EXE, as well as continually adding the path to the build's wince tools directory.
So I created a c:\mozilla-build\msys\etc\profile.d\profile-setup-hg.sh file, containing:
#!/bin/sh export PATH="$PATH:/c/progra~1/Mercurial" # This is an addition to get the shim cross-compile build tools into # our path. - jvw 24-Apr-08 export PATH="$PATH:/c/hg/mozilla-central/build/wince/tools/bin"
This sets up my HG.EXE path, as well as the path to my WinCE build tools (arm-wince-as.exe, arm-wince-gcc.exe, arm-wince-lib.exe, and arm-wince-link.exe)