http://bugs.winehq.org/show_bug.cgi?id=22429 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #28 from Anastasius Focht <focht(a)gmx.net> 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.