That right,
As of today, the patch I've sent a few days ago to the list has been integrated into the tree. Turns out that all those "#include <search.h>" were not needed, so the patch was even smaller than I thought! :)
There are some things that need to go into the Wine tree before you can play with the wxWindows thing: 1. Dan's patch that fixes the RECT definition 2. Francois' patch that fixes winsock.h 3. My patch that adds io.h 4. My patch that adds wineg++ 5. My patch for tchar.h I think that's it... (I can't quite tell because I have the big NONAMELESS* patch in my tree).
Alexandre, the wxWindows folks are eager to play with it, and have asked me to let them know when they can do so. Not a big deal, but if there are problems with any of these, please let me know so I can address them.
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...]
- Francois' patch that fixes winsock.h
I'll try to complete it shortly.
- My patch that adds io.h
I'm not sure this one is a good idea. We already have an io.h in the msvcrt directory as we need it for compatibility with msvcrt. So with your patch we would have:
include/io.h include/msvcrt/io.h
That seems like an include order nightmare. Furthermore your header only contains: int access(const char *__path, int __amode);
If you use that function you will have to link with the msvcrt. Ortherwise your Winelib application is going to call the glibc access function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it seems like you might as well use the msvcrt headers...
On January 7, 2003 02:09 pm, Francois Gouget wrote:
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...]
- Francois' patch that fixes winsock.h
I'll try to complete it shortly.
- My patch that adds io.h
I'm not sure this one is a good idea. We already have an io.h in the msvcrt directory as we need it for compatibility with msvcrt. So with your patch we would have:
include/io.h include/msvcrt/io.h
That seems like an include order nightmare. Furthermore your header only contains: int access(const char *__path, int __amode);
If you use that function you will have to link with the msvcrt. Ortherwise your Winelib application is going to call the glibc access function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it seems like you might as well use the msvcrt headers...
Sorry about my previous attempt, I've pressed Send by mistake. And I've learned you can't stop KMail from sending... :)
On January 7, 2003 02:09 pm, Francois Gouget wrote:
include/io.h include/msvcrt/io.h
That seems like an include order nightmare. Furthermore your header only contains: int access(const char *__path, int __amode);
It's a big problematic, but not much. winegcc get this right anyway, and I can't see how it can be a problem: if you use msvcrt, you first have to include those headers. If not, they are not in the search path, so they don't exist. What scenario to you forsee where this can be a problem.
If you use that function you will have to link with the msvcrt. Ortherwise your Winelib application is going to call the glibc access function which will choke on the Windows paths 'c:\Temp\xxx.tmp'. So it seems like you might as well use the msvcrt headers...
That's the user's choice. We need to support io.h, mingw has it, cygwin has it. If we provide it only in msvcrt, we force everybody to use msvcrt, which is not right IMO.
Thing is, the cygwin io.h contains only these definitions:
extern long get_osfhandle(int); extern int setmode (int __fd, int __mode); int access(const char *__path, int __amode);
You can check it out at: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/io.h?...
Since program not using msvcrt expect only these funtions, that's what we need to provide. I don't know what get_osfhandle(), and setmode() are (they are not standard Unix functions), I've added included only access().
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
Sorry about my previous attempt, I've pressed Send by mistake. And I've learned you can't stop KMail from sending... :)
On January 7, 2003 02:09 pm, Francois Gouget wrote:
include/io.h include/msvcrt/io.h
That seems like an include order nightmare. Furthermore your header only contains: int access(const char *__path, int __amode);
It's a big problematic, but not much. winegcc get this right anyway, and I can't see how it can be a problem: if you use msvcrt, you first have to include those headers. If not, they are not in the search path, so they don't exist. What scenario to you forsee where this can be a problem.
The case where a developper mistakenly does: -I/usr/include/wine -I/usr/include/wine/msvcrt
And then wonders why things don't compile...
[...]
Thing is, the cygwin io.h contains only these definitions:
extern long get_osfhandle(int); extern int setmode (int __fd, int __mode); int access(const char *__path, int __amode);
Yes, but Mingw applications are Windows applications and thus hey use Windows paths (c:\Windows\wininit.ini) and link with a C library that understands these Windows paths. But that will definitely not work in Wine unless you link with msvcrt. There's no way around that.
That's the user's choice. We need to support io.h, mingw has it, cygwin has it. If we provide it only in msvcrt, we force everybody to use msvcrt, which is not right IMO.
For Cygwin the situation is different (symetrical to the Winlib one in fact). The applications are Unix applications that use Unix paths (/windows/wininit.ini) on Windows and thus have to link with the Cygwin C library rather than the system 'native' C library (msvcrt). (or crtdll, but no one on Windows uses crtdll)
For exactly the same reasons, Winelib applications, using Windows paths (c:\Windows\wininit.ini) on Unix have to link with the Wine C library (msvcrt) rather than the native one (glibc) in order to call functions with these paths.
[...]
Since program not using msvcrt expect only these funtions, that's what we need to provide. I don't know what get_osfhandle(), and setmode() are (they are not standard Unix functions), I've added included only access().
They are both implemented in msvcrt.
On January 7, 2003 03:00 pm, Francois Gouget wrote:
For exactly the same reasons, Winelib applications, using Windows paths (c:\Windows\wininit.ini) on Unix have to link with the Wine C library (msvcrt) rather than the native one (glibc) in order to call functions with these paths.
But this is missing the point. What you are saying is that we should not allow people to link to the native libc, because you think that the msvcrt behavior is more correct. I beg to differ.
If people choose to ling to glibc, they must be aware the apps will not work with Windows paths. It's their choice.
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
On January 7, 2003 03:00 pm, Francois Gouget wrote:
For exactly the same reasons, Winelib applications, using Windows paths (c:\Windows\wininit.ini) on Unix have to link with the Wine C library (msvcrt) rather than the native one (glibc) in order to call functions with these paths.
But this is missing the point. What you are saying is that we should not allow people to link to the native libc, because you think that the msvcrt behavior is more correct. I beg to differ.
If people choose to ling to glibc, they must be aware the apps will not work with Windows paths. It's their choice.
No. I contend that applications making use of access and other similar APIs in Winelib will not work at all unless they have been specifically designed for that case, in which case they should not be using io.h anyway. Thus for me adding this header has no value and will only cause trouble due to the confusion it introduces.
You contend that Windows applications calling the glibc access function will still work with no (related) modification (though you conceed they may only be partially functional), thus justifying the presence of io.h.
That's where we differ.
"Dimitrie O. Paun" dpaun@rogers.com writes:
That's the user's choice. We need to support io.h, mingw has it, cygwin has it. If we provide it only in msvcrt, we force everybody to use msvcrt, which is not right IMO.
IMO it is right. I would say this is a cygwin bug; cygwin is supposed to be Unix compatible, and under Unix access() is in unistd.h. So if the app needs access() it should include unistd.h; if it needs the other functions from io.h then it has to use msvcrt because they don't exist in the Unix libc.
On January 7, 2003 03:15 pm, Alexandre Julliard wrote:
IMO it is right. I would say this is a cygwin bug; cygwin is supposed to be Unix compatible, and under Unix access() is in unistd.h. So if the app needs access() it should include unistd.h; if it needs the other functions from io.h then it has to use msvcrt because they don't exist in the Unix libc.
Right -- I now see better where you guys come from.
Now, thing is, cygwin does include io.h, and apps expect it. You can make a good argument that it shouldn't, but it does.
I don't know much about their problem space, so I give them the benefit of the doubt that they knew what they were doing. In all honesty, I can also see a good argument for it being in cygwin, but this is besides the point -- the file is there, and apps depend on that.
I just want to say that it has been proved, time and again, that in the long term we are better off sticking to common practice. Every time we tried to cure worlds problems, we got bitten back. We have already so many battles to fight, do we want to take on this one?
"Dimitrie O. Paun" dpaun@rogers.com writes:
I don't know much about their problem space, so I give them the benefit of the doubt that they knew what they were doing. In all honesty, I can also see a good argument for it being in cygwin, but this is besides the point -- the file is there, and apps depend on that.
These apps are broken if they depend on io.h for access(). We cannot provide two different io.h in different directories, this will be a nightmare.
We don't have to be 100% compatible with any random source out there; we are not 100% compatible with msvc either. What we need is to provide a way to write code that works both on Wine and on the original platform, so that once you have made it portable you don't need further changes. In this case the solution is unistd.h.
On Wed, 8 Jan 2003, Dimitrie O. Paun wrote: [...]
Right -- I now see better where you guys come from.
Now, thing is, cygwin does include io.h, and apps expect it. You can make a good argument that it shouldn't, but it does.
Note that I'm not completely opposed to to a new io.h header but it should not be directly in 'include'. Since it's specific for cygwin compatibility it should go in 'include/cygwin' where it will do no harm to other people. So people who want/need Cygwin compatibility would add -I/wherever/include/cygwin to the include path just like people who need msvcrt compatibility add -I/wherever/include/msvcrt.
Now whether it is worth going to the trouble at this point I'm not convinced. Maybe if more headers surface. Btw, it clearly seems that Cygwin borrowed this header from msvcrt. So does it mean applications using this header are linking with the native Windows msvcrt library? Or did they replicate the msvcrt functionality in their C library?
Did they borrow other msvcrt headers?
On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: [...]
Since program not using msvcrt expect only these funtions, that's what we need to provide. I don't know what get_osfhandle(), and setmode() are (they are not standard Unix functions), I've added included only access().
get_osfhandle() takes a Windows file handle (HANDLE as returned by CreateFile) and returns a small int you can use with read, write, close, etc.
setmode() lets you set the default file opening more: either TEXT (with LF -> CR/LF conversion) or BINARY (no conversion).
I can see how get_osfhandle() can be useful for interoperability in Cygwin. setmode() seems of a more dubious value though (especially since it means they must have implemented the awful CR/LF conversion across their C library API (unless setmode() is nothing but a stub)).
On January 8, 2003 02:08 pm, Francois Gouget wrote:
I can see how get_osfhandle() can be useful for interoperability in Cygwin. setmode() seems of a more dubious value though (especially since it means they must have implemented the awful CR/LF conversion across their C library API (unless setmode() is nothing but a stub)).
get_osfhandle() seems useful in Wine as well, no? As for semode(), it can work both ways. A simple
#define setmode() do {} while(0)
seems to be a good first order approximation... Do we do the awful CR/LF conversion in msvcrt?
On Wed, 8 Jan 2003, Dimitrie O. Paun wrote:
On January 8, 2003 02:08 pm, Francois Gouget wrote:
I can see how get_osfhandle() can be useful for interoperability in Cygwin. setmode() seems of a more dubious value though (especially since it means they must have implemented the awful CR/LF conversion across their C library API (unless setmode() is nothing but a stub)).
get_osfhandle() seems useful in Wine as well, no?
Actually I got things reversed: * get_osfhandle() takes a C library file descriptor (fd) and returns a Win32 file handle (HANDLE). * open_osfhandle() is the one that takes the Win32 file handle (HANDLE) and returns a C library file descriptor (fd). I always get those two confused.
Both are implemented in Wine's msvcrt library which is where they belong since the C library file handle is specific to msvcrt, i.e. if you get an fd from msvcrt and give it to open from the glibc bad things will happen (error in the best case, reading/writing to the wrong file in the worst case).
There is similar functionality in Wine for Unix file descriptors which is provided by: wine_server_fd_to_handle and wine_server_handle_to_fd. But these work differently from the msvcrt ones.
As for semode(), it can work both ways. A simple
#define setmode() do {} while(0)
seems to be a good first order approximation...
Sure it's a hack that will let you compile the application. It will even run as long as it doesn't rely on that feature.
Do we do the awful CR/LF conversion in msvcrt?
Nope, it's a stub in msvcrt for now. However it will print a trace if called with a parameter it does not support, and unlike header hacks it can actually be made to work.
The better question is whether cygwin really implements setmode()... If no then the above hack is sufficient. Otherwise you will eventually need to: * implement a cygwin compatible C library and link cygwin applications with it * or link cygwin applications with the msvcrt (after improving it). This is quite likely to work * or modify the application during the port so that it does not rely on this functionality
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget