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