Replies: 4 comments 2 replies
-
Gosh what even is the oldest cpu someone could be running off. I don’t think we have a real need to drop 32 bit but you did just see why we had them in a subdirectory all through dsp. If that many dll in repo root bothers you then it was a mistake to move them out of the subfolder. Honestly I see no reasons to remove them but no reasons to keep them either. Anything hardware in the last 10 years has 64 bit support. There hasn’t been reason to keep a 32bit os since windows xp? But I will leave general warning about removing support for stuff and things:
Story time: My 1st “server” was a busted up asus netbook. Windows xp, 32 bit, single core intel atom cpu at 1ghz, 1gb ram. Everything ran great till the dsp team forced a minimum of win7 and a newer edition of visual studio without any for-warning. Had to upgrade the ram (to its max of a whopping 2gb - when I say potato I mean potato) and install win7 just to build again, and until i could do that I was building on win7 desktop and transferring the exe’s over the network just to run after pulling updates. A lot of other servers at the time were put off by the compiler upgrade. Some folded. Some stopped updating. Not many were vocal about it, so the team likely wasn’t even aware at the time that they had just alienated a bunch of end users (not sure they would have cared, tbh). Later when I was part of the dsp team I made sure we had a transition period and ample warning the next time a compiler upgrade was incoming. So far, we’ve not had any reason to drop any os support since winXp. Between the os using more ram than p did, navmeshes becoming a think and upping the amount of ram the map server needed (even without the meshes on, related core changes started using more) it became clear 2gb wasn’t going to provide a good experience much longer. The Annwn (welsh for “other world”) server packed it in a year and a half later. Oh and that netbook? No screen no keyboard no trackpad. Reeealy busted up. Usually remoted into it. Had to use external everything for the os load. |
Beta Was this translation helpful? Give feedback.
-
Think I still have some old Socket 7 boards/chips stashed somewhere... even an old slot 1 system. When did those 64-bit K8's launch... 2001, 2003? Like 20 years ago? Never know though... some one may want to tinker with a super lightweight/handheld build somewhere out there. Perhaps use a disclaimer approach like SE did with FFXIV after the 2.0 relaunch... it may run fine on XP... but they were not actively supporting it. |
Beta Was this translation helpful? Give feedback.
-
As someone with absolutely no stature in this project, I'll nevertheless add my two cents: please don't ever drop system support without a compelling (and, preferably, overwhelming) reason. I could echo a hundred of Teo's stories. :) |
Beta Was this translation helpful? Give feedback.
-
We're now coming up to what would be the 2024 refresh season and I'm doing a piece of work that is made substantially harder by having to handle Windows 32-bit, so I'm taking this opportunity to drop it support. We've held on long enough! |
Beta Was this translation helpful? Give feedback.
-
Should we drop 32-bit support on Windows?
I just glanced at the root of the repo and noticed our fat list of Windows DLLs:
I'd need to do some testing first, but surely we can drop
x64
anddebug
variants of DLLs?Unless it's actually impossible to link debug/release versions of ZMQ/Program...
I'm 99% sure that the default configurations on Windows are 64-bit and you'd have to go a little out of your way to enable 32-bit.
EDIT: This would be as part of the 2022 Refresh effort, where I'll be re-compiling these DLLs anyway
EDIT2: I ended up preserving 32-bit and updating all the DLLs as necessary
Beta Was this translation helpful? Give feedback.
All reactions