Re: [PATCH v4 0/12] MR2386: windows.perception.stub: Implement IHolographicSpaceStatics2/3 interfaces.

[Mohamad Al-Jaf (＠maljaf)]

On Fri Mar 17 10:14:05 2023 +0000, Rémi Bernon wrote:
> Yes, thanks a lot.
> > Yeah, it might be useful to keep them around. I spent a long time
> > working on it so it would be nice to keep it, but perhaps I should first
> > split it up into smaller additions for easier review. In any case,
> > here's a branch of the headers in case you need it in the future: https://gitlab.winehq.org/maljaf/wine/-/commits/WinRT-Core
> > I can only imagine the time your spent, and thanks for doing that. It
> > may be arguably useful to have them in Wine, but at the same time it's
> > also a lot of additions.
> > The amount of code that is in the SDK IDL files is quite overwhelming, I
> > don't know if there's any saner way to have them than rewriting
> > everything by hand. They are actually generated from some binary
> > metadata, so maybe we could do that too (but then where to source this
> > metadata is a good question).
> > An alternative which I thought about was to implement IDL 3.0 syntax,
> > which I believe allows much terser interface / runtimeclass declaration,
> > and would generate the same header output.
> > Or, somehow, we could make WIDL compatible with the SDK IDL files, and
> > use them directly, but here like with the .winmd metadata, there's the
> > question of how to source it properly.
> > In any case I'm really not looking forward the time where we'll need to
> > stub or implement all these new interfaces...
> > No problem, anything to make review easier for you.

Yeah, it is a lot of additions. Maybe I'll wait for an application to need it before submitting it again, even if it's just for compilation like FireFox mingw.

Interesting, I did notice the Windows SDK idl files say they are autogenerated at the top. Sourcing the metadata is indeed the main problem. There are some in C:\Windows\System32\WinMetadata and you could use the tool Ildasm.exe to disassemble them, but this seems like a grey area around clean room design and might be best to avoid it. Another option would be trial-and-error, just writing and rewriting binary metadata until it generates a similar idl file to the Windows SDK one. Though, I'm not sure if it's worth the effort.

I took a look at the IDL 3.0 syntax and you're right, it's much more concise and would help with the bigger idl files like `windows.ui.core.idl`. The documentation is thorough: https://learn.microsoft.com/en-us/uwp/midl-3/intro

I wouldn't mind stubbing the interfaces, though for windows.ui.core.idl there's definitely too many functions in the `ICoreWindow` interface alone. Implementing them is another issue, hopefully they're not too complex.

Also, thanks for the review! :slight_smile:

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/2386#note_27267