D3DKMT wrapper works wrong
Svyatpro opened this issue · 14 comments
Simple Direct2D test doesn't work correctly with WineD3D's d2d1.dll with your GDI32:D3DKMT wrapper.
However, using GDI32.DLL wrapper from One-Core-API works properly.
Here is test application:
https://bugs.winehq.org/attachment.cgi?id=49553
oh many thanks, now i have a test application to properly implement it... it was just a test implementation as the program that initially required it.... didnt used it on the programs i tested :)
I am not sure what is wrong here Svyatpro.
Please detail the issue.
oh, btw about the test application, how do we use it? as it's all in japanese? i did "direct2D" and click on the button on that same line... and it appears to work fine here on XP (so i assume the program is already patched?)
No. You need to have Wine Direct2D installed.
If there is no proper d2d1.dll loaded the Test application switches to GDI renderer.
Make sure you have all WineD3D binaries installed including d2d1.dll and do the following to test:
Choose Direct2D and click a button on that same line with "GDI", "GDIPLUS", "Direct2D".
If your implementation is fine you will see different lines painted very fast, but with your GDI3x.DLL forced in WineD3D.dll, I only see a blank testing field.
WineD3D_win2k.zip
Try these binaries. It includes everything you need on testing.
d3d10_1.dll and dwrite.dll from both OCAPI and AppCompat folders have unresolved dependencies, even after patching with DLLCompat.
OCAPI
dwrite.dll
kernel3x.dll
GetLocaleInfoEx
IsValidLocaleName
LCIDToLocaleName
d3d10_1.dll
kernel3x.dll
InitOnceBeginInitialize
InitOnceComplete
AppCompat
All the above and a few more
dwrite.dllgdi3x.dll
GetFontFileInfo
GetFontRealizationInfo
So, some things must be implemented before we can even test your case.
In other words, I don't have everything for testing. I have "most of it" :p
Here you are. d3d10_1.dll now has no unresolved dependencies (Regular Wine version).
DWrite.dll is not required in this test.
Right, I've come back with Direct2D test results.
OCAPI: image will be drawn/updated only once, after a delay.
DllCompat: image will not be drawn, at all.
The OCAPI behaviour also happens in windows 7 x86 VM(pre-SP1), with real Direct2D.
Same OCAPI behaviour reproduced on Win10 x64 PC(real Direct2D) of a friend, just to be sure.
Yes, OCAPI has a GDI3X.DLL that wraps D3DKMT* functions on its own. DLLCompat has GDI3X.DLL from your wrapper project.
But neither you test on XP/Vista/7/10 there should be no differences because all key functions and API's are locally distributed.
It would seem to me that the failure point is somewhere between D3DKMTCreateDCFromMemory and D3DKMTDestroyDCFromMemory.
Removing the GetObjectType checks(return val 0) from D3DKMTDestroyDCFromMemory makes the demo app work(but it's very wrong).
Furthermore, GetObjectType inside D3DKMTCreateDCFromMemory works flawlessly.
Perhaps taking a look at source of the demo to see what other GDI32 apis are called along the way on the D3DKMT_CREATEDCFROMMEMORY will help solve this.
This issue if far from dead and buried.
Commenting out "return STATUS_INVALID_PARAMETER"s in D3DKMTDestroyDCFromMemory is most definitely not a proper fix :p
d2d1.dll has magical pixies inside that make it resist ApiMonitor hooking of its static imports.