Building with MSVC

[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 $@ $<


-- 
--gv