Hallo,
the installer of MS Encarta 99 is a mixture of 16 and 32 bit code. Soemthing seems wrong here:
Some 16 bit memory if filled with a string
89497 08483bf8:Call KERNEL.88: LSTRCPY(0x03f7781a,0x03177044 "%CMDLINE%") ret=030f:0687 ds=031f 89498 08483bf8:Ret KERNEL.88: LSTRCPY() retval=0x03f7781a ret=030f:0687 ds=031f
A 32 bit handle to that memory is aquired:
89503 08483bf8:Call KERNEL.516: GETVDMPOINTER32W(0x03f7781a,0x0001) ret=030f:ae4a ds=031f 89504 08483bf8:Ret KERNEL.516: GETVDMPOINTER32W() retval=0x40498d2e ret=030f:ae4a ds=031f
Access to the 32 bit view of that memory goes astray
113220 08483bf8:Call kernel32.lstrcmpA(40498d2e "\021\021\021\021\021\021\021\021...1 113221 08483bf8:Ret kernel32.lstrcmpA() retval=ffffffff ret=10001464
But the 16 bit view still gives the right result:
113785 08483bf8:Call KERNEL.90: LSTRLEN(0x03f7781a "%CMDLINE%") ret=030f:a525 ds=031f 113786 08483bf8:Ret KERNEL.90: LSTRLEN() retval=0x0009 ret=030f:a525 ds=031f
Trying to debug a little, I looked at the 32 bit view and it's content is right right after the GETVDMPOINTER32W call. If I debugged right, the content of *0x40498d2e seemed to change inside the application code and not in a wine function.
But why at all gives the lstrlen call in line 113785 still the right result?
Bye
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Free Software: If you contribute nothing, expect nothing --