32/64 Bit Wars to cease in 2012.

Prediction: The 32/64 Bit Wars will come to an end in 2012. Everybody is sick and tired of reading those 32 vs 54 stories all over the place.

Hopefully, this following PCWoreld blog will mark the end of this madness:

Windows 7 64-bit Users Living in a 32-bit World?
...
The most obvious example of a 64-bit Windows user living in a 32-bit world is online. Windows users can get a 64-bit version of Internet Explorer, but if you use other popular browsers like Chrome, Firefox, or Opera, then you're going to have to go 32-bit. In fact, if you're a dedicated Firefox user, you may want to think twice before making the 64-bit switch. Although Firefox is supposed to work on a 64-bit system, some Firefox users say the have had to resort to Windows 7's XP mode just to get Firefox to open ...

Don't tell me I am the only one sick 'n tired  reading this stuff.

By summer they will all stop thrashing  this dead horse. I think.

You are? I don't care. It works just fine. If you buy something new, it should be 64 bit unless you have a very good reason not to.

You are? I don't care. It works just fine. If you buy something new, it should be 64 bit unless you have a very good reason not to.

My point was I am tired of wading about it. By now everybody should know that if you run the 64 bit system you should be ready and able to get the 64 bit programs to go with it. If anybody is stuck on FireFox,  just install a 32 bit version of Windows and live in the past.

But if you don't even have a 64 bit CPU, the whole topic is pointless. And many users, the majority, and still using 32 bit CPUs.

Oh I forgot to post the link to PCWorld. Here is is, if anybody cares.
http://www.pcworld.com/article/181165/windows_7_64bit_users_living_in_a_32bit_world.html

I've been using a 64 bit OS for 2 years, and running successive 32 bit versions of Firefox, all bristling with addons, all of that time, and have had no problems whatsover.

In fact, if you're a dedicated Firefox user, you may want to think twice before making the 64-bit switch.

This is just plain bollocks, as we say here in Britain. Where does Geek find these stupid articles he quotes from?

You're from britain? Now Obama makes even less sense ...

Anyhow, Firefox works just fine on 64bit Windows. No problems whatsoever.

You're from britain? Now Obama makes even less sense ...

I know where I stand politically, and while that position* does not coincide exactly with Obama's, I find his opponents deeply repulsive.

* I see some US right wingers call Obama a "European socialist". That is ridiculous. I am a "European Socialist" and even the farthest "left" Democrats are way to the right of even European conservative parties, let alone socialist ones.

My point was I am tired of wading about it. By now everybody should know that if you run the 64 bit system you should be ready and able to get the 64 bit programs to go with it.

You can. The only reason most people use 32-bit browsers is because Adobe has been sitting on their thumbs for years. 64-bit Firefox builds work fine, but I've found that I have to use 32-bit on account of pages not being displayed for lack of things like flash.

Same story for IE, and any other 64-bit Browser. (Except google chrome, which doesn't even offer a 64-bit version for windows.)  For the most part, the problem isn't that it's difficult to make a program 64-bit, but it's difficult (impossible, really) to make your program 64-bit when it has dependencies that have no 64-bit version. In this case, Browser usage for most people depends, at least in part, on flash functionality. While it's arguable whether  that will be needed in the future (with the advent of HTML5) at the current time it is still used quite heavily. In many ways it's sort of sad that a single company's inability to create a 64-bit version of a single component can hold back "acceptance" of 64-bit systems (it hasn't, but it seems to have affected perceived acceptance)

Also, we need to consider the timeline, here.

The first 32-bit processor, the 386, was released in 1987. We didn't have widespread consumer support for 32-bit systems until the release of Windows 95. That's 7 years. The first consumer-oriented 64-bit processor was the AMD Opteron, released in 2005. We're sitting on the same 7 year mark, but the fact is that there hasn't been a "killer app" that necessitates moving to the 64-bit architecture. With 32-bit, it was Windows 95 and the various applications that required it. 64-bit architectures have yet to get one.

If anybody is stuck on FireFox,  just install a 32 bit version of Windows and live in the past.

Why? I use firefox, but I also use the 64-bit version of a number of applications; additionally, with 8GB of RAM I really have no choice but to use a 64-bit OS which even if I only use 32-bit applications will make that 8GB available to them. I also use several applications- and I have several games, which provide 64-bit executables for systems capable of running it; of course if I was to run a 32-bit OS, I'd be unable to use those 64-bit builds, and my 64-bit processor would sit in 32-bit emulation mode, it's 64-bit capabilities completely unused.

Saying that people who are still using firefox should stick with 32-bit windows is foolish. Why artificially limit a system's capabilities purely on the basis of a single application (which in this case, works fine either way anyway, both as a 32-bit running on x64 as well as the 64-bit builds, as ST states, the notation about firefox requiring XP mode or anything to that accord are nonsense)

And many users, the majority, and still using 32 bit CPUs.

Err... where are you getting this information from?

quotes from the link:

Even though 64-bit Windows systems were first introduced with Windows XP

Except they weren't. 64-bit Windows XP came in several versions; the IA-64 version for the Itanium which had terrible performance with 32-bit applications since they ran under software emulation, which isn't even close to the architecture used today; and a AMD64 version (x64) which was essentially Windows Server 2003 and wasn't released until several years after Windows XP, and after SP1 was released. It w imaas, for all intents and purposes, Not windows XP and was not marketed in the same way at all. So this presents an erroneous image.

One example is Real Player, which only recently came out with a 64-bit compatible version--Real Player SP 1.

I don't think anybody has taken Real Player seriously for at least a decade.

As a general rule, 32-bit versions of software will work on a 64-bit system. But that kind of defeats the purpose of upgrading, doesn't it?

No. Not even close. even if you only ran 32-bit applications- the built-in system components and applets will all still be 64-bit and take advantage of 64-bit features.

you're using an XP-era printer or scanner, it's a pretty safe bet that your device will not be 64-bit compatible.

If you still have an "XP era" printer, than that printer has had a Long service life. Buy another bloody printer.

I particularly love how the article hones in on this as if this is the "early days" of 64-bit system adoption. 64-bit is here and it's ALREADY adopted. the vast majority of systems run today by consumers are 64-bit capable, and nearly all systems sold in the last three to four years are x64. (I was unable to find concrete stats myself, but if one was to base such statistic purely on the systems being used by members seeking help on this forum it's a rare case where they have a system that isn't x64).

I don't think anybody has taken Real Player seriously for at least a decade.

Does that still exist? Boy, that is one annoying program.

Does that still exist? Boy, that is one annoying program.

well if we believe the article it does. I was surprised as well. I imagine nobody actually installs it on purpose, it probably has to get itself bundled into installers to get into people's PCs.

Does Geek realize this article dates from 2009?

Geek, what year do we live in?

[Moderator]

Many of his news articles are older.

Many of his news articles are older.

heh "news"...

Thanks all for rounding out this thread.  This is not 'News'  actually. Rather the point is that the industry should by now be over this 32/64 bit thing. As BC said, there is an apparent n7 year cycle. Still people complain about FireFox and lack of 64 bit support. And Adobe. And whoever. Even some printers and recently been on the market without real 64 bit Windows 7 drivers.

So, my prediction is that the 32/64 Bit Wars will end in the summer of 2012.
And not just 'cause In said so. Because it is about time. 

Also, the Mayan predictions about 2012 were about 64 bit computation, not the end of the world. The Mayans were waiting for 2012 before they went 64 bit. -----
It is just simple  logic.   

[Moderator]

Wow...

[Malware Removal Specialist]

In fact, if you're a dedicated Firefox user, you may want to think twice before making the 64-bit switch. Although Firefox is supposed to work on a 64-bit system, some Firefox users say the have had to resort to Windows 7's XP mode just to get Firefox to open ...

Waterfox - The fastest 64-Bit variant of Firefox!

Oh, and here's another interesting tidbit:

if a program is written in Java, it will work just fine on any platform, as long s the proper VM is installed; (you can install 32-bit java on a 64-bit windows system too, I think, but there isn't any compatibility issue as far as the java code goes (unless the programmer adds it).

Same story for .NET applications, but you cannot easily install the 32-bit version on a x64 system (the 32-bit version really comes with the 64-bit version anyway). And the program is compiled basically when you run it- if you have a 64-bit system, the result is a 64-bit program. If you have a 32-bit system, it's 32-bit, etc. Even applications written in C/C++ often have both the 32-bit version and 64-bit version in the same file; some good examples of that being tools like Process Monitor, Process Explorer, and so forth, which wrap a 64-bit executable within a 32-bit executable, and when it starts, it unpacks the 64-bit version and runs it if it detects the machine is x64, otherwise it runs the 32-bit version.

And at this point, the creation/compilation of a 64-bit version of a program is often just a compiler switch away. As I noted, the main issue is that many programs rely on other components that don't have 64-bit equivalents, which is often beyond their control. This throws a monkey wrench into the works even for .NET and java applications; many java applications reference third party libraries or make system calls using JNI for a better user experience; these system calls differ by version and java and .NET go to a lot of trouble to make the system you are running on "transparent"- which is to say there is no obvious way to tell, without trying to be clever (Such as measuring the size of a IntPtr).

Personally, this has had a rather large effect on me, and most of my applications are now "force" compiled to be x86. This is because of my game, BASeBlock, which naturally requires the use of sound. I chose BASS.NET for a sound library. Unfortunately, there is only a 32-bit assembly for that, and in order to reference a 32-bit assembly, your assembly must be 32-bit. But since a 32-bit assembly can only reference a 32-bit assembly, I also had to change my update library to be 32-bit; and since some of my other applications used that library, I had to change their compilation options as well, etc. None of them would really benefit from the additional advantages of x64 (they don't do any heavy data processing or use gobs of memory) but it is still a massive pain in the rear; not to mention if I merely overlooked a x64 version (of the sound library), I'd end up having to test everything twice; once as x64, and once as x86. And then again on Mono for the same platforms, which makes things even more painful.

This may be why a large number of applications aren't 64-bit; for the same reason a large number of applications weren't 32-bit earlier; they simply didn't need it, and since it's usually wise to target for a lowest common denominator, they simply settled on 16-bit. In much the same fashion, we have various developers who simply  can't be bothered with 64-bit, and since they want it to work on 32-bit and know that a 32-bit program will also run on windows x64, they simply make a 32-bit version and forget about it.

Once the majority of systems are running x64, and developers can look on 32-bit as a thing of the past, like 16-bit before it, 64-bit will become the commonplace "default" for any application. At this point the "default" is to make it 32-bit, and make a 64-bit version if possible. Eventually, it will switch to make a 64-bit version and a 32-bit version if possible.

Oh, and here's another interesting tidbit:
...
Once the majority of systems are running x64, and developers can look on 32-bit as a thing of the past, like 16-bit before it, 64-bit will become the commonplace "default" for any application. At this point the "default" is to make it 32-bit, and make a 64-bit version if possible. Eventually, it will switch to make a 64-bit version and a 32-bit version if possible.

a
Point well mad BC. 
The is a very simple mechanism where a compiler thing can do a 64 bit EXE file that will convert itself into 32 bit when appropriate at run time. Perhaps that is what you were talking about. Or maybe not. Anyway, developers should consider doing something like t that. As you said, that should work unless the programmer was making assumptions about the size of pointers. But even that can be fixed. You just pay the programmer's unemployment compensation.

The is a very simple mechanism where a compiler thing can do a 64 bit EXE file that will convert itself into 32 bit when appropriate at run time.

Not exactly. the logic still has to be written; the Sysinternals tools use a particular method to make it a single executable. All that logic is part of the codebase, not something baked in by the compiler.

As you said, that should work unless the programmer was making assumptions about the size of pointers.

Not exactly... it will work but only in VM languages like .NET or Java. in C and C++, where pointer arithmetic is commonplace, a lot of dependency on pointers being a specific size can be added without realizing it. For example, various built-in types can change size. Of course this can be fixed with typedefs, but at the same time, there is the issue of file formats with regard to those data types.

basically, from a programming standpoint, a migration has several pitfalls:

First, a lot of applications rely on other applications created by other vendors; for example, solutions created using VBA. At that point regardless of how well your application is written, the application you are working with might not work well as a 64-bit application, or there might be compatibility issues between the 32-bit version of that application and the 64-bit version. Prime example?  an Excel application that accesses eBay’s Web service for the purpose of automating sales. The 64-bit version of Excel isn’t completely compatible with the 32-bit version of Excel, so you encounter a host of unexpected problems with your application upgrade. It’s easy to miss a problem such as using a 32-bit number to hold a 64-bit handle, truncating it, and causing a crash because the handle isn’t valid.

Data access- which I touched on before, can introduce all sorts of problems to the migration of an existing codebase. One prevalent issue is that a 64-bit application that writes 32-bit values will write then as 64-bit values, because the data type used in the codebase is a different size. So when a 32-bit application accesses that data, it only gets 32-bits out of a full 64 bits, and when it saves it back it essentially truncates what the 64-bit version wrote, assuming it understands it at all. In most cases, the entire database becomes mangled before anybody even notices there is a marshaling problem. Sometimes it can be more subtle. Example being managed code such as Java or .NET calling into the Operating System. To the managed code, the value still appears to be 32-bits (because it is supposed to be platform independent), but to the operating system that handle is really 64-bits and is treated as such, introducing a subtle, difficult to reproduce once every while crash or intermittent issue. What ends up happening is one of the devs has to trace every data transaction to ensure what you think you're writing as data is what you're actually writing.

This issue extends of course to disk storage, as well as in memory. Many devs learn the hard way that data structes that work fine in a 32-bit environment- or even a 16-bit environment- no longer work in a 64-bit environment. There can be many causes, but the primary one is that a 64-bit environment packs data into structures differently, which can break assumptions made in various locations of the code as to how the structure is laid out in memory. even if all the data elements are the same size, they aren't in the same location in memory that might be expected. Of course this issue is exacerbated by the more widely known, basic issue regarding pointer size.

Add into this the common practice of using "clever" code (which typically only proves how stupid you are... but, I digress) using things like bitshifts and bit-wise OR and ANDs to achieve tasks that they wouldn't typically be used for. Many of these "tricks" rely on the size of the value being manipulated to be 32-bits, an assumption which of course fails when those values are suddenly 64-bits wide.

There is far more to the migration than merely dealing with bigger pointers. For new code it is of course easy to take account and avoid; but many developers are dealing with codebases that are several years old and it is unlikely that 64-bit was even considered during initial development.