wine-devel Digest, Vol 46, Issue 10

[chris ahrendt]

wine-devel-request at winehq.org wrote:
> _______________________________________________
> wine-devel mailing list  -  wine-devel at winehq.org
> http://www.winehq.org/mailman/listinfo/wine-devel
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: RFC on Base Wine Config
> From:
> Kai Blin <kai.blin at gmail.com>
> Date:
> Sun, 3 May 2009 09:04:13 +0200
> To:
> wine-devel at winehq.org
>
> To:
> wine-devel at winehq.org
>
>
> On Sunday 03 May 2009 07:07:35 Ben Klein wrote:
>   
>> 2009/5/3 chris ahrendt <celticht32 at 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
>
>   
>   

Thanks Kai,
This is the kind of dialog I was looking for in the RFC.  This makes 
sense.  In a way with you are in a seperate 'region' and do not have 
access to that regions resources unless you
map it. Even though wine is not a emulator it is essentially a VM 
running in userspace on the box that you need to allocate some resources 
to. (not so much like solaris 10 or zVM's where
you can set up resources for everything). Ok clear now.

Chris