April 2002 - Wine-Devel - list.winehq.org

Re: [PATCH] HOMAM III fix

by Martin Lexa

* Andreas Mohr (andi(a)rhlx01.fht-esslingen.de) wrote: > Actually GetFullPathName was known to have some trailing \\ issue. > So this had to be fixed somehow. > It just astonished me a bit to see some code part completely removed > instead of a "real" fix. > But he said that he can't think of any occasion where it breaks, > so it might be ok. And there is another strange thing... HOMAM III is installed in C:\Program Files\3DO\Heroes3 directory. If I run wine from this directory with HEROES3.EXE as parameter everything works ok, of course, after "fix". However, if I run wine from, for example C:\Program Files\3D0 directory, it gave me error "Unable to initialize resources - ...". wine --debugmsg +all 'C:\Program Files\3DO\Heroes3\HEROES3.EXE' Debug output: . . . 0806fa00:trace:reg:NtQueryValueKey (0x58,L"AppPath",2,0x40896ab4,256) 0806fa00: get_key_value( hkey=88, name=L"AppPath" ) Get key \\Machine\\Software\\New World Computing\\Heroes of Might and Magic\xae III\\1.0 value "AppPath"="C:\\Program Files\\3DO\\" 0806fa00: get_key_value() = 0 { type=1, total=44, data={43,00,3a,00,5c,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,20,00,46,00,69,00,6c,00,65,00,73,00,5c,00,33,00,44,00,4f,00,5c,00,00,00} } . . . Call kernel32.GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,40896cac,40896c9c) ret=00599630 trace:dosfs:DOSFS_GetFullName . (last=0) trace:string:lstrcpynA (0x40896398, "/opt/c", 1024) trace:string:lstrcpynA (0x4089639f, "Program Files/3DO", 1017) trace:string:lstrcpynA (0x4089679b, "PROG~FBU\\3DO", 1021) trace:dosfs:DOSFS_GetFullName returning /opt/c/Program Files/3DO = C:\PROG~FBU\3DO trace:string:lstrcpynA (0x4089679a, "/Program Files/3DO", 1021) 0806fa00:trace:string:lstrcpynA (0x408967ad, ".\\DATA\\", 1003) 0806fa00:trace:dosfs:DOSFS_DoGetFullPathName got C:\Program Files\3DO\DATA\ 0806fa00:trace:string:lstrcpynA (0x40896cac, "C:\\Program Files\\3DO\\DATA\\", 260) 0806fa00:trace:dosfs:DOSFS_DoGetFullPathName returning 'C:\Program Files\3DO\DATA\' . . . Look at the final path, it's WRONG. It should be 'C:\Program Files\3DO\HEROES3\DATA\'. If I run wine from directory 'C:\Program Files' the final path is even worse -> 'C:\Program Files\DATA\'. And yes, same happen if try it without my fix - except that last backslash. What's going on here? I don't understand this. Looks like black magic to me ;) Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Francois Gouget

On Fri, 5 Apr 2002, Andreas Mohr wrote: [...] > Are you sure that simply completely removing code doesn't break anything > here in other cases ? The only way to handle that is to write a regression test involving GetFullPathName and a couple other related functions (like GetLongPathName (buggy) and GetShortPathName). Then we can check the behavior in Windows. If someone writes such a test I will run it on Win95, Win98, NT4 and WinXP and we will finally know. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

April 5, 2002

Re: [PATCH] HOMAM III fix

by Andreas Mohr

On Fri, Apr 05, 2002 at 01:16:11PM -0500, Vincent Béron wrote: > Enrico Horn a écrit : > > > > Hi > > > > On Friday 05 April 2002 19:06, Andreas Mohr wrote: > > > On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > > > > Hello! > > > > > > > > Function CreateFileA get this file path (just for example): > > > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > > > > > > > As you can see the correct path should be: > > > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > > > > > > > This lead to error message "Can't initialize resources.Possible disk > > > > problem." > > > > > > > > I see the problem in the function DOSFS_DoGetFullPathName(), which in > > > > the end removes the ending backslash from the path. The attached patch > > > > fixes it. > > > > > > > > Bye, Martin > > > > > > > > > > Yep, that might fix *your* problem, but don't you think that code snippet > > > might have been there for a purpose ? > > > > > To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" > > I sent to this list more than a week ago. Until now no real answer has been > > given. > > > Are you sure that simply completely removing code doesn't break anything > > > here in other cases ? > > I cant think of any situation where this might be needed. > > I may be wrong though. > > Yet so far I have no explanation for this piece of code and > > removing it seems to work fine. > > > > Enrico > > farmboy1(a)subdimension.com > > I tracked it to a patch by Uwe Bonnes, around the 2000/04/28. It brought > the dos_fs.c revision from 1.46 to 1.47. The CVS comment is: > "DOSFS_DoGetFullPathName: rewrite to return resulta like OSR2". > > Have you tried to run HOMAM III under OSR2? Or even just a call to the > proper Win32 API? > It might be just some different behaviours under different Windows > falvours... > > As to which of the two is what we want, I can't help you on that. Actually GetFullPathName was known to have some trailing \\ issue. So this had to be fixed somehow. It just astonished me a bit to see some code part completely removed instead of a "real" fix. But he said that he can't think of any occasion where it breaks, so it might be ok. Probably a candidate for regression testing, though ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 5, 2002

Re: [PATCH] HOMAM III fix

by Martin Lexa

Hi! * Andreas Mohr (andi(a)rhlx01.fht-esslingen.de) wrote: > Yep, that might fix *your* problem, but don't you think that code snippet > might have been there for a purpose ? > > Are you sure that simply completely removing code doesn't break anything > here in other cases ? Same thing came to my mind too. The only "thing" it breaks is the value of lastpart parameter. However, should somebody tell me what is the REAL purpose of the lastpart parameter, please? I don't see any, because it only returns value if the return path has no ending backslash. If ending backslash will not be present the error will came up again... There is not much room for fixing it elsewhere, because after end of GetFullPathNameA function, which call DOSFS_DoGetFullPathName, the function CreateFileA is called with "wrong" filename value, as I described in my previous e-mail. Bye, Martin

April 5, 2002

Re: [PATCH] HOMAM III fix

by Vincent Béron

Enrico Horn a écrit : > > Hi > > On Friday 05 April 2002 19:06, Andreas Mohr wrote: > > On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > > > Hello! > > > > > > Function CreateFileA get this file path (just for example): > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > > > > > As you can see the correct path should be: > > > > > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > > > > > This lead to error message "Can't initialize resources.Possible disk > > > problem." > > > > > > I see the problem in the function DOSFS_DoGetFullPathName(), which in > > > the end removes the ending backslash from the path. The attached patch > > > fixes it. > > > > > > Bye, Martin > > > > > > > Yep, that might fix *your* problem, but don't you think that code snippet > > might have been there for a purpose ? > > > To find out this purpose was the purpose of my mail "DOSFS_DoGetFullPathName" > I sent to this list more than a week ago. Until now no real answer has been > given. > > Are you sure that simply completely removing code doesn't break anything > > here in other cases ? > I cant think of any situation where this might be needed. > I may be wrong though. > Yet so far I have no explanation for this piece of code and > removing it seems to work fine. > > Enrico > farmboy1(a)subdimension.com I tracked it to a patch by Uwe Bonnes, around the 2000/04/28. It brought the dos_fs.c revision from 1.46 to 1.47. The CVS comment is: "DOSFS_DoGetFullPathName: rewrite to return resulta like OSR2". Have you tried to run HOMAM III under OSR2? Or even just a call to the proper Win32 API? It might be just some different behaviours under different Windows falvours... As to which of the two is what we want, I can't help you on that. Bye, Vincent

April 5, 2002

Re: Removed sorting of registry key values

by Andriy Palamarchuk

Paul Millar wrote: > On Wed, 3 Apr 2002, Andriy Palamarchuk wrote: > >>The tests show that values are exported in the same >>order in which they are created. This means the values >>are stored not in any particular order. > > > That doesn't necessarily follow ... > > The export function(s) could map the sorted registry back into its > original order. At the cost of sizeof( void *) bytes per registry entry > (perhaps less, I haven't looked too closely at the registry code), you > could have the registry keys sorted (for fast access) and export back into > the original order in O(n) > > Is it worth the memory for that level of compatibility? All of you guys, thank you for the feedback. I had a doubt before submitting the patch. Andriy Palamarchuk

April 5, 2002

Re: [PATCH] HOMAM III fix

by Andreas Mohr

On Fri, Apr 05, 2002 at 06:46:27PM +0200, Martin Lexa wrote: > Hello! > > Function CreateFileA get this file path (just for example): > > C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod > > As you can see the correct path should be: > > C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod > > This lead to error message "Can't initialize resources.Possible disk > problem." > > I see the problem in the function DOSFS_DoGetFullPathName(), which in the > end removes the ending backslash from the path. The attached patch fixes it. > > Bye, Martin > Index: dos_fs.c > =================================================================== > RCS file: /home/wine/wine/files/dos_fs.c,v > retrieving revision 1.103 > diff -u -u -r1.103 dos_fs.c > --- dos_fs.c 2 Apr 2002 02:46:27 -0000 1.103 > +++ dos_fs.c 5 Apr 2002 16:24:19 -0000 > @@ -1341,9 +1341,6 @@ > } > if (full_name.short_name[namelen-1]=='.') > full_name.short_name[(namelen--)-1] =0; > - if (!driveletter) > - if (full_name.short_name[namelen-1]=='\\') > - full_name.short_name[(namelen--)-1] =0; > TRACE("got %s\n",full_name.short_name); > > /* If the lpBuffer buffer is too small, the return value is the Yep, that might fix *your* problem, but don't you think that code snippet might have been there for a purpose ? Are you sure that simply completely removing code doesn't break anything here in other cases ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 5, 2002

[PATCH] HOMAM III fix

by Martin Lexa

Hello! Function CreateFileA get this file path (just for example): C:\\Program Files\\3DO\\Heroes3\\DATAh3bitmap.lod As you can see the correct path should be: C:\\Program Files\\3DO\\Heroes3\\DATA\\h3bitmap.lod This lead to error message "Can't initialize resources.Possible disk problem." I see the problem in the function DOSFS_DoGetFullPathName(), which in the end removes the ending backslash from the path. The attached patch fixes it. Bye, Martin

April 5, 2002

Re: SetCooperativeLevel

by Tels

-----BEGIN PGP SIGNED MESSAGE----- Moin, On 05-Apr-02 Jason Phillips carved into stone: > > > Well first are you confusing Transmeta with Transgaming? Transmeta is the Yes. Sorry, s/transmeta/transgaming/g; And transgaming has their own mailing list, and their own CVS, which I already synced and build (I don't know if it contains all source code parts, though, but I suppose yes - AFAIU transgaming gives you anything, you just redistribute it commercially - or something along these lines) [snip the rest] Cheers, Tels - -- "Why do you go so slowly? Do you think this is some kind of game?" PGP key available on http://bloodgate.com/tels.asc or via email. perl -MDev::Bollocks -e'print Dev::Bollocks->rand(),"\n"' greatly extend B2B architectures -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPK2/IXcLPEOTuEwVAQGsgQf+I97ziYy4ZbYODW7dkSNjXPp0nAg/jKlj q4rCBhcvV1adFbNZ7JBGZJrkHVKZjiLLq99kK244iE+SQXKBG6kr9zIWbd9iCYSB gXwdqc4lf8mmVKiZz+EEtV5hCT1Dyst+hY9fxAYBYso1ZjXD/wz59Ds8YE9oLEOe y5sHzbzzXFsyLfRb7EWDwgXLB3TTRx0LPsHKLrzyn4k+7NMTimx8F2zFY5bhWqOW huvcDZ0vF3ldh1XuGl13t/fN8kqRpQfdHe/8RgXEXM1g/j9490zPVpFFZ67LY8ZE RkxVd6IWOFaVlGDmuCz04hPoeBQqg51hzTSga0aNw6R/GDFI9tdMnQ== =F3SZ -----END PGP SIGNATURE-----

April 5, 2002

Re: [PATCH] async IO API, reworked

by Dimitrie O. Paun

On April 5, 2002 06:32 am, Martin Wilck wrote: > Added files: > include : async.h (structs and inline functions for ^^^^^^^ Shouldn't this file be added to include/wine dir, as it seems to be an internal Wine header. -- Dimi.

April 5, 2002