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.
-- v5: Sleep forever in SLOpen. Add SLGetApplicationPolicy stub. Add SLLoadApplicationPolicies stub.
From: Daniel Tang danielzgtg.opensource@gmail.com
--- dlls/sppc/sppc.c | 9 +++++++++ dlls/sppc/sppc.spec | 2 +- include/slpublic.h | 3 +++ 3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/dlls/sppc/sppc.c b/dlls/sppc/sppc.c index 8819961d7c6..4287e0e47e2 100644 --- a/dlls/sppc/sppc.c +++ b/dlls/sppc/sppc.c @@ -58,6 +58,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..82e13f43063 100644 --- a/dlls/sppc/sppc.spec +++ b/dlls/sppc/sppc.spec @@ -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..952585f64d9 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, @@ -66,6 +68,7 @@ SLCAPI HRESULT WINAPI SLGetLicensingStatusInformation(HSLC, const SLID*, const S 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 }
From: Daniel Tang danielzgtg.opensource@gmail.com
--- dlls/sppc/sppc.c | 10 ++++++++++ dlls/sppc/sppc.spec | 2 +- include/slpublic.h | 1 + 3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/dlls/sppc/sppc.c b/dlls/sppc/sppc.c index 4287e0e47e2..452ee78cea8 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 ); diff --git a/dlls/sppc/sppc.spec b/dlls/sppc/sppc.spec index 82e13f43063..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 diff --git a/include/slpublic.h b/include/slpublic.h index 952585f64d9..e945b2fe841 100644 --- a/include/slpublic.h +++ b/include/slpublic.h @@ -65,6 +65,7 @@ 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*);
From: Daniel Tang danielzgtg.opensource@gmail.com
--- dlls/sppc/sppc.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/dlls/sppc/sppc.c b/dlls/sppc/sppc.c index 452ee78cea8..36dbefbeaa3 100644 --- a/dlls/sppc/sppc.c +++ b/dlls/sppc/sppc.c @@ -58,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; }
On Tue Mar 14 06:05:47 2023 +0000, Alex Henrie wrote:
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:
- Add SLLoadApplicationPolicies stub.
- Add SLGetApplicationPolicy stub.
- 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.
Done.
I found your Git commands useful for refreshing my memory.
On Tue Mar 14 05:55:36 2023 +0000, Alex Henrie wrote:
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.
The next step after Staging that I know of is Proton. I would not like to have to do that, and they focus on games not office suites anyway. Anything other than Wine itself is harder to install and get working. It's already hard to run Proton outside of Steam, and harder to get other tools used with Wine to work with it.
On Tue Mar 14 06:08:50 2023 +0000, Daniel Tang wrote:
The next step after Staging that I know of is Proton. I would not like to have to do that, and they focus on games not office suites anyway. Anything other than Wine itself is harder to install and get working. It's already hard to run Proton outside of Steam, and harder to get other tools used with Wine to work with it.
[Phoenicis](https://github.com/PhoenicisOrg/phoenicis-winebuild/tree/master/patches) (formerly PlayOnLinux) might also be interested.
On Tue Mar 14 06:19:10 2023 +0000, Alex Henrie wrote:
[Phoenicis](https://github.com/PhoenicisOrg/phoenicis-winebuild/tree/master/patches) (formerly PlayOnLinux) might also be interested.
(Actually, it looks like they still call the software PlayOnLinux on their website, but not in Git?)
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.
I'm sorry, that was curt of me. It's a bit of a sore point.
The original wine-staging project may have been described as a fork by Sebastian or Michael. I wasn't there for those conversations. Under Alistair's leadership though we've been trying to orient the project as specifically not a fork, though, and as a place only for patches that were going in the right direction and would eventually make it upstream. That was something we went into detail on at the 2018 Wine conference.
-
Alex Henrie (＠alexhenrie) -
Daniel Tang
-
Daniel Tang (＠danielzgtg)
-
Zebediah Figura (＠zfigura)