Data dump and programmatic dump from decompilation and even some other form of data dump is off-limit... I think perhaps sometimes (some of the) wine people are taking it quite strictly. For example, a while ago, I filed an issue about cp932/cp936/cp950/etc are not exactly the same as the unicode consortium's big5/jis/gb to unicode mappings - Microsoft for historical or whatever reasons have codepages which are not 100% identical to unicode consortium's mapping. I wrote a little program to just loop over the mapping and run it on windows, output it to text, and attached them to a bug report - and promptly had the attachments deleted from bugzilla as "you cannot dump window's data structure". But how else can you do it if you want an exact match of behavior? For my purpose then (for MS windows compliance/compatibility as far as a font's encoding coverage goes), I needed an exact match - it must be MS cp* exactly, and not the "approximately the same" unicode consortium mapping... I think the bugzilla issue is still open, but I haven't checked recently. On Thursday 12 December 2024 at 21:49:53 GMT, Fabian Maurer dark.shadow4@web.de wrote:
Hello,
Not sure who, apart from Alexandre, could help here, but I wanted to ask for some clarification on the clean room guidelines (https://gitlab.winehq.org/ wine/wine/-/wikis/Clean-Room-Guidelines)
Let's say we want to add a few new COM classes / interfaces from WinRT for some program. What is the official way to get those header definitions? Copy paste from the official SDK?
Or worse, there is some windows adjacent dlls that only contain typelibs - can we decompile those typelibs to get the COM interface definitions?
Or how about undocumented functions that are documented by third parties? ROS is off limits, all others as well? There are for example C# projects that provide P/Invoke definitions of otherwise undocumented functions.
I think it would be helpful for the wiki to be updated with a bit of clarification.
Thanks in advance, Regards, Fabian Maurer