Hi all,
I am starting to work on CRTDLL implementing it on top of Windows calls
instead of UNIX.
As I understand it, Windows executables definitely need a working CRTDLL as
forwarding things like fopen to UNIX would not give the desired behavior.
Are Winelib programs also supposed to use the wine CRTDLL? If so then it's
necessary to provide headers like stdlib.h and math.h to Winelib programs
and to link the winelib programs against the wine crtdll instead of the
native libc. The problem I see with this is that it's feasible for a
winelib program to want to use the native libc instead of CRTDLL. Using the
native libc is the current behavior AFAIK.
It is not possible to put the headers into include/ because other wine code
will use them instead of the UNIX headers. Should they be placed in
something like include/wincrt? What directory should they be installed to?
How should we allow wine sourcecode to choose the use of the native files or
the provided files?
Currently things like FILE are defined as CRTDLL_FILE directly in the source
file instead of a seperate header. It will be desirable to allow the crtdll
source to include both the UNIX libc headers and parts of the Wine crtdll
headers. How should the wine crtdll headers look? Should they use some
preprocessor magic to allow them to be used by winelib programs (e.g. with
names like "FILE") and also by the wine source itself (e.g. with names like
"CRTDLL_FILE").
For now I am not providing any headers, just implementing the functions, but
I will if someone can tell me how it should be done.
As far as the CRTDLL implementation goes, I am currently implementing
CRTDLL with all of the functions and structures prefixed with CRTDLL_
(following the current trend). I am calling native libc functions when it
makes sense to do so (like most math functions).
I vaguely remember this being brought up before and the consensus being
something along the lines of libc functions should be used when available
and we can always create and link against another UNIX library to implement
functions that are not supported on all libcs rather than clutter the code
with tons of #ifdefs. I also vaguely remember that using the libc functions
is preferred because they are generally the best implementation of the
function. Obviously this does not hold true for things like fopen and
friends, but for things like math functions this should be fine.
Currently the crtdll.spec directly uses several libc functions, which I also
do not see any reason to change. If the function is implemented correctly
by the libc then use it. If wine or this crtdll code is to be ported to a
platform that does not have a libc, the aforementioned creation of another
library should be done to implement the function. It should be acceptable
for the CRTDLL to link against this library to provide the implementation of
the functions.
One notable concern was the handling of varargs functions. I believe that
the CRTDLL code should hanlde varargs in the style of the OS it is running
on and that winebuild should create a thunk layer for varargs functions on
platforms that require it. CRTDLL should not try to handle Windows format
varargs in its code. From the looks of it, it appears this is how things
are currently done, although Linux does not require this layer as its libc's
varargs handling is the same as Windows just like the other calling
conventions.
So, does my reasoning sound okay? What should be done with the headers?
-Dave
