64-bit version backwards-compatible to 32-bit programs?

Status
Not open for further replies.

stan412

Distinguished
Jul 7, 2006
61
0
18,630
As the title implies, I am wondering if a Windows XP user such as myself would be able to seamlessly transfer some files/programs that I got accustomed to, into Windows 7.

Right now I use a 32-bit Windows XP, and from my knowledge, Windows Vista 64-bit gives fits to 32-bit software/drivers(?).

I will go on a hunch and guess that Windows 7 will accommodate 32-bit programs with the "Run in Compatibility Mode," but otherwise I have no idea. If Windows 7 will completely "break" from 32-bit things, maybe Windows 7 isn't for me.
 
Solution
On the processor side:

The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.

Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully...

croc

Distinguished
BANNED
Sep 14, 2005
3,038
1
20,810
Never used Vista, but you have knowledge? I guess that Win 7 isn't for you, then.

From my knowledge, everything that runs under XP 32 runs just fine in Vista 32 / 64, and as well for Win 7 64. I've had a few issues with some older 16 bit programs after moving from Win 98se to XP, and my old Creative sound card would no longer work. I also lost my creative game port support in XP, so there went my joystick and steering wheel... Damn, why did MS drop 98SE? Everything I had then worked just fine...
 
On the processor side:

The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.

Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully understand and run it because they are still 'speaking' the same language. And the reverse isn't true: Imaging speaking to a grade school child with words and phrases an MBA can use. The kid (older standard) won't understand it. The MBA can fully understand the child, though.



On the side of the OS: There is a similar mechanic, though here it's called an "API" (Application Programming Interface). In very broad terms, it works like the instructions sent to a CPU: These are the commands and formats programmers use to talk to the Operating System, which they use to access system resources like memory and information on the hard drive. You can think of it like the teller window at the bank: It's your way to pass an instruction inside in order to get the result you want. When you go to the teller (API), you have to give her a message [/i](instruction)[/i] in the format that that she understands, right? The OS wants to see some Function (Withdrawl), the location required (Account #), and some data set (how much). If you give the teller (OS) that, then you'll get your twenty bucks.

As long as the program (game, whatever) follows the proper API's then it will run on the Operating System.

Therefore: As long as a given (32 bit) game is written to the proper Windows (Vista) API's, and compiled to run on an x86 processor, then it *will* run on 64 bit (Vista).


Generally speaking, when you hear about incompatibilities it's because the programmers who wrote a given application either did not adhere to the proper API spec when they wrote their code, or because they took short cuts (which may no longer work), or because the (new) Operating System's API set is different from the old one.

This is why that 10 year old game, or the printer, or whatever doesn't work any more. The rule "Dont run old sh*t on your new sh*t" exists for a reason, after all :D
 
Solution

zorro_84

Distinguished
Mar 9, 2009
12
0
18,510
in vista 64 you can right click on a program go to properties selet compatibility then select run this program in compatibility mode then select from the dropdown list should have the same opition in windows 7
 

kg4icg

Distinguished
Mar 29, 2006
506
0
19,010


Just remember 1 thing, You can't run 32 bit drivers on a 64 bit system, you have to have 64 bit drivers.
 

mikrev007

Distinguished
Oct 28, 2008
264
0
18,790


But the OS must specifically implement support for 32bit applications. The CPU also has support for running 16bit applications in a 64bit OS, but Microsoft has chosen not to support that in their 64bit OSes.
 
I was speaking in terms of the binaries being able to run on the processor. But yes, as a matter of course, the OS the game is running in has to support both. I explained why it works in the case of Windows in the API section of the same post.

My understanding regarding 16 bit is that there's (actually/also) some limitation in the processor itself when running in 64 bit mode, and therefore the inability to run 16 bit code is not wholly/necessarily a limitation of the OS. Now, I'm a hobbyist but I can certainly see the reasoning where the OS designers would look to some limitation on the processor side and decide to not code that way. Not to mention the business case for killing 16 bit apps. A while ago I chewed my way through an AMD white paper on the topic. Let me see if I can dig it up.
 

St-OwNed

Distinguished
Apr 7, 2009
27
0
18,530
lol... not sure if you were looking for that much info. But in short yes most 32bit apps work with Windows7. I say most because it's still in beta. The current builds are progressivly getting better and there is word that the RC should be out soon. But even if you had a problem with a program there are other options out there, such as VM's and dual boot. I'm sure Scott could give you loads of info on that.. :)

 

stan412

Distinguished
Jul 7, 2006
61
0
18,630
Thanks for all your continued responses!
I know what I'm about to ask is not really relevant to this thread but, does having a Dual-core CPU really necessary? I mean, hopefully Win7 will really BE the anti-Vista and be not a resource-hog...I do have a 512MB video card...
 

Dahak

Distinguished
Mar 26, 2006
1,267
0
19,290
I'm now running VISTA ULTIMATE 64 EDITION and all my 32 bit software and programs,including games,seem to run with no problems.So I'd say your pretty safe on the backwards compatability.Goodluck.
 



You certainly don't have to have a dual core processor, if your old single core is getting the job done for you.
But as programs, and OS's become more demanding, a dual core should be in your list of upgrades.
Even for people who don't need a high end processor, even a low-end dual core is just nice to have.

It does need to be a 64 bit processor.
 



<Gross Oversimplification Alert> Trying to explain a VERY complicated subject... Helpful responses are hugely welcomed. Keep in mind the OP is not an "IT" person, but a regular user.


Think of it this way: A single core processor is the equivalent of one (really fast) person available to work. When there's multiple tasks, that individual has to constantly switch back and forth.

If you have two people, you can split the work into logical parts and divide it up. So one guy can concentrate on an important job, while the other one may handle all the peripheral stuff. Adding more people can allow you to do more 'Jobs' at the same time. Multithreading is a way to get one person (Core) to do more than one task "at once". Simple and logical, right?


The current limitation in computer terms is that most programs were written for one. So many of the programs we have now will only use one "Worker". A simple example might be you have a very single minded person who washes cars. He gets the water, gets the soap, gets the sponge, examines the car to decide where to start, washes, rinses, dries, etc... But like I said: He's simple and single minded. So he does it all himself, in the same order, every time. He doesn't know any better, and can't learn or change.

If you have more than one of these guys, you can wash more than one car at once. Otherwise, one car gets fully washed before the worker moves on to the next. More "Cores" mean more single-minded workers to do more tasks at the same time. In this context, the Operating System plays traffic cop and helps organize what gets done where.


In computer terms, a "Multithreaded" program would divide at least some of the work into other processes that can be done elsewhere. For example: We'll create a "method" called "Fetch_More_Water" and a condition where "If Water is less than 2, then Fetch More". If this is independent of the guy who does the washing, you can give it to "Little_Brother" and make him go get more water.


This is what "Multithreading" is - One program can get split up into logical parts, which can be performed independently. In my example, it doesn't matter when the water arrives just so long as there's more than 1 available at all times, right? But if the side process was "Dry_The_Car", then it matters when that happens. This is called "Concurrency", and while my example is VERY VERY simple, this is the underlying reason why it's very hard to write true multithreaded programs: Managing all of the little tasks in terms of if and when they occur in relation to all the other tasks that may or may not be running at that moment.



Bringing this back to "Should I get a Multi~Core Processor": Understand that while *YOU* may only be playing one game at that moment, your computer has more to do then just play your game. It has to switch back and forth between your game and everything else. With a multi core CPU, the operating system can decide that the first Core can concentrate on your game, while the other one does the other stuff. And the more stuff you run at once - game, voice communications, Music, browser, temperature monitiring program, etc etc etc.... - the more you'll benefit from having more than one processor core.
 

lostcoder

Distinguished
Aug 16, 2009
5
0
18,510
I read this one froum post complete and had to sign up. I have been on and read countless forums and I was just knocked back by the expertise and friendly attitude so here I am.


I read it all here and would like confirmation in my own words.


If I want to take use us more recognized and usable memory I will have to install a CPU that is 64 bit and at the same time upgrade my XP to 64 bit.

Doing that should utilize say 8GB of memory and as perfectly explained above all out 32 bit programs will run IF they were compipled correctly.



Thanks so much. I am building my first ever PC.



JIM
 
Most people don't recommend 64-bit XP because there nearly as many drivers available for it as there are for 64-bit Vista or Windows 7.
 
Status
Not open for further replies.