SA Developer .NET

Hi

We developed SSIS packages to import data - part of the process we ran a 32bit program via command line (batch file) to do some processing. This application is 32 bit, but the installer is 16 bit. All worked fine (installing the program and running it) on Server 2003 x86 - now moving to the production environment which is x64 I keep receiving the error "the file ...\setup.exe is valid, but is for a machine type other than the current machine" when trying to install it. Unfortunately it seems the program does register and use some DLL's so copying the installed files (in Program Files directory) over to the new server is not working.

Is there any way to "upgrade / convert" this 16bit installer to 32bit? Any other suggestions how I can go about this? The application converts a csv file with business specific algorithms and is sort of a show stopper...

Thanks

Hendrik

Hi there,

Is there no way you could get a newer version of the program from the original manufacturer? Or is it a custom written app? Because as far as I know, there is no way to convert a 16bit app to 32 bit directly without the developer recompiling the app in a 32 bit installer, which you won't be able to do if you're not the original developer.

Also, (and forgive me for my ignorance here, haven't worked in x64 at all), is there no way you could "emulate" 32 bit on the server? Like when you use the app compatibility tab in Windows XP and Vista for an application's properties?

Hope this can help,

---

The Question is the Answer, and the Answer is the Question!

Not sure what the bigger constraints of your architecture are, but have you considered running the application in a Virtual Machine on the server?

---

Driven Software

As has been suggested I'd recommend the following:

• Depending on who own the installer, approach them and get an update that has been tested and known to work.
• Alternatively post a link to the installer here and one of us can take a look and see what the underlying problem is.

---

Microsoft Xbox MVP | http://craign.net/

Ummmm...most installers can be unpacked by 7-ZIP or Winrar. However, 16-bit installers often have their files individually packed (so you get like .ex_ and .dl_ files). Those can be unpacked too using Microsoft's expand utility (expand -r filename.ex_).

 

But a better idea: in a VM or on a seperate PC, take a before and after snapshot. A good way to do this is through a tool like Advanced Uninstaller (http://www.innovative-sol.com/uninstaller/) - although I've never used it, so I don't know if you'll be able to easily see the log that its Installation Monitor produces. A manual way is to run a disk comparison utility to see which files are changes, and which files are created during the install. Also, use a registry compare utility to compare the before and after registries. Finally, use regsvr32 (regsvr64 on 2003 x64? I have nfi!) to register DLL's. Generally, you can regsvr32 on any DLL's that it puts in the system32 (system64? :-P) directory. If no DllRegisterServer method exists, regsvr32 will complain. If it does, it calls it and voila - DLL's registered. From a minimal-amount-of-effort perspective, I would first try extracting the setup and associated files. Check the installed PC for those copied to the program files directory. Dump the rest in system32/64 (which is in the %path%, so it should work even if it's supposed to be in a different directory). Run regsvr32/64 filename.dll for each dll you dump in the system directory. Start the app. If it fails to start, do the registry compare thing.

---

And so the kief looked and lo, it was kief.

Hi guys Thanks for all the replies!

I did aproach the company who originally wrote and packaged the software - but (as expected) they simply said they do not support the x64 architecture and there is no plans to do.

I eventually got it to work! As suspected, the biggest issue was that the installation package registers a dll and I could not get this to work in the beginning... I installed the application on a 32bit XP "source" machine first.
Solution (Please note this explanations might not be 100% "technically correct" but is my understanding and experience):

Firstly to keep in mind - on x64 architecture the SYSTEM32 directory actually contains 64bit DLL's!!! There is also a "Syswow64" directory in Windows which keeps your 32bit DLL's. Yeah sure you'd expect it to be the other way around - but not untypical Microsoft :-)
Secondly - when registering a 32bit DLL on x64, you MUST run the regsvr32.exe from the "Syswow64" directory - using the regsvr32.exe one in system32 is for registering 64bit dll's (there is no regsvr64.exe). ALSO to add some more confusion the regsvr32.exe sees the "syswow64" directory as "system32"... THUS I copied my 32bit dll into the syswow64 directory and ran the following from command prompt:

cd c:\windows\syswow64
regsvr32.exe c:\windows\system32\myDLL.dll  (YES although physically the file is located in the syswow64 directory)
You could also just do the following: regsvr32.exe mydll.dll - but for explanation purposes I'd mention both.

So after I copied all the files from source machine to x64 server in the Program Files (x86) directory, and registered my dll as above I got it working! You might have a situation where more than one DLL is required, for that you can use "Filemon.exe" (downloaded from the web) while running regsvr32.exe and the log will tell you which other DLL's is required by the one you are trying to register...

I hope the above makes sense! Feel free to ask any questions.

Cheers
Hendrik

lol - I should've known my assumption that there would be a system64/regsvr64.exe was silly, of COURSE it would work in some completely arbitrary and strange way:-P Gotta love M$ sometimes...thankfully, we're sticking to 32-bit virtualised server's for most of our stuff here...

---

And so the kief looked and lo, it was kief.