I have some COM and some native dlls that are compiled for a Win CE device that I have. I would like to take a look at them, so I can create an application that references them and extends the functionality of some programs already on the device. When I open them with the Dependency Walker or Visual Studio 2008, both tell me that they are invalid DLLs. However, I'm fairly certain they are not corrupted, as I extracted them from the ROM of the device along with other files (bmps and the like) that are not corrupted. So I'm asking- are WinCE dlls fundamentally different than win32 dlls, and as such vs and depends is not reading them correctly? Or is something else going on?
Otherwise, zildjohn01 is right that you sometimes can't copy executables or DLLs from the ROM of a WinCE device. It depends how the OS image is made: if the DLLs or EXEs are included as "MODULES" rather than "FILES" then you cannot copy them back off.
Wince Copy Rom Files
When the system detects that a storage card has been inserted, it looks in the root directory of that card for a directory with a specific name. If that directory exists and contains an application named autorun.exe, the application is first copied to the \windows directory, and then launched with a command line string install. When the card is removed, the copy of autorun in the \windows directory is again launched, this time with a command line of uninstall.
After you have a dumped rom file, you can use the tool dumprom from forum.xda-developers.com to get the content of the rom file. This is very usefull, as you now get access to files, that are protected on the device itself. For example, you can not get the export function list from shell32.exe on a device (ie with PEInfo), as the file is a eXecute In Place (XIP) file. Now on the Desktop PC, you can get the ROM files from dump.bin extracetd into a directory of your choice and then you can take a look at the file contents. On forum.xda-developers.com you will also find tools to re-assemble the files into a new ROM file and can then put this new ROM image onto the device.
Another very good source for information about how a WinCE system works and what are all the registry entries are for is the Windows CE 4.2 Platform Builder. You can download an evaluation software, which includes very valuable sources, utilities and help files. Although the evaluation will expire, the utilities, sources and help files (WinCE 4.2 has about 60MB help files, see pdf sample here) are still accessible and are ready to serve you. You don't need to be a platform builder to get value from these. Another good source for missing informations are the source codes of Windows CE: i.e. get the Windows CE 3.0 source code.
Should the user only be able to use your Application only? If so, then this is been called kiosk mode or lockdown application. The user can not leave your application and cannot change settings that your application needs to run. If you don't lock the user, it may possible, that the user changes essential system settings or deletes files, plays games instead of working with your application.
If your application is finished, you have to decide, how it will be installed. You can install it manually, if there are only a few devices, where the application will be installed. But if you offer your application to useres in the world or if there are many devices to setup, then you should provide a automatic installation. Automatic installation files on Windows CE and Pocket PC devices are CAB files. You can build a cab using the cabwizard. Cabwizard is part of embedded Visual Tools 3.0 (eVT3), embedded Visual C++ 4.0 (eVC4), Visual Studio .Net 2003 and possibly other development tools. Cabwizard needs an INF file, which is like a script, to compile a CAB file. As the INF file is partly complicated, you should think about using WinCE Cab Manager by OCP software. (Be warned, that the Cab Manager does not work perfectly. It crashes on 0 byte files, it will not import reg files with binary data correctly.) A description of the INF file is here. The INF file will hold the information about which files to copy where, where to create links, the target of the links, how to change the registry. Here is another description by ITC describing the INF file format and how to create cab files: Making a CAB file.htm
If you need special functions, you write a setupdll.dll, which will be installed as first file during the install and will be invoked by the OS four times: at the beginning with installinit, at end with installexit and during uninstall with uninstallinit and uninstallexit. How can this be done by the OS installing different CABs? The setupdll.dll is extraced first from the cab and will be copied to \Windows\AppMgr renamed to the reflect the cab file information. Now it is available to the OS also all CAB files use the same setupdll.dll name. There is a link to more information and here is another example of an setupdll.dll.
After you get the cab file, you copy it either via ActiveSync (there are automation tools available too), TCP/IP or simply using a PC card reader to have a memory card with the cab that you put into the device.
If you put in a memory card or boot a device, the OS will look for a AutoRun.exe in a processor specific directory. For Intels PCA, ARM, XScale this directory is 2577 (more in Douglas Boling book, see book links). If the OS finds such a programm, it will be copied to the windows dir and then be executed. It is up to you, how you use this. ITC(1) uses a special AutoRun.exe together with other tools to work thru batch like files called AutoRun.dat, AutoExec.dat and AutoUser.dat. For more information on these look here.
The OS uses wceload.exe to install CAB files. If you tap a cab inside the file explorer, wceload is called and installs the CAB. As default, the cab is deleted after the installation. wceload supports some options, which you can use in a batch like file to customize your installation needs. Here is wceload.doc.
Windows CE 4.x and PocketPC 2003 come with a preinstalled .NET Compact Framework. So some of the files are in ROM. When you try to install a Compact Framework service pack or update, either manually or automatically, you will be asked if you like to overwrite some System files. To avoid this, you must replace the ROM files by dummy files before you start the install of the service pack or update. These dummy files do not have the system, hidden or the IN_ROM flag and can easily overwritten by the cab installation. BTW this is a nice trick: you cannot delete ROM files but you have a file with the same name on top of this ROM file. So, if you don't like a user to play solitare.exe, which is a IN_ROM file, simply replace solitare.exe with an application of your choice by copying it on top of solitare.exe.
In the case of the compact framework service pack 3, the cab install asks for permissions to overwrite mscoree.dll, mscoree1_0.dll, cgacutil.exe and netcfagl1_0.dll. I have written a small cab with a setupdll, that will just create some dummy files with these names (Download PrePareNETCF.zip, incl. source). If you install the cab before the service pack, you will not be asked to replace files.
In Linux, kernel modules must be compiled with the same header files that thekernel itself was compiled with. Since WinDriver installs kernel modules, itmust compile with the header files of the Linux kernel during the installationprocess.
With the first stable release of Free Pascal for Windows CE the installation of a WinCE development environment was never easier. The step-by-step guide below is all you need to install and configure Lazarus to compile wince applications.
NOTE: recently a "wincemenures.or" file is reported missing on linking. You just need to copy this file from "lazarus/lcl/interfaces/wince" to "lazarus/lcl/units/arm-wince" and everything will be fine.
Everything is just as you do with other interfaces and OSes.Make sure you have selected wince as widgetset in in Compiler Options->Paths and in Code tab page select WinCE as target os and arm as Target CPU.
Step 2 - If you are using Microsoft Device Emulator Preview, launch(or restore)it. Make sure you've started emulator with 128MB of RAM. Select a path for shared folders in emulator, add copy command to your .bat file used for building your application to copy the compiled exe file to your shared path. (as you can see in my .bat file). Here is a .bat file you can use to launch the emulator with 128 of ram.
Step 5 - Now you can safely debug your application.gdb for wince will be launched.it will copy arm-wince-pe-stub.exe to \gdb folder and check if your application.exe file is there and will launch the program.If you encountered an error a) make sure the \gdb folder is created and b) that both arm-wince-pe-stub.exe and your .exe file are present. Also most of the times because of big size of a .exe file, you can not copy that into your \gdb file. So, you'll have to call Microsoft Device Emulator Preview with 128mg ram instead of the default 64mg ram.
The Toradex bootloader and BSP were designed to be easily configurable. This relieves the application developer from the burden of creating a customized operating system image. Instead, the necessary adaptations can be made by registry settings and adding files to the on-board flash file system.
Toradex provides the Microsoft Platform Builder workspaces (solution files) which can be used to build an identical image as the pre-built binary images provided by Toradex. However, we recommend to use the binary images and configure them to your needs rather than building your own image. There are many advantages:
In case you want to migrate your project to one of the new SDKs, some renaming in the .sln and .vcproj files has to be done. Toradex provides a command line tool that does this job for you. Run the tool and provide the path to one of your projects as a parameter. You get the tool from here. 2ff7e9595c
Comments