Steam will stop running on Windows 2003 in XXX days

[Shimaaji]

Hi,

Steam just recently started showing the following message in the title bar:

Steam will stop running on Windows 2003 in XXX days.

(It's at 136 days right now, so the day where it stops working would be Tuesday, 1 January 2019.)

Still a bit of time left, but is there an easy workaround?

[spoon0042]

If you just want the message to go away, sure, set the windows version to Windows 7 for Steam in winecfg. Whether or not that breaks other things, well...

[Bob Wya]

Still a bit of time left, but is there an easy workaround?

@Shimaaji

A brought this up (briefly) with Jeremy White (Codeweavers CEO), at the recent Wineconf. tl;dr don't expect a legitimate fix in Wine anytime soon (never??)

The only workaround that actually works still - is the CrossOver Steam Hack (patch)...
This will support WINEPREFIX's which are set to Windows 7 / Windows 10, etc.

The Windows XP AppDefault hacks I added to winetricks only work with Wine Staging (and are still a bit flaky). Obviously this goes away next January (2019) anyway...

If you're not comfortable building Wine from source, I believe all the bundled Lutris Wine builds have this patch by default (certainly the tk-glitch ones do).

Or of course purchase a Crossover license.

Bob

[DarkShadow44]

A brought this up (briefly) with Jeremy White (Codeweavers CEO), at the recent Wineconf. tl;dr don't expect a legitimate fix in Wine anytime soon (never??)

The only workaround that actually works still - is the CrossOver Steam Hack (patch)...

Not sure, what exactly has chromium sandbox to do with that expiry message?
Anyways, I'm not sure why we can't get a legitimate fix in wine for that. For staging, only bug 45650 and bug 45649 are remaining, and I kinda already sorted them out.

[Bob Wya]

A brought this up (briefly) with Jeremy White (Codeweavers CEO), at the recent Wineconf. tl;dr don't expect a legitimate fix in Wine anytime soon (never??)

The only workaround that actually works still - is the CrossOver Steam Hack (patch)...

Not sure, what exactly has chromium sandbox to do with that expiry message?
Anyways, I'm not sure why we can't get a legitimate fix in wine for that. For staging, only bug 45650 and bug 45649 are remaining, and I kinda already sorted them out.

Steam's web store, browser and friends list all use CEF for renderering. Steam enforces sandboxing for the cef.win7 build.

You can disable CEF sandboxing for the cef.winxp build - manually using the -no-cef-sandbox parameter.

Windows 2003 (aka Windows XP 64-bit) and Windows XP support for Steam, will end in January 2019.

The Crossover hack bypasses the main Steam client call to the CEF renderer and allows CEF sandboxing to be forcibly disabled (at present).
This hack works for the cef.win7 Steam process as well.

Vanilla Wine / Wine Staging will have a pretty broken Steam client next year, unless the CEF sandboxing issue is fixed by then.
So a mainlined Wine patch / patchset, that fixes this issue, would be much appreciated!

Bob

[dimesio]

Not sure, what exactly has chromium sandbox to do with that expiry message?

Probably bug 38960; the workaround has always been to set steamwebhelper.exe to XP.

[DarkShadow44]

Steam enforces sandboxing for the cef.win7 build.

Ouch, didn't know that!

Vanilla Wine / Wine Staging will have a pretty broken Steam client next year, unless the CEF sandboxing issue is fixed by then.
So a mainlined Wine patch / patchset, that fixes this issue, would be much appreciated!

Yeah, makes sense. Good thing it's only one tough issue remaining!

[Bob Wya]

@DarkShadow44

I just checked out your recent 32-bit thunking patch...
Is this just to make the pre-existing 32-bit thunking more generic - so it will work across Windows versions?

I was trying to follow the discussion about this at this years Wineconf...
But this was going over my head quite quickly.
I've been teaching myself a bit of x86 assembly - so I've got some idea of what's going on.

If I understood correctly this thunking is a block of bytes, before the "actual" Windows DLL code, that lets you jump to another block of code, before returning to start to execute code in the DLL itself.
I'm still trying to wrap my head around (the big picture) of how Wine loads a DLL into memory...

I guess the patch not quite fully baked for the cef implementation in the Steam client (which I'm guessing is different from chromium).
Although I did notice that the steamwebhelper.exe process doesn't appear to crash at all any more.

Anyway, I appreciate the work you are doing on this! Even if nobody else does...
The Windows Steam client is an important part of the Wine experience!

Thanks
Bob

[DarkShadow44]

I just checked out your recent 32-bit thunking patch...
Is this just to make the pre-existing 32-bit thunking more generic - so it will work across Windows versions?

Steam expects different thunks for different windows versions, so currently it doesn't work properly. The generic approach I tested works across windows versions. Not sure why exactly though, I mostly got empirical data.

If I understood correctly this thunking is a block of bytes, before the "actual" Windows DLL code, that lets you jump to another block of code, before returning to start to execute code in the DLL itself.
I'm still trying to wrap my head around (the big picture) of how Wine loads a DLL into memory...

It's not so much a matter of how Wine loads a DLL into memory, it's quite separate. And I guess you misunderstood what exactly it does. it only applies to ntdll, and not to startup code, but to its exported functions. See, ntdll exports all windows syscalls as Nt* functions. On windows that's just a small shim that calls into the kernel (or into Wow64) but Wine doesn't have syscalls like windows, there's actual code instead of simple thunks.
When a program like chromium tries to hook those functions, it reads unexpected assembly, and errors. That's where the thunks come in, we need to add those, so programs can treat ntdll like on windows.

I guess the patch not quite fully baked for the cef implementation in the Steam client (which I'm guessing is different from chromium).
Although I did notice that the steamwebhelper.exe process doesn't appear to crash at all any more.

AFAIK both cef and chromium have the same source, and I can confirm that with my patches the new steam chat works just fine with the sandbox.

Anyway, I appreciate the work you are doing on this! Even if nobody else does...
The Windows Steam client is an important part of the Wine experience!

Thanks, almost took half of my vacation, so I hope it's of worth to users!

[Bob Wya]

Steam expects different thunks for different windows versions, so currently it doesn't work properly. The generic approach I tested works across windows versions. Not sure why exactly though, I mostly got empirical data.

Just out of interest, would this implementation, work with Steam, when Wine was set to a specific version of Windows compatibility?
Or am I misinterpreting what you are saying here?
E.g. that Steam's CEF sandboxing implementation expects particular a particular byte-code sequence for each Windows version, and your implementation doesn't exactly match any of these sequences...

It's not so much a matter of how Wine loads a DLL into memory, it's quite separate. And I guess you misunderstood what exactly it does. it only applies to ntdll, and not to startup code, but to its exported functions. See, ntdll exports all windows syscalls as Nt* functions. On windows that's just a small shim that calls into the kernel (or into Wow64) but Wine doesn't have syscalls like windows, there's actual code instead of simple thunks.
When a program like chromium tries to hook those functions, it reads unexpected assembly, and errors. That's where the thunks come in, we need to add those, so programs can treat ntdll like on windows.

Ahh yes, reminds me of Guy1524's complaints on irc (#winehackers) about Wine mainly just implementing ntdll.dll, leaving kernel32.dll as all stubs...
Which was causing him some issues with his work on the BattlEye patches for fortnite...

Thanks, almost took half of my vacation, so I hope it's of worth to users!

You only start to appreciate how long it takes to produce a very simple patch for Wine, once you start writing a few...
Especially the re-submissions, etc. It's hard work!

I'm trying to build up a mental model of how Wine works, in the form of the "big picture"...
I need to start mapping / writing up some notes on all of this...

So anyway, thanks for your enlightening comments!
Bob

[DarkShadow44]

Just out of interest, would this implementation, work with Steam, when Wine was set to a specific version of Windows compatibility?
Or am I misinterpreting what you are saying here?
E.g. that Steam's CEF sandboxing implementation expects particular a particular byte-code sequence for each Windows version, and your implementation doesn't exactly match any of these sequences...

Yeah, setting wine to a different windows version makes cef use a different path, expecting different byte-code sequences. However, they have a "relaxed" mode, which I'm leveraging. Even if there is no perfect match, it's still try to patch, my generic approach seems to be enough to make it work just fine.

Ahh yes, reminds me of Guy1524's complaints on irc (#winehackers) about Wine mainly just implementing ntdll.dll, leaving kernel32.dll as all stubs...
Which was causing him some issues with his work on the BattlEye patches for fortnite...

Heh also curious about these patches.
Though kernel32 contains a lot of logic too, just not all the low level logic.

So anyway, thanks for your enlightening comments!

Heh, I love talking about this, so you're welcome.

[spoon0042]

Steam's web store, browser and friends list all use CEF for renderering. Steam enforces sandboxing for the cef.win7 build.

um, does it? It seems to have been working lately.

It still crashes enough to be annoying, but it runs at least.

(3.14 staging winehq deb package / win 7 64-bit prefix / nothing set for apps or libs in winecfg)

[Bob Wya]

um, does it? It seems to have been working lately.

It still crashes enough to be annoying, but it runs at least.

3.14 staging winehq deb package / win 7 64-bit prefix / nothing set for apps or libs in winecfg

With or without Fabian's patch (linked to above)... The Steam store is still blank for me with Wine Staging 3.14.

Clean 64-bit WINEPREFIX, install Steam.
Leaving the WINEPREFIX at Windows 7 compatibility with no overrides.

Building app-emulation/wine-staging with gcc 7.3.0 - to workaround any Wine build issues introduced by gcc 8.1.0.

Bob

[spoon0042]

Weird.

I'm still running with -no-cef-sandbox (obviously? unless I'm completely misreading things)

ps shows C:\Program Files (x86)\Steam\bin\cef\cef.win7\steamwebhelper.exe running with --no-sandbox

[DarkShadow44]

I'm still running with -no-cef-sandbox (obviously? unless I'm completely misreading things)

The point here is, it should work without "-no-cef-sandbox" after my patches. After all, that's all my patches are for.

With or without Fabian's patch (linked to above)... The Steam store is still blank for me with Wine Staging 3.14.

Even after applying both patches from the two bug reports I linked? Because it works for me.

[spoon0042]

Right? I'm still reading Bob's post as -no-cef-sandbox only working on XP.

Would be great if it worked without, don't let me stop you.

[Bob Wya]

I'm still running with -no-cef-sandbox (obviously? unless I'm completely misreading things)

The point here is, it should work without "-no-cef-sandbox" after my patches. After all, that's all my patches are for.

With or without Fabian's patch (linked to above)... The Steam store is still blank for me with Wine Staging 3.14.

Even after applying both patches from the two bug reports I linked? Because it works for me.

Righteo.

So I applied:

• wine-staging-3.14-0009-ntdll-Hack-to-prevent-freeze-in-NtProtectVirtualMemo.patch
• wine-staging-3.14-0010-winebuild-Simplifly-32bit-syscall-thunk-to-fix-issue.patch

(on top of Wine Staging 3.14).

I get the Friends mini-window and the Steam store rendering OK, with win7.cef sandboxing enabled. Good. Very Good in fact.
I do see constant popup dialogs, with the message: SteamAPI_Init() failed. Not so good...

Is this just because I'm not applying the full suite of xx / 10 patches , you've been working on...

Bob

[DarkShadow44]

I do see constant popup dialogs, with the message: SteamAPI_Init() failed. Not so good...

Is this just because I'm not applying the full suite of xx / 10 patches , you've been working on...

No, I do get them too.
Though I don't know why yet, maybe another shortcoming with the sandbox...

Though I get a bunch of

00db:err:module:import_dll Library tier0_s.dll (which is needed by L"C:\\Program Files\\Steam\\steamclient.dll") not found
00db:err:module:import_dll Library vstdlib_s.dll (which is needed by L"C:\\Program Files\\Steam\\steamclient.dll") not found

which is odd, since they exist.
We need better logging when loading a library fails!

[Bob Wya]

I do see constant popup dialogs, with the message: SteamAPI_Init() failed. Not so good...

Is this just because I'm not applying the full suite of xx / 10 patches , you've been working on...

No, I do get them too.
Though I don't know why yet, maybe another shortcoming with the sandbox...

Though I get a bunch of

00db:err:module:import_dll Library tier0_s.dll (which is needed by L"C:\\Program Files\\Steam\\steamclient.dll") not found
00db:err:module:import_dll Library vstdlib_s.dll (which is needed by L"C:\\Program Files\\Steam\\steamclient.dll") not found

which is odd, since they exist.
We need better logging when loading a library fails!

Good that's fine then and pretty identical to what I see!
I worry when I get results inconsistent with other people.

Bob