Building with MSVC

Stefan Dösinger stefandoesinger at gmail.com
Wed Jul 13 03:55:22 CDT 2022


Hello,

> Am 13.07.2022 um 11:30 schrieb Gisle Vanem <gvanem at 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...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220713/f29187b9/attachment.sig>


More information about the wine-devel mailing list