The link doesn't seem to work. I have the ecco_pro yahoo user group open and I am on the file section. Which specific download are you referring to? The updated installer which is an .exe file? I tried that before with no luck.

By the way, on the single directory install, I did run the .reg file but not from within ecco. From a windows explorer window- double clicked it and it seemed to run. I got a message saying registry was updated or something to that effect.

The ecco_pro files site doesn't have any file called setup32.exe. Only the automated installer called EccoPro_4.01_UpdatedInstall.exe
Updated Installer for ECCO Pro 4.01 - Installs ECCO Pro on Windows XP SP2 and Windows Vista .

I already tried that installer- first attempt, actually. Same results. No printing.

As Dave G. pointed out last March the Ecco install program has
16 bit code and won't run...he therefore ran it under VirtualPC.
But it is possible natively. Both the shooter and Eccoext work.
Here's how I did it.

I copied a working Ecco directory from an XP install to the
\Program Files (x86) on the Vista 64 machine. I then copied
TDLIR32.DLL, PROTL32.DLL, & DATZAP32.DLL from
\windows\system32 on the XP machine to the same directory on
the Vista 64 machine. Then I copied the Ecco*.* files from the
XP \Windows directory to the Vista \Windows directory.

I created a shortcut to the Eccoext.exe file on my desktop and it
was done.

The x64 version of Windows is not capable of natively running 32-bit code. Because most applications are 32-bit, the x64 version of Windows makes use of an emulator known as WOW64 to allow 32-bit applications to run.

One of the problems with running 32-bit code on a 64-bit operating system is that the OS must maintain complete code separation. Microsoft has created a new folder named \Windows\SysWOW64 that is used to store the 32-bit DLLs. In the 32-bit version of Windows, DLL files are normally stored in the \windows\system32 folder. However, the x64 version of Windows uses the \windows\system32 folder for 64-bit DLLs.

As you can see, the WOW64 emulator must perform file system redirection in order to guarantee that 32- and 64-bit code remain separated. But keeping DLL files separated is only the beginning. The WOW64 emulator performs file system redirection for several key components of the Windows operating system.

Another location in Windows where file system redirection is used is the Program Files folder. Almost every application you install it gets installed to the C:\Program Files folder. Because each application is installed in a separate subfolder, the Program Files folder seems like an unlikely target for file system redirection. However, in the x64 version of Windows, only 64-bit applications are usually installed in the Program Files folder -- 32-bit applications are installed in a folder named \Program Files (x86).

However, the Program Files folder may not always be in the same place on every computer. I have seen deployments (admittedly few and far between) in which Windows was installed on a secondary hard drive. As such, most application developers do not hard-code the c:\Program Files path into applications. Instead, Setup programs usually make a call to an OS function known as SHGetSpecialFolder() in order to determine the exact name and location of the Program Files folder. Although this bit of information may seem trivial, it is useful in making sure that applications are installed to the correct folder.

In the 32-bit version of Windows, the SHGetSpecialFolder() function is used to determine the name and location of the Program Files folder. But in the x64 version, the function looks at whether the Setup application was running 32- or 64-bit code and performs folder redirection based on that application.

Application installation is not the only time when the Program Files folder is referenced; it may also be referenced during application run time. Although there are several ways that an application can determine the name and location of the Program Files folder, environment variables are often used. In a 32-bit version of Windows, the %ProgramFiles% environment variable contains the path to the Program Files folder. In an x64 version of Windows, this environment variable is still used, but it works differently.

The most important rule of the x64 platform is that you absolutely cannot mix 64- and 32-bit code. Environment variables are often called from within scripts. That being the case, running scripts can get a bit tricky in a 64-bit environment. Should Windows treat the script as 32-bit code or as 64-bit code? The answer affects not only the contents of the environment variables, but also which external programs the script can call. For example, a 64-bit script can't launch a 32-bit process (at least not in the usual way).

Windows gets around these issues by offering two command prompts: one 64-bit and one 32-bit. Environment variables are set according to which command environment is being used.

For example, if you open a command prompt by entering the CMD.EXE command at the Run prompt, Windows will open a 64-bit command prompt. In most cases, the %ProgramFiles% environment variable for the command environment will be set to C:\Program Files. If you run a script, the script can interact with 64-bit applications, but not with 32-bit apps.

On the flip side, if you enter the C:\Windows\SysWOW64\cmd.exe command at the run prompt, you'll be running a 32-bit command prompt. In that case, the %ProgramFiles% environment variable will be set to C:\Program Files (x86).

As you can see, the location of the Program Files folder is redirected depending on whether you're running 32- or 64-bit code. But there's one exception to this rule. If an application has the C:\Program Files path hard-coded, then C:\Program Files will be used, even if the application is made up of 32-bit code. Folder redirection does not occur for hard-coded paths. Fortunately, hard-coding paths is not a common programming practice.