Hi,
David Elliott wrote:
[...]
> Are Winelib programs also supposed to use the wine CRTDLL?
Yes and no. They need a C library (badly).
Frankly I've never used 'crtdll.dll' and don't know it very well. All
I know is that it seems very similar to a C library except I'm not sure
who is supposed to use it. All the windows programs I've worked on/know
of use the standard 'msvcrt.dll'. And all the 'C library' headers in the
Windows directory are for 'msvcrt.dll'.
> 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.
Yes, we'll need 'our' C library headers for WineLib programs, one
day. I've given some (_some_) thought on that. Here's a dump of how I
see things currently. Keep in mind that it will need to be further
discussed and refined.
First we must put these headers 'out of the way' so that their use is
optional. There are multiple reasons for that the most important being
that we still need to be able to get access to the native (unix) headers
for compiling Wine. The best seems to be a subdirectory of 'include'.
Then I think we should have three different configurations:
* native C library - Unix semantics
This is what we currently have. The WineLib application compiles with
the native (unix) headers, and links with the native C library. The
semantics of all the C library functions is therefore the Unix
semantics: fopen takes a Unix path, does not understand O_TEXT, etc.
* MSVCRT C library - Windows semantics
With this solution we provide C headers that are compatible with
those of Microsoft. We provide them in 'include/msvcrt' and the user
puts '-I$(WINE_ROOT)/msvcrt' in his include path. The WineLib
application is linked with a library called 'libmsvcrt.so' in such a way
that the he actually calls the C functions of this library rather than
those of the native C library (playing with the link order and no-sys
library options and such I guess). I say 'libmsvcrt.so' because that's
what I know. Maybe 'libcrtdll.so' would work too. The semantics of the
functions implemented by this library are the Windows semantics: fopen
takes a dos path and recognises O_TEXT, we implement _beginthread and
friends, etc.
* 'Mixed' C library - Unix semantics
This is an intermediate solution. The semantics is that of Unix like
in the 'native C library' case. But we provide a specially designed set
of headers to ease compilation:
- macros map things like '_hypot' to 'hypot'
- macros provide replacements for things like _itoa
- macros fake support for 'O_TEXT'
- maybe some macros would map an API to a CRTDLL_xxx function
- provide additional headers like 'direct.h'
- maybe approximate a little bit: map _flushall to sync
- etc.
The headers would be in 'include/mixedcrt' and a WineLib application
would link with the native C library and possibly with crtdll if it uses
APIs that have been remapped to one of the CRTDLL_xxx functions.
The important thing here is: 'Unix semantics' plus some compatibility
features.
Notes:
* Unicode
We should provide the appropriate prototypes so that it works in the
'MSVCRT C library' case. For the other two solutions Unicode will not be
supported (because of the 2 vs. 4 chars difference).
* Thread safeness
Again the MSVCRT solution should be thread safe because it is on
Windows. For the other two it all depends on the native C library, i.e.
it's most likely not thread safe.
* This scheme leaves the door open for adding other C library
implementations. If Borland has their own slightly different C library
then we add the corresponding headers in 'include/bcrt' and provide
another library.
I have actually implemented some of the headers for the 'Mixed C
library' solution. I attached a tarball containing the new files.
--
Francois Gouget
[EMAIL PROTECTED]
mixedcrt.tar.gz
