While debugging League of Legends I noticed that `LoadLibraryEx()` is invoked with binary filename (non-text) and non-NULL `hFile`.
In Windows such call would return `NULL` with LastError set as `ERROR_INVALID_PARAMETER` but current Wine implementation would try to proceed ahead.
I don't know if this is intentional trick to mess up debugging/reversing tools or if we have some memory corruption before that overwrites filename buffer. But then I can't imagine how `hFile` could have gotten corrupted since shouldn't that be simple static value in register...
Having this MR causes very noticeable difference in LoL:
* without it - process deadlocks
* with it - no deadlock
Also while looking at this, I tried a lot of different flag combinations on Windows 10 and here I implemented so it works exactly like that.
I also implemented test case for non-NULL `hFile` but I didn't bother for other flags since I don't know if we even care about those.
--
v2: kernelbase: LoadLibraryEx validate flags like Win10
kernelbase: LoadLibraryEx support LOAD_PACKAGED_LIBRARY
kernelbase: LoadLibraryEx enforce valid flag combinations
kernelbase: Add test case for LoadLibraryEx() when hFile is non-NULL
https://gitlab.winehq.org/wine/wine/-/merge_requests/4587
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: ntdll: Use public type for SystemSupportedProcessorArchitectures returned data.
include: Add missing enum to wdm.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4605
- Make it present some frames
- Make it check that the frames are from the new device, instead of checking TerminateDevice count; fixes https://bugs.winehq.org/show_bug.cgi?id=55649
- ~~Make it check for and avoid some absurd crash on Windows~~
~~I tried everything I could think of, but Windows absolutely refuses to present a frame after changing the D3D device, instead choosing to return various absurd errors (segfaults, deadlocks, out of memory, etc). I suspect the VMR9 is haunted.~~
edit: Works on Windows now
--
v10: quartz/tests: Improve VMR9 ChangeD3DDevice test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970
Add stubs for CrtImplementationDetails::Thow*ModuleLoadException functions
This will help some applications not crashing.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=34537
Next part will be moving this code to msvcp and to make sure Cin, other related classes are implemented for msvcmxx.dlls
--
v6: msvcm80: Add stub for ThrowNestedLoadModuleException function.
msvcm80: Add stub for ThrowModuleLoadException(String, Exception) function.
msvcm80: Add stub for ThrowModuleLoadException(String) function.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4596
On Tue Dec 5 19:35:28 2023 +0000, Piotr Caban wrote:
> This generally looks good for me. How about changing
> `CrtImplementationDetails_ThrowModuleLoadException_Inner` function name?
> I'm not familiar with the function so it's hard to suggest a better name
> (maybe `CrtImplementationDetails_ThrowModuleLoadException_inner` or
> `CrtImplementationDetails_ThrowModuleLoadException_exc`). In other
> functions we're using lowercase suffix if needed.
> This MR is marked as draft. Please mark it as ready when appropriate.
I will rename to CrtImplementationDetails_ThrowModuleLoadException_inner and What I found that from extensive searching on google and the error messages is that the it trys to rethrow the inner exception as ModuleLoadException.
eg:
https://forum.unity.com/threads/c-wrapper-for-unity.265398/
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4596#note_55104