Everything you always wanted to know about CeGCC but were afraid to ask.

Table of Contents

  1. What are "Windows (Embedded) CE", "Windows Mobile", "Handheld PC", "Pocket PC", "SmartPhone" and "Portable Media Center"?
  2. How can I transfer files between my PC and my WinCE device?
  3. Can I debug/test my DLL/EXE entirely on the PC itself (without any risk to make any harm to my WinCE device)?
  4. I hate to use the command-line driven "gdb"! Doesn't there exist any debugger with a graphical front-end?
  5. I get "Unable to start remote stub '\gdb\wince-stub.exe'. Windows CE error 126." when I try to debug MyProgram with the "arm-wince-cegcc-gdb".
  6. I get "Error creating process \gdb\MyProgram.exe, (error 126)." when I try to debug MyProgram.
  7. I get "Error while mapping shared library sections: coredll.dll: No such file or directory." when I try to debug MyProgram.
  8. I get "No line number known for MyProcedure", or "(no debugging symbols found)", or "No symbol table is loaded. Use the 'file' command.", when I try to debug MyProgram.
  9. I get "/cygdrive/e/pedro/cegcc/0.50/src/mingw/crt3.c: No such file or directory.", or "Function 'main' not defined.", when I try to "list" the source code in the debugger (and who's that mysterious Don Pedro anyhow?).
  10. Why is my "arm-wince-mingw32ce-g++" compiled DLL/EXE so large?
  11. The arm-wince-mingw32ce compiler complains about undeclared identifier 'SOME_WIN_CE_IDENTIFIER'.
  12. The arm-wince-mingw32ce linker complains about undefined reference to 'SomeWinCeFunctionW' (and what's that "W" suffix appended to the function's name?).
  13. How can I find/trace any missing "DLL imports"?
  14. I get "GetLastError returns c1" when I try to use my DLL/EXE.
  15. I get "ERROR_BAD_EXE_FORMAT" when I try to use my DLL/EXE.
  16. I get "'MyProgram' is not a valid Windows CE application" when I try to run MyProgram.
  17. DLL does not work with Windows Mobile 6.1
  18. Need More Informations?
  19. Who's to be plead guilty for all that crap that I had to read in here?
  1. What are "Windows (Embedded) CE", "Windows Mobile", "Handheld PC", "Pocket PC", "SmartPhone" and "Portable Media Center"?

    See Wikipedia articles about the Windows CE and the Windows Mobile. See the History & Overview of Windows CE and the Determining the Windows CE / H/PC version from the HPC:Factor CESD, the Windows CE / Windows Mobile Versions table from the Pocket PC FAQ, and the Learn Windows Mobile from the Windows Mobile Developer Center. In practice, all this means that, different WinCE driven devices come with different sets of implemented functions in the system provided default DLLs, and even with partially different sets of system provided default DLLs. This in turn means that, a utility (or a DLL), which runs on one variation of WinCE, may refuse to start on another one (even when their kernel versions match), just because some required functions are missing in some system DLLs, or even some required system DLLs are missing at all.
    Note also that, while compiling your source code, you may need to define the "_WIN32_IE" and the "_WIN32_WCE" macros , in order to tell the compiler which version of WinCE you're using.

    Table of Contents

  2. How can I transfer files between my PC and my WinCE device?

    Several possibilities exist.

    Table of Contents

  3. Can I debug/test my DLL/EXE entirely on the PC itself (without any risk to make any harm to my WinCE device)?

    If you use a contemporary PC Windows (x86/x64) system, then you can use the free Microsoft Device Emulator 2.0 -- Standalone Release.

    In order to use it, you just need to: The installation will create shortcuts on your start menu from where you can launch the various configurations of the Windows Mobile 5.0/6 MSFP (ARM CPU). You will also see a shortcut for the Device Emulator Manager (DEM) using which you can launch any of the installed images.
    Note again that, you do NOT need any non-free tools (in particular, you do NOT need the Microsoft Visual Studio, for example).
    For the time being, I do not know if this software can be used on Linux with the Wine), sorry.

    Table of Contents

  4. I hate to use the command-line driven "gdb"! Doesn't there exist any debugger with a graphical front-end?

    Well, you can use the free GNU Data Display Debugger (DDD). It's a graphical front-end for several command-line debuggers, including the gdb. Besides "usual" front-end features, such as viewing source texts, DDD has become famous through its interactive graphical data display, where data structures are displayed as graphs. When invoking DDD, you simply need to specify the name under which the inferior debugger is to be invoked:

    Note however, from time to time, you will still need to interact with the gdb, via its command-line console window (integrated in DDD).
    For more informations see the DDD Manual.
    See also this answer, if you're debugging a GUI application.

    Table of Contents

  5. I get "Unable to start remote stub '\gdb\wince-stub.exe'. Windows CE error 126." when I try to debug MyProgram with the "arm-wince-cegcc-gdb".

    The arm-wince-cegcc compiled binaries (including the "arm-wince-cegcc-stub.exe") require at least the "cegcc.dll" to be present on your WinCE device. You can copy the "/opt/cegcc/arm-wince-cegcc/lib/device/cegcc.dll" to the "\gdb" subdirectory, or to the "\Windows" subdirectory, or to any subdirectory that is present in the registry subkey "SystemPath", in the "HKEY_LOCAL_MACHINE\Loader" registry entry, on your WinCE device (any change to the "SystemPath" subkey itself does not take effect until the WinCE device is reset).
    You should not get this error when you try to use the "arm-wince-mingw32ce-gdb" (arm-wince-mingw32ce binaries NEVER need the "cegcc.dll", so also the "arm-wince-mingw32ce-stub.exe" does not need it), unless you are trying to debug an arm-wince-cegcc binary (the arm-wince-cegcc generated binary DLL/EXE will need it, of course), but in this case you should switch back to the "arm-wince-cegcc-gdb".
    See Beware! need to install CeGCC DLL's first, and How can I find/trace any missing "DLL imports"?.
    Note, the magic error "126", hexadecimal "0x7e", known also as "ERROR_MOD_NOT_FOUND" and "The specified module could not be found", is defined in the "winerror.h".

    Table of Contents

  6. I get "Error creating process \gdb\MyProgram.exe, (error 126)." when I try to debug MyProgram.

    Your DLL/EXE could not be loaded/started. This usually means that, one (or more) DLLs, required by your DLL/EXE, are missing on your WinCE device (or, if all DLLs exist, one or more functions, which your program needs, are missing in some of them). You need to copy the required DLLs to the "\gdb" subdirectory, or to the "\Windows" subdirectory, or to any subdirectory that is present in the registry subkey "SystemPath", in the "HKEY_LOCAL_MACHINE\Loader" registry entry, on your WinCE device (any change to the "SystemPath" subkey itself does not take effect until the WinCE device is reset).
    See Beware! need to install CeGCC DLL's first, I get "GetLastError returns c1" when I try to use my DLL/EXE., and How can I find/trace any missing "DLL imports"?.
    Note, the magic error "126", hexadecimal "0x7e", known also as "ERROR_MOD_NOT_FOUND" and "The specified module could not be found", is defined in the "winerror.h".

    Table of Contents

  7. I get "Error while mapping shared library sections: coredll.dll: No such file or directory." when I try to debug MyProgram.

    So what? Does it really bother you THAT much? Haven't you got any more serious problems in your life?

    Table of Contents

  8. I get "No line number known for MyProcedure", or "(no debugging symbols found)", or "No symbol table is loaded. Use the 'file' command.", when I try to debug MyProgram.

    The best idea is to recompile your source code (with "-g" and without "-s" compiler flags), and then try to debug it once again.

    Table of Contents

  9. I get "/cygdrive/e/pedro/cegcc/0.50/src/mingw/crt3.c: No such file or directory.", or "Function 'main' not defined.", when I try to "list" the source code in the debugger (and who's that mysterious Don Pedro anyhow?).

    You get this error message because, the debugger tries to "list" the source code for the "program entry point routine", which it apparently cannot locate in your source code.
    Most probably, you're trying to debug an application which is a WinCE GUI (Graphical User Interface) application. The normal user's startup routine for such an application is called "WinMain". However, the "standard" entry point, for C/C++ language programs, is the "main". So, CeGCC implements a special glue module which automatically defines the "main" function for you, which then calls your "WinMain" routine.
    The solution is simple, just ask the debugger to "list WinMain", and you should immediately see your source code, unless you have forgotten to provide the debugging symbols.
    Note also that, when you compile a program that has the "main" routine of its own, then the automatic CeGCC "main" module is simply not used. In this case, you should never get such an error message, unless you have forgotten to provide the debugging symbols (try to "list main"), of course.
    See Startup and termination of WinCE programs.
    Last, but not least, that mysterious Don Pedro is the one whoem you own a big tribute, for the possiblility to run your CeGCC binary distribution. He's the one who prepared it for you.

    Table of Contents

  10. Why is my "arm-wince-mingw32ce-g++" compiled DLL/EXE so large?

    First, let me explain, why I am taking about the "arm-wince-mingw32ce-g++" compiler only, and not about the "arm-wince-cegcc-g++". The reason is simple. The "arm-wince-mingw32ce" target ALWAYS STATICALLY LINKS the stdc++ library into your every DLL/EXE binary. This may cause some really LARGE PARTS of this library to be INCLUDED in EACH of your DLL/EXE. You aks why? So do I! Apparently, it is the conseqence of the fact that, this target comes from the MinGW project, and that's how they do it. The "arm-wince-cegcc" target, on the other hand, uses DYNAMICALLY LINKED stdc++ library, by default (of course, Beware! need to install CeGCC DLL's first).
    So, let us now try to get the lowest possible size of your "arm-wince-mingw32ce-g++" compiled binaries. Let us create a very dumb "MyProgram.cpp", which contains just "int main(void) { return 0; }".

    Last, but not least, you can, of course, use the above advices to minimize the size of your "arm-wince-mingw32ce-gcc" generated DLL/EXE binaries, too (i.e. when you compile any C source code, except for the Standard Template Library advice, which is C++ specific).

    Table of Contents

  11. The arm-wince-mingw32ce compiler complains about undeclared identifier 'SOME_WIN_CE_IDENTIFIER'.

    First, make sure that you properly define the "_WIN32_IE" and the "_WIN32_WCE" macros , while compiling your source code (in order to tell the compiler which version of WinCE you're using).
    If you do, then it's quite possible that you've hit a CeGCC bug.
    Indeed, we don't have all the macros we should have. Our include files ("/opt/mingw32ce/arm-wince-mingw32ce/include/*") are inherited from other projects (e.g. MinGW). They're very good, but they tend to lack some WinCE specific stuff (well, WinCE is not their focus). A patch for our include files would be very welcome. The good sources for this information are (in this order):

    A bad source for such information is a copy of a Microsoft include file - that's copyrighted.
    In any case, please, do inform us about the missing identifier (regardless whether you were able to fix it, or not), using either the CeGCC Tracker system, and/or the cegcc-devel mailing list.

    Table of Contents

  12. The arm-wince-mingw32ce linker complains about undefined reference to 'SomeWinCeFunctionW' (and what's that "W" suffix appended to the function's name?).

    First, make sure that you properly define the "_WIN32_IE" and the "_WIN32_WCE" macros , while compiling your source code (in order to tell the compiler which version of WinCE you're using).
    If you do, then it's quite possible that you've hit a CeGCC bug.
    In general, because the Microsoft Windows System comes in so many flavours, there exist two mysterious suffixes, "A" and "W", which may get appended to function names. They directly correspond to the "ASCII" and the "Wide-Character" versions of the Windows API. The system include files are meant to automatically map a function name into a function with an added "A" or "W" to its name, depending on whether the "UNICODE" macro is defined, or not. For WinCE, however, the "UNICODE" should always be defined, as WinCE supports only that part of the API. Hence, there is no need to append the "W" suffix in this case (and it should not be present). Our include files ("/opt/mingw32ce/arm-wince-mingw32ce/include/*") are inherited from other projects (e.g. MinGW). They're very good, but they tend to lack some WinCE specific stuff (well, WinCE is not their focus).
    By running "arm-wince-mingw32ce-strings" on the right library file ("/opt/mingw32ce/arm-wince-mingw32ce/lib/*.a"), you can check whether the "SomeWinCeFunction" is present in there. If it is not there, then we need to implement this function. If it is present, however, then it usually requires just some slight modifications of one of our include files (you should then immediately be able to use this function, no further steps required). The fix is to "#ifdef" the function's prototype, in the appropriate header file, with "_WIN32_WCE", so that this function is always declared as "SomeWinCeFunction", instead of the non-WinCE "SomeWinCeFunctionA" + "SomeWinCeFunctionW" pair (which also depends on the "UNICODE" macro). See, for example, any other function, which is present in the same header file as "SomeWinCeFunction", in order to learn what needs to be done. A patch for our include files would be very welcome.
    In any case, please, do inform us about this problem (regardless whether you were able to fix it, or not), using either the CeGCC Tracker system, and/or the cegcc-devel mailing list.

    Table of Contents

  13. How can I find/trace any missing "DLL imports"?

    Different variations of Windows CE based systems come with different sets of functions implemented in the system provided default DLLs, and with partially different sets of system provided default DLLs (even when their kernel versions match). Hence, it sometimes happens that a user added DLL / EXE will not run on the user's system, just because it misses a specific function to be imported from some specific system default DLL, or even the required DLL itself does not exist at all on the user's system.
    How can one find/trace any missing "DLL imports"?
    You can find the ultimate answer below!

    And voilà, you can use the Dependency Walker to trace your problems!
    There is still one thing, I need to mention here. As of today, Sun, Nov 11, 2007, the Dependency Walker has some problems with binaries (DLL/EXE) generated by the CeGCC-0.50 release (and earlier, I believe). The problem is related to the DLL names "encoded" inside of the CeGCC generated DLL/EXE files. All these names miss the ".dll" file name extension. As a result, the Dependency Walker seeks for files named "DllName" (which do NOT exist) instead of "DllName.dll" (which, hopefully, DO exist). A temporary solution is to keep a copy of every "DllName.dll" file as a "DllName" file (note, you do NOT need these copies on your WinCE device, just on the PC).
    For the completeness of this description, let me add the following.

    Table of Contents

  14. I get "GetLastError returns c1" when I try to use my DLL/EXE.

    Your DLL/EXE could not be loaded/started. Are you mistakenly trying to run a PC Windows (x86/x64) DLL/EXE on your WinCE device? If not (i.e. you are sure this is really a WinCE ARM binary), then this usually means that one or more functions, which your program needs, are missing in some system DLLs, or even that one or more required DLLs are missing at all (well, you might have also forgotten to copy some DLLs, that came with your program, to your WinCE device, for example). In such case, one gets a mysterious message "'MyProgram' is not a valid Windows CE application", often bundled with a mysterious error message "GetLastError returns c1". The "0xc1", decimal "193", error is called "ERROR_BAD_EXE_FORMAT". It is defined in the "winerror.h" file.
    See How can I find/trace any missing "DLL imports"?

    Table of Contents

  15. I get "ERROR_BAD_EXE_FORMAT" when I try to use my DLL/EXE.

    That is just another form of the message "GetLastError returns c1".

    Table of Contents

  16. I get "'MyProgram' is not a valid Windows CE application" when I try to run MyProgram.

    That is just another form of the message "GetLastError returns c1".

    Table of Contents

  17. Need More Informations?

    See the CeGCC Documentation.

    Table of Contents

  18. DLL doesn't work with Windows Mobile 6.1

    Memory management changes in Windows Mobile 6.1 cause some DLLs not to load. It has been suggested (see this blog that the underlying problem is a writable code section in the DLL, other reports suggest that the DLL size may be an issue.

    The workaround or solution (I'm not sure what to call it) that we have is to restrict this DLL to Slot 0 by adding the following registry key: 

           [HKEY_LOCAL_MACHINE\System\Loader\LoadModuleLow] "MyDll.dll"=dword:1
    Obviously you need to change "MyDll" into the name of the DLL that causes the problem.

    Please note that using the this approach will force your entire DLL into Slot 0 and, it may prevent other modules from loading in that slot. Therefore, the above registry setting should be used with caution.

    Table of Contents

  19. Who's to be plead guilty for all that crap that I had to read in here?

    Well, many sources contributed, but, the main blame (at least, for the time being) should definitely be put on Jacek M. Holeczek, who got them (in here) together.

    Table of Contents

Information

Support
Powered by Sourceforge.net