[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    [Fwd: Header files that conflict with UNIX headers]
From:       David Elliott <dfe () infinite-internet ! net>
Date:       2000-10-28 23:14:21
[Download RAW message or body]

Forwarding this to Wine-devel since I originally sent it to wine-patches
because I just hit "Reply-All" and didn't bother to check.

I agree with Francois, I really shouldn't get up before like 5 or so, 4 is
too early ;-) (pm that is)

-Dave



X-Mozilla-Status2: 00000000
Message-ID: <39FB564D.F8893140@infinite-internet.net>
Date: Sat, 28 Oct 2000 17:42:21 -0500
From: David Elliott <dfe@infinite-internet.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18-0_biscuit_4-w4l.i686 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: fgouget@codeweavers.com
CC: wine-patches@winehq.com
Subject: Re: Header files that conflict with UNIX headers
References: <39FA4F6D.2F19B898@infinite-internet.net> <39FA868C.FCD93EF4@free.fr> \
                <39FAB5DF.A0E76E77@infinite-internet.net> <39FB33EC.45FDAF8F@free.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Francois Gouget wrote:

> David Elliott wrote:
> > 
> > Francois Gouget wrote:
> > 
> > > Hi,
> > > 
> > > David Elliott wrote:

[SNIP]

> 
> > 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.
> 

Actually, that was the whole point, that not providing MSVCRT is a really bad thing
for Winelib.

[SNIP]

> > > 
> > > * 'Mixed' C library - Unix semantics
> > > 

[SNIP]

> 
> > 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).
> 

Right, I qualify this later on realizing that just using the MSVCRT implementation
probably won't work for most functions.  See below.

[SNIP]

> > 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 :-)
> 

[SNIP Extinguish, Embrace, Extinguish, Extend code]

I am guessing that that is probably not very portable, but I haven't looked at other
libc headers (other than glibc).

[SNIP]

> > 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.
> 

That is an issue.  I was reading MSDN and it appears that all these non-threadsafe
functions use TLS in MSVCRT.  But on UNIX IIRC they are still non-threadsafe because
they have been replaced by the xxx_r versions.  However it is fairly trivial to use
the xxx_r function to provide the threadsafe implementation of the xxx function given
some space on the 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.
> 

Okay, good, I liked the idea too.  However, see below the stuff about obfuscating the
names on purpose for easier linking.

[SNIP]

> 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.
> 

Perfect.  I would go so far as to say you should have another smaller library, maybe
libwinemsvcrt.so (or maybe even just a static libary) that would provide only the
functions that we don't want to/can't get from the native libc.

> 
> > 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.
> 

It's really kind of hackish.  Hmm... actually, come to think of it you could maybe \
use some objcopy trickery to simply change the names of all the exports.  Or you \
could simply sed 's/^@ cdecl /@ cdecl MSVCRT_/  the specfile and generate the
libobfuscatedmsvcrt.so.  The idea here is that all the MSVCRT exports will have an
MSVCRT_ prefix and that therefore it now becomes a matter of correct code in a header
file as opposed to correct link order.

For example, if you have a UNIX stdlib.h with this definition:
int fprintf( FILE *stream, const char *format, ...);

Then in the msvcrt/stdlib.h you would have:
int MSVCRT_fprintf( MSVCRT_FILE *stream, const char *format, ...);
#define fprintf(...) MSVCRT_fprintf(...)   /* Sorry, I forgot the syntax of varargs
macros, but you get the idea */
#define FILE MSVCRT_FILE

The idea here is that after the application's code is run through the preprocessor it
will have the MSVCRT_ prefix appended due to all the #defines.  So now if you want to
use a native libc implementation of a function, you simply don't #define function
MSVCRT_function, and provide the real prototype from the header and it will go \
looking for the real libc definition.  Another advantage is that in the msvcrt header \
files there will simply be a section at the end that looks like:

#ifndef __WINE__
#define FILE MSVCRT_FILE
#define fprintf(...) MSVCRT_fprintf(...)
#define some_other_function(...) MSVCRT_some_other_function(...)
/* And so on and so forth */
#endif

This system might be more useful for mixed-mode /IF/ we actually wanted to use
functions out of MSVCRT, but I think you are right and since UNIX semantics need to \
be followed in mixed mode, very little will be useable.

However, it does solve is the link order juggling, and also when the compiler
generatees warnings it will refer to the MSVCRT_ name and thus it will be readily
identifiable which function is being talked about.  Consider the added benefit of
cleaner looking headers (see above) and it starts to look like a really good idea.
I actually didn't think this was a good idea at first, but I am starting to like it a
bit more.

> 
> > 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.
> 

Right, I think that that is caused by the fact that in windows you are allowed to
import another DLL, but in UNIX you are not, therefore we have to specifically
implement that behavior like you are saying.  It's a moot point anyway, because if \
you look above I noted that you could simply use two different specfiles to \
accomplish it in a cleaner way.

> 
> [...]
> > _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.
> 

Hmm.. porting a UNIX application to Windows (the reverse of Wine) shouldn't have
problems with errno, as it is defined as *_errno() which is still an modifiable
lvalue.  And since _errno() returns the pointer to the variable in TLS, it's even
threadsafe too.  Or it is supposed to be in any case.

> 
> [...]
> > 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)!
> 

No, you actually succeeded ;-)  I didn't wake up until about 4:10, it's saturday and
I was stupid and satyed up until 8am.  And I was thinking you were in a much \
different timezone, when it would appear you are now in the same timezone as me \
(along with everyone else at CW).

-Dave



[prev in list] [next in list] [prev in thread] [next in thread]