After this and the related MRs, MS Office 365 finally loads. We see the fancy start screen, and we need modify the options to trust the folder we have our Word documents in. This works for `WINWORD.EXE`, `EXCEL.EXE` and `POWERPNT.exe`. I am able to open an existing file and view it.
This MR is limited to showing the first page or so of the Word document. It freezes with the Wine crash dialog basically the moment right after the screen is rendered. There is no backtrace in the dialog, but winedbg points to `v8jsi.dll` and so does the console output without winedbg. Creating new documents is not achieved by this MR either.
-- v4: sppc: Add stubs for MS Office.
From: Daniel Tang danielzgtg.opensource@gmail.com
--- dlls/sppc/sppc.c | 27 +++++++++++++++++++++++++++ dlls/sppc/sppc.spec | 4 ++-- include/slpublic.h | 4 ++++ 3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/dlls/sppc/sppc.c b/dlls/sppc/sppc.c index 8819961d7c6..36dbefbeaa3 100644 --- a/dlls/sppc/sppc.c +++ b/dlls/sppc/sppc.c @@ -39,6 +39,16 @@ HRESULT WINAPI SLGetLicensingStatusInformation(HSLC handle, const SLID *app, con return SL_E_RIGHT_NOT_CONSUMED; }
+HRESULT WINAPI SLGetApplicationPolicy(HSLP handle, const WCHAR *name, UINT *type, UINT *count, BYTE **data) +{ + FIXME("(%p %s %p %p %p) stub\n", handle, debugstr_w(name), type, count, data ); + + *count = 0; + *data = NULL; + + return S_OK; +} + HRESULT WINAPI SLOpen(HSLC *handle) { FIXME("(%p) stub\n", handle ); @@ -48,6 +58,14 @@ HRESULT WINAPI SLOpen(HSLC *handle)
*handle = (HSLC)0xdeadbeef;
+ /* + * Microsoft office stops crashing and just adds to the title a suffix of + * "(Non-Commercial Use) (Unlicensed Product)" if we make the thread sleep forever + */ + for (;;) { + Sleep(1000); + } + return S_OK; }
@@ -58,6 +76,15 @@ HRESULT WINAPI SLClose(HSLC handle) return S_OK; }
+HRESULT WINAPI SLLoadApplicationPolicies(const SLID *app, const SLID *product, DWORD flags, HSLP *result) +{ + FIXME("(%s,%s,%lx,%p) stub\n", wine_dbgstr_guid(app), wine_dbgstr_guid(product), flags, result); + + *result = NULL; + + return S_OK; +} + HRESULT WINAPI SLPersistApplicationPolicies(const SLID *app, const SLID *product, DWORD flags) { FIXME("(%s,%s,%lx) stub\n", wine_dbgstr_guid(app), wine_dbgstr_guid(product), flags); diff --git a/dlls/sppc/sppc.spec b/dlls/sppc/sppc.spec index 6926d4d8b6d..e31dc2a9786 100644 --- a/dlls/sppc/sppc.spec +++ b/dlls/sppc/sppc.spec @@ -30,7 +30,7 @@ @ stub SLGenerateOfflineInstallationIdEx @ stub SLGetActiveLicenseInfo @ stub SLGetApplicationInformation -@ stub SLGetApplicationPolicy +@ stdcall SLGetApplicationPolicy(ptr wstr ptr ptr ptr) @ stub SLGetAuthenticationResult @ stub SLGetEncryptedPIDEx @ stub SLGetGenuineInformation @@ -50,7 +50,7 @@ @ stub SLInstallProofOfPurchase @ stub SLInstallProofOfPurchaseEx @ stub SLIsGenuineLocalEx -@ stub SLLoadApplicationPolicies +@ stdcall SLLoadApplicationPolicies(ptr ptr long ptr) @ stdcall SLOpen(ptr) @ stdcall SLPersistApplicationPolicies(ptr ptr long) @ stub SLPersistRTSPayloadOverride diff --git a/include/slpublic.h b/include/slpublic.h index 3f3a39274d1..e945b2fe841 100644 --- a/include/slpublic.h +++ b/include/slpublic.h @@ -33,6 +33,8 @@ typedef GUID SLID;
typedef PVOID HSLC;
+typedef PVOID HSLP; + typedef enum _tagSLDATATYPE { SL_DATA_NONE = REG_NONE, @@ -63,9 +65,11 @@ typedef struct _tagSL_LICENSING_STATUS } SL_LICENSING_STATUS;
SLCAPI HRESULT WINAPI SLGetLicensingStatusInformation(HSLC, const SLID*, const SLID*, LPCWSTR, UINT*, SL_LICENSING_STATUS**); +SLCAPI HRESULT WINAPI SLGetApplicationPolicy(HSLP, const WCHAR *, UINT *, UINT *, BYTE **); SLCAPI HRESULT WINAPI SLGetWindowsInformation(LPCWSTR, SLDATATYPE*, UINT*, LPBYTE*); SLCAPI HRESULT WINAPI SLGetWindowsInformationDWORD(LPCWSTR, LPDWORD); SLCAPI HRESULT WINAPI SLOpen(HSLC*); +SLCAPI HRESULT WINAPI SLLoadApplicationPolicies(const SLID *, const SLID *, DWORD, HSLP *);
#ifdef __cplusplus }
I removed `IsMSOffice()`. I hope other applications don't regress after this.
prefer to find a way to make Office work without sleeping forever in SLOpen
This can be done in a future MR. Doing so myself would stretch the limits of my abilities.
Is it strictly necessary to set the output pointers to 0xdeadbeef? Would Office work if you just set them to NULL,
No. I am now setting them to NULL as you suggested.
or if you don't set them at all?
That's not a good idea as I would hate debugging nondeterministic bugs caused by that variable being left at arbitrary values. The existing code used `0xdeadbeef` as a sentinel value because of this. I used that value in the original version of this MR to follow that code style.
please only include tests for the functions that you have implemented
I removed the tests for the existing functions. I additionally removed the tests for the functions in the other PR. I don't really understand this module so all I could implement was some limited form of snapshot testing.
pass on both Windows and Wine
The tests probably won't pass on Windows. `SLGetApplicationPolicy` probably needs a real `HSLP handle` but `SLLoadApplicationPolicies` doesn't return a real value. In turn we don't have real `SLID` values. I just removed the tests. Someone can add them once this module is no longer all stubs.
It's looking better now, thanks. I realize that this is a bit onerous, but to maximize the chances of this code being accepted, it should be split into three separate commits:
1. Add SLLoadApplicationPolicies stub. 2. Add SLGetApplicationPolicy stub. 3. Sleep forever in SLOpen.
You may already be a Git expert, but if not, you may find that `git reset HEAD^` and `git add -p` are helpful for redoing a commit as multiple commits.
Patches 1 and 2 will hopefully not be controversial. I still don't know what others are going to think of patch 3. If it is not considered acceptable for mainline Wine, please submit it to [Wine Staging](https://gitlab.winehq.org/wine/wine-staging) instead; one of the goals of the Staging fork is to make things work in ways that would not be considered acceptable in mainline Wine.
Patches 1 and 2 will hopefully not be controversial. I still don't know what others are going to think of patch 3. If it is not considered acceptable for mainline Wine, please submit it to [Wine Staging](https://gitlab.winehq.org/wine/wine-staging) instead; one of the goals of the Staging fork is to make things work in ways that would not be considered acceptable in mainline Wine.
That is not a goal of the wine-staging project, and it is not our intent to be a fork. We accept patches that are fundamentally in the right direction for upstream, even if they're not ready *yet*, but we don't want anything that is fundamentally wrong. We don't intend to maintain anything forever. If this is not deemed acceptable for upstream I don't think we want it in wine-staging either.
On Tue Mar 14 05:55:36 2023 +0000, Zebediah Figura wrote:
Patches 1 and 2 will hopefully not be controversial. I still don't
know what others are going to think of patch 3. If it is not considered acceptable for mainline Wine, please submit it to [Wine Staging](https://gitlab.winehq.org/wine/wine-staging) instead; one of the goals of the Staging fork is to make things work in ways that would not be considered acceptable in mainline Wine. That is not a goal of the wine-staging project, and it is not our intent to be a fork. We accept patches that are fundamentally in the right direction for upstream, even if they're not ready *yet*, but we don't want anything that is fundamentally wrong. We don't intend to maintain anything forever. If this is not deemed acceptable for upstream I don't think we want it in wine-staging either.
I apologize, I meant no offense. I remember that Wine Staging was originally described as a "fork" and that that was a "good thing", but I can't find the email, or maybe I am remembering an in-person conversation at WineConf 2015. I guess whether Staging is a "fork" depends on your definition of "fork".
I do remember conversations at WineConf where people said that Wine Staging is more committed to making things work for the sake of end users than mainline Wine is. I also remember nv*.dll being mentioned, and I got the impression that nothing like those patches in Staging would ever be considered acceptable in mainline. I may have misunderstood; please correct me if I am wrong.
@danielzgtg In the end the decision on whether to include the change to SLOpen in mainline Wine or in Wine Staging is not up to me, so take my advice with a grain of salt.
-
Alex Henrie (＠alexhenrie) -
Daniel Tang
-
Daniel Tang (＠danielzgtg)
-
Zebediah Figura (＠zfigura)