Building with MSVC

[Gisle Vanem]

Hello list. My first post here.

First off, I'm not using Linux and does not
want to. I'm on Win-10 and would (just for fun)
try to build e.g. Wine's 'explorer.exe' and other
tool using MSVC-2022 and/or clang-cl v.13. I see
that the sources are full of '_MSC_VER' and assume
it would be possible.

I've built all 'tools/' program just fine with a set
of home-brewed GNU-makefiles.

But have some problems with missing symbols during link.
For example these:
   _NtUserMessageCall@28
   _DrawCaptionTempW@28

MSDN came up blank for these. But I see that 'NtUserMessageCall@28'
is exported from my normal 'win32u.dll' on Win-10. But there's
no entry for them in any Win-Kit library AFAICS.

So are we supposed to use Wine's 'win32u.dll' as a trampoline
to the real and undocumented functions?

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

I've read the FAQ so I'm not sure my effort is supported at all.
Or if some MinGW-distro is required.

[Stefan Dösinger]

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

[Gisle Vanem]

Stefan Dösinger wrote:
> > 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

Hello Stefan!

I d/l a .zip from your repo and Chrome+WindowsDefender found
it to contain:
   Trojan:Win32/Wacatac.B!ml
   file: F:\gv\tmp\wined3d_vs-master.zip->wined3d_vs-master/widl/widl.exe

Cloning your repo also found the same issue with 'widl/widl.exe'.
Strange since I built 'widl.exe' myself (using clang-cl) and there were
no issue. But I've managed to built e.g. your 'libwine.lib'.
> 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.

I already use Cygwin tools with GNU-make for MSVC/clang-cl.
Works fine. I used MinGW years ago until I got feed-up with it.
> 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.

Those .spec-files are totally alien to me. I suppose they are
for creating .def files etc. using winebuild.exe. Correct?
Like in your 'wined3d.vcxproj'. But MSbuild fails to find the tool (!?).
> How do you get Wine's implib in Visual Studio?

I don't use it.
> 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.

I've already done that; built 'widl.exe' and generated most (all?)
like this:

$(TOP_DIR)/include/%.h: $(TOP_DIR)/include/%.idl $(TOP_DIR)/widl.exe
    $(TOP_DIR)/widl.exe -I$(TOP_DIR)/include -hH $@ $<