Windows 7 forum: What do the items in my process list with a *32 mean?

So it doesnt matter even if i am running 64 bit?

thank you

Windows 3.1 was 16-bit.
Windows 95 was 32-bit
XP Pro was both either 32-bit or 64-bit
Vista on higher 64-bit

Windows 95 could run Windows 3.1 programs even though these were 16-bit programs.
Same is true of Vista and some rare versions of XP Pro (64-bit)
16-bit programs ran 16 bits at a time through the processor; 32-bit programs ran 32 bits through the processor; 64-bit programs run 64 bits at a time through the processor. The higher the bit process, the more physical system memory can be installed and used; the faster the system is in processing data.

Nevertheless both Vista and Windows 7 come in 32-bit flavors. A 32-bit processor cannot run 64-bit software.

A 64-bit processor can easily run 32-bit programs. Microsoft ensured backwards compatibility for lower bit numbers. (Might've thought it best to keep the users they had, as buying new 64-bit programs can get expensive, especially for business.)

XP Pro 64-bit was a bit of an anomaly and Microsoft really did not support it, as it came out just before Vista. So, it is rare.

If you want to get real technical, the whole Win9x/Me line were still 16-bit, because what most people thought of as Windows was really just a GUI shell running on top of DOS. It was basically a special 32-bit stack thrown on top of a 16-bit OS. That's a bit of an oversimplification, but the legacy of DOS was what caused people to have never ending problems with "system resources" and the general instability of the whole line of operating systems. The Windows shell was able to run in a protected mode, but there was no enforcement of this, and a single 16-bit program would bring the whole house of cards crashing down.

Windows NT 3.1 and on through XP were all fully 32-bit protected mode operating systems with enforcement. There was kind of experimental 64-bit build of XP, and technically there were 64-bit builds of at least NT4 and Win2000 for SPARC64 and Alpha instruction sets. However, few people ever really knew about these, and as you might imagine, kind of a limited market since those are high end workstation and server chips. Amusingly, MS initially comes out saying that they're dropping 64-bit platforms with XP, only to ultimately go back on that when the x86-64 instruction set comes out. I can't recall for sure, but there might have also been a port to Intel's doomed IA64 instruction set. You are correct that the 64-bit version of XP wasn't really intended for widespread use, which is why it was only ever distributed as OEM. Vista was taking a lot longer than expected to get out the door, MS' partners were getting impatient, so they slapped together a quick 64-bit version of XP.

It is something of a misnomer that more bits means more data being processed at a time, thus more efficiency. It's both true and untrue all at the same time. For the most part, save a few programs like video editing, you just won't see much of a difference because the number of bits being processed at a time wasn't a limiting factor. Unless you have a program that makes use of 64-bit variables like video editing, the number of bits really doesn't matter that much. Although, I forget the specific day of doom, but computers tell time by counting the number of seconds since some date in like 1970, and a 32-bit integer variable can only go up to around 4 billion. So at some point within most of our lifetimes, we'd hit the integer wraparound point where clocks reset to think it's 1970 something. Kind of the whole Y2K think all over again. People come up with ugly, temporary, hacks, which end up sticking around for decades. And despite it being a pretty well known problem to a key set of people, nothing is ever done about it. Granted a 64-bit integer variable will probably take us a few centuries to deplete, and the human race may not even survive that long, but rather than solve the underlying problem we've just applied another band-aid fix.

Also, since we're getting into the weeds a bit... There's no 16-bit support on ANY of Microsoft's current 64-bit offerings. A 32-bit version of Windows will have 16-bit support, but not the 64-bit version. I'll have to admit to never having looked into exactly why that is, but if I had to guess I would assume it's a limitation of the CPU architecture. I would presume x86-64 mandates the use of protected mode operation, and that would preclude 16-bit programs from running unless MS set up a special kind of sandbox which is probably just way too much trouble for a handful of apps people shouldn't still be holding onto anyway. Of course I could be completely full of it on that last point, so make sure to get some corroboration before taking it at face value.

Finally, for all intents and purposes XP x64 is DOA at this point. It never made it to SP3, and MS dropped support for SP2 a little while back. So it is no longer getting security updates and the like, but never mind that, as driver support was always poor at the best of times.

Good stuff here!

I had forgotten about 16-bit problems (been a while) and did not know about 64-bit systems not supporting 16-bit programs, but it makes sense, as Microsoft would want to leave that part of the legacy behind as much as it could. Random freezes and crashes were all a part of that 16-bit legacy.

So, the hoopla with Windows 95 as 32-bit was only just that? Or was it because it had to support 16-bit programs in order for users to migrate to it, and so in part inherited the instabilities of the 16-bit operating systems that came before it?

Not included in the post above is the progression of the file systems: MS-DOS 1-7, FAT12, FAT16, FAT 32, NTFS, all of which would impact the storing of data and reliability and integrity of that data storage as well.

A little of both. Win9x/Me was kind of a hybrid. They were still running DOS underneath, and DOS was still a 16-bit OS, but the Windows shell was 32-bit and capable of using protected mode operation, just not enforcing it. Any program developer that wanted to could access the hardware directly instead of doing it the proper way and going through the OS. Once XP came along and introduced a fully 32-bit protected mode OS to the masses, you saw a lot of legacy programs breaking because the OS shut them down when they tried to access the hardware directly. You also saw a noticeable drop in things like MBR viruses, to the point where they're practically extinct today.

AFAIK, the decision to just continue building on top of DOS was one of convenience. While I can't claim to know a lot of the specifics of how OS/2 Warp implemented 16-bit Windows support, presumably they did so via some level of sandboxing so it was isolated from the rest of the OS. Meaning one rogue 16-bit Windows app couldn't take down the entire OS. Much like the grand plans for Vista early on, I'm sure originally Win95 was intended to be a completely new OS, but then as development targets were missed more and more often, they just slapped it onto DOS instead. You often hear "insider" stories about the development of some product or another at Microsoft, and one of the reoccurring themes seems to be that Bill Gates was always really big on just reusing existing programs. Especially when development targets are being missed.