Eric Pouech wrote:
> > In the debugger, I used "x /d 0x409168bc" to find the lpType. The
> > output is 0, the default, which I understand is a string.
> well, the type is REG_NONE... so not in every case a string
>
Looking back at the Microsoft win32 api page that references the
RegQueryValueEx function, I see where I mistakenly interpreted that the
type defaults to string (It was referring to the default type when the
value of LpValueName is null). Anyway, the registry key in question,
"AppLang", has a value in the registry of "0x0409,enu" (at least in the
~/.wine/user.reg file).
> debugger's command sounds ok. be sure you use them at the right place
> (eg after the server's call has returned) (silly question I know)
Yep, even double checked after receiving this email.
Before the debugger gives a prompt the log file shows the following line
(this line actuall occurs twice, identically):
trace:reg:RegSetValueExA (0x28,"AppLang",0,1,0x405e7e3e,10)
Here, the type is being set to 1 (string). As soon as the debugger
prompt is available, x /s 0x405e7e3e gives _IP_EBP_28
Searching for references to this string in the log gives the following
lines:
597 000118d0 0x4070c8d0 SMapLS_IP_EBP_28
...
607 00011970 0x4070c970 SUnMapLS_IP_EBP_28
...
597 000118d0 0x405f08d0 SMapLS_IP_EBP_28
...
607 00011970 0x405f0970 SUnMapLS_IP_EBP_28
Once again, at the debugger prompt:
x 0x4070c8d0 -> 00000000
x 0x4070c970 -> 00000000
x 0x405f08d0 -> b9d6b7e8
x /s 0x405f08d0 -> è·Ö¹ÿÃ (this is the same value returned by
RegQueryValueEx in the LpData buffer later in the program)
x 0x405f0970 -> b9d617e8
x /s 0x405f0970 -> èvÖ¹ÿÃ
Looking at the memory/selector.c file, it seems that the SMapLS lines
map a pointer (linear) to another pointer (segmented). I'm not sure
exactly what this means (I'll have to research this later), but is it
possible that this is where the registry key value is changed; or does
everything look as expected?
Looking again at the register value query call:
Call advapi32.235: RegQueryValueExA(00000040,004ac7c4
"AppLang",00000000,409168bc,4091686c,409168b8) ret=00468b3f fs=008f
The LpData is now 41012ec0 (x 0x4091686c). Assuming that this value is
memory reference: x /s 0x41012ec0 -> <AppName>
I'm not sure I understand where this came from, unless there is a
misdirected pointer or something.
> from the rest of the log, it may well be that the app is looking for
> the "good" DLLs, even if the names sound wrong to you, but it's hard
> to tell
>
Any ideas on how I can try to find out how the filename string for the
dll was created? I tried to enable the string debugmsg to look for
relevant calls by looking for functions that addressed any memory
locations occupied by the string, but was unsuccessful.
Thanks for your help,
Jim Shepherd
[EMAIL PROTECTED]