Main Area and Open Discussion > General Software Discussion

Program Files or Program Files (x86)?

<< < (2/3) > >>

mwb1100:
they cannot figure out how to work together!
-Curt (March 08, 2012, 10:16 AM)
--- End quote ---

What exactly do you mean by this?  If you give more details someone may be able to help.

The only problems I notice between 32-bit and 64-bit programs is that shell extensions often don't work if your file manager and the program providing the shell extension don't have the same 'bitness'.  To resolve this problem, more and more programs that have shell extensions register both 32-bit and 64-bit versions when installing on a 64-bit OS (as they should).

db90h:
I don't think there's any real reason yet to use a 64-bit browser...and this is coming from someone who routinely has 100+ tabs open every day. :)
-Innuendo (March 09, 2012, 09:17 AM)
--- End quote ---

Agreed. It is funny, but years ago I thought x32 would be dead in no time. Here we are, years later, with it still being the defacto standard in most cases because CPU utilization is not usually the bottleneck, and x32 code is nearly as fast as x64 code since x64 code comes with extra memory overhead.

40hz:
Agreed. It is funny, but years ago I thought x32 would be dead in no time. Here we are, years later, with it still being the defacto standard in most cases
-db90h (March 09, 2012, 05:33 PM)
--- End quote ---

Ithink you'll see 32-bit software being deployed and running on 64-bit systems as long as it is possible to continue to do so. Heavily debugged, field tested, and working software is not going to be consigned to the dustbin just because questionable gains might be achieved by going over to "64-bithood."

As long as there's still 32-bit compatibility, there will be 32-bit programs.

vlastimil:
I, for example, have decided not to publish 64-bit editions of some of my applications because it would be unreasonably difficult to maintain the compatibility with 32-bit Photoshop plug-ins (I would have to start a separate 32-bit process and load the 32-bit plug-ins there and then communicate between the main 64-bit process and the child 32-bit process - this would slow things down due to extra data transfers). Also, I use a tiny piece of generated code to speed up image bit-depth conversion that only works for 32-bit environment and the 64-bit edition uses the default slower path.

So, sometimes, the 64-bit editions are almost as good and almost as fast as 32-bit editions... I would stick with 32-bit editions unless the author of the software recommends you to use 64-bit editions or you are running into virtual memory problems.

Innuendo:
Agreed. It is funny, but years ago I thought x32 would be dead in no time. Here we are, years later, with it still being the defacto standard in most cases because CPU utilization is not usually the bottleneck, and x32 code is nearly as fast as x64 code since x64 code comes with extra memory overhead.-db90h (March 09, 2012, 05:33 PM)
--- End quote ---

I think at one point we all thought x86 was going to be dead in no time. 16-bit died because there was huge benefit in moving to a 32-bit architecture. There's just not that much of an advantage to moving exclusively to 64-bit. It does have its advantages, however, so it should be used wherever practical.

I just usually recommend people be very careful when it comes to programs that rely heavily on plugins or you run into the problem Curt did.

Navigation

[0] Message Index

[#] Next page

[*] Previous page