[Bug 33236] New: Bible Converter Project fails to convert anything

List overview All Threads

newer

older

[Bug 53929] New: ExttextOut does...

[Bug 22912] New: Half Life 2 and...

wine-bugs＠winehq.org

17 Mar 2013 17 Mar '13

8:24 p.m.

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

Bug #: 33236 Summary: Bible Converter Project fails to convert anything Product: Wine Version: 1.5.26 Platform: x86-64 URL: http://www.churchsw.org/bible-converter-project OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: gaming4jc2@yahoo.com Classification: Unclassified

This program is freeware with source code. You can confirm it is not working by simply pressing Convert. It immediately says "Conversion completed successfully" even though no action was taken and no files are exported.

Errors in terminal: fixme:exec:SHELL_execute flags ignored: 0x00004100 fixme:ntdll:NtRaiseHardError : stub. Errorstatus was 40000015

-- 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.

Show replies by date

wine-bugs＠winehq.org

17 Mar 17 Mar

8:25 p.m.

New subject: [Bug 33236] Bible Converter Project fails to convert anything

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

Luke gaming4jc2@yahoo.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source

--- Comment #1 from Luke gaming4jc2@yahoo.com 2013-03-17 15:25:23 CDT --- Adding tags, download and source available.

wine-bugs＠winehq.org

8:28 p.m.

New subject: [Bug 33236] Bible Converter Project fails to convert anything

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

joaopa jeremielapuree@yahoo.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr

--- Comment #2 from joaopa jeremielapuree@yahoo.fr 2013-03-17 15:28:46 CDT --- Did you install .Net 2.0 with Winetricks ?

wine-bugs＠winehq.org

8:32 p.m.

New subject: [Bug 33236] Bible Converter Project fails to convert anything

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

--- Comment #3 from Luke gaming4jc2@yahoo.com 2013-03-17 15:32:09 CDT --- Will test that now, I was using default install with Mono/Gecko only.

wine-bugs＠winehq.org

9:52 p.m.

New subject: [Bug 33236] Bible Converter Project fails to convert anything

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

--- Comment #4 from Luke gaming4jc2@yahoo.com 2013-03-17 16:52:17 CDT --- Still seeing the same error.

fixme:gdiplus:get_gdi_brush_color unhandled brush type 2 fixme:shell:URL_ParseUrl failed to parse L"Bible Converter.resources" fixme:shell:URL_ParseUrl failed to parse L"Bible Converter.resources" fixme:exec:SHELL_execute flags ignored: 0x00000100 fixme:ntdll:NtRaiseHardError : stub. Errorstatus was 40000015 fixme:process:FlushProcessWriteBuffers : stub

wine-bugs＠winehq.org

11 p.m.

New subject: [Bug 33236] Bible Converter Project fails to convert anything (VMWare ThinApp 4.x, Wine's LdrLoadDll doesn't behave like native, needs to call NtXXXSection API)

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

Anastasius Focht focht@gmx.net changed:

--- Comment #5 from Anastasius Focht focht@gmx.net 2013-03-17 18:00:21 CDT --- Hello folks,

the application starts a helper process "Simple_Bible_Reader_v2.3.exe" which is extracted from resource section of main executable.

--- snip --- 002b:Call KERNEL32.CreateProcessW(00000000,0032d858 L"C:\users\focht\Temp\tmp7ac4.tmp.exe BIB 0 "" 1 "" True "C:\users\focht\Temp\tmp7ac5.tmp.log"",00000000,00000000,00000000,00000400,00000000,00000000,0032cf00,0032cef0) ret=7e1c0cd3 ... 002f:Call KERNEL32.__wine_kernel_init() ret=7bc546d0 002f:trace:loaddll:load_native_dll Loaded L"C:\users\focht\Temp\tmp7ac4.tmp.exe" at 0x79bf0000: native 002b:Ret KERNEL32.CreateProcessW() retval=00000001 ret=7e1c0cd3 --- snip ---

tmp7ac4.tmp.exe -> Simple_Bible_Reader_v2.3.exe

Unfortunately "Simple_Bible_Reader_v2.3.exe" is wrapped with VMware ThinApp 4.x. (hence the source code of the main application is useless here).

--- snip --- Generic check : VMware ThinApp 4.0.x - 4.6.x - 2011 - Copyright 2006-2009 VMware, Inc. thinstal.com / www.vmware.com , Overlay : 090500... Nothing discovered ... ThinyApp Packager Suit - packed crypted --- snip ---

This application virtualization (sandboxing) solution hooks many native API. Reminds me of bug 23451 (which is about native API process creation sequence).

--- snip --- ... 002b:Call KERNEL32.GetModuleHandleW(79bf2282 L"nt0_dll.dll") ret=79bf21bc 002b:Ret KERNEL32.GetModuleHandleW() retval=00000000 ret=79bf21bc 002b:Call KERNEL32.SetFilePointer(0000003c,000ba186,0032ed6c,00000000) ret=79bf1f08 002b:Ret KERNEL32.SetFilePointer() retval=000ba186 ret=79bf1f08 002b:Call KERNEL32.ReadFile(0000003c,0032ed8c,0000000c,0032ed68,00000000) ret=79bf1f1a 002b:Ret KERNEL32.ReadFile() retval=00000001 ret=79bf1f1a 002b:Call KERNEL32.VirtualAlloc(00000000,00018185,00101000,00000040) ret=79bf171d 002b:Ret KERNEL32.VirtualAlloc() retval=7ffb0000 ret=79bf171d 002b:Call KERNEL32.SetFilePointer(0000003c,000ba192,0032ed68,00000000) ret=79bf1f08 002b:Ret KERNEL32.SetFilePointer() retval=000ba192 ret=79bf1f08 002b:Call KERNEL32.ReadFile(0000003c,7ffb0000,00018185,0032ed64,00000000) ret=79bf1f1a 002b:Ret KERNEL32.ReadFile() retval=00000001 ret=79bf1f1a 002b:Call ntdll.NtCreateSection(0032ed54,0000000e,00000000,0032ed5c,00000040,08000000,00000000) ret=79bf26c1 002b:Ret ntdll.NtCreateSection() retval=00000000 ret=79bf26c1 002b:Call ntdll.NtMapViewOfSection(00000040,ffffffff,0032ed70,00000001,00000000,00000000,0032ed58,00000002,00100000,00000040) ret=79bf2700 002b:Ret ntdll.NtMapViewOfSection() retval=00000000 ret=79bf2700 ... 002b:Call ntdll.LdrLoadDll(00000000,00000000,00354218,0032eb28) ret=003403c3 002b:Ret ntdll.LdrLoadDll() retval=c0000135 ret=003403c3 002b:Call ntdll.NtRaiseHardError(40000015,00000001,00000001,0032e31c,00000000,0032e310) ret=0033c895 002b:fixme:ntdll:NtRaiseHardError : stub. Errorstatus was 40000015 002b:Ret ntdll.NtRaiseHardError() retval=c0000002 ret=0033c895 002b:Call ntdll.NtTerminateProcess(ffffffff,c0000001) ret=0033c8bf --- snip ---

The problem here is that Wine's loader doesn't behave like native loader (some native APIs are not called during dll load sequence).

MSDN article that describes what native does: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx ("What Goes On Inside Windows 2000: Solving the Mysteries of the Loader")

The virtualizer expects LdrLoadDll internal helpers to check and map the file through NtXXXSection() API (NtOpenSection with the fully qualified file name to check for existence, NtCreateSection + NtMapViewOfSection for loading etc.).

Wine's loader doesn't do this hence the hooked native API never get called, leading to failure.

Regards

wine-bugs＠winehq.org

29 May 29 May

6:05 p.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)

https://bugs.winehq.org/show_bug.cgi?id=33236

Anastasius Focht focht@gmx.net changed:

--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, still present.

'BoxedApp' virtualization scheme (bug 22797 has some examples) also suffers from this.

Download: http://www.download3k.ru/DownloadLink1-BoxedApp-SDK.html

The 'Sample1_DLLEmbedding.exe' example app crashes after clicking the 'call function' button

The 'BoxedApp' application virtualization scheme hooks a large number of native API:

--- snip --- "NtOpenFile" "NtCreateFile" "NtWriteFile" "NtReadFile" "NtDeleteFile" "NtSetInformationFile" "NtQueryInformationFile" "NtClose" "NtCreateSection" "NtOpenSection" "NtFlushVirtualMemory" "NtQueryAttributesFile" "NtSetSecurityObject" "NtMapViewOfSection" "NtQueryVirtualMemory" "NtQuerySection" "NtUnmapViewOfSection" "NtDuplicateObject" "NtQueryFullAttributesFile" "NtQueryVolumeInformationFile" "NtSetVolumeInformationFile" "NtQueryDirectoryFile" "NtLockFile" "NtUnlockFile" "NtFlushBuffersFile" "NtFsControlFile" "NtNotifyChangeDirectoryFile" "NtWaitForSingleObject" "NtWaitForMultipleObjects" "NtExtendSection" "NtCreateKey" "NtDeleteKey" "NtDeleteValueKey" "NtEnumerateKey" "NtEnumerateValueKey" "NtFlushKey" "NtLoadKey" "NtLoadKey2" "NtNotifyChangeKey" "NtOpenKey" "NtOpenKeyEx" "NtQueryKey" "NtQueryMultipleValueKey" "NtQueryValueKey" "NtReplaceKey" "NtRestoreKey" "NtSaveKey" "NtSetInformationKey" "NtSetValueKey" "NtUnloadKey" "NtRenameKey" "CreateActCtxW" "NtQueryObject" "RtlQueryInformationActivationContext" "LdrGetDllFullName" "CreateProcessA" "CreateProcessW" "CreateProcessAsUserW" "WinExec" "LdrLoadDll" "LdrUnloadDll" "NtQueryInformationProcess" "NtQuerySecurityObject" "NtAccessCheck" "CoRegisterClassObject" "CoRevokeClassObject" "CoFreeUnusedLibraries" "CoCreateInstance" "CoCreateInstanceEx" "CoGetClassObject" "CoRegisterSurrogate" "EncryptFileW" "DecryptFileW" --- snip ---

Example: original entry point 'ntdll.LdrLoadDll'

--- snip --- 7BC57D4B 8BFF MOV EDI,EDI 7BC57D4D 55 PUSH EBP 7BC57D4E 8BEC MOV EBP,ESP 7BC57D50 5D POP EBP 7BC57D51 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4] 7BC57D55 83E4 F0 AND ESP,FFFFFFF0 7BC57D58 FF71 FC PUSH DWORD PTR DS:[ECX-4] 7BC57D5B 55 PUSH EBP 7BC57D5C 89E5 MOV EBP,ESP 7BC57D5E 56 PUSH ESI 7BC57D5F 53 PUSH EBX 7BC57D60 51 PUSH ECX 7BC57D61 83EC 2C SUB ESP,2C 7BC57D64 E8 A76DFCFF CALL ntdll.__x86.get_pc_thunk.bx ... --- snip ---

With trampoline:

--- snip --- 7BC57D4B E9 B08267FF JMP 7B2D0000 7BC57D50 5D POP EBP 7BC57D51 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4] 7BC57D55 83E4 F0 AND ESP,FFFFFFF0 7BC57D58 FF71 FC PUSH DWORD PTR DS:[ECX-4] 7BC57D5B 55 PUSH EBP 7BC57D5C 89E5 MOV EBP,ESP 7BC57D5E 56 PUSH ESI 7BC57D5F 53 PUSH EBX 7BC57D60 51 PUSH ECX 7BC57D61 83EC 2C SUB ESP,2C 7BC57D64 E8 A76DFCFF CALL ntdll.__x86.get_pc_thunk.bx ... --- snip ---

'BoxedApp' scheme tries to place the thunks near the dll being hooked:

--- snip --- ... 0023:Call KERNEL32.LoadLibraryA(100c2470 "ntdll.dll") ret=10001480 0023:Ret KERNEL32.LoadLibraryA() retval=7bc10000 ret=10001480 ... 0023:Call KERNEL32.GetSystemInfo(0033f6ac) ret=1000115b 0023:Ret KERNEL32.GetSystemInfo() retval=0033f6ac ret=1000115b ... 0023:Call KERNEL32.VirtualQuery(7bc216dc,0033f6d0,0000001c) ret=10001179 0023:Ret KERNEL32.VirtualQuery() retval=0000001c ret=10001179 0023:Call KERNEL32.VirtualAlloc(7bce0000,00000005,00002000,00000040) ret=100011d4 0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4 0023:Call KERNEL32.VirtualAlloc(7bcd0000,00000005,00002000,00000040) ret=100011d4 0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4 ... 0023:Call KERNEL32.VirtualAlloc(7b2e0000,00000005,00002000,00000040) ret=100011d4 0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4 0023:Call KERNEL32.VirtualAlloc(7b2d0000,00000005,00002000,00000040) ret=100011d4 0023:Ret KERNEL32.VirtualAlloc() retval=7b2d0000 ret=100011d4 0023:Call KERNEL32.VirtualAlloc(7b2d0000,00000005,00001000,00000040) ret=100011f8 0023:Ret KERNEL32.VirtualAlloc() retval=7b2d0000 ret=100011f8 0023:Call ntdll.RtlMoveMemory(00592716,0033f698,00000004) ret=10001231 0023:Ret ntdll.RtlMoveMemory() retval=00592716 ret=10001231 0023:Call ntdll.RtlMoveMemory(7b2d0001,0033f698,00000004) ret=10001254 0023:Ret ntdll.RtlMoveMemory() retval=7b2d0001 ret=10001254 ... 0023:Call KERNEL32.VirtualAlloc(7b2c0000,0000000b,00002000,00000040) ret=100012df 0023:Ret KERNEL32.VirtualAlloc() retval=7b2c0000 ret=100012df 0023:Call KERNEL32.VirtualAlloc(7b2c0000,0000000b,00001000,00000040) ret=10001306 0023:Ret KERNEL32.VirtualAlloc() retval=7b2c0000 ret=10001306 0023:Call ntdll.RtlZeroMemory(0033f6ec,00000016) ret=10023d70 0023:Ret ntdll.RtlZeroMemory() retval=0033f6ec ret=10023d70 0023:Call ntdll.RtlMoveMemory(0033f65c,7bc216dc,0000000f) ret=10023f01 0023:Ret ntdll.RtlMoveMemory() retval=0033f65c ret=10023f01 0023:Call ntdll.RtlZeroMemory(0033f66c,00000016) ret=10023d70 0023:Ret ntdll.RtlZeroMemory() retval=0033f66c ret=10023d70 0023:Call ntdll.RtlMoveMemory(7b2c0000,0033f65c,00000001) ret=10023f9c 0023:Ret ntdll.RtlMoveMemory() retval=7b2c0000 ret=10023f9c 0023:Call ntdll.RtlZeroMemory(0033f6ec,00000016) ret=10023d70 0023:Ret ntdll.RtlZeroMemory() retval=0033f6ec ret=10023d70 0023:Call ntdll.RtlMoveMemory(0033f65c,7bc216dd,0000000f) ret=10023f01 0023:Ret ntdll.RtlMoveMemory() retval=0033f65c ret=10023f01 0023:Call ntdll.RtlZeroMemory(0033f66c,00000016) ret=10023d70 0023:Ret ntdll.RtlZeroMemory() retval=0033f66c ret=10023d70 0023:Call ntdll.RtlMoveMemory(7b2c0001,0033f65c,00000005) ret=10023f9c 0023:Ret ntdll.RtlMoveMemory() retval=7b2c0001 ret=10023f9c 0023:Call ntdll.RtlMoveMemory(7b2c0007,0033f698,00000004) ret=1000137a 0023:Ret ntdll.RtlMoveMemory() retval=7b2c0007 ret=1000137a 0023:Call KERNEL32.FlushInstructionCache(ffffffff,7b2c0000,0000000b) ret=10001390 0023:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=10001390 --- snip ---

Intermediate thunk to native hook dispatcher:

--- snip --- 7B2D0000 E9 1B0AD494 JMP bxsdk32.10010A20 7B2D0005 0000 ADD BYTE PTR DS:[EAX],AL --- snip ---

The continuation thunk (called from dispatcher):

--- snip --- 7B2C0000 8BFF MOV EDI,EDI 7B2C0002 55 PUSH EBP 7B2C0003 8BEC MOV EBP,ESP 7B2C0005 E9 467D9900 JMP ntdll.7BC57D50 7B2C000A 0000 ADD BYTE PTR DS:[EAX],AL 7B2C000C 0000 ADD BYTE PTR DS:[EAX],AL --- snip ---

Similar to 'VMWare ThinApp', this virtualization scheme also expects calls to NtOpenFile and NtCreateSection during module load sequence (see http://msdn.microsoft.com/en-us/magazine/cc301727.aspx).

Having those (hooked) API called allows the virtualizer to map the dll from its own internal resources.

Wine doesn't call those API, see internal 'load_dll'.

$ sha1sum boxedappsdk__demo__3_3_5_7.zip bfbdd0df4526cd34615a8d13a788a6cdc8713041 boxedappsdk__demo__3_3_5_7.zip

$ du -sh boxedappsdk__demo__3_3_5_7.zip 25M boxedappsdk__demo__3_3_5_7.zip

$ wine --version wine-1.7.19-70-gd6a59f7

Regards

-- 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.

wine-bugs＠winehq.org

20 Feb 20 Feb

1:18 p.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)

https://bugs.winehq.org/show_bug.cgi?id=33236

Qian Hong fracting@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com

-- 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.

WineHQ Bugzilla

3 May 3 May

9:04 p.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)

https://bugs.winehq.org/show_bug.cgi?id=33236

Anastasius Focht focht@gmx.net changed:

--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,

revisiting, obviously still present.

Adding some stable links via Internet Archive. The original site is defunct and past snapshots were not successful.

https://web.archive.org/web/20200503205120/https://files.downloadnow.com/s/s...

https://archive.org/details/boxedappsdk__demo__3_3_5_7

$ sha1sum Bible_Converter_v2.3.exe eac46220fa205e874318a9ee7d44fe46d7522e83 Bible_Converter_v2.3.exe

$ du -sh Bible_Converter_v2.3.exe 3.3M Bible_Converter_v2.3.exe

$ sha1sum boxedappsdk__demo__3_3_5_7.zip bfbdd0df4526cd34615a8d13a788a6cdc8713041 boxedappsdk__demo__3_3_5_7.zip

$ du -sh boxedappsdk__demo__3_3_5_7.zip 25M boxedappsdk__demo__3_3_5_7.zip

$ wine --version wine-5.7-170-gd1f858e03d

Regards

-- 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.

WineHQ Bugzilla

20 Oct 20 Oct

10:49 a.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)

https://bugs.winehq.org/show_bug.cgi?id=33236

Paul Gofman pgofman@codeweavers.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com

--- Comment #8 from Paul Gofman pgofman@codeweavers.com --- I suppose this should be fixed, at least in general, in the current Wine. In case some issues are remaining they probably deserve more specific bugs.

-- 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.

WineHQ Bugzilla

26 Oct 26 Oct

10:25 a.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader w.r.t. use of NtXXXSectionAPI (VMWare ThinApp 4.x)

https://bugs.winehq.org/show_bug.cgi?id=33236

Anastasius Focht focht@gmx.net changed:

--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello Paul,

--- quote --- I suppose this should be fixed, at least in general, in the current Wine. In case some issues are remaining they probably deserve more specific bugs. --- quote ---

no, I've checked some VMWare ThinApp 4.x wrapped apps - they don't work. This includes 'Simple_Bible_Reader_v2.3.exe' this bug was initially created for. Wine's loader still doesn't match the needed native API callouts/sequences of Windows loader to have this work.

The BoxedApp 'Sample1_DLLEmbedding' example from comment #6 works now - but that's due to a different reason. I mixed that in here which was a mistake. I will rework meta-bug #22797 to make it useful.

--- snip --- ... 0270:Call ntdll.LdrLoadDll(00000000,00000000,7fda4218,0031ec2c) ret=7fd903c3 0270:Ret ntdll.LdrLoadDll() retval=c0000135 ret=7fd903c3 0270:Call ntdll.NtRaiseHardError(40000015,00000001,00000001,0031e420,00000000,0031e414) ret=7fd8c895 0270:fixme:ntdll:NtRaiseHardError 40000015 stub 0270:Ret ntdll.NtRaiseHardError() retval=c0000002 ret=7fd8c895 0270:Call ntdll.NtTerminateProcess(ffffffff,c0000001) ret=7fd8c8bf --- snip ---

ThinApp native API runtime/wrapper hooks only very few native API/syscalls in Wine at this point and expects them to be called:

There are few more hooks but they are not relevant here (yet).

I've already provided the needed information in my comment #5 from 2013.

https://web.archive.org/web/20200730075037/https://docs.microsoft.com/en-us/...

--- quote --- LdrpCheckForKnownDll allocates two Unicode strings to hold the fully qualified DLL file name and the file name by itself. By calling NtOpenSection with the fully qualified file name, a FileExists operation is performed and LdrpCheckForKnownDll returns a section handle if the DLL is known. Otherwise, the two Unicode strings are freed and LdrpMapDll must call on the services of LdrpResolveDllName and LdrpCreateDllSection. --- quote ---

There is a lot more useful information in this article but this is the first blocker.

https://source.winehq.org/git/wine.git/blob/6373792eec0f122295723cae77b0115e...

--- snip --- 2222 static NTSTATUS open_dll_file( UNICODE_STRING *nt_name, WINE_MODREF **pwm, void **module, 2223 SECTION_IMAGE_INFORMATION *image_info, struct file_id *id ) 2224 { 2225 FILE_BASIC_INFORMATION info; 2226 OBJECT_ATTRIBUTES attr; 2227 IO_STATUS_BLOCK io; 2228 LARGE_INTEGER size; 2229 FILE_OBJECTID_BUFFER fid; 2230 SIZE_T len = 0; 2231 NTSTATUS status; 2232 HANDLE handle, mapping; 2233 2234 if ((*pwm = find_fullname_module( nt_name ))) 2235 { 2236 NtUnmapViewOfSection( NtCurrentProcess(), *module ); 2237 *module = NULL; 2238 return STATUS_SUCCESS; 2239 } 2240 2241 attr.Length = sizeof(attr); 2242 attr.RootDirectory = 0; 2243 attr.Attributes = OBJ_CASE_INSENSITIVE; 2244 attr.ObjectName = nt_name; 2245 attr.SecurityDescriptor = NULL; 2246 attr.SecurityQualityOfService = NULL; 2247 if ((status = NtOpenFile( &handle, GENERIC_READ | SYNCHRONIZE, &attr, &io, 2248 FILE_SHARE_READ | FILE_SHARE_DELETE, 2249 FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE ))) 2250 { 2251 if (status != STATUS_OBJECT_PATH_NOT_FOUND && 2252 status != STATUS_OBJECT_NAME_NOT_FOUND && 2253 !NtQueryAttributesFile( &attr, &info )) 2254 { 2255 /* if the file exists but failed to open, report the error */ 2256 return status; 2257 } 2258 /* otherwise continue searching */ 2259 return STATUS_DLL_NOT_FOUND; 2260 } ... --- snip ---

ThinApp 4.x doesn't hook NtOpenFile() - Wine's equivalent for the "FileExists operation" mentioned in the article, hence it bails early for "special" dlls. It uses the hooked section API to map "special" dlls from/to memory.

$ wine --version wine-5.20

Regards

-- 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.

WineHQ Bugzilla

10:42 a.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader w.r.t. use of NtXXXSectionAPI (VMWare ThinApp 4.x)

https://bugs.winehq.org/show_bug.cgi?id=33236

--- Comment #10 from Paul Gofman pgofman@codeweavers.com --- Thanks for the details. My point was, "LdrLoadDll to behave like native Windows" looks like too broad to easily understand what exactly is currently missing in Wine (given that now Wine does not bypass Nt functions to load a module like that was the case earlier).

Do I understand correctly that to solve this specific bug Wine needs to call NtOpenSection instead of NtOpenFile for modules?

-- 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.

WineHQ Bugzilla

1:24 p.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader w.r.t. use of NtXXXSectionAPI (VMWare ThinApp 4.x)

https://bugs.winehq.org/show_bug.cgi?id=33236

--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello Paul,

--- quote --- Do I understand correctly that to solve this specific bug Wine needs to call NtOpenSection instead of NtOpenFile for modules? --- quote ---

I've revisited that piece of Wine code after long time and might have drawn an incorrect conclusion. Mapping Windows LdrpXXX functionality as described in the article to Wine's internal loader functionality (helper functions) is tricky as various pieces are missing / split in different ways.

The articles states that NtOpenSection() is called from LdrpCheckForKnownDll(). Wine currently doesn't implement 'KnownDlls' and its object directory.

To be honest I don't know the right place for putting a hookable NtOpenSection() in the current Wine loader design.

Regards

-- 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.

WineHQ Bugzilla

17 Nov 17 Nov

7:13 p.m.

New subject: [Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader w.r.t. use of NtXXXSectionAPI (VMWare ThinApp 4.x)

https://bugs.winehq.org/show_bug.cgi?id=33236

Fabian Maurer dark.shadow4@web.de changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de

-- 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.

769

Age (days ago)

4301

Last active (days ago)

wine-bugs@winehq.org

13 comments

2 participants

tags (0)

participants (2)

wine-bugs＠winehq.org
WineHQ Bugzilla