Protecting the ABI with patents won't help...
I don't know of any patents on the ABI. It's simply undocumented. Are you sure you're not referring to the debug info format, i.e. PDB files? There definitely are some patents surrounding that, but Microsoft has opened up quite a bit and published
enough source code that one could generate their own PDBs from scratch by reading that source code. And the source code is BSD licensed, with comments indicating that they are trying to help LLVM / Clang generate PDBs. And LLVM / clang has been actively adding source code over the past few months to read / write the raw bits of PDB files. So, while I'm not going to comment on the legal aspects of patent issues, you are free to draw your own conclusions here.
Out of curiosity, do you know why clang-cl need some VS bits, and how that works in terms of strict copyright / licensing? I guess they tried to remain open-source (and that's the reason it doesn't support the full ABI) but I haven't spent time in this yet...
Just to be clear, when I talk about "The Microsoft ABI", I am talking about the rules governing the binary code produced by the compiler. Function prologues and epilogues, record layout, name mangling, object file format (i.e. section names etc), and things like that.
Based on this, clang-cl
does support the full Microsoft ABI. It's 100% compatible, short of bugs (which you should report
here). There are some
non-ABI related differences, such as that it uses all of clang's diagnostics engine, supports the same set of C++ features that clang supports, etc. I think also there are a few really obscure Microsoft extensions that are not supported (although all of the more common / useful MS extensions
are supported). And the reason they're not supported is because they're bad and/or unnecessary, not because of patents. Otherwise, clang-cl is intended to produce binary compatible object files and executables.
For example, you can generate a bunch of .obj files with clang-cl, then link them with Microsoft's linker.
So just to make sure we're on the same page, it
does support the full ABI. (If you have a specific example in mind though, feel free to mention it and I'll try to address it).
With that out of the way, I haven't answered yet why clang-cl needs some VS bits. When you install VS you get, among other things, the following:
1. CRT and STL headers and libraries (e.g. <stdio.h>, <vector>, msvcrt.lib, etc)
2. Windows headers and libraries (e.g. <windows.h>, kernel32.lib, etc)
3. Various other support SDKs (e.g. DIA SDK for reading PDB files)
4. The compiler (cl.exe)
5. The linker (link.exe)
6. Various other tools (mt.exe, rc.exe, midl.exe, ml.exe, ml64.exe, etc)
1, 2, and 3 are almost certainly covered by something, but IANAL so I won't speculate on what. In any case, this isn't a big impediment because creating hermetic toolchains is a solved problem, so it seems reasonable to think that someone who already has a license for VS (which, btw, is free and permissive), could copy these files from a valid installation to another machine.
4 is already addressed by clang-cl and is, for all intents and purposes, 100% compatible.
5 is a work in progress. The LLVM linker (lld) is already about 80% compatible with the Microsoft linker. Where it still lacks is in support for generating PDB files, and LTO / PGO. All of those things are actively being developed, and given that Microsoft has opened up on the PDB format (mentioned earlier), there's no reason to think this won't happen with the same level of fidelity as has been achieved with the compiler.
6 is currently the big missing piece. There are 4 primary tools here.
mt.exe is the
manifest tool. It takes a block of xml called an
Application Manifest, and sticks it into the EXE.
rc.exe is the
resource compiler. It takes a
resource file, which is human readable/editable, compiles it into binary format, and sticks that into the EXE. This isn't just for GUI apps despite its name. Things like the executable's version number, publisher information, icon, etc are all resources, and you need a resource file for these things to work.
midl.exe is the "
IDL compiler". It's used for creating and interacting with certain types of COM objects. It takes an
IDL file, parses it, and then generates C++ header files that you can just #include to easily interact with COM objects.
ml.exe is
MASM (Microsoft Macro Assembler). It's pretty much what it sounds like.
All that needs to happen to be 100% complete is to re-write these 4 tools (maybe even just the first 3, it seems reasonable to just say "we don't support MASM, it's not *that* different from the assembly dialect that clang already supports, just re-write your assembly code"). None of them is particularly complicated, and in fact work is beginning soon to do exactly that. Currently the VS bits are needed because without llvm versions of these tools, clang-cl has no choice but to shell out to the one that is installed with VS.
Once that happens, you will be able to build any Win32 executable on any platform (even a big endian system!) provided you have the headers and libraries (e.g. numbers 1, 2, and 3 above) available on that machine.