Hello,
Am 13.07.2022 um 11:30 schrieb Gisle Vanem gvanem@online.no:
I see that the sources are full of '_MSC_VER' and assume it would be possible.
Yes, building with msvc is something we have an eye on. It is not very actively maintained though.
E.g. I have a Visual Studio project that is de facto a separate build system for the d3d parts of Wine plus some related things: https://github.com/stefand/wined3d_vs
If your main goal is to build and run things on Windows, maybe mingw is easier to use. It comes with more unix-y utilities and you can build binaries targeting windows with Wine's builtin autoconf-based build system.
If you need msvc (e.g. I started that wined3d_vs thing to use Microsaoft's perfmon) you will hit some bugs.
So are we supposed to use Wine's 'win32u.dll' as a trampoline to the real and undocumented functions?
Use Wine's import libs (win32u.lib) to link, yeah. Microsoft's import libs either don't exist any more in modern SDKs (e.g. d3d8.lib) or some functions got removed (I think there's some gdi32.lib stuff that used to be there and is now missing).
You can also submit a patch to remove the exports from our own implib (mark it -private in the .spec file) and solve it with GetProcAddress in other modules. If Windows doesn't export it, we generally shouldn't export it either. But if it is an internal-ish module like win32u our motivation to have a lot of GetProcAddress code is limited.
How do you get Wine's implib in Visual Studio? Build Wine's win32u in Visual Studio and tell it to generate one. At least that's what I did with d3d8, and then link d3d8_test.exe against that self-built import lib.
Then there is 'DrawCaptionTempW'. I find no prototype for it in the Win-Kit SDK. But I find it in TDM-MinGW's 'libuser32.a'. Ref: https://gist.github.com/wbenny/123a41973af776df9c7d5610586b9e9d
Regarding headers, building against Microsoft's headers is unsupported. Use Wine's headers. Microsoft's headers have some bugs that we don't want to replicate - e.g. some directx headers have incorrect vtables when building with C instead of C++. We don't want to have a a lot of extra code in e.g. d3d9/tests to accommodate that.
Regarding .idl files, you need to build them with widl, not midl. Microsoft's headers have some cpp_quote() COM interfaces that aren't valid as IDL code in midl, e.g. ID3DInclude. widl accepts some things that avoid cpp-quoting those things.
One day I'll move my visual studio project to Wine's gitlab and I am generally willing to accept merge requests that add non-d3d modules and fix other issues...