We have used the attached sample to test this. The patch I have sent earlier had two fixes; Fix-1 (wide character string) and Fix-2 (Remote Path Name). Basically we have Team Developer product which generates the runtime win32 applications. These generated application are behaving differently on Win32 and Wine.
Please find attached the sample win32 application that demonstrates the behavior of WNetGetConnection API. 1. The sample has hard coded the network drive name as "N:" for this demonstration. Please map a new network drive named "N:" before running this sample program. 2. In Wine, apply the fix-1 (wide character issue) before applying fix-2 to see the different behavior. 3. Invoke Menu item Test->GetRemotePath
Thanks, Krishna
-----Original Message----- From: Alexandre Julliard [mailto:julliard@winehq.org] Sent: Thursday, May 06, 2004 11:57 AM To: Krishna Murthy Cc: wine-devel@winehq.org Subject: Re: WNetGetConnection(): Fix for incorrect drive name and remote name and
Krishna Murthy Krishna.Murthy@guptaworldwide.com writes:
We did some analysis and come to conclusion that QueryDosDevice is a better choice than GetVolumeInformation.
What sort of analysis? Do you have an app that needs that, and if so why is returning a Unix path better? What does the app do with it?
-- Alexandre Julliard julliard@winehq.org
Krishna Murthy Krishna.Murthy@guptaworldwide.com writes:
We have used the attached sample to test this. The patch I have sent earlier had two fixes; Fix-1 (wide character string) and Fix-2 (Remote Path Name). Basically we have Team Developer product which generates the runtime win32 applications. These generated application are behaving differently on Win32 and Wine.
Well, this still doesn't answer my question, but never mind, I put the patch in. It's not more incorrect than before anyway, so if you prefer to see something that looks more like a valid path that's OK with me. Just be aware that if any real app tries to do something with the results it will fail just as badly as before.