2019-09-11 23:51:49

Hey folks,

Doing some interesting game engine accessibility work that I can hopefully share soon, but one issue I'm running up against are 32-bit builds. Specifically, I'm trying to package my work to make it easier to use, and I can't get a 32-bit build of this code compiling either on my Windows 10 test VM or on Appveyor.

I don't use Windows heavily, but I'm wondering to what extent those of you who do think this is a big deal?

I'm kind of inclined to declare that it isn't. I think my last 32-bit computer was my 2008-era netbook, unless you count the Samsung Galaxy S III I got in 2012. I've run 32-bit Raspbian on my RPis, but they're 64-bit as well, and I'm only using them for home automation and not gaming. And I haven't had high-end PCs until fairly recently, but even so I haven't had to go out of my way to avoid 32-bit systems. Even my cheap Chinese phone is aarch64, as are all the new $35/$50 RPis just released.

So I'm wondering how much more time I should waste on this before declaring it dead and moving on. To those of you releasing games/software, is there lots of interest in 32-bit under Windows? Or, if you do it, do you only do so to avoid a minority of folks who will try and fail to run your 64-bit app on an older system?

If you'd like to dive into the specifics, see this forum thread: https://users.rust-lang.org/t/cant-buil … dows/32407 Otherwise I just want to know to what extent this is a big deal. Hopefully it isn't, because this is proving to be a big pain in the ass on a whole bunch of levels.

2019-09-12 01:11:39 (edited by Ethin 2019-09-12 01:12:02)

I generally never build my software for 32-bit. Even if people ask, I don't see the point any more. 32-bit is pretty much dead except for very niche environments, and so I generally don't advise that people do it at all (unless they're NVAccess, who *absolutely* refuse to go to 64-bit and only give me excuses).

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 01:14:51

I wouldn't honestly worry about it. You'll get people moaning about it, but they generally have 10 year old systems. While it's unfortunate they might not be able to get something a little more up to date, the world is slowly dropping 32 bit and it's not your fault that stuff isn't compiling on older systems. These people are going to be left in the dust soon enough if they can't get a better system. I feel for them, but it is what it is.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2019-09-12 01:41:03

Thanks, good to know. I can't even get this particular engine working on a 10-year-old 64-bit system because it has very low-end graphics, so having crappy video hardware will probably be a bottleneck before 32-bit support is. Glad to have the perspective, I'd thought about running 32-bit Windows to run old 16-bit DOS games, but even that wasn't a big enough draw to waste space on a 32-bit VM.

2019-09-12 02:13:05 (edited by Munawar 2019-09-12 02:14:31)

Agreed re: stick to 64-bit. It took the market a long time to catch up, and part of that is as Ethin said: some companies simply refuse to compile exclusively on 64-bit. This is because they're afraid of breaking compatibility when their fears are generally unfounded since if you buy a system today, 99.9% of the time it will be a 64-bit system.

There was a time when the excuse was "well, 32-bit plugins won't run on 64-bit applications" but what these arguments failed to consider was that even when 64-bit was in full swing, people were still building exclusively for 32-bit systems, perpetuating the problem. So the only way to really move the market forward is for us as developers to simply start dropping 32-bit support.

Right now, many of us, like myself, solve the problem, by writing indirection into our code (I use 32-bit NVDA libs on 32-bit systems and 64-bit NVDA libs on 64-bit systems,) but newer applications shouldn't even worry about 32-bit support. Native 64-bit apps also benefit from better compiler optimization since there are instructions that the compiler can use that it doesn't have access to when compiled for 32-bit. A 64-bit app will run better on a 64-bit processor when compiled natively for 64-bit processors.

So, you're not losing anything by compiling only for 64-bit; there's nothing a 32-bit system can give you that 64-bit can't.

2019-09-12 03:31:09 (edited by Ethin 2019-09-12 03:39:56)

@5, exactly. NVAccess's refusal excuse was because they would need to rewrite the bit bridge to compensate for 64->32-bit transitions and vice-versa (I don't think this is technically necessary since it sounds like the bit bridge already does this). They also cited the excuse of "portability". I get the idea of portability, I really do; but your not getting complete portability unless you start compiling for 64-bit and 32-bit simultaneously (which is its own hell). I just do not support 32-bit at all, and I will refuse to compile anything for 32-bit these days because 32-bit does not provide any kind of advantage other than total portability. (There was this wiki post I saw a month or so ago that discussed what the Linux kernel had to go through just to emulate i386 support. I can't seem to find it any more though...)

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 03:36:55

OK, so possibly a stupid question. Tolk ships with 32-bit and 64-bit NVDA dlls--nvdaControllerClient64.dll and nvdaControllerClient32.dll. Are those tied to the system architecture, or to installed versions of NVDA? I.e. would I need 32-bit Tolk on a 64-bit system if someone has a 32-bit version of NVDA installed?

Not even sure if NVDA ships 32-bit versions--Orca is in Python and shipped in script form, and just imports the libraries installed with my base system. Not sure if those DLLs communicate in-process or use some sort of IPC mechanism, and as such don't care about whatever architecture NVDA is built as.

Thanks again.

2019-09-12 03:40:46

@7, they're architecture specific of windows, not of NVDA. NVDA ships with no 64-bit builds (even though I've been trying to get them to do it).

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 03:41:51

OK, I found the wiki article I was talking about. Its here.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 05:45:19

Nice, going to save reading that full wiki article for when I'm on fewer substances, but thanks for pointing me to it. I'd always seen the 32-bit vs. 64-bit issue under Linux framed as "64-bit binaries use more memory than 32-bit, so choose the 32-bit distro where possible." And while that may technically be true, it seemed a bit like cutting off a limb because it's a quick way to lose 20 pounds, never mind the other losses...

Anyhow, thanks everyone. Interestingly enough, I just read about a dude who writes viruses in new programming languages he's learning, not caring whether or not his Rust virus works on 32-bit systems. So if they're worthless enough for him then they're worthless enough for me too. smile

https://www.guitmz.com/linux-fe2o3-rust-virus/

2019-09-12 06:45:00

Saw that one in 'This Week in Rust'. People say that 64-bit processes use more memory and I just laugh because its only a 4 byte increase. If it were 4 megabytes or kilobytes, then yes, that argument would be a valid concern. But that argument is like attempting to justify not switching to 32-bit from 16-bit programs: 32-bit programs supposedly use more memory, and therefore the 16-bit program is better. I'm sorry but that logic is seriously flawed and makes absolutely no sense. No modern video game would be able to run under 32-bit. Try getting a game like MK 11, Madden 20, or GTA V to run under 2 GB of RAM (to give the OS some to keep functioning). Sorry, not happening.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 08:11:05 (edited by ogomez92 2019-09-12 08:11:17)

Eh, I always build my games 32 bit only (for windows). Mac builds, 64 bit. I make my windows builds 32 bit because I had multiple complaints from people saying that they use 32 bit machines and can't run  my games, so it's easier to have a 32 bit build and no 64 bit until windows pcs start dropping support for 32 bit apps, at which point I will build only for 64 bit.

cheers.

ReferenceError: Signature is not defined.

2019-09-12 14:31:06

@Nolan: not a stupid question at all. The dll you load depends on what you're compiling for. If you compile for 64-bit then load the 64-bit dll.

In managed languages like .NET where you have an "Any CPU" option, you need to write indirection into your code whose logic is like this:

If I'm running on 32-bit then load the 32-bit dll, else load the 64-bit dll

Before TDV had this logic, I was using only the 32-bit dll of NVDA and it worked fine on my 64-bit system. Now, TDV loads the 64-bit dll on my 64-bit processor although it could very well use the 32-bit dll if I compiled my application for 32-bit only.

So, just load appropriate to the architecture you're compiling for and you'll be fine. As Ethin said NVDA doesn't come with 64-bit binaries so it doesn't care, it's your application that cares because you're doing the right thing and compiling natively for the architecture. For example, the 64-bit version of your application won't run the 32-bit NVDA dll properly.

@ogomez92: This is fine if you want to maintain compatibility with the widest range of users running legacy software. But as developers we eventually have to take responsibility and force an upgrade. We're held back by users' choice to run outdated software. It's a lot like the switch to Python 3. Many people, including myself, were resistant to Python 3 (for me up until recently.) But sooner or later you have to realize that the upgrades offer new features and improvements that the old software doesn't have.

To the point about memory consumption, yup I've heard that argument too and it does have its truth, since pointers are 8 bytes on 64-bit processors. So if you allocate an array of four pointers, you'll end up using 32 bytes on a 64-bit processor and only 16 bytes on a 32-bit processor. But this is hardly a reason for not switching to 64-bit. We have more RAM nowadays so we have a lot more room for expansion.

Plus, consider Ethin's example of MK. I imagine they do a lot of work with double-precision numbers because of graphics. Although, DirectX natively uses single-precision numbers in its APIs for efficiency and memory consumption (not sure about their graphics API though.)

On a 32-bit processor since a double is 8 bytes it has to store it into two places (called registers) since a register is only as wide as the word size of the CPU. On a 64-bit processor it can store the double number in a single register and call it a day.

2019-09-12 14:47:00

Some features you enjoy as a 64-bit builder are:
* Implicit SSE and SSE2 support (higher requires a newer processor, though there are few that don't support all of SSE)
* AVX, AVX-512 support
* XOP, FMA4, CVT16, and XSAVe support
* Greater memory availability
* Much better optimizations all around
There are definitely some things I'm forgetting. But you get to enjoy all of this; in 32-bit, you don't know if you have all of this, and some of it you just don't have at all. Take just SSE and SSE2 support, which is required for the x86_64 architecture. On 32-bit, windows has to check to see if your processor supports it before enabling it. On a 64-bit processor, we don't need to check at all; we just enable it and go. XOP, FMA4, CVT16, and XSAVE are updates to SSE, and if you use a good compiler, its probably going to at least use SSE, if not SSE2. (Intels compilers can use all of this technology and can probably generate the best and fastest code, though GCC is right next to it in terms of optimization abilities followed very closely by LLVM.)
@12, I'm guessing that those who complain about 32-bit support are running a 32-bit version of windows on a 64-bit machine. This (as Munawar has outlined multiple times) is a terrible idea, and has major consequences. I would advise you just to start building for 64-bit and tell those who wine about it to shove off and actually upgrade to a 64-bit build of windows. They'd get better performance anyway.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 16:14:44

I agree 32-bit systems are becoming a thing of the past. However, the way I look at it is that some users are still running lower end systems either because the system was purchased a few years ago, or they're not too concerned with the technical side of things, and 32-bit systems are still appealing. Also, if you write 32-bit applications, they tend to run on both 32-bit and 64-bit environments. I think it's just fine to not have to deal with 32-bit builds with the understanding you might lose some users. Also, even though some users may have a 64 bit computer, they still tend to run 32 bit operating systems for some reason. Perhaps it's not viable to try to adapt, but when I compile an app, I usually try to compile 32-bit version.

2019-09-12 17:04:29

@15, 32-bit applications need to go through emulation modes and require other very complicated methods to actually work (see the article I linked to a few posts back). I would classify that as far worse since there's a much greater overhead when using 32-bit apps than if your using something that is native to the processor your running on. Sure, the overhead isn't noticeable but its still there. I would go with 64-bit builds; I'd rather lose users than allow those same users to tell me what I can and can't build my software for. Its technically not my problem if they can't run my software, especially if I explicitly indicate no 32-bit support.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2019-09-12 17:11:24

In windows I still build for 32-bit. I just don't see any advantages to making my games 64-bit. OSX I build 64-bit, but you sort of have to.

Much less active on this forum than in the past.

Check out my live streams: http://lerven.me
follow me on Twitter: http://twitter.com/liamerven

2019-09-12 17:19:52

@16, technical explanations and justifications are good and well, but regular end users don't care about any of that. And again, if you're fine with losing some of that user base, then more power to you. I'm just saying that there is still somewhat  of a case to try to adapt to building for 32-bit systems. 64-bit systems are certainly becoming prevalent, and I agree people should just upgrade, but not everyone is of the same mindset or cares enough about technology to want to upgrade, despite some inherent improvements and lack of future support.

2019-09-12 17:20:52

I would be curious to know how many people are still using 32-bit who arent still on xp?

Much less active on this forum than in the past.

Check out my live streams: http://lerven.me
follow me on Twitter: http://twitter.com/liamerven

2019-09-12 18:49:35

@liam

If you think you are building 100% 64 bit builds for MacOS, TGTR still has some 32 bit. Mainly in sound_lib modules, but if you want more info i can provide. This is a bit off topic so shoot me a DM on twitter. see my signature for my twitter page.

I don’t believe in fighting unnecessarily.  But if something is worth fighting for, then its always a fight worth winning.
check me out on Twitter and on GitHub

2019-09-12 19:45:58

Hello,
I do a bit of light gaming on my school computer. If that counts, I'm using one with 32-bit windows7.

I post sounds I record to freesound. Click here to visit my freesound page
I usually post game recordings to anyaudio. Click here to visit my anyaudio page

2019-09-13 13:41:05

you should still do 32 bit, i my self only build 32 bit. Don't think it would die so soon, that wouldn't also be a catastrofy for blind people but also for sighted. There are a lot of old programs also for sighted people.

Lamas with hats, but with sponge bob as carl Stay tuned.

https://www.youtube.com/channel/UCvAUQt … subscriber