It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
I'm planning on getting Windows 7 through this offer, and I don't know which version to get.
I don't have a 64 bit computer right now, but I'm planning on building one in the next year or two.
My question is: do I get the 64 bit version and sit on it until I get around to building a computer that can use it, or do I get the 32 bit version that I can use now?
This question / problem has been solved by melchizimage
Thats no reason to go crazy and knobble yourself by making near future games impossible to run, thats a reason to dualboot with XP or 98SE. Shit, all a virtual machine developer like VMware needs to do is get a license to run the firmware from a geforce 2 or something and they'd have the ultimate retrogaming platform
avatar
Wishbone: All valid points, but the thing that has led me to seriously consider going back to 32-bit when I upgrade to Win7 (from my current Vista64), is that certain old games are flat-out impossible to get running on 64-bit OS's, because the executables are 16-bit. I must admit that I dont understand that OS limitation, but they only support the current and the previous "bitrate" (that's not the word I was looking for, but the best I could come up with) of executables.

The OS limitation is due to how OSes are coded. A 64-bit OS is coded in 64-bit, but for backwards compatibility there is 32-bit emulation. With 32-bit Windows you get a 32-bit OS with backwards compatibility 16-bit emulation. Only one emulation is present in the Windows OSes.
What I don't know is why you can't have both 32- and 16- bit emulation, but it might just be to keep the OS tidy in it's build rather than making it more complicated with even further emulation.
But yes, if you really need 16-bit capability now, go with Aliasalpha's suggestion of dual boot.
EDIT: Anyway, let us hope that those good old 16-bit games get the GOG treatment and are made compatible with 64-bit Windows!
Post edited December 29, 2009 by korell
avatar
Aliasalpha: Definitely go for 64 bit. 32 is getting to the point of death now, pretty sure that intel & amd don't make 32bit cpus anymore, games are starting to come with dual core recommended (and that being a requirement isn't ever far behind) memory is getting cheap enough that soon it'll be assumed everyone has 8GB and one day 32 bit will stop being supported so you might as well make the change now rather than later. In all my time using 64bit OS' (Both Vista Ultimate and 7), I have not had a single driver issue that wasn't because of HP being cunts when it comes to releasing ANY drivers (or support at all) for their laptops
avatar
Wishbone: All valid points, but the thing that has led me to seriously consider going back to 32-bit when I upgrade to Win7 (from my current Vista64), is that certain old games are flat-out impossible to get running on 64-bit OS's, because the executables are 16-bit. I must admit that I dont understand that OS limitation, but they only support the current and the previous "bitrate" (that's not the word I was looking for, but the best I could come up with) of executables.

I'm running 64-bit Windows and I'm going to set myself a little challenge.
Wine is designed to run Windows programs on Linux. You can run 32-bit Windows apps on 64-bit Linux.
Wine is also cross-platform. I'm going to attempt to compile Wine on 64-bit Windows and see if it runs a 16-bit executable.
Wish me luck.
avatar
TheJoe: I'm running 64-bit Windows and I'm going to set myself a little challenge.
Wine is designed to run Windows programs on Linux. You can run 32-bit Windows apps on 64-bit Linux.
Wine is also cross-platform. I'm going to attempt to compile Wine on 64-bit Windows and see if it runs a 16-bit executable.
Wish me luck.

Good luck :-D
There was actually a Wine for Windows once, but they've stopped compiling it for the Windows platform now. Sadly, noone else seems to be doing so either. I've looked for it extensively, precisely as a way of running 16-bit Windows games on a 64-bit Windows. So if you happen to succeed, be sure to let us know.
avatar
TheJoe: I'm running 64-bit Windows and I'm going to set myself a little challenge.
Wine is designed to run Windows programs on Linux. You can run 32-bit Windows apps on 64-bit Linux.
Wine is also cross-platform. I'm going to attempt to compile Wine on 64-bit Windows and see if it runs a 16-bit executable.
Wish me luck.
avatar
Wishbone: Good luck :-D
There was actually a Wine for Windows once, but they've stopped compiling it for the Windows platform now. Sadly, noone else seems to be doing so either. I've looked for it extensively, precisely as a way of running 16-bit Windows games on a 64-bit Windows. So if you happen to succeed, be sure to let us know.

I was not successful, but only because of a wrong configure flag. I actually just compiled Wine for a processor that doesn't exist; now that's an achievement.
I talked to a Wine dev and only the DLLs and Wine programs (WineD3D, Wine DXDiag, winecfg etc) can be actually be compiled for Windows. Wineserver which is the fake NT Kernel that Wine requires cannot be made for Windows simply because there's "too much Linux" in it.
That said, I don't believe that Wine on Windows would require Wineserver. I believe that only the DLLs would be required, but that raises the question "Just how do you use them?"
I'm going to look into using AndLinux, which is a minimal port of CoLinux; it's actually a miniature Linux Kernel that runs on Windows, effectively making Linux programs work on Windows. I'll attempt to build Winedows again if I can figure out the right flag for the configure script and then see if I can get an application to use Wine DLLs instead of Windows DLLs.
Here's some reference material to take a peek at....
http://lwn.net/Articles/316536/
http://wiki.osdev.org/Long_Mode
http://en.wikipedia.org/wiki/X86#64-bit_Long_mode
http://en.wikipedia.org/wiki/X86-64#Operating_modes
When the CPU is told by the OS during the boot sequence that 64bit code will be executed it enters 'Long Mode' ... in Linux you can check if your CPU is 64bit capable by looking in /proc/cpuinfo for the 'lm' (long mode) flag.
In Long Mode there is an extra set of CPU registers that get enabled but the part relevant to the question above is that a number of cpu instructions for v8086 (the 16bit compatibility 'mode' in 32bit cpus) are dropped in long mode - for efficiency sake.
So it's not a windows choice to not run 16bit applications on 64bit windows. It is an system architectural issue that 16bit applications cannot run on a x86-64 cpu running in 64bit mode.
So if you have a need for 16bit applications still you need to run in 32bit - note that Dosbox gets around this as it is an emulator and a 32 or 64 bit Dosbox still emulates the same old 16bit 486 era CPU... and ScummVM is similar to that (not emulated but the executable rewritten in 32/64bit).
Edit: Oops the above isn't totally true.... based on that operating mode chart it would in principle be possible to run 16bit applications on 64bit windows... but it is linked to why you can't. The windows 16bit subsystem (ntvdm) is based on using v8086 mode which is only available in 32bit cpus and is not possible in 64bit cpus. Microsoft would have to rewrite this virtualizing much of the CPU to support the dropped instructions and effectively emulate a 16bit CPU anyway.....
See this article in addition to the previous:
http://blog.delphi-jedi.net/2009/10/30/why-16bit-applications-cannot-run-on-windows-64bit/
Edit2: Bit of research shows that 'Windows XP compatibility mode' in 64bit Windows 7 is a 32bit windowsXP instance and can run 16bit applications... So if you have a system that can make use of that compatibility mode (compatible CPU and premium/ultimate windows) you can use that for your 16bit apps.
Post edited December 31, 2009 by jimbob0i0
avatar
TheJoe: I was not successful, but only because of a wrong configure flag. I actually just compiled Wine for a processor that doesn't exist; now that's an achievement.

Thats forward planning there, as soon as that CPU is made you'll be sitting on its very first application!