I installed mingw under Wine today, and aside from the EULA etc. showing up blank in the installer, it installed just fine. And it even compiles programs ok! Cool!
Unfortunately, mingw's gcc causes Wine to emit zillions of warnings like this:
Warning: L"/mingw/lib/gcc-lib/mingw32/specs" not accessible from a configured DOS drive
Seems like somehow Wine should have been able to avoid issuing that warning. Oh, ok, mingw could stick a drive letter on the path, or use \ as a dir separator, but it shouldn't have to, should it? - Dan
p.s. Here's the full set of warnings from one compile of one C file:
fixme:console:SetConsoleCtrlHandler (0x78010087,1) - no error checking or testing yet Warning: L"/mingw/lib/gcc-lib/mingw32/specs" not accessible from a configured DOS drive fixme:win32:PE_CreateModule Security directory ignored Warning: L"/mingw/lib/gcc-lib/mingw32/3.2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../include" not accessible from a configured DOS drive Warning: L"/mingw/include" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/include" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/include" not accessible from a configured DOS drive Warning: L"/usr/local/mingw32/include" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/as.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/as" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/as.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/as" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/as.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/as" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/as.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/as" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/as.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/as" not accessible from a configured DOS drive fixme:win32:PE_CreateModule Security directory ignored Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/collect2.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/collect2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/collect2.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/collect2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/collect2.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/collect2" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/collect2.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/collect2" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/collect2.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/collect2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/bin/mingw32/3.2/collect2.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/bin/mingw32/3.2/collect2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/bin/collect2.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/bin/collect2" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/crt2.o" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/crt2.o" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/lib/mingw32/3.2/crt2.o" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/lib/crt2.o" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/lib/mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../../mingw32/lib/." not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/../../../." not accessible from a configured DOS drive Warning: L"/lib/mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/usr/lib/mingw32/3.2/." not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/ld.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/ld" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/ld.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/3.2/ld" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/ld.exe" not accessible from a configured DOS drive Warning: L"/mingw/lib/gcc-lib/mingw32/ld" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/ld.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/3.2/ld" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/ld.exe" not accessible from a configured DOS drive Warning: L"/usr/lib/gcc/mingw32/ld" not accessible from a configured DOS drive fixme:win32:PE_CreateModule Security directory ignored Warning: L"/mingw/mingw32/lib/ldscripts" not accessible from a configured DOS drive
On February 24, 2003 12:22 am, Dan Kegel wrote:
Seems like somehow Wine should have been able to avoid issuing that warning. Oh, ok, mingw could stick a drive letter on the path, or use \ as a dir separator, but it shouldn't have to, should it?
In other words, you want to disable the warning? I personally don't have a problem with that, anyone cares to enlighten us on why that warning is there?
Dimitrie O. Paun wrote:
On February 24, 2003 12:22 am, Dan Kegel wrote:
Seems like somehow Wine should have been able to avoid issuing that warning. Oh, ok, mingw could stick a drive letter on the path, or use \ as a dir separator, but it shouldn't have to, should it?
In other words, you want to disable the warning? I personally don't have a problem with that, anyone cares to enlighten us on why that warning is there?
Mingw is referring to paths relative to drive C, and these paths just happen to look a lot like Unix paths. Wine obligingly tries to open them as Unix paths before trying them as DOS paths. And if Mingw were to try to open some path that accidentally exists both in my Unix root and in my fake C drive, Wine might open the wrong one.
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths. It's tempting to try living without that feature for a while. If it's not really used, we can get rid of it, and those warnings will vanish, too.
The code in question is:
static int DOSFS_GetPathDrive( LPCWSTR *name ) { int drive; LPCWSTR p = *name;
if (*p && (p[1] == ':')) { drive = toupperW(*p) - 'A'; *name += 2; } else if (*p == '/') /* Absolute Unix path? */ { if ((drive = DRIVE_FindDriveRootW( name )) == -1) { MESSAGE("Warning: %s not accessible from a configured DOS drive\n", debugstr_w(*name) ); /* Assume it really was a DOS name */ drive = DRIVE_GetCurrentDrive(); } }
The "Absolute Unix path?" heuristic works well for most software, but not for mingw. - Dan
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths.
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
Dimitrie O. Paun wrote:
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths.
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
Hmm, that's a good idea. Same kinds of errors could happen, but they're probably a bit less likely... - Dan
Dan Kegel wrote:
Dimitrie O. Paun wrote:
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths.
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
Hmm, that's a good idea. Same kinds of errors could happen, but they're probably a bit less likely...
- Dan
Seems to me the problem here is that mingw is passing these paths into Wine at all. The only apparent way to get to DOSFS_GetPathDrive is through DOSFS_GetFullName or DOSFS_GetShortPathName so either mingw is calling one of those functions with Unix path names or its calling some other Win32 API function with Unix path names which then calls one of those functions. But how would that work on Windows? Surely mingw should always convert unix paths to Windows paths *before* giving them to any Win32 function?
David
Seems to me the problem here is that mingw is passing these paths into Wine at all. The only apparent way to get to DOSFS_GetPathDrive is through DOSFS_GetFullName or DOSFS_GetShortPathName so either mingw is calling one of those functions with Unix path names or its calling some other Win32 API function with Unix path names which then calls one of those functions. But how would that work on Windows? Surely mingw should always convert unix paths to Windows paths *before* giving them to any Win32 function?
I have a feeling the Windows path handling routines are very flexible, and will accept unix style paths, I know you can use / instead of \ in paths and things usually still work. I guess some test cases would be needed.
David
David Fraser wrote:
Seems to me the problem here is that mingw is passing these paths into Wine at all. The only apparent way to get to DOSFS_GetPathDrive is through DOSFS_GetFullName or DOSFS_GetShortPathName so either mingw is calling one of those functions with Unix path names or its calling some other Win32 API function with Unix path names which then calls one of those functions. But how would that work on Windows? Surely mingw should always convert unix paths to Windows paths *before* giving them to any Win32 function?
These are 100% windows paths. No conversion is needed. Wine is just confused because Mingw is using the / path separator instead of the \ path separator. It may be a surprise to some, but that works A-OK in Windows. - Dan
On Sunday 23 February 2003 11:24 pm, Dimitrie O. Paun wrote:
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths.
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
If it just rejected unix paths I think it would break winedbg's ability to find source files, and who knows what else... but reversing the order as Dan recommends above should work AFAICS (not very :) )
Now all someone needs to do is build WINE on mingw running under WINE <g>
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
On Monday 24 February 2003 11:23 am, Steven Edwards wrote:
Now all someone needs to do is build WINE on mingw running under WINE <g>
Then we can say wine is "self hosting" ;)
Dimitrie O. Paun wrote:
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try so hard to understand Unix paths.
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as a (absolute) unix one otherwise it just returns the current drive. Changing this behavior is not simple and however annoying the message is it is correct.
AFAICT this function is internal only and only called by GetShortPathNameW. In order to change this behavior we would have to make changes to GetShortPathNameW so that it tries the path with the current drive first and then calls this (modified) function. After looking at the code for the last couple of hours I'm sure it could be done but I don't know if it is worth it.
At present I think that it would be better to change the message
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1)
{
- MESSAGE("Warning: %s not accessible from a configured DOS drive\n", debugstr_w(*name) );
+ WARN("failed to find %s as an absolute unix path mapped to configured DOS drive \n", + debugstr_w(*name) ); + WARN("assuming it was a really a DOS name") /* Assume it really was a DOS name */
drive = DRIVE_GetCurrentDrive();
}
Or something like that.
Tony Lambregts wrote:
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as a (absolute) unix one otherwise it just returns the current drive. Changing this behavior is not simple and however annoying the message is it is correct.
The message is correct, but Wine's behavior is not. I'm pretty sure you understand the issue, but for anyone still wondering: The problem is strictly theoretical at this point, but we should be aware of it in case somebody runs into it in the future. Here's the scenario: * user installs MinGW or some other app that's been ported to Win32 but uses Unix-style path separators for win32 directories * a path used by the program happens to exist both in the Windows filespace on drive C: (presumably this would be something installed by the app) and in the Unix filespace. For instance, the path /etc/blort/config might be a configuration file for a library used both on Linux and installed independently onto drive C: by the application. * The app tries to open the file on drive C:, and gets the file in Linux instead. Bang! The program crashes, or gives bad results.
... In order to change this behavior we would have to make changes to GetShortPathNameW so that it tries the path with the current drive first and then calls this (modified) function. After looking at the code for the last couple of hours I'm sure it could be done but I don't know if it is worth it.
Thanks for looking at it.
At present I think that it would be better to change the message
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1) {
MESSAGE("Warning: %s not accessible from a configured DOSdrive\n", debugstr_w(*name) );
WARN("failed to find %s as an absolute unix path mapped toconfigured DOS drive \n",
debugstr_w(*name) );WARN("assuming it was a really a DOS name") /* Assume it really was a DOS name */ drive = DRIVE_GetCurrentDrive(); }Or something like that.
Or something like that, yeah. We want to display a hint that there might be a misinterpretation of a DOS path as a Unix path. - Dan
It seems to be true, ported mingwmicq-0.4.10.1-mingw.exe wrote .micqrc into my linux $HOME.
The message is correct, but Wine's behavior is not. I'm pretty sure you understand the issue, but for anyone still wondering: The problem is strictly theoretical at this point, but we should be aware of it in case somebody runs into it in the future. Here's the scenario:
- user installs MinGW or some other app that's been ported to Win32 but uses Unix-style path separators for win32 directories
- a path used by the program happens to exist both in the Windows filespace on drive C: (presumably this would be
something installed by the app) and in the Unix filespace. For instance, the path /etc/blort/config might be a configuration file for a library used both on Linux and installed independently onto drive C: by the application.
- The app tries to open the file on drive C:, and gets the
file in Linux instead. Bang! The program crashes, or gives bad results.... In order to change this behavior we would have to make changes to GetShortPathNameW so that it tries the path with
the
current drive first and then calls this (modified) function. After looking at the code for the last couple of hours I'm sure it could
be
done but I don't know if it is worth it.
Thanks for looking at it.
At present I think that it would be better to change the message
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1) {
MESSAGE("Warning: %s not accessible from a configuredDOS
drive\n", debugstr_w(*name) );
WARN("failed to find %s as an absolute unix pathmapped to
configured DOS drive \n",
debugstr_w(*name) );WARN("assuming it was a really a DOS name") /* Assume it really was a DOS name */ drive = DRIVE_GetCurrentDrive(); }Or something like that.
Or something like that, yeah. We want to display a hint that there might be a misinterpretation of a DOS path as a Unix path.
- Dan
-- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Dan Kegel wrote:
Tony Lambregts wrote:
What about reversing the order: first try the DOS path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as a (absolute) unix one otherwise it just returns the current drive. Changing this behavior is not simple and however annoying the message is it is correct.
The message is correct, but Wine's behavior is not. I'm pretty sure you understand the issue, but for anyone still wondering: The problem is strictly theoretical at this point, but we should be aware of it in case somebody runs into it in the future. Here's the scenario:
- user installs MinGW or some other app that's been ported to Win32 but uses Unix-style path separators for win32 directories
- a path used by the program happens to exist both in the Windows filespace on drive C: (presumably this would be something installed by the app) and in the Unix filespace. For instance, the path /etc/blort/config might be a configuration file for a library used both on Linux and installed independently onto drive C: by the application.
- The app tries to open the file on drive C:, and gets the
file in Linux instead. Bang! The program crashes, or gives bad results.
Well... AFAICT this situation could only happen in a "Wine with windows" install. In a wine only installation this situation should not occure since wine will always choose the unix path. Perhaps it would be better to change the behavior so that Wine tries the path as a DOS path first but it isn't a quick and easy thing to do.
The reason I am interested in this is that there are a number of other bug/features in Wine's emulation of the DOS file system that I am looking at (1). Anyways at this point I am not as familiar/comforable with this section of the code to attempt to change it.
[snip]
Or something like that, yeah. We want to display a hint that there might be a misinterpretation of a DOS path as a Unix path.
so you really would want something more like this :
{ if ((drive = DRIVE_FindDriveRootW( name )) == -1) { - MESSAGE("Warning: %s not accessible from a configured DOS drive\n", debugstr_w(*name) ); + WARN("failed to find %s as an absolute unix path mapped to configured DOS drive \n", + debugstr_w(*name) ); + WARN("assuming it was a really a DOS name") /* Assume it really was a DOS name */ drive = DRIVE_GetCurrentDrive(); } + else + { + WARN("Using %s as a absolute unix path\n" debugstr_w(*name) ); + } } else drive = DRIVE_GetCurrentDrive();
Sort of dambed if we dambed if we don't. At least WARN's arn't automaticly spit out.
Tony Lambregts wrote:
Well... AFAICT this situation could only happen in a "Wine with windows" install.
I'm doubt that's the case. As far as I can see, this can easily happen on any Wine installation. All it takes is a Windows app that uses Linux-like paths that happen to clash with real Linux paths.
Then again, I could be all wet. I suppose I should write a little test case. Maybe even submit it as a regression test. That would make things clearer.
- Dan
Dan Kegel wrote:
Tony Lambregts wrote:
Well... AFAICT this situation could only happen in a "Wine with windows" install.
I'm doubt that's the case. As far as I can see, this can easily happen on any Wine installation. All it takes is a Windows app that uses Linux-like paths that happen to clash with real Linux paths.
Then again, I could be all wet. I suppose I should write a little test case. Maybe even submit it as a regression test. That would make things clearer.
Sounds like the best idea.
-
Dan Kegel -
David Fraser -
Dimitrie O. Paun -
Gregory M. Turner -
Mike Hearn -
Steven Edwards -
Sylvain Petreolle -
Tony Lambregts