32-bit computers often have trouble running 16-bit programs. 8-bit? Get an emulator.
Once the 64-bit machines take over, will I not be able to play my “old” 32-bit games anymore? Or have they addressed that issue this time around?
If I buy a new computer in the next month or so, then in three or four years will it be literally unable to run any new software coming out at that time?
-FrL-
I am not sure if I am following that last part. 64 bit CPU’s have been around for a long while and you should get one if you buy a computer now. Worst case being all new XP software is phrased out in three or fours years (extremely unlikely considering the base and low incentive to upgrade to Vista), you would just need to upgrade to Vista to be back in the game.
Microsoft always flubs something up but Vista has to handle 32 bit software because that is about all that is going to be available when it gets released. ^4 bit computing offers some advantages but 32 bit will still be around for a long while.
Thanks, regarding my last question, I was undergoing what I believe is known technically as a “brain fart.”
I was really thinking of the question whether software in three or four years will run in WinXP or not.
I’ve done some searching on the web since I posted here, and it seems the general buzz is that there will be XP versions and Vista versions of things sold simultaneously, at least for a while. I don’t know if that’s just pure speculation, though.
-FrL-
It has to be. Don’t think of it in terms of all your friends buying new rigs in the next few years and causally moving on. Corporations are armpits deep in XP commitment at this point and it will stay around for a really long while. I work in big corp IT and I haven’t heard a peep about moving anything over. We don’t really need to anytime some as far as I can see and it would cost millions to do so. I believe most companies are in the same boat. The prior Microsoft upgrades were compelling for business but I don’t know about this one.
For the rest of your life you should have no difficulty running software of any vintage or platform dating back to early Windows days (and most stuff from the DOS days: if you can run it now in a DOS window it should be fine moving forward). The processor will execute the code and you’ll run a virtual machine if necessary, which should not entail much of a performance hit, aside from which tomorrow’s processors should be able to run yesterday’s code fast enough even if emulation were necessary.
Remember Wow32 running 16 bit apps? Welcome to Wow64.
This actually wasn’t really because of the switch from 16-bit to 32-bit. Old DOS programs(which were 16-bit) need to run in what’s called “Real mode”, where they’re allowed to do whatever they like to the computer. Modern Operating Systems, on the other hand, run in “Protected Mode”, which prevents different programs from interfering with one another. So the old DOS programs wouldn’t work anymore, because they’d try to do something like directly interface with the video card, which only the OS is allowed to do in Protected Mode. There will not be a similar problem when switching to 64-bit – Windows will still be running in Protected Mode.
On some OSes, barring rare CPU bugs. FreeDOS runs most MS-DOS programs just fine, either as a standalone OS or under dosemu for Linux. (It’s a bit better standalone, I think, because some programs do strange things with the hardware dosemu doesn’t quite support yet.)
There was never an 8 bit x86. You can hardly expect a CPU to run code made for an entirely different processor family.
Oops, for some reason I have memories which claim my family’s old XT was eight bit, and which claim that somehow windows 95 was involved in the change to 16 bit. But looking it up, I see that you’re right and that I’m not jus wrong but wierdly wrong. Memories of my childhood are, as usual, strange.
-FrL-
On the Mac platform, the original Macs and the operating systems up through System 6 were 24-bit although the CPU was a 32-bit CPU. Probably most of the applications from that early era would run fine in 32-bit mode on later operating systems (including the Classic environment of MacOS X), but a few were not 32-bit clean and would not. A notable example is the MacWrite word processing program that shipped for free with the operating system — not the later Claris products based on it (MacWrite II, MacWrite Pro) but the original one-document-at-a-time, no-footnotes, freebie. To run programs such as that, you need an emulator (such as vMac).
I don’t know if there are analogous situations in the DOS/Windows world, but if there are a virtual machine should be sufficient (it was Intel instruction-set architecture all the way back… as far as I know, no instructions that were valid in the 8086 or 80286 chipsets were killed off in the '386+ era, is that right?).
So I would think the only apps and softwares that would be truly obsoleted would be those few that did specialized things with now-obsolete external hardware and which predate the hardware abstraction layer. I’m thinking of a graphics program that was hardwired to work with a pen plotter which in turn hooked up to both a serial port and the regular printer parallel port of an old-style DOS PC, and it would not work under Windows. I understand a few DOS games don’t work right in a “DOS Window” and therefore won’t run on any Windows built since the era where you could reboot in DOS natively, yes?
But aside from those, you should not have to fear that future computers will be unable to run whatever you run now. (Heck, I can run most PC programs you can run and I’m on a Mac…not even an Intel Mac, a PowerPC Mac)
Remember there is a distinction between a 64-bit CPU and a 64-bit Operating System.
64-bit computers run 32-bit apps no problem as long as you have a 32-bit OS running. It is when you move to a 64-bit OS that things get dicier. I see many programs stating they do not support 64-bit OSes or there are special versions of them. Likewise with device drivers.
To some extent. The 80386 and later (that is, the 32-bit x86 chips) can run 16-bit code in a kind of hardware virtual machine called V86 (Virtual 8086) mode:
This seems to suffice for a good deal of software. Linux has a system call called vm86 which causes the current process to enter V86 mode, which is the main trick dosemu uses. Once in V86 mode, dosemu runs FreeDOS which in turn loads autoexec.bat and so on just as if it were running alone on the hardware.
I don’t know what the problem with Windows is. Windows NT et seq. (including XP) should be just as good as Linux is at running 16-bit code because it should be using essentially the same trick. According to Wikipedia, this is indeed what Windows does.
Yes. And, as I said, I don’t know why Windows is so flaky that way. It’s easy to remap memory accesses and make things like video work again: dosemu runs graphical DOS programs just fine, and all DOS programs did graphics by directly diddling video RAM addresses.
Software emulation is always an option. That solves everything, albeit at a speed penalty. (Of course, when you’re emulating an IBM PC XT that originally ran at 4.77 MHz you’re more likely to want to slow things down artificially than try and speed them up. Especially if you’re running games.)
Actually, Windows 95 was the first fully 32-bit version of Windows, so you just got your number wrong. Windows 3.1 had some special 386 mode that did 32-bit (I think that’s what it did anyway) but wasn’t really designed for 32-bit protected mode.
And let me add that the 386 and up also had a 16-bit protected mode. And 32-bit protected mode operating systems can run 16-bit protected mode applications without emulation (assuming they were designed for that operating system). It’s real mode applications that require emulation. I don’t know much about the Itanium, but the AMD 64 processors are backwards compatible. You’ll be able to run 32-bit programs without emulation, again assuming you’re running the operating system for which the program was designed. (By that, I mean you can’t run a 32-bit Windows program in 64-bit Linux without emulation. That’s obvious though.) As if that wasn’t enough, programs can use the 64-bit extensions even in 32-bit mode, so you can run 64-bit programs in 32-bit operating systems as long as they were designed for the 32-bit operating systems, because some features of 64-bit mode will be missing. Fun stuff, eh? I’ve had a good look at AMD’s architecture manuals for the sledgehammer processors.
I meant to mention that I’m pretty sure the 286 had the 16-bit protected mode as well, although it was rarely utilized.
Indeed. I think the only (commercial) OS that did so was IBM’s OS/2.
Huh? I thought 95 was chock-full of legacy 16-bit code, which was its main distinguishing point from Windows NT which was 32-bit since its birth in the early nineties.
[ul]
[li]Giving you an incentive to upgrade and abandon the previous windows version completely[/li][li]They don’t need to worry about pissing you off. It’s not as if you have many alternative OSs to choose from.[/li][/ul]
This is true: Windows 95 was a DOS-based OS to a fairly large extent, running DOS drivers in native mode and so on, but it couldn’t run on a 16-bit chip because key parts of the OS were 32-bit, such as the file handling code.
BWAHAHAHAHA!