ship .idl files rather than .h files for windows SDK

[andrewrk]

This is a toolchain installation size optimization.

Many of the C header files Zig ships that come from mingw-w64 have this header:

/*** Autogenerated by WIDL 8.5 from include/xpsrassvc.idl - Do not edit ***/

If we compare total file sizes, it comes out to roughly 40 MiB reduced to 10 MiB:

[nix-shell:~/Downloads/mingw-w64/mingw-w64-headers]$ cat $(find -name "*.idl") | wc -c
10436832

[nix-shell:~/Downloads/mingw-w64/mingw-w64-headers]$ cat $(grep -RIl "Autogenerated by WIDL") | wc -c
41764448

In terms of tarball size it's roughly 2.4 MiB to 724 KB:

[nix-shell:~/Downloads/mingw-w64/mingw-w64-headers]$ cat $(find -name "*.idl") | xz | wc -c
740960

[nix-shell:~/Downloads/mingw-w64/mingw-w64-headers]$ cat $(grep -RIl "Autogenerated by WIDL") | xz | wc -c
2490188

A prerequisite for this issue would be a WIDL implementation in Zig. That could be a fun project for a contributor.

[odecaux]

Exposing such a parser to the user would enable generating bindings to the COM and WinRT APIs.

[nektro]

is this the same IDL that's https://webidl.spec.whatwg.org ?

edit: hmm there are similarities but I think its different https://android.googlesource.com/toolchain/mingw/+/refs/heads/main/mingw-w64-v6.x/mingw-w64-headers/include/xpsrassvc.idl

[Paul-Dempsey]

Microsoft Windows IDL: https://learn.microsoft.com/en-us/uwp/midl-3/

[andrewrk]

Wine has an implementation you can look at. There's also one in mingw-w64 which may or may not just be the code ported from Wine.

[harrylaulau]

Hi, wanna ask a few questions to make sure I understand the issue properly.

Windows SDK from downloaded from MS includes all the .idl and .h of Windows SDK. Since it is not compatible with gnu libc (used with Clang when zig compiles), so Zig doesn't use it. Instead the .h distributed by mingw-w64 is used. These header files are generated by manually parsing the .idl into a gnu libc compatible form of headers (by Migw-w64's widl).

Now since those .h files are big, and they only exist for zig to understand the ABI, doing .idl -> .zig glue code would bring benefits in minimizing dependency, compiler size, improve compatability, probably decrease compiling speed, and make bug management easier.

Am I understanding correctly? Sorry if these are naive questions.

[xinlifoobar]

Do you suggest using the wine implementation, e.g. zig with cpp bindings, or pure zig solution? I'm interested in the latter.

[andrewrk]

Pure zig solution, obviously :-)

[sno2]

Is the status of this issue changed by https://github.com/ziglang/zig/issues/16269#issuecomment-2241286865?

[NyuB]

I would be interested in having a look at this, could you clarify the intended outcome, what options are you considering for this widl integration ?

• No language change:
  • translate the distributed .idl files to .h files once at first usage, which will reduce the distributed tarball size but not the installed files
• A builtin command similar or within @cImport like @idlImport("stuff.idl"), and this could either
  • produce C header content from the IDL file on the fly then feed them to the existing @cImport mecanism
  • directly produce Zig's ast nodes from the IDL without the above indirection
• Something else ?

[tiehuis]

I've created an early wip idl compiler here: https://github.com/tiehuis/zidl