安裝 Steam
登入
|
語言
簡體中文
日本語（日文）
한국어（韓文）
ไทย（泰文）
Български（保加利亞文）
Čeština（捷克文）
Dansk（丹麥文）
Deutsch（德文）
English（英文）
Español - España（西班牙文 - 西班牙）
Español - Latinoamérica（西班牙文 - 拉丁美洲）
Ελληνικά（希臘文）
Français（法文）
Italiano（義大利文）
Bahasa Indonesia（印尼語）
Magyar（匈牙利文）
Nederlands（荷蘭文）
Norsk（挪威文）
Polski（波蘭文）
Português（葡萄牙文 - 葡萄牙）
Português - Brasil（葡萄牙文 - 巴西）
Română（羅馬尼亞文）
Русский（俄文）
Suomi（芬蘭文）
Svenska（瑞典文）
Türkçe（土耳其文）
tiếng Việt（越南文）
Українська（烏克蘭文）
回報翻譯問題
此主題已被鎖定 
討論區規矩與守則
2 
檢舉此篇文章
Steam.exe is still 32-bit and I do believe that does handle a lot of the client logic, correct?
--
I'm not an expert but, I think steam.exe handles all the non-HTTP Steam network connection stuff, "game downloading, decryption and installation", cloud download/upload, license authentication (DRM), and game stat upload/download. It obviously does other stuff too (like the old UI), but I think I got all the most important stuff listed.
The only part, where I can think of that, having a 64-bit code could make a difference is the decryption process when you are downloading a game. But I'm fairly sure, that at best we are talking about few seconds difference in install speed when downloading ~20GB game.
... especially given that tiny little fact that dev time is a finite resource. There's only so many work time to spend and there's projects that got bigger impacts, i.e. the software for the Steam Deck.
I'm really going to have to write a Python script (when I have time) to count the percentage of bytes of code in the Steam client which already have a shipping 64-bit Windows version, because I bet it's pretty high.
Also, it's not like they'd even have to build any extra infrastructure to deal with shipping multiple versions of a binary; they're already shipping 3 versions of the CEF and webhelper binaries[github.com] for Windows, for various combinations of OS versions and bitness.
Overlays have to match the game ( else it causes crashes & other errors ) That steam will always have 32bit ones so long as there are 32bit games & that will include wrappers if an OS can't support that natively anymore.
That the many parts of windows where a program like steam would be better with some parts 32bit & some parts 64bit. This won't change until 'THE LARGEST USER BASE' WINDOWS drops 32bit, and that won't change until cpus stop being hybrid x86_64 as the mainstream default.
ATM, it's easy for linux, windows, or even MacOS to either native or extend support to 32bit because the default CPU is x86_64, and No Mac/Win ARM based chips aren't changing that because the entire back library or programs & games people want to keep are still for the x86_64 design, and aren't even a small fraction of their respective OS %
The point was to refute the idea that Valve shipping 64-bit Steam binaries was some insurmountable maintenance burden. Which it clearly isn't, because all of the code for the Steam client is already shipping as a 64-bit binary, if not on Windows for a particular binary then for sure on macOS.
Yeah, of course. Nobody is saying that the 32-bit binaries should go away, just that they should ship a 64-bit steam.exe and any of the DLLs which currently don't have 64-bit versions so that the main Steam process can run as a 64-bit process.
Just like it isn't an insurmountable maintenance obstacle to ship 64-bit binaries for Steamworks and overlay purposes, it would be perfectly possible to include the same binaries as 32-bit versions in a 64-bit Steam client.
1. 32bit versions of Windows & linux will always exist (untill mainstream CPUs shift off of x86_64)
-- this means they will need to maintain a 32bit version of 'every aspect',
~~ which means there are some aspects of Steam clients that do not & will not benefit being made* into 64 bit when 32 bit is entirely viable.
2. This only introduces more vulnerabilities & security exploits, along with possible 'user generated' misuse of the wrong bit executable.
The way they do it currently supports both systems, prevents dumb users from using the wrong version of the software, and further prevents future work of having to gate off x64bit games from select clients, and further introducing more problem points, that would take even more dev time....
--- and all for what... a needless forcing of windows/linux binaries to be entirely 32/64bit.
You realize that using the justification of 'well they have to ship 64 bit versions of dlls.. is a meaningless & misleading statement.. .they ♥♥♥♥ 32bit versions of them as well. They have an often 'unused' webhook 32bit one for those that use the web browser in the steam overlay for a 32bit game.
the fact of the matter is, the only reason the main 'launcher' is 64 bit, is java & it's just 'easier', and more supported within the bulk of the users.
-aka, it actually served a point.
The bootstrapper is 32bit ..because it serves solution. & Unless there gets to be an otherwise extensive IA64 CPUs.... It will work equally as well on 32 bit windows & 64 bit windows, without giving users the ability to screw up an install in a interesting way. (without really trying & knowing how)
Microsoft are going to stop providing 32-bit versions of Windows 10: https://download.microsoft.com/download/c/1/5/c150e1ca-4a55-4a7e-94c5-bfc8c2e785c5/Windows%2010%20Minimum%20Hardware%20Requirements.pdf
Windows 11 is going to be 64-bit only. So, no, 32-bit versions of Windows & Linux will not always exist. They're already mostly gone.
Just because I'm being paranoid that I'm going to be accused of being misleading: yeah, 32-bit software will still run on 64-bit Windows. But call me old-fashioned, but software should generally actually be for the OS it's running on, rather than running in a compatibility mode.
I'm not sure where you get this idea. The programming mistakes which lead to vulnerabilities and security exploits are things aren't things which are dependent on which architecture the code is compiled for.
But, in 64-bit mode the effect of these vulnerabilities are better mitigated. For example, one security mitigation against vulnerabilities is called address-space layout randomisation (ASLR). This means that each binary is loaded at a random address in the address space, which makes it harder to leverage vulnerabilities into being able to perform remote code execution. In 64-bit mode, there's more address space available, so ASLR is more effective; there's more available address space to randomise in. This is something mentioned by the person who has the last disclose report on Valve's Hackerone: https://hackerone.com/reports/584603 describing a RCE against CS:GO.
This exploit against steam.exe itself: https://hackerone.com/reports/470520 mentions ASLR as well, noting that only about 9 bits are randomised. In a 64-bit process, it's more like 17-19 bits[www.fireeye.com]. This makes it much, much harder to break ASLR; that specific exploit would be at least 256 times harder to pull off, reducing the odds from 1/512 to 1/131072.
I don't see how there's much scope for this. If you somehow try to run the 64-bit executable, Windows just tells you that you're running an unsupported executable.
If you are really, really concerned about this, the (inital) Steam installer is very small, 1.7 MB, putting both the 32-bit and 64-bit executables in there will hardly break the size budget (especially at the client then kicks off a 100 MB+ download to fully install itself. Also: the store front page is about 7 MB!) so putting both executables in there and having the installer pick the right one is simple and user-proof.
This isn't future work, Steam already has 64-bit only games. There's a "64-bit" tag which developers can apply to content depots so it only downloads on 64-bit systems. See, for example, Rust[steamdb.info].
It's not meaningless, and I certainly wasn't trying to be misleading. Yes, they have both 32-bit and 64-bit versions of those binaries. Like I said, the point was to show that porting the entire Steam client is not a huge and difficult task, especially because a very large portion of it is already ported for Windows, and that's not even counting the fact that it's also entirely ported to 64-bit on macOS.
I don't at all know what you're talking about here. Steam doesn't use Java.
IA-64 is Intel's Itanium architecture, which is a completely different thing. It's a completely separate ISA from x86_64.