How is it a win in any way? You're not making the program actually work, and you're adding more useless code to the repository. Nor is it contributing particularly interesting work; stubs are not hard to write.
I agree stubs are not interesting, boring, and easy to write, but I still believe they are useful, and help programs work better the majority of the time, wine often spam "FIXME (...) stub" a lot when running programs, while the program appear to run completely fine.
I think the fact https://gitlab.winehq.org/wine/wine/-/merge_requests/2374 made an installer work is a **huge** win for Wine, even if the installed program it installed didn't work properly afterward.
From what other peoples reported, having `SLInstallLicense`, `SLGetSLIDList`, and `SLGetApplicationPolicy` all as stubs in sppc without any extra hacks makes Office365 able to fully install and show a window saying there is a missing license, and it freezes afterwards due to an error related to `v8jsi.dll`, which the code seems to be available here https://github.com/microsoft/v8-jsi under MIT.
Sure, it's not hard, but it's a pain. I've had to deal with that before and I'd really rather not again.
Well, this is definitely foreshadowing a personal project of mine.
Sure. Where would you suggest to put this advice?
Both on the wiki and somewhere visible in the wine code-base.
For the wiki, I'll say putting a link to contributing guidelines there https://wiki.winehq.org/Developers and there https://wiki.winehq.org/Source_Code should be the minimum, cause I often visit the "Source_Code" page to access the gitlab (So I assume other devs may do that too) and the "Developers" because it's where the guidelines are expected to be.
For the codebase, a link to where the guidelines are in `README.md` should be enough.
Including reference or link to guidelines in multiples places is very important to make sure first time contributors don't miss them.
It's actually pretty much impossible. The licenses are encrypted with a private key which is distributed as part of the OS, and which we cannot legally redistribute.
<details> <summary>Info I gathered for partial sppc implementation (Optional read)</summary>
Trying to get info while not reading/accessing closed/restricted information/code, I found the following code which could be helpful in some way, some of these contain stubs but some useful info: - https://github.com/AR1972/Injector/tree/master/asus <- Contain an example license an example usage, the attached license isn't encrypted in any way, and sent as-is into `SLInstallLicense`, if we can at least partially support unencrypted licenses maybe it's a good start? - https://github.com/TGSAN/slshim/blob/master/slshim.c <- Mostly stubs, but still implement some functions giving more insight into how to implement sppc funtions.
I was also able to determine all the calls go thru a windows service that process licenses, I was thinking of making all the license processing stuff locally on the dll instead on an external service, since I only did a surface investigation to avoid reading anything restricted, I don't know where the license data is stored, and thought on making wine use a custom folder to store licenses.
</details>
But now that I'm reassessing the situation with this new info, I can confidently say going from stubs to the maximum level of implementation legally possible in wine will bring fewer benefit to wine than going from nothing to stubs will, off course any stubs would need to return that the license is invalid for legal reasons.
Probably making a patch-set fixing `v8jsi.dll` issues would make theses sppc stubs an undeniable last requirement for Office365 to fully run, and make the stubs no longer part of the "useless clutter" category, would it be fine if I make an MR called "Fully fixing Office365" containing theses stubs if I make sure to use the minimum amount of stubs required to make both the installer and the program itself work properly?
# Stub guideline tangent
@zfigura Also could you give me an example of guidelines on where stubs are or are not allowed, just try to write it like if it was a real guideline, I'll try to follow it to the best of my abilities when making MRs, while keeping in mind what you wrote here is temporary.
I think an example of guidelines for stubs what would align with your line of thought while being reasonable would be:
``` # Contributing stub guideline
Try to avoid stubs and semi-stubs to a minimum, you may only make new stubs or updates existing stubs if **all** of theses condition are met: 1. Making a full implementation or semi-stub require a substantial amount of effort or is not possible in wine. 2. The stub is required to allow a stable and normal execution of a program. 3. The stub must not attempt to bypass, circumvent, or workaround any licensing or content protection system. 4. The stub contain a `FIXME` for debug, a `TRACE` can be used instead **only** if the stubs is being called frequently enough that it is causing noticeable performance issues on the targeted program. 5. The stub behavior is consistent regardless of process name or loaded executable.
You **must** explicitly justify that each of the stubs in your MR follow each of theses rules, and you must explicitly tell which programs is benefiting from the stubs, and in which way it is benefiting from the stub, with a link on where to get a legal copy of the programs if available.
For special cases such as semi-stubs, you must still include justification like stubs.
When improving an existing stub, you must still justify your motivation of the stubs if your are not making a full or partial implementation.
When making COM classes (Aka. vtbl/interface) that contain multiple functions, you may justify the need of a stub per COM class instead of per stub. See: https://wiki.winehq.org/Wine_Developer%27s_Guide/COM_in_Wine#Adding_the_stub...
Note: Your stubs may be rejected if other part of wine prevent the program from running properly, as a general rule, only try to upstream stubs when wine is fully ready to handle the software with your MR applied. ``` (I took a lot of time to proof read this myself)
The condition about "licensing" is for legal reason, as in my opinion, the `Sleep(1000)` in https://gitlab.winehq.org/wine/wine/-/merge_requests/2377 is a clear legal liability for the Wine project. (Note: I'm not a lawyer.) (See "DMCA anti-circumvention provisions" at https://www.law.cornell.edu/uscode/text/17/1201)
The MR https://gitlab.winehq.org/wine/wine/-/merge_requests/5484 is an example of why the exception to COM classes is very important. I even make an explicit reference to https://wiki.winehq.org/Wine_Developer%27s_Guide/COM_in_Wine#Adding_the_stub... in the guideline.
I hope this will inspire you to write a corrected policy on stubs, I would suggest you copy mine as a base and change what you don't like about it. I really want clearer guidelines, this would help a lot and stop peoples wondering why their MR is ignored, as the community could point theses developers to the guidelines.
I know it's a long read, but it should be worth your time.