Linear and segmented memory drifting apart

[Uwe Bonnes]

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

Free Software: If you contribute nothing, expect nothing
--