[PATCH] HOMAM III fix

[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

[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 ?

[Martin Lexa]

Hi!

* Andreas Mohr ([e-mail]) 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

[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         [e-mail]        http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux

[Geoffrey Hausheer]

On Friday 05 April 2002 13:56, Francois Gouget wrote:
> 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.

I have some code I did a week ago to test file and path functions.  I've 
really barely begun (there are a LOT of path/file functions to test), but if 
it would be useful, I can clean up what I've got so far and post it here.  I 
have preliminary tests for the three functions you mention above (only ANSI 
so far) though.  Or if it is not so important, you can wait until I've 
actually finished all the tests I plan to do, which will probably be sometime 
next week.

.Geoff

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
[e-mail]

[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
> [e-mail]

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

[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
> > [e-mail]
>
> 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 ;-)

[Martin Lexa]

* Andreas Mohr ([e-mail]) 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

[Martin Lexa]

* Martin Lexa ([e-mail]) wrote:
> 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} }
>   .
>   .
>   .

Things, getting better and better... 
  Please, look at the value of AppPath reg! I think it should be
C:\Program Files\3DO\HEROES3\ not C:\Program Files\3DO\. I run regedit
and look at that value and yes, everytime I run wine with this game
the reg AppPath will change to the actual path where I ran wine from.
If I, for example run wine from C:\Program Files\3DO\HEROES3 directory the
value of AppPath reg change to C:\Program Files\3DO\HEROES3\.
I verified it with regedit.
  I think it's a bug or am I wrong? May be it's a Wine's feature ;) ?

Martin

[Enrico Horn]

Hi,
On Friday 05 April 2002 21:58, Martin Lexa wrote:
> - Andreas Mohr ([e-mail]) 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 snipped]
> 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 ;)

That is understandable.
it seems that HoMM3 assumes C:\Program Files\3DO\Heroes3 or wherever it
was installed in as current path and wont check that it really is so.
the GetFullPathNameA call with the relative path .\DATA\
will of course fail when this assumption isnt true.
One solution could be to start the exe in path that it resides in but
this might cause problems with other apps and is really not the right thing to 
do.
I would assume that HoMM3 would fail on windows too if called like this, any 
one who can confirm this?

Enrico
[e-mail]

[Martin Lexa]

* Enrico Horn ([e-mail]) wrote:
> That is understandable.
> it seems that HoMM3 assumes C:\Program Files\3DO\Heroes3 or wherever it
> was installed in as current path and wont check that it really is so.
> the GetFullPathNameA call with the relative path .\DATA\
> will of course fail when this assumption isnt true.
> One solution could be to start the exe in path that it resides in but
> this might cause problems with other apps and is really not the right thing to 
> do.
> I would assume that HoMM3 would fail on windows too if called like this, any 
> one who can confirm this?

When I've Windows installed I played this game and everything works
ok for me. Yes, it was the same copy, which I'now trying to use under
Wine.
> Enrico
> [e-mail]

Martin