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