Re: Header files that conflict with UNIX headers
--- David Elliott <[EMAIL PROTECTED]> wrote: > > This is probably just for your information, but > as I > > understand it. > > > > crtdll.dll only came with the very first version > of > > Windows 95, all subsequent version of Win95 (A, B, > C, > > OSR2, OSR2a, etc) either didn't have it at all, or > had > > msvcrt.dll > > > > Umm, negative. CRTDLL is still included in Windows > 98SE. However I think > you may be right that it is not used by anything, > but MSVCRT is used > instead. According to MSDN, MSVC(++) 6 links > against one of 6 C runtime > libraries. The first two are release and debug > versions of a > STATICLY LINKED LIBC(D).LIB which are not MT safe. > The next two are release > and debug versions of another staticly linked, but > MT safe LIBCMT(D).LIB. > Finally, there are the MSVCRT(D).LIB import > libraries for MSVCRT.DLL. No > where does it mention CRTDLL. Yeah... Sorry got a little mixed-up there. The problem we had was missing the msvcrt (assuming to was installed by Windows, when infact it's not, in the case of a First version of Windows 95). Also, another difference I believe I've heard before is that MSVCRT.DLL bring MS closer to having a POSIX 'compatible' run-time library. > AFAIK, CRTDLL is an older implementation that had > bugs relating to > MT safeness (i.e. It was supposed to be safe but > fell short in some cases). > IMHO implementing CRTDLL is not a very high > priority, while implementing a > reliable C library (MSVCRT) is. However, if it > works out that the > MSVCRT implementation can be used to implement most > or all of CRTDLL, then > I think that would be a reasonable thing to do. Agreed. I haven't seen many (if any) apps that use/need CRTDLL.DLL, but I have run into some apps that needed MSVCRT.DLL (and in some situations where it wasn't there and the installer didn't put it on the system either.) Sorry for the confusion, guess that'll teach me to shoot my mouth off... :( George __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/
Re: Header files that conflict with UNIX headers
George Boutwell wrote: > crtdll.dll only came with the very first version of > Windows 95, all subsequent version of Win95 (A, B, C, > OSR2, OSR2a, etc) either didn't have it at all, or had > msvcrt.dll Luckily for this discussion, I had to blow away my C: partition last night and reinstall Win98 (gold retail version). It includes CRTDLL.DLL in WINDOWS\SYSTEM, dated May 11, 1998 (same as the other default system DLLs for Win98 gold retail). MSVCRT is also included of course, since Internet Explorer needs it. -Ian Schmidt [EMAIL PROTECTED]
Re: Header files that conflict with UNIX headers
George Boutwell wrote: > --- Francois Gouget <[EMAIL PROTECTED]> wrote: > >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'. > > This is probably just for your information, but as I > understand it. > > crtdll.dll only came with the very first version of > Windows 95, all subsequent version of Win95 (A, B, C, > OSR2, OSR2a, etc) either didn't have it at all, or had > msvcrt.dll > Umm, negative. CRTDLL is still included in Windows 98SE. However I think you may be right that it is not used by anything, but MSVCRT is used instead. According to MSDN, MSVC(++) 6 links against one of 6 C runtime libraries. The first two are release and debug versions of a STATICLY LINKED LIBC(D).LIB which are not MT safe. The next two are release and debug versions of another staticly linked, but MT safe LIBCMT(D).LIB. Finally, there are the MSVCRT(D).LIB import libraries for MSVCRT.DLL. No where does it mention CRTDLL. See http://msdn.microsoft.com/library/periodic/period99/win320799.htm for more details. > > Not sure what effect that has on how much > support/non-support Wine/Winelib should have for > crtdll.dll > AFAIK, CRTDLL is an older implementation that had bugs relating to MT safeness (i.e. It was supposed to be safe but fell short in some cases). IMHO implementing CRTDLL is not a very high priority, while implementing a reliable C library (MSVCRT) is. However, if it works out that the MSVCRT implementation can be used to implement most or all of CRTDLL, then I think that would be a reasonable thing to do. I am going to go ahead and start implementing MSVCRT so it can be used by winelib. -Dave
Re: Header files that conflict with UNIX headers
--- Francois Gouget <[EMAIL PROTECTED]> wrote: >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'. This is probably just for your information, but as I understand it. crtdll.dll only came with the very first version of Windows 95, all subsequent version of Win95 (A, B, C, OSR2, OSR2a, etc) either didn't have it at all, or had msvcrt.dll Not sure what effect that has on how much support/non-support Wine/Winelib should have for crtdll.dll HTH, George __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
[Fwd: Header files that conflict with UNIX headers]
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 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 h, 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 >
Re: Header files that conflict with UNIX headers (fwd)
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 h, 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/h
Re: Header files that conflict with UNIX headers
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". However, newer versions of windows include it (at least it is in my 98SE cab files, and I think IE uses it). Although if one installed IE, then it would presumably install MSVCRT.DLL, and since IE is free for download, no one has yet done MSVCRT. At least that is my understanding of the situation. I have already looked at MSDN, and noticed that all new windows development seems to link against MSVCRT and not CRTDLL (like you mention). And yet CRTDLL is included in Wine because it came with Win95. This situation seems to be entirely bass ackwards for Winelib development. > > > 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'. > Yes, I agree. I like the names you are using too. >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. > Okay, that's what I thought. This is probably not very ideal for porting source seeing as how this is definitely going to require changes to the apps source. > > * 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. > We want to use libmsvcrt.so and implement MSVCRT. CRTDLL seems to be deprecated by Microsoft, and I have heard it is not very threadsafe, and I remember Alexandre saying that if a function is documented as not being threadsafe there shouldn't be additional overhead to make it threadsafe. However, supposedly CRTDLL is /supposed/ to be threadsafe, it's just that it isn't very much so in practice. At least that is what I gather from discussion on this list and from MSDN. It does export funtions like _beginthread. Personally I feel that sharing the CRTDLL implementation with MSVCRT would be better than specifically writing a non-threadsafe version of a function for CRTDLL. > > * '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. > > Notes: > * Unicode >We s
Re: Header files that conflict with UNIX headers
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
Header files that conflict with UNIX headers
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
