Juan Lang wrote:
ok then I am very confused then... I deleted the / mapping all together and then ran the dotest script and the make test scripts dotest fails if the / mapping is not there along with the inetmib1 test. I opened a bug concerning the inetmib test failing and was told that my configuration with the / mapping deleted was an invalid wine configuration that the / is absolutely needed by wine.
So I am confused... is it required or not?
It is not required. What _is_ required is that the path to the current executable is mapped, somewhere. I suggested you remap Z: to / as it's the default, and it was the most concise way to ensure that your configuration met the requirement. As Ben said, you could map any drive. Heck, you could have mapped Q: to the dlls/inetmib1/tests directory and the inetmib1 test would have worked, while having no mapping would not work. --Juan
I realise this juan... I guess I am not being completely clear somewhat.... If I am in windows and go into explorer... go to a network drive. I do not nescisarily have to map that drive in order to run an application (so long as the DLLS it needs, if any, are not just on that drive). I can click the application and it runs. I realise this may be a fundamental difference between unix and windows but still they should theoretically run the same. Also from a command line I can do (I think if I am remembering correctly (been doing to much z work lately) ) //server/directory/app.exe and it will retrieve and run the app... (I think) Chris
2009/5/3 chris ahrendt <celticht32(a)yahoo.com>:
Juan Lang wrote:
ok then I am very confused then... I deleted the / mapping all together and then ran the dotest script and the make test scripts dotest fails if the / mapping is not there along with the inetmib1 test. I opened a bug concerning the inetmib test failing and was told that my configuration with the / mapping deleted was an invalid wine configuration that the / is absolutely needed by wine.
So I am confused... is it required or not?
It is not required. What _is_ required is that the path to the current executable is mapped, somewhere. I suggested you remap Z: to / as it's the default, and it was the most concise way to ensure that your configuration met the requirement. As Ben said, you could map any drive. Heck, you could have mapped Q: to the dlls/inetmib1/tests directory and the inetmib1 test would have worked, while having no mapping would not work. --Juan
I realise this juan... I guess I am not being completely clear somewhat.... If I am in windows and go into explorer...
We've been through this before. Wine is not Windows. In Wine, the drive has to be mapped in dosdevices.
go to a network drive. I do not nescisarily have to map that drive in order to run an application (so long as the DLLS it needs, if any, are not just on that drive). I can click the application and it runs. I realise this may be a fundamental difference between unix and windows but still they should theoretically run the same.
But you're NOT running the test from a network drive, are you? And even if you were, you'd need some way to inform Wine that it's there, which would be to map it to a drive. Does Wine even support Windows-style shares?
Also from a command line I can do (I think if I am remembering correctly (been doing to much z work lately) ) //server/directory/app.exe and it will retrieve and run the app... (I think)
You should probably verify this. 2009/5/3 chris ahrendt <celticht32(a)yahoo.com>:
And you are looking at the wrong bug... 1 The bug in question is actually : 18283 (now closed as the issue was resolved by the mapping) not 17996.
18283 didn't come up in my search. It would have been much easier if you mentioned the bug number when you first mentioned that you reported a bug for this.
The only way to fix it was mapping the / drive or mapping the ~/wine-git directory to a physical drive for wine to use...
Yes. This is how it works. This is how it always has worked.
In Windows you don't nescissarily need to map a drive to run an application from that networked drive.
It's NOT a networked drive, is it? Drive mappings are the only way to tell Wine and apps running in Wine where your files are in your host-system (Unix-style) filesystem. Note that it would be a breach of security to allow some method to access / without a direct mapping in dosdevices.
Also no its not a PEBKAC it is a valid question and a request for comment not a request for insult and slam.
This message appears in your bug report:
Warning: could not find DOS drive for current working directory '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows directory.
PEBKAC QED.
Grow up..
How about you *THINK* about what you're doing and how it works before reporting obviously invalid bugs?
On Sunday 03 May 2009 07:07:35 Ben Klein wrote:
2009/5/3 chris ahrendt <celticht32(a)yahoo.com>:
Replying to Ben's email as I didn't get Chris' email Ben replied to. I would also like to note that I don't appreciate the tone both of these emails are taking in the end. Please try to be civil. That being said, let me get to the technical part.
I guess I am not being completely clear somewhat.... If I am in windows and go into explorer...
We've been through this before. Wine is not Windows. In Wine, the drive has to be mapped in dosdevices.
go to a network drive. I do not nescisarily have to map that drive in order to run an application (so long as the DLLS it needs, if any, are not just on that drive). I can click the application and it runs. I realise this may be a fundamental difference between unix and windows but still they should theoretically run the same.
The important part here is that your local drives are local drives. Don't confuse the Wine drive mappings with network drive mappings in Windows. Think about a Wine drive mapping like plugging a new hdd into your box.
But you're NOT running the test from a network drive, are you? And even if you were, you'd need some way to inform Wine that it's there, which would be to map it to a drive. Does Wine even support Windows-style shares?
Nope. We could, but then you'd have to create a Samba share to allow us to use the directory. I'm pretty sure a wine drive mapping is easier and faster.
Also from a command line I can do (I think if I am remembering correctly (been doing to much z work lately) ) //server/directory/app.exe and it will retrieve and run the app... (I think)
That's a bit besides the point, as this is still a valid UNC path. Now imagine I've got a USB hdd with my app on it, and that's usually connected at U:, with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB drive to U: is just what the wine dosdevice mapping is like. If I now tell windows to remove the USB device, my desktop link to U:\test\app.exe is not going to work anymore.
This message appears in your bug report:
Warning: could not find DOS drive for current working directory '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows directory.
Here my analogy would be a bit stretched, as in that you'd still manage to be on the USB drive while it's already been disconnected. But basically you're trying to run a program that's on a drive not connected to your wine "box". Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote:
It's NOT a networked drive, is it? Drive mappings are the only way to tell Wine and apps running in Wine where your files are in your host-system (Unix-style) filesystem.
The discussion on wine-devel in April related to bug 15883 suggested the implementation of \\?\unix\ which would in turn allow programs access to things that aren't mapped in the DosDevices list, unless specifically disallowed (which wasn't discussed at the time) A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be a reasonable thing to expect to work under Wine.
Note that it would be a breach of security to allow some method to access / without a direct mapping in dosdevices.
How so? I'm fairly sure this suggestion was dismissed in the above-mentioned email discussions as well. [1] http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------
2009/5/3 Paul TBBle Hampson <Paul.Hampson(a)pobox.com>:
On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote:
It's NOT a networked drive, is it? Drive mappings are the only way to tell Wine and apps running in Wine where your files are in your host-system (Unix-style) filesystem.
The discussion on wine-devel in April related to bug 15883 suggested the implementation of \\?\unix\ which would in turn allow programs access to things that aren't mapped in the DosDevices list, unless specifically disallowed (which wasn't discussed at the time)
A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be a reasonable thing to expect to work under Wine.
But that requires either 1) the app to be aware of \\?\unix, or 2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists. #2 would also require some way to be configured to allow the equivalent of removing the default Z: drive mapping for people who want it. However, it would not provide any additional functionality and could easily be considered a waste of time. Of course, that's not up to me ;)
Note that it would be a breach of security to allow some method to access / without a direct mapping in dosdevices.
How so? I'm fairly sure this suggestion was dismissed in the above-mentioned email discussions as well.
AFAIK, the main reason people remove the Z: mapping is a security concern. It's not an issue for me, but some people like to restrict the files that win32 apps can access to a subdirectory in $HOME. If there's some workaround to access files outside the drive mapping (assuming pure win32 of course :D ), then unless it can be disabled by the user, it's a security breach.
On Sun, May 03, 2009 at 08:54:32PM +1000, Ben Klein wrote:
2009/5/3 Paul TBBle Hampson <Paul.Hampson(a)pobox.com>:
On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote:
It's NOT a networked drive, is it? Drive mappings are the only way to tell Wine and apps running in Wine where your files are in your host-system (Unix-style) filesystem.
The discussion on wine-devel in April related to bug 15883 suggested the implementation of \\?\unix\ which would in turn allow programs access to things that aren't mapped in the DosDevices list, unless specifically disallowed (which wasn't discussed at the time)
A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be a reasonable thing to expect to work under Wine.
But that requires either 1) the app to be aware of \\?\unix, or
This would be rather badly broken. The point of \\?\ is that apps (and in fact the Win32 API) doesn't parse such paths, but passes them on to the filesystem.
2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists.
The _point_ is that if Wine sees a \\?\unix/foo/bar path, it operates upon the file at /foo/bar, irrespective of the drive mappings.
#2 would also require some way to be configured to allow the equivalent of removing the default Z: drive mapping for people who want it. However, it would not provide any additional functionality and could easily be considered a waste of time. Of course, that's not up to me ;)
The point of \\?\unix is not to add functionality, it's to allow removal of current functionality, specifically the magic recognition of "/x/y" as a unix path instead of "X:/x/y" with X as the drive of the current working directory, in order to fix bug 15883.
Note that it would be a breach of security to allow some method to access / without a direct mapping in dosdevices.
How so? I'm fairly sure this suggestion was dismissed in the above-mentioned email discussions as well.
AFAIK, the main reason people remove the Z: mapping is a security concern. It's not an issue for me, but some people like to restrict the files that win32 apps can access to a subdirectory in $HOME. If there's some workaround to access files outside the drive mapping (assuming pure win32 of course :D ), then unless it can be disabled by the user, it's a security breach.
The point made as I recall it in the earlier thread is that this is a false sense of security, and that apps can already get outside the drive mappings for filesystem access. I don't know how, but that was the point that was made. Off the top of my head, there's Win32 APIs that let you enumerate and map physical disk devices to DOS drive letters. So you could just readd Z:\ in your app if you wanted. Frankly I would like to break that illusion of security by providing \\?\unix, if I find the time. (The hard part is identifying all the parts of Wine that use the '/' recognition to function) -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------
Am Sonntag, 3. Mai 2009 13:42:24 schrieb Paul TBBle Hampson:
The point made as I recall it in the earlier thread is that this is a false sense of security, and that apps can already get outside the drive mappings for filesystem access.
I don't know how, but that was the point that was made. Linux syscalls. A Windows app can happily call int 0x80 to do whatever a Linux app running with the same permissions can do. It requires the app to be aware of Wine though.
participants (5)
-
Ben Klein -
chris ahrendt -
Kai Blin -
Paul TBBle Hampson -
Stefan Dösinger