Am 22.03.2017 um 00:08 schrieb Kenneth:

> I do have some un-answered questions about this entire process, though:
> 
> 1) Is the successful SETUP32.exe installer --or installer 'stub', as it's
> called-- a 'generic' installer (well, generic to InstallShield-configured
> application disks)? Or is it *specific* for use only with that particular
> Photoshop app/disk, made for it and nothing else? (The website I got it from
> didn't make a distinction.) If it's 'generic', can it be used to install *other*
> older 32-bit apps that happen to use InstallShield? (I haven't tried this yet.)

At best, it might be a generic replacement for installers created with
the same installer toolkit; but I'd expect it to work only for that
specific application. I can't imagine how it could be totally generic,
given that installers are technicall just applications and might
theoretically do just about anything.

> 2) After the install, I took a look at the actual Photoshp.exe application file;
> it isn't running in 'compatibilty' mode, but runs OK nevertheless.  So if a
> replacement 32-bit installer allows a 32-bit program to successfully install and
> run on Windows 7 (which it did), then I don't really understand the actual NEED
> for running in 'compatibility' mode with a required Windows XP download, or
> running in a 'virtual PC' environment at all, since neither of these were
> required in my case. What other purpose(s) does compatibility mode, etc. have?

There are multiple different things in play here:


[A] 64-bit vs. 32-bit vs. 16-bit. This is primarily a CPU thing.

A x86-64 CPU can run in one of various different modes:

(1) A 16-bit single-tasking mode.
(2) A 16-bit multitasking OS mode.
(3) A 32-bit multitasking OS mode.
(4) A 64-bit multitasking OS mode (AMD64).

Mode (2) includes an emulation of (1).
Mode (3) includes emulations of both (1) and (2).
Mode (4) includes only an emulation of (3).

Thus, any operating system designed to run 64-bit applications is
fundamentally unable to run 16-bit applications, except via software
emulation. Running 32-bit applications, on the other hand, is a piece of
cake.

(New CPU features, like hypervisor support, may modify this picture,
presumably by providing a mode that emulates all the modes (1) through (4).)


[B] Windows API and software development guidelines.

Over time, new Windows versions have not only changed the user
interface, but also the set of functionality the OS provides to
programs, and in various cases clarified (or even changed) how
prorammers are supposed to make use of that functionality for particular
use cases. As a result, some old software may be using features in a way
they they are no longer intended to be used, and which may have been
disabled for security reasons.

For example, some programs designed for Windows XP or earlier would
expect to have write access to the directory in which the program's
binaries were installed, which Windows 7 no longer allows.


To my knowledge, the compatibility modes provided by Windows 7 are all
about [B]. 32-bit applications /per se/ run file on 64-bit Windows.

You might even encounter 64-bit software that needs XP compatibility
mode (there was a Windows XP x64 edition, and although technically it
was based on Windows Server 2003, it presumably was more similar to
genuine XP than to Vista).

Post a reply to this message