Hi all,
I guess it's my turn this time ;-\
My App Path code didn't 0 initialize two HKEYs.
As that code is using "goto", the compiler was unable to figure out
that the HKEYs weren't properly initialized, so it didn't generate a
compile warning for me to notice it before I submitted that patch :-\
As the HKEYs weren't initialized, they were non-0 and thus being closed
on function returned.
This problem caused the winedos "invalid exe file" message, BTW.
How did it happen ?
Well, the stack at the HKEY place for some reason contained exactly the
0x20 value that the HFILE handle of the DOS binary used...
And as the code was doing a CloseHandle on that uninitialized registry
key...
...it closed the HFILE of the DOS binary !!
Thus the file seek and ReadFile failed -> "invalid binary".
In other words: dark brown paper bag :-)
Thanks God I became quite suspicious about the frequent wineserver log
errors, so I noticed the grave problem.
God knows in how many other cases this wreaked havoc...
Sounds like using "goto" isn't such a good idea after all...
Alexandre, please tell me if you even want me to rewrite the code not
using goto...
*sigh*
--
Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
"Point is, nothing here is unfamiliar or unexpected. How long does
it take before there's general recognition that Microsoft software
has no business on the Internet? - Dennis E. Powell re: Code Red
Determining best CVS host...
Using CVSROOT :pserver:cvs@rhlx01.fht-esslingen.de:/home/wine
Index: files/directory.c
===================================================================
RCS file: /home/wine/wine/files/directory.c,v
retrieving revision 1.48
diff -u -r1.48 directory.c
--- files/directory.c 31 May 2002 23:06:47 -0000 1.48
+++ files/directory.c 11 Jul 2002 20:31:21 -0000
@@ -623,7 +623,7 @@
*/
static BOOL DIR_TryAppPath( LPCSTR name, DOS_FULL_NAME *full_name )
{
- HKEY hkAppPaths, hkApp;
+ HKEY hkAppPaths = 0, hkApp = 0;
char lpAppName[MAX_PATHNAME_LEN], lpAppPaths[MAX_PATHNAME_LEN];
LPSTR lpFileName;
BOOL res = FALSE;
