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 should 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.
-- Audiogames-reflector mailing list Audiogamesemail@example.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector