In Advanced Installer, how can I know if a 32bit process is running within a 64bit machine? I need to know this in order to prevent final users to install our application in given scenarios. Our approach is to use custom actions to detect if a given process is running, but it seems that Advanced installer isn't able to recognizes the ".exe *32" in the string end. Does someone know how to proceed in this situation?
This is not the correct approach. To stop users from installing the application on 64 bit machines you need to go to Launch Conditions page and uncheck all the 64-bit OS-es from the list. This will make your package to stop from installing on 64-bit machines.
Of course, for clients running a 64-bit OS you need to create a new setup package, that contains the 64-bit version of your application. For this package set the package type 64-bit AMD from Install Parameters page. Also, in Launch Conditions page make sure you uncheck all the 32-bit OS-es.
If you're really using a custom action to detect a particular 32-bit process, it's nothing to do with Advanced Installer. Your code enumerates the processes to find the one you want, does an OpenProcess() to get a handle and then calls IsWoW64Process, and closes the handle. If you have an x64 MSI file it won't install on a 32-bit system anyway, so I'm assuming that you are trying to prevent your x64 MSI file from installing on a 64-bit system if a certain 32-bit process is running.
Related
I am trying to install Oracle 12c instant 32-bit client alongside my 64-bit installation because I can't connect Visual Studio to the 64-bit version (throws BadImageFormatException). I run the installer and give it another directory for home, so it's like this:
64-bit: D:\app\MyUser\product\12.1.0\dbhome_1 (previously installed)
32-bit: D:\app\Lazar\product\12.1.0\dbhome_x84
The installer performs the checks and sends me to next step. I click install and it crashes!
Can someone please help?
I've actually run into the same problem. It looks like it is some sort of issue with the registry.
It appears to be a missing registry entry for the location of the Oracle Inventory. The below blog explains the following steps to add the missing registry key:
Open regedit
Go to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node
Create a new key with name "Oracle"
Go to Oracle and then create a new String Value with name "inst_loc"
Give the value as "C:\Program Files (x86)\Oracle\Inventory"
Retry installation
This blog post has more detail on the fix (though not much) and is where I originally found my solution.
https://oracledba1949.wordpress.com/2016/03/11/oracle-12-1-0-2-32bit-client-installation-on-windows-2012-x64bit/
I also had the same issue and finally realized that Oracle installer doesn't support both 64bit and 32bit versions alongside. At least as you have mentioned in the question, it has got a bug. Here how I resolved the problem.
Hence both 64bit & 32bit versions unable to install alongside, first, uninstall the 64bit version.
Run the command %ORACLE_HOME%\deinstall\deinstall.bat
If any errors occur while uninstall, refer to the log and correct accordingly.
Recommend to restart the computer.
Install the 32bit version.
This will resolve your problem.
I'm in the process of adding MySQL ODBC conector as a prerequisite in Installshield. Oracle provides two separate MSI for 32bit and 64bit and they dont support cross-architecture(32-64).
I'm able to add both of these modules as two separate prerequisite with two separate custom conditions to check for the exact architecture.(win32 or win64)
when I used both of these prerequisite in a setup project I'm not able to build it for 32 bit. If I build it for 64 bit the setup will support only for 64 bit PCs.
Is there any option to add both 32bit and 64 bit prerequisites to a single setup and make it run on both platforms and let it to decide to install the suitable version of the prerequisite.
prerequisite conditions are as below
User is running a particular OS -> Custom(Platform Id=Any, Major Version=10,Minor Version1, Service Packs=-,Product Type=Any, Platform Architecture=Win32, CSDVersion="", Build No=)
User is running a particular OS -> Custom(Platform Id=Any, Major Version=10,Minor Version1, Service Packs=-,Product Type=Any, Platform Architecture=Win64, CSDVersion="", Build No=)
PS- I'm using Installshield 2015 premier edition (SP1) with VS2013
The error msg when I tried to build it or 32bit is:
error -5008: intel64 or amd64 must be specified in the template of the summary
In the General Information view, Summary Information Stream section, set the Template Summary property to x64;1033. Note: If you live in a country where English is not the language, you will use a different language code from 1033.
This will make sure your installation if 64bit. In a 64bit installer, you can add 32bit components.
We are running an AS400 v5r2 and I have iSeries Client access installed. Since v5r2 does not support a x64 ODBC driver does anyone know how I can either install two versions (v5r4 supports x64) of iSeries Client Access on the same box or just install the x64 odbc driver from the more recent version without uninstalling all of v5r2 components.
Installing two versions of Client Access is probably not going to work, since both register their ODBC drivers with the same name, so only one would be available at a given time.
OTOH the PC side of V5R4 Client Access would probably work without problem with a V5R2 OS/400; perhaps even 6.1 iSeries Access, too. So you can upgrade the x64 box and check whether everything is working. FYI, I had problems with the first versions of 6.1 iSeries Access when running on x64 boxes, later versions were a bit better; also, I do not remember that V5R4 Client Access had a 64-bit variant at all.
Do not forget that on a x64 PC, there are two different ODBC drivers, one for 32-bit applications (stored on C:\WINDOWS\SysWOW64\cwbodbc.dll and that you can manage with the 32-bit administradorC:\WINDOWS\SysWOW64\odbcad32.exe), and another one for 64-bit applications (stored on C:\WINDOWS\System32\cwbodbc.dll and that you can manage with the 64-bit administrador C:\WINDOWS\System32\odbcad32.exe.) Unless your application is recompiled for 64-bit, what you are interested in is the former one, and if V5R2 Client Access runs flawlessly on that PC, everything is fine. Some applications like Office 2010 come in two flavours, but precisely for compatibility reasons like ODBC, it is still recommended to run the 32-bit variant even on 64-bit workstations.
1) V5R2 is very dead. You aren't going to get a lot of help when it comes to supporting an OS this old.
2) V5R4 is also dead.
3) Generally speaking, IBM intends that Client Access will work for operating systems two levels back and two levels ahead, so you could try using a V5R4 ODBC driver against a V5R2 DB2. The issue is going to be getting a V5R4 version of Client Access.
4) If you have questions about admin issues like this, Server Fault is probably the better choice.
EDIT: Add details of Client Access installation
Client Access has two logical pieces, a server side component and a client side component. Both pieces are available in the IFS, in the QIBM directory tree. If you have an already-working setup of Client Access on the server side, you can install the client side one of two ways:
1) Map a network drive to the IFS and run setup from there. This obviously won't be helpful to you because the V5R2 software doesn't support x64. If you are still under software maintenance, you could order a newer version of Client Access and install it on the server, and then use the newer version to install the needed ODBC driver.
2) Use the IBM-supplied CD to install the client component directly on the client. This allows you to install a different client version than the one on the server. Not generally recommended but in the case where you're migrating away from an unsupported machine, it's probably not a big worry. If your company ordered V5R4 at any time, you have the Client Access CDs.
The key thing for you is that you don't need to install the full Access product if all you need is the ODBC driver.
The biggest problem facing you is the age of the software. IBM stopped supporting V5R4 in Sep 2013. You aren't going to be able to place an order for it with IBM. You might be able to order V6R1 but the ODBC driver may not work with V5R2 - you'd have to try it. See the IBM i Access web site for details, but it's not downloadable.
If you can use OLEDB, try IBM's FTP site.
I'm making installation script and I'm using ODBC, how can I automatically add a node to ODBC Data Sources.
Building installer with Visual Studio setup project, but I'm able to run any script for it.
Thank you.
1)
ODBC Data Sources are typically defined in registry entries - located at -
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI...... (DSNs on 32bit Windows or 64bit Windows)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI...... (DSNs on 64bit Windows for 32bit Drivers)
That part of the registry contains the "System" DSNs - HKEY_CURRENT_USER contains "User" DSNs.
Of course, all drivers are different so there may be additional stuff required elsewhere too...
2)
You could also consider using File DSNs and ship the fie with the installer.
3)
You could also consider a DSN'less connection - but this would depend on how the ODBC application is coded.
I have a problem with connecting to remote graph from DirectShow Filter Graph Editor. When I run application that creates a direct show graph, on my Windows XP machine graph is shown in the list of remote graphs, but on the Windows 7 (x64) machine list of remote graphs is empty. I have registered proppage.dll and also registered directshowspy.dll ... but still no results. Any ideas?
There's a proppage.dll and an x64/proppage.dll and you'll need to register both to ensure that both x64 and x86 apps work.
The DLL files should be available with the Windows SDK. In case of the Windows 10 SDK, for example, the files will typically reside in the x64 and x86 folders in the %ProgramFiles(x86)%\Windows Kits\10\bin\%version% folder, with %version% being the installed version of the SDK (e.g. 10.0.18362.0).
I ran into this issue when I first moved to Windows 7. A DirectShow is composed of filters that are either built for x86 or x64 architecture.
If you're registering the x64 version of DirectShowSpy.dll, don't expect to be able to spy on a graph that uses x86 filters.
Get the x86 version of DirectShowSpy.dll, unregister your installed version and then install the x86 version.
I keep both versions of DirectShowSpy.dll on my machine and register the appropriate one for working on specific graphs.
I also recommend RadScorpion's GraphStudio ;)
Hope this helps!
Is this the same application that works in XP but not in Windows 7? The app needs to manually expose its graph to the Running Object Table so that GraphEdit will see it.
Example here: http://forum.inmatrix.com/index.php?showtopic=4439&view=findpost&p=19994
Well, I got same problem and figure out that GraphEdit must be run at the Admin level.
Otherwise, I can not see any remote graph.