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 > [EMAIL PROTECTED]
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
