I just moved mercury/32 from a Windows Server 2003 machine to a Windows Server 2008 R2, which is a 64-bit OS.
Two issues surfaced, both of which could be worked around, but, for the record, might be resolved in a future release of mercury/32:
When installing on Windows Server 2008 R2, I wanted to install Mercury/32 in "C:\Program Files (x86)\Mercury\". This was accepted by the installer, but after the wizard completed, it proceeded to install in "C:\Program Files (x86)\" instead. This behavior was reproducible, although I was able to spot the missing directory on the second attempt, since the wizard gives the opportunity to cancel the install after showing the full install path on the screen. I also tried using "%The immediate workaround is to install using the 8.3 version of the directory name (in my case C:\PROGRA~2\Mercury). The PROGRA~2 was discoverable from a command prompt via "DIR /D /X" (run from C:\). I'm not sure if a different system would give the same 8.3 result, so I recommend this procedure to ensure the correct directory is chosen. using the 8.3 directory name in the installer.
Running malias.exe from a command-line prompt produces a pop-up with the heading "Unsupported 16-Bit Application" with the body text "The program for feature "\??\C:\PROGRA~2\Mercury\malias.exe cannot start or run due to incompatibility with 64-bit versions of Windows. Please contect the software vendor to ask if a 64-bit Windows compatible version is available". I was able to copy my ALIAS.MER file from the old server, so this was a non-issue. Running malias on a 32-bit Windows OS would work too, but eventually that might not be a practical solution for new installations.
[warning: soapbox] A general comment on new Microsoft Windows OS's:
While it used to be common practice (my 44+ years as a programmer are showing) to have editable, and volatile files in the "Program Files" directory (or other file system space reserved for executables), it is now frowned upon because it requires programs to have write-access to files, necessitating Administrator access on a continuing basis (as opposed to install-time admin access). In an ideal "Windows" world, Mercury.ini and other volatile files should reside elsewhere (perhaps %ALLUSERSPROFILE%\Application Data\Mercury\Mercury.ini). Thus the files installed in a "Program Files" directory would be read-only, and the application would not require elevated privileges on an every-day basis. It's easy for me to say this, but as a developer, the task of making such changes to a mature, but highly successful application such as Mercury32, is time consuming. I only make these comments in the interest of Mercury/32 continuing as a viable solution in its segment of the marketplace.
Rob
<p>I just moved mercury/32 from a Windows Server 2003 machine to a Windows Server 2008 R2, which is a 64-bit OS.</p><p>Two issues surfaced, both of which could be worked around, but, for the record, might be resolved in a future release of mercury/32:</p><p>When installing on Windows Server 2008 R2, I wanted to install Mercury/32 in "C:\Program Files (x86)\Mercury\".&nbsp; This was accepted by the installer, but after the wizard completed, it proceeded to install in&nbsp; "C:\Program Files (x86)\" instead.&nbsp; This behavior was reproducible, although I was able to spot the missing directory on the second attempt, since the wizard gives the opportunity to cancel the install after showing the full install path on the screen. I also tried using "%The immediate workaround is to install using the 8.3 version of the directory name (in my case C:\PROGRA~2\Mercury). The PROGRA~2 was discoverable from a command prompt via "DIR&nbsp; /D /X" (run from C:\).&nbsp; I'm not sure if a different system would give the same 8.3 result, so I recommend this procedure to ensure the correct directory is chosen. using the 8.3 directory name in the installer.</p><p>Running malias.exe from a command-line prompt produces a pop-up with the heading "Unsupported 16-Bit Application" with the body text "The program for feature "\??\C:\PROGRA~2\Mercury\malias.exe cannot start or run due to incompatibility with 64-bit versions of Windows. Please contect the software vendor to ask if a 64-bit Windows compatible version is available". I was able to copy my ALIAS.MER file from the old server, so this was a non-issue.&nbsp; Running <i>malias</i> on a 32-bit Windows OS would work too, but eventually that might not be a practical solution for new installations.</p><p>[warning: soapbox] A general comment on new Microsoft Windows OS's:</p><p>While it used to be common practice (my 44+ years as a programmer are showing) to have editable, and volatile files in the "Program Files" directory (or other file system space reserved for executables), it is now frowned upon because it requires programs to have write-access to files, necessitating Administrator access on a continuing basis (as opposed to install-time admin access). In an ideal "Windows" world, <b>Mercury.ini </b>and other volatile files should reside elsewhere (perhaps %ALLUSERSPROFILE%\Application Data\Mercury\Mercury.ini). Thus the files installed in a "Program Files" directory would be read-only, and the application would not require elevated privileges on an every-day basis. It's easy for me to say this, but as a developer, the task of making such changes to a mature, but highly successful application such as Mercury32, is time consuming. I only make these comments in the interest of Mercury/32 continuing as a viable solution in its segment of the marketplace.</p><p>Rob
</p>
