This document describes the structure of the CeGCC/MinGW32ce directory tree
and of its modules.
By modules we mean the different softwares or their components,
which we assemble to create CeGCC and MinGW32ce.
Directory structure - src/
src/mingw
This directory's primary purpose is to hold the necessary startup code
and needed static code
to be able to use coredll.dll as only runtime.
You can consider src/mingw a gcc replacement for corelibc.lib
in other development tools.
Added to that, there are some other goodies.
src/mingw/mingwex
Mingwex holds the MinGW added extensions to add support for C99 and some POSIX functionality not found in COREDLL.
See http://www.mingw.org/MinGWiki/index.php/mingwex
Please don't just add stubs there.
Those are more harmful than good,
because if you do, an app using autoconf's AC_CHECK_FUNC will find it,
and instead of providing a proper replacement, will call the stubbed
one, which won't work obviously.
src/mingw/profile
src/mingw/mingwex/wince
This is where one places wince code that doesn't fit in the other mingwex dirs,
because the desktop versions of mingw don't need it. Keep in mind, that the
less we diverge from the upstream versions, the easiest we can pull from updates they have.
src/mingw/include
The headers in mingw/include correspond to the libc part of coredll.dll
(stdio.h, stdlib.h, etc, etc.).
This contrasts with src/w32api/include which holds headers corresponding to
win32 api definitions, there is no libc runtime stuff there.
The arm-wince-mingw32ce toolchain uses only the Windows CE DLLs,
the arm-wince-cegcc uses newlib, so it uses the corresponding newlib headers.
You can't (shouldn't) mix headers from newlib, and from mingw/include.
Take a look, there are headers with the same name,
for instance, there is a stdio.h in newlib,
and a stdio.h too in mingw/include, but they are incompatible. Usually
the headers from newlib are more complete, but
so is the c runtime support in newlib. The danger in mixing the two sets
is in that some (many/most) constants
and structures are completely different in the two.
Take for instance the stdio functions. The FILE struct (think fprintf,
fwrite, etc) is totally incompatible in the two. Sure, struct FILE
is (mostly) an opaque structure, but there are cases where an inline
function accesses its members directly. Take stdout for instance,
in newlib, it maps to something like '_impure_ptr->_stdout' (from heart,
so the names may be wrong), while in
mingw/include (mingw32ce), it maps to '_getstdfilex(1)'.
Now imagine a cegcc app, calling newlib's version of fprintf like so:
fprintf (stdout, "Look ma, I can crash!\n");
which after preprocessing, maps to:
fprintf (_getstdfilex(1), "Look ma, I can crash!\n");
If that doesn't crash, it will be pure luck.
src/w32api/include
This holds headers corresponding to
win32 api definitions, there is no std c runtime stuff there.
src/newlib
Newlib is a portable C library implementation.
We're using it to augment the arm-wince-cegcc toolset, because in many apps, the libc part of coredll is very limited.
src/newlib/newlib/libc/sys/wince
Our implementation of newlib is itself augmented with some Windows CE specific stuff.
Look here for more information regarging this layer. The very minimal unix-like layer provided by CeGCC.
Comparison to other libraries and modules
MSVCRT
This is Microsoft Visual C RunTime library, the runtime library currently most used in Windows NT/9x.
MSDN describes msvcrt.dll
here
as a multi-threaded dynamic link library (aka DLL).
In this page
it is further described as a system library that is intended for use by Windows itself,
but that you're allowed to use in applications.
Current versions of Windows CE use coredll.dll instead.