I have a 32-bit application that I'm packaging with InstallShield 2009 Premier. I would like to be able to install it on 32- and 64-bit machines, but the InstallShield installer doesn't seem to be able to automatically detect that it's being run on a 64-bit machine and consequently redirect the creation of registry keys to HKLM\Software\Wow6432Node... and the creation of files to C:\Program Files (x86)... Despite my best googling, I can't seem to find out how to configure the InstallShield project to account for this.
Any ideas?
Since you have a 32-bit application, you need to leave its installer the way it is.
Wow6432Node and Program Files (x86) were specifically designed for 32-bit applications. On a 64-bit machine Program Files and HKLM\Software are for 64-bit applications only.
A mixed 32/64-bit installer can be used only for an AnyCPU application.
Related
Is it possible to build app from windows for linux target?
Also, is it possible to debug linux target with windows machine?
You may install Windows Subsystem for Linux on Windows 10 (Fall Creators Update and later). Any Linux distribution available from the Microsoft Store would be adequate. Then, add the development environment (compilers, development libraries) to you Linux subsystem, and you may build your project for Linux using the bash shell. This would be only slightly more comfortable than installing a Linux virtual machine, but with the inconvenience that GUI programs don't run in WSL. For running and debugging you will need a virtual machine.
I want to convert my 32bit application to 64bit so I could compile it and keep working on it on my 64bit machine. How can it be done?
To compile at 64bit:
Inside Visual Studio go to Build > Configuration Manager
Then you can specify CPU by selecting the Platform column and choosing between X86 and x64.
Then you can explicitly compile at 64bit.
That said Any CPU should be good enough for you to keep working on it. My carry around is 64bit, but the buildserver can output the projects as either 32bit or 64bit depenedent on the release template.
Also dependent on your Visual Studio version, there is the Prefer 32bit flag which may be of use dependent on your exact requirements.
I want to dynamically link OpenCL.dll on the users PC.
When I analyse my own PC I am able to find a lot of OpenCL.dll
C:/Windows/SysWOW64
C:/Windows/System32/DriverStore/...
C:/Windows/System32
C:/Program Files(x86)/AMD APP SDK /...
So I would like to know which is the correct path to load this dll at run time?
Also what is the path for other platforms?
If you are running a 32-bit executable on a 64-bit machine, you want the C:\Windows\SysWOW64 version. If you are running a 64-bit executable on a 64-bit machine or a 32-bit executable on a 32-bit machine, you want the C:\Windows\System version. But I will say that the Windows LoadLibrary call will figure that stuff out for you. You should just be able to call LoadLibrary(L"OpenCL.dll"). It will pick the right one for you.
The other locations are part of driver or SDK installations that may not be deployed on other systems that have OpenCL.
I have an ASP.NET application that I am currently developing in C#.
The application needs a set of reference (dlls) to work. At development phase I need to use the x86 (32 bits) libraries but when I put the application in production I need to substitute the libraries with the x64 (64 bits) version.
Is it correct and safe to deploy the sytem in my IIS7 (Server 2008) as it is in Visual Studio (so working with x86 libraries) and then change the x86 libraries with the x64 directly in production environment (by copy pasting)? If that is not the case may you please suggest a more clean way?
In all cases you should test/develop with the same version as you deploy on production. So in development you should compile for x64 if your production server is x64. Otherwise you have the risk of error when you go to production. For example you can use a x86 lib which you do not compile yourself. The you will only notice this on production, which is a little late.
The way to go is to make all environments the same.
We are developing a Data Synapse calc node process in C# that requires functionality in a Win32 DLL. We have no problems building this.
The question is it has to run on a Windows 64 bit system, with Data Synapse 5.1 Grid APIs for Windows 64. While Windows 64 will run most processes transparently using WOW we don't know that Data Synapse's 64 bit will in some way stop this from working?
Anyone done this?
8 Jun 2009: Update.
when we try to run a win32 service on the win64 grid we run into problems because on Win64 the grid code intrastructure runs as 64 bit Java. This java calls our service using a win64 JINI call to our service which is implemented as a DLL. Unfortunately as a Win32 DLL.
Do you want your C# code to run as a .NET service? .NET Services run in-process and as far as I know, there is no way of mixing 32bit and 64bit code within a single process.
I see two solutions
1) Run 32bit DataSynapse engines OR
2) Run the C# code in a surrogate 32bit process. Use some form of IPC to communicate between some stub code running in the engine process and the surrogate process.
I believe this infrastructure has already been built by DataSynapse for C/C++ code and is called IsolateService. To use IsolateService a simple C->.NET bridge would need to be developed on the remote end or a .NET executable wrapper developed to host the .NET dll and handle COMs.
Nathan
Maybe you can install and run a win32 engine at the win64 machine, in that case everything is in WOW.
If you try to install a win32 engine on a win64 machine, make sure that your installed manager is ALSO USING a 32 bits JDK Java (look for the environment variable JAVA_HOME).
So, in order to have a 32-bit running on a 64-bit machine, you must have a 32-bit Java JDK, and the DataSynapse manager must have been installed pointing to the 32-bit Java machine (when installing the manager, the JAVA_HOME variable should be pointing to the 32-bit version).