Maurizio said:
I tried to install an old software, which runs well under WIN XP, I got:
The version of this file is not compatible with the version of windows
you're running. Check your computer's system information to see whether
you need an x86(32bit) etc................
I tried to run it with win xp sp3 compatibility mode, I didn't succeed.
is there a solution for that?
it makes no sense to destroy backward compatibility, is this true?
We are to *guess* if you have a 32- or 64-bit version of Windows 7?
Provide details about YOUR setup. You didn't even mention which
*edition* of Windows 7 that you have.
Windows XP allowed both 16- and 32-bit installers. With 16-bit
installers getting really ancient compared to the newest version of
Windows, 64-bit versions of Vista/7 only permit 32- and 64-bit
installers.
"16-bit programs are not supported on 64-bit versions of Windows Vista
or of Windows 7."
http://support.microsoft.com/kb/926657
You said you already tried compatibility mode. You never mentioned
WHICH edition of Windows 7 that you have. Some of them permit you to
install XP Mode with is Windows VirtualPC running a license of Windows
XP. So you might be able to install your old software in XP Mode.
http://windows.microsoft.com/en-us/windows7/products/features/windows-xp-mode
http://www.microsoft.com/windows/virtual-pc/get-started.aspx
If you have an edition of Windows 7 that doesn't support XP Mode, you
can still get VirtualPC 2007 and install Windows XP in a virtual machine
(VM) to run your 16-bit programs from there. However, you will need a
legitimate license for Windows XP to run it inside a VM. Legitimate
means you never used that XP license to upgrade to another version of
Windows since you only get to maintain the 1 license to Windows across
all the upgrades from the full version (e.g., 1 full + 4 upgrades = 1
license, not 5). So the disadvantage of using Windows inside a VM is
that you need a license for it. XP Mode in Windows 7 (some editions)
gives you both Windows 7 and a Windows XP licenses.
You will still get the 16-bit error if you install XP Mode or Virtual PC
if you just run the 16-bit installer as you have before. You need to
make sure you run the 16-bit install *in* the VM for Windows XP. Sorry,
but I haven't used XP Mode so you'll need to have someone tell you how
to do target an install so it is executed within the VM. With
VirtualPC, you load the VM (it shows in its own console window) and run
the installer there. I have read where users trying to use XP Mode for
16-bit programs couldn't get them to work until they disabled the
Integration Features for XP Mode.
If it's a really old DOS-mode program, neither VirtualPC (running
Windows XP) or XP Mode (under Windows 7) may work. In that case, you
might trying using DOSbox. However, you said the old software ran under
Windows XP so you might get it to work in XP Mode else try VirtualPC.
However, unlike XP Mode, VirtualPC doesn't support USB devices, so if
you're stuck having to use a VMM (virtual machine manager), like
VirtualPC, you might want to instead look at VirtualBox which does
support USB devices. VMplayer (VMserver is no longer supported) which
is free also supports USB devices and is another VMM choice. If it's a
really old DOS-mode program that you happened to get working in Windows
XP, you might instead want to use a VMM to run MS-DOS and run your old
DOS-mode program from there.
While VMs let you run old software under old operating system, or even
under different operating systems (i.e., running Linux in a VM on
Windows), they aren't made for playing games. All the hardware except
the CPU is emulated by software which means it everything in a VM runs
slower, sometimes much slower. If you want to use the native (real)
hardware with your old games, you would have better performance running
those old programs on their intended operating system by using multi-
booting: you use a multi-boot manager to select which OS to load when
you boot your computer. You'll need a multi-boot manager that resides
wholly in the 446-byte bootstrap area of the MBR of the hard disk (first
detected or used by the BIOS), like GAG (gag.sourceforge.net), along
with other primary partitions (on the same or different hard disk as
Windows) where you install the other OS and use the multi-boot manager
to select them to load on booting the computer. Then you're not using
emulated hardware to run your old apps but instead running them in their
own intended OS and on the real hardware for faster and more compatible
operation. Since GAG runs from the MBR bootstrap (outside of any OS),
it should be compatible with Windows 7; however, I haven't used GAG for
awhile and definitely not with Windows Vista or 7 (I now have separate
hosts for each OS to eliminate all the software workarounds).
Windows 7 x86 (32-bit) can run a 16-bit installer in Windows 98/ME
compatibility mode. Windows 7 x64 cannot run 16-bit programs. Although
some 16-bit installers deliver 32-bit programs, you still need to run
the 16-bit installer to extract the 32-bit program. So check if the
software vendor has a later version of their program that uses a 32-bit
installer.
Yes, it does make sense to destroy backward compatibility. Supporting
old stuff requires a lot of overhead and to support it. If you had a
product that was dead for many years, why would you still support it?
Car makers are only required to manufacture parts for 10 years after
introducing a model (after that it comes out of stock or comes from
aftermarket suppliers). Figure 6 years for computer stuff. It is,
after all, /*soft*/ware. Hardware has longer longevity.
