Is there a 64-bit Steam client for Windows?

[Zhrindhar]

Steam support seems to be oblivious about its own product and has no clue, so I am asking the question here...is there a 64-bit Steam client for Windows? I hope this group is not as lacking in knowledge!! ;-)

[Danger]

Цитата допису aiusepsi:

You don't need to keep the entire patch in memory. It's a streaming process, like a production line. You take data in at one end, and you spit it out onto hard disc on the other side.

You only need to have enough memory for all the stuff that's in flight, which is maximally bounded by hard-disc bandwidth and the time it takes to get from one side of the production line to the other. Fastest SSD I can find at the moment pushes 500 MB/s, so you'd only blow through 2 GB if data spent 4 seconds winding its way through the Steam client; 4 seconds is an eternity, something like 8 billion clock cycles.

Anyways in practice, it'll more usually be bound by your download rate, which is a heck of a lot lower.

Now sure, you need 64-bit numbers to keep track of the whole patch, yeh. But you don't need a 64-bit process to have 64-bit numbers.

Have you noticed how slow the patches occur on things like ARk, etc? It's already insanely slow as it is. Constant indications of downloading, and installing, rinse and repeat. I dare say their streaming and patching capabilities are severely lacking. By the time I've gotten a patch downloaded and installed, I've already grown some gray hairs! LOL

[Stephh]

Salutare
Am o problema cu un joc,tot imi da 'Ets2 has stopped working'
Oare ma puteti ajuta cu problema va rog?

[Vodka Boris]

My steam turn 32 bit but i used it on 64 bit pc

[KIBERMAX]

To create a 64 bit client, Valve has a lot of work to do, and knowing Valve they like to work slowly, if we ever see a steam 64 bit client, it won't happen very soon.

[Crashed]

Цитата допису Termit:

To create a 64 bit client, Valve has a lot of work to do, and knowing Valve they like to work slowly, if we ever see a steam 64 bit client, it won't happen very soon.

Specifically ensuring compatibility with both 64- and 32-bit Steamworks runtimes?

That said, since Microsoft has no plans to depreciate WOW64 there isn't any real reason to make the main client 64-bit.

[aiusepsi]

Цитата допису Termit:

To create a 64 bit client, Valve has a lot of work to do

They're shipping a 64-bit macOS client already. They have very little work to do.

[DePhoegon]

Цитата допису aiusepsi:

Цитата допису Termit:

To create a 64 bit client, Valve has a lot of work to do

They're shipping a 64-bit macOS client already. They have very little work to do.

That's seriously not understanding how MacOS works.

Ya, and the way Mac & windows approaches X64 is different, along with how they approach drivers & system hooks including graphics api.
-- aka, it's easier to do a 64bit macOS program & minimilizes impact, because of how it works.


Does not one actually realize how little it'd actually do & frankly how much bs would be caused, because steam would still need to have both 64 & 32 bit hooks, likes it does now.
-- There really isn't a need to force the browser aspect that is Steam ... to be 64 bit.

Really unless you went out of your way to never once use 32 bit programs ... ever with steam, or ever hook overlay any 32bit application/wraper with steam... you still need the 32bit hook.. >.>

a 32bit steam for windows/linux is leaner & faster w/ no benefits given if it was recompiled into 64bit.

[Crashed]

Цитата допису DePhoegon:

Цитата допису aiusepsi:

They're shipping a 64-bit macOS client already. They have very little work to do.

That's seriously not understanding how MacOS works.

Ya, and the way Mac & windows approaches X64 is different, along with how they approach drivers & system hooks including graphics api.
-- aka, it's easier to do a 64bit macOS program & minimilizes impact, because of how it works.


Does not one actually realize how little it'd actually do & frankly how much bs would be caused, because steam would still need to have both 64 & 32 bit hooks, likes it does now.
-- There really isn't a need to force the browser aspect that is Steam ... to be 64 bit.

Really unless you went out of your way to never once use 32 bit programs ... ever with steam, or ever hook overlay any 32bit application/wraper with steam... you still need the 32bit hook.. >.>

a 32bit steam for windows/linux is leaner & faster w/ no benefits given if it was recompiled into 64bit.

They only shipped a 64-bit Mac client out of necessity, correct? 64-bit Windows has WOW64 and 64-bit Linux has multiarch.

[DePhoegon]

Цитата допису Crashed:

Цитата допису DePhoegon:

That's seriously not understanding how MacOS works.

Ya, and the way Mac & windows approaches X64 is different, along with how they approach drivers & system hooks including graphics api.
-- aka, it's easier to do a 64bit macOS program & minimilizes impact, because of how it works.


Does not one actually realize how little it'd actually do & frankly how much bs would be caused, because steam would still need to have both 64 & 32 bit hooks, likes it does now.
-- There really isn't a need to force the browser aspect that is Steam ... to be 64 bit.

Really unless you went out of your way to never once use 32 bit programs ... ever with steam, or ever hook overlay any 32bit application/wraper with steam... you still need the 32bit hook.. >.>

a 32bit steam for windows/linux is leaner & faster w/ no benefits given if it was recompiled into 64bit.

They only shipped a 64-bit Mac client out of necessity, correct? 64-bit Windows has WOW64 and 64-bit Linux has multiarch.

For what it concerns, and a basic stance of the matter. Windows can extend x86 first, Mac OS is x64 extending x86 There is ALOT more complex subject matter over it & what's better or not is an extreme technical pov.

It actually provided something tangible for the Mac OS system. It wasn't so much 'out of need' as you might think.
-- it was leaner to go 64 bit for the mac client.

You also have to remember, so long as the mainstream majority of processors are x86_64 (which means they are actually hybrids given the x64/AMD64 name) they preform native 32bit & 64bit code execution just fine and both windows & mac are valid measures of how to handle it. The need for a 64bit client would come in when the CPUs switch to IA64 (a 64bit only cpu) or drop the native 32bit part of it (which isn't on the market 'just yet')
-- This will drastically differ if RISC really takes off for desktop systems.

It's not so much the 32bit subsystem for windows (Wow64) it's how windows handles it.
running closer to how Hyper-V itself works.. side by side, where a 64 bit program gets it's native stuff from the windows memory managers (w/e they are, which isn't entirely important), OR WOW64 (the 32bit hookings for windows on windows).
-- Which is why windows is better suited to even allow for 16bit & in extreme conditions 8bit programs in near native performance. [though security layers don't withstand, it's not officially supported]

YOu also have to remember,
1. Updater
2. launcher
3. steam browser (library, store, community, etc windows in the app)
4. Game hooks

These 4 major components of Steam are separated, and can be different bit sizes.
- Steam updater I believe might be 64bit,
- launcher/browser are 32bit
- Game hook uses the correct 64 or 32 bit hooks to mach which ever game is currently being hooked.
- That a 32bit browser client can be running with a launched 64bit game & having used a 64bit steam overlay hook.

That windows has 'problems' if you attempt to hook a program that mismatches the bit it is (32 or 64 itself), and is why Programs like OBS, Discord, Skype, etc will have a 32bit & 64bit hook for each Graphic API it'd support outside native Graphic API calls to the system (typically window share from a window that isn't being made by a program that is using Graphic calls from DirectX, OpenGL, or Vulkin by it self. more or less... It gets complicated... but short answer is, to hook properly... you need to hook on the Graphic API used by said program and safer bets most to any graphically driven games do not use the standard windows 'graphic api' (like windows explorer or a browser will), and instead attempt to address a known Graphics API directly, and things have to match up throughout the chain for windows.)

[aiusepsi]

Цитата допису DePhoegon:

That's seriously not understanding how MacOS works.

Ya, and the way Mac & windows approaches X64 is different, along with how they approach drivers & system hooks including graphics api.
-- aka, it's easier to do a 64bit macOS program & minimilizes impact, because of how it works.

My day job is writing C++ code, which we then compile to support a bunch of different architectures and operating systems. So I'm saying this from experience: if you can compile your code to target x86_64 on macOS, switching from compiling targeting x86 to targeting x86_64 on Windows is trivial.

[Crashed]

Цитата допису DePhoegon:

Цитата допису Crashed:

They only shipped a 64-bit Mac client out of necessity, correct? 64-bit Windows has WOW64 and 64-bit Linux has multiarch.

For what it concerns, and a basic stance of the matter. Windows can extend x86 first, Mac OS is x64 extending x86 There is ALOT more complex subject matter over it & what's better or not is an extreme technical pov.

It actually provided something tangible for the Mac OS system. It wasn't so much 'out of need' as you might think.
-- it was leaner to go 64 bit for the mac client.

You also have to remember, so long as the mainstream majority of processors are x86_64 (which means they are actually hybrids given the x64/AMD64 name) they preform native 32bit & 64bit code execution just fine and both windows & mac are valid measures of how to handle it. The need for a 64bit client would come in when the CPUs switch to IA64 (a 64bit only cpu) or drop the native 32bit part of it (which isn't on the market 'just yet')
-- This will drastically differ if RISC really takes off for desktop systems.

It's not so much the 32bit subsystem for windows (Wow64) it's how windows handles it.
running closer to how Hyper-V itself works.. side by side, where a 64 bit program gets it's native stuff from the windows memory managers (w/e they are, which isn't entirely important), OR WOW64 (the 32bit hookings for windows on windows).
-- Which is why windows is better suited to even allow for 16bit & in extreme conditions 8bit programs in near native performance. [though security layers don't withstand, it's not officially supported]

YOu also have to remember,
1. Updater
2. launcher
3. steam browser (library, store, community, etc windows in the app)
4. Game hooks

These 4 major components of Steam are separated, and can be different bit sizes.
- Steam updater I believe might be 64bit,
- launcher/browser are 32bit
- Game hook uses the correct 64 or 32 bit hooks to mach which ever game is currently being hooked.
- That a 32bit browser client can be running with a launched 64bit game & having used a 64bit steam overlay hook.

That windows has 'problems' if you attempt to hook a program that mismatches the bit it is (32 or 64 itself), and is why Programs like OBS, Discord, Skype, etc will have a 32bit & 64bit hook for each Graphic API it'd support outside native Graphic API calls to the system (typically window share from a window that isn't being made by a program that is using Graphic calls from DirectX, OpenGL, or Vulkin by it self. more or less... It gets complicated... but short answer is, to hook properly... you need to hook on the Graphic API used by said program and safer bets most to any graphically driven games do not use the standard windows 'graphic api' (like windows explorer or a browser will), and instead attempt to address a known Graphics API directly, and things have to match up throughout the chain for windows.)

x86 doesn't even have 8-bit. 16-bit support requires either emulation or virtualization because the necessary processor features are not accessible in Long Mode.

[DePhoegon]

Цитата допису Crashed:

Цитата допису DePhoegon:

For what it concerns, and a basic stance of the matter. Windows can extend x86 first, Mac OS is x64 extending x86 There is ALOT more complex subject matter over it & what's better or not is an extreme technical pov.

It actually provided something tangible for the Mac OS system. It wasn't so much 'out of need' as you might think.
-- it was leaner to go 64 bit for the mac client.

You also have to remember, so long as the mainstream majority of processors are x86_64 (which means they are actually hybrids given the x64/AMD64 name) they preform native 32bit & 64bit code execution just fine and both windows & mac are valid measures of how to handle it. The need for a 64bit client would come in when the CPUs switch to IA64 (a 64bit only cpu) or drop the native 32bit part of it (which isn't on the market 'just yet')
-- This will drastically differ if RISC really takes off for desktop systems.

It's not so much the 32bit subsystem for windows (Wow64) it's how windows handles it.
running closer to how Hyper-V itself works.. side by side, where a 64 bit program gets it's native stuff from the windows memory managers (w/e they are, which isn't entirely important), OR WOW64 (the 32bit hookings for windows on windows).
-- Which is why windows is better suited to even allow for 16bit & in extreme conditions 8bit programs in near native performance. [though security layers don't withstand, it's not officially supported]

YOu also have to remember,
1. Updater
2. launcher
3. steam browser (library, store, community, etc windows in the app)
4. Game hooks

These 4 major components of Steam are separated, and can be different bit sizes.
- Steam updater I believe might be 64bit,
- launcher/browser are 32bit
- Game hook uses the correct 64 or 32 bit hooks to mach which ever game is currently being hooked.
- That a 32bit browser client can be running with a launched 64bit game & having used a 64bit steam overlay hook.

That windows has 'problems' if you attempt to hook a program that mismatches the bit it is (32 or 64 itself), and is why Programs like OBS, Discord, Skype, etc will have a 32bit & 64bit hook for each Graphic API it'd support outside native Graphic API calls to the system (typically window share from a window that isn't being made by a program that is using Graphic calls from DirectX, OpenGL, or Vulkin by it self. more or less... It gets complicated... but short answer is, to hook properly... you need to hook on the Graphic API used by said program and safer bets most to any graphically driven games do not use the standard windows 'graphic api' (like windows explorer or a browser will), and instead attempt to address a known Graphics API directly, and things have to match up throughout the chain for windows.)

x86 doesn't even have 8-bit. 16-bit support requires either emulation or virtualization because the necessary processor features are not accessible in Long Mode.

You're right..
the support from windows (which is unofficial) for 16bit applications to be ran, puts them into a 32bit wrapper, but windows natively supports putting the 16bit through it's own process.. which was the point.
-- I use it for multi-media dos/win3.x games natively on windows 10(x64)

It was ported & adapted from the windows 10 (x86) platform which had it officially supported. (& yes, it used a 32bit wrapper as well, very thin wrapper.. but the technical details are entirely beyond me.)
-- unofficial sources (OTVDM) there are several versions, and if you pair it with the right API programs.. alot of early win 2-3.x/win 95 can be ran near as natively as possible.

The point was more about windows approach being able to offer other paths before others, and doesn't need to extend from one to the other. (which is why moving away from 32bit atm, with a 32bit hybrid processor being the normal, isn't worth the effort)

[DePhoegon]

Цитата допису aiusepsi:

Цитата допису DePhoegon:

That's seriously not understanding how MacOS works.

Ya, and the way Mac & windows approaches X64 is different, along with how they approach drivers & system hooks including graphics api.
-- aka, it's easier to do a 64bit macOS program & minimilizes impact, because of how it works.

My day job is writing C++ code, which we then compile to support a bunch of different architectures and operating systems. So I'm saying this from experience: if you can compile your code to target x86_64 on macOS, switching from compiling targeting x86 to targeting x86_64 on Windows is trivial.

technically true & not. The reasons why it'll be worthwhile on Mac, & not worth while on WIndows (currently) aren't because of the effort persay on the developers end.

[Tharon]

Compiling a 32-bit or 64-bit application isn't as trivial as it may seem.
It is true that it is simply a matter of changing the target in the compiler, but there can be (and often are) compatibility problems with calls to external DLLs or to the operative system.
Nothing insurmountable, but it still requires attention and tests to verify the existence of any problems.

The question then is: is it worth it? In the case of Steam the answer is no.
There is a belief that a 64-bit application is faster and more stable than a 32-bit one, but that is absolutely false. The only difference between a 32-bit and a 64-bit application is the amount of memory they can use. If the application requires less than 4 GB of ram, the adoption of 64 bits is useless, moreover, it is counterproductive since the doubling of the size of the registers leads to a greater use of ram.

In short, a 64-bit version of Steam would only cost effort and won't be any better than a 32-bit one so it just doesn't make sense to create one or request for it.

On Mac, of course, the situation changes, since support for 32-bit executables has been abandoned by Apple.

[Kaldaien]

That would have been accurate a few years ago, but the Steam client would now be constrained by a 32-bit Chromium webhelper that cannot use its thread-optimized memory allocator for lack of address space.

Since 99% of the new client is a web browser and you do not want a 32-bit browser starved for memory, it stands to reason it's time for 64-bit. Valve realized this and the client is already 64-bit on Windows save for the service component.