[Bug 22429] VMWare ThinApps don't run

http://bugs.winehq.org/show_bug.cgi?id=22429

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #28 from Anastasius Focht   2010-06-27 13:39:57 ---
Hello,

this ThinApp stuff is comparable in architecture to Xenocode.
They wrap/hook/partly emulate NT native API to provide "sandbox" like
behaviour.

There are different issues in the examples provided here, I tackle only one per
bug, using FireFox as example.

While skimming through the Firefox trace logs I noticed the following anomaly
with object manager queries:

--- snip ---
...
002d:trace:ntdll:NtOpenSymbolicLinkObject (0x32e0d8,0x80000000,{name=L"\??",
attr=0x00000000, hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32e0d8,0x80000000,{name=L"\??\C:", attr=0x00000000, hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtQuerySymbolicLinkObject (0xb0,0x32e0e0,0x32e0dc)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32df30,0x80000000,{name=L"\Device", attr=0x00000000, hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32df30,0x80000000,{name=L"\Device\HarddiskVolume", attr=0x00000000,
hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32df30,0x80000000,{name=L"\Device\HarddiskVolume\Program Files",
attr=0x00000000, hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32df30,0x80000000,{name=L"\Device\HarddiskVolume\Program Files\Mozilla
Firefox", attr=0x00000000, hRoot=(nil), sd=(nil)}
)
002d:trace:ntdll:NtOpenSymbolicLinkObject
(0x32df30,0x80000000,{name=L"\Device\HarddiskVolume\Program Files\Mozilla
Firefox\firefox.exe", attr=0x00000000, hRoot=(nil), sd=(nil)}
)
...
002d:trace:msgbox:MSGBOX_OnInit L"Executable 'C:\Program Files\Mozilla
Firefox\firefox.exe' had the following unrecoverable error:\nUnable to open
C:\Program Files\Mozilla Firefox\firefox.exe"
--- snip ---

The virtualization layer/wrapper seemed to build the link object names for
\Device\HarddiskVolume## devices incorrectly, omitting the number(s).
Wine's mount manager was giving link info correctly away.

After dissecting/debugging of ThinApp layer I came to conclusion that a NULL
terminator needs to be included in returned link object name (unicode) strings.
For instance if the wrapper called NtQuerySymbolicLinkObject() it would copy
the returned link name string using following (translated pseudo) code:

wchars_to_copy = (returned_length/sizeof(WCHAR))-1; 
<wchar copy routine>

Because Wine only returns the byte count of all wide characters - excluding
(wide) NULL terminator - the app eats the last wide character away.
E.g. "\Device\HarddiskVolume1" would become "\Device\HarddiskVolume"

I verified my findings and it helped Thinapped Firefox from comment #27 to
start successfully.

Regards