Damn, I sent it to the wrong list! I shouldn't get up so early!
David Elliott wrote:
>
> Francois Gouget wrote:
>
> > 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'.
> >
>
> Yeah, and Wine doesn't even provide MSVCRT because "Applications will install
> it".
It is true that applications should install msvcrt themselves. And it
is reasonable strategy not to implement it in Wine. But this strategy
does not work with WineLib. The C library is too commonly used and too
important.
[...]
> > Then I think we should have three different configurations:
> >
> > * native C library - Unix semantics
[...]
> > * MSVCRT C library - Windows semantics
[...]
> > * '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.
> >
>
> So basically if it's implemented by the libc use it, but if it's not then use the
> MSVCRT implementation.
Just a slight adjustment. The operative word here is 'Unix
semantics'. So eventhough 'sopen' is not implemented in the native C
library we cannot take that of msvcrt because it would provide a Windows
semantics: windows paths. So basically in such a case I would say: too
bad, modify your source anyway (unless someone finds a creative
solution).
>
> >
> > 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).
> >
>
> This answers the question I was about to ask. I assume if a function is
> implemented by the native libc then we go with the native libc implementation
> since it would be rather hard to include a UNIX header leaving out the parts that
> would conflict.
It would be possible to remove parts of the C library. It's not in my
headers because I did not have this problem but it's all done so that
you can have something before you include the native header :-)
/*
* Extinguish
*/
#define wcsdup do_not_call_wcsdup
...
/*
* Embrace
*/
... include the native header here
/*
* Extinguish (again)
*/
#undef wcsdup
...
/*
* Extend
*/
#define wcsdup(a) ....
...
> > * 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.
> >
>
> Aren't all the glibc's threadsafe? Especially with Wine exporting the pthreads
> primitives? Is anyone still living in the darkages with non-threadsafe libc
> 5???
I'm not entirely sure. The problem is with functions that return data
in a static buffer, like hmmmm, ctime. In some Unix C libraries the
regular function is not threadsafe and if you want something that is
threadsafe then you should call xxx_r (different signature) instead. Of
course maybe now they all rely on some form of TLS.
[...]
> It is my understanding that when compiling Winelib programs __WINE__ is not
> supposed to be defined, but when compiling Wine itself, it is.
Yes. And usually when compiling a WineLib application it is WINELIB
that is defined. But in the headers it's better to entirely rely on
__WINE__.
> So the headers
> could use that to determine whether they should name things with a MSVCRT_ prefix
> (when compiling wine) or not (when compiling apps in MSVCRT mode).
Yes. This should work.
> I am not entirely sure how mixed mode should be handled. I originally thought of
> simply straight-out using libc functions when available and using the
> MSVCRT provided implementation when not. I was thinking of making the mixed-mode
> headers actually #include "../msvcrt/headername.h" with something defined that
> would make them only provide definitions for certain functions. However, it
> occurred to me that the implementations of several functions will be different
> for the two cases. And looking at your examples, Macros using the native libc's
> functionality would be a much better solution. When it all boils down to it,
> very few things in mixed-mode should actually be imported from MSVCRT, especially
> if you consider things like how errno is handled, you would want to update the
> native UNIX errno, whereas for a clean implementation for the emulator and for
> winelib apps using MSVCRT mode you would want to have your own errno. In fact,
> the only functions you could reliably import would be simple one or two line
> jobs, and that could be better done with a macro anyway.
Yes, for mixed mode I would prefer not to use msvcrt at all, although
it may be necessary to make an exception for some functions so that we
can take them from crtdll. The goal would be that in most cases you link
with the native C library and that's it.
Mixed mode should mostly provide syntactic sugar.
> I did think of one solution to the linking problem: If there was a library like
> libobfuscatedmsvcrt.so that imported the real names from msvcrt (that is, was
> linked against MSVCRT) and exported them with an MSVCRT_ prefix, then the headers
> could use things like #define malloc(x) MSVCRT_malloc(x) and prototype the
> functions with the MSVCRT_ prefix. Therefore the unresolved symbols all have the
> MSVCRT_ preifx. The app would then be linked against the
> libobfuscatedmsvcrt.so.
I'm not sure about the details of the linking aspects. I think
there's persons more knowledgeable than me for this subject. Also we
should probably do some testing with a simple case to determine how
various compilers behave, whether we need the prefix, etc.
> However IIRC .so files can't or shouldn't be linked
> against other .so's in UNIX (although it is acceptable for a DLL to import from
> other DLLs in windows), so that is probably not a very good idea, but I am
> throwing it out for anyone to consider anyway.
I believe linking a .so with another works. Actually it's even one
item in my WineLib todo list: currently if you link with ole32 you also
need to link with advapi32, rpcrt4, etc. because ole32 uses all these.
But I don't think that is necessary on Windows. I would like to get to a
point where we can simply link with ole32 without having to also specify
all the dlls that it depends on.
[...]
> _errno is a function that returns a pointer to errno, so:
> #define _errno() &errno
> would be the correct definition for the mixed-mode headers. For the
Aaaah, errno. Yes I remember. I had some problems with it a long time
ago when porting a Unix application to Windows!
I agree for the mixed-mode _errno definition.
[...]
> Well, anyway, it is way past my bedtime now (6am) so I am going to hit the sack.
> Hopefully you will have replied to this by the time I wake up!
I just got up and I guess I failed (unless you get up at 4pm)!
[...]
--
Francois Gouget
[EMAIL PROTECTED]
