I made my application as install setup by install shield 5.0 on 32bit machine but before that i migrated my application into 64bit. after installed my application on 64bit machine, my application registry values are gone into under wow6432 node as HKLM\SOFTWARE\Wow6432Node(myapplication) but my application trying to read those values from HKLM\SOFTWARE(myapplication). could you please where is the wrong. what shall i do this case.
thanks,
KAM
Your install is 32-bit and it automatically writes to Wow6432Node on 64-bit system. You need to disable registry reflection or to directly write to 64-bit registry key (I don't know how to do that on install shield, but you should find it in the manual, search for Registry Reflection).
See my answer here on how to explicitly read the 32 or 64-bit 'views' of the registry. You have a few options depending on your situation - you can make the 32-bit version read the 64-bit view (so it'll use HKLM/Software. This means that you won't need to change the installer) or you could force the 64-bit version read the 32-bit view (this may be better if you need different options in the 32 and 64-bit versions)
Related
Is there a posibility to tell Innosetup to uninstall the 32 bit version of the application (that usually resides in Program Files (x86)) in order to install the 64 bit version of the application (usually in Program Files). If the 32 bit version is not uninstalled, then bot of them will start at startup, causing problems.
I don't know if there is a procedure for this. Given the fact that the 64 bit application will basically be a different application, trying to uninstall the 32 bit application seems like trying to uninstall a non-related application.
The motivation will be that less and less vendors offer support for 32 bit libraries. For example, there are no 32 bit libraries for Qt for msvc2017. So the earlier I move to 64 bit the better.
Note: if this is not possible in Innosetup, any other alternative is welcome.
Just uninstall the previous 32-bit version, as any other.
See How to detect old installation and offer removal?
It should work almost out-of-the-box, as long as both the installers for 32-bit and 64-bit version have the same AppId. The only difference is that you need to look to for the uninstall key explicitly in HKLM32 (32-bit hive) instead of HKLM/HKEY_LOCAL_MACHINE (which defaults to 64-bit hive in 64-bit install mode).
If you uninstall the 32-bit version from InitializeSetup already, as the accepted answer to the above question shows, Inno Setup won't notice that the 32-bit version ever existed and will even "reset" the default installation path to the 64-bit Program Files folder.
We are migrating our Java EE / JBoss web application currently running on 32-bit linux box & 32-bit JVM to 64-bit linux box & 64-bit JVM.
We analyzed & changed the JVM heap, permgen, stack etc., sizes appropriately. Is that enough or should we consider any other parameters/ make any other changes as a part of the 64bit migration?
We are currently using "jboss-eap-4.3" / "jboss-4.0.5.GA". Do we need to install / upgrade the JBoss server?
Also, can you point me if any other mandatory change that I am missing on 32-bit to 64-bit migration?
Should I check if all the jar files that we use in our application are compatible to 64-bit jvm?
Define tests which cover your use cases, and run these against both installations
Define a load test scenario, and run it against both installations as well
Management should approve both suites/procedures.
There should be no need to check .jars for 64-bit compatibility, unless you use JNI. Anyway problems should be revealed by the tests mentioned before.
Use the newest stable JBoss version. Otherwise you could run into problems while trying to get support for an older version.
Keep your old installation for a certain time to be able to switch back.
I am converting some 32-bit .Net apps to x64. Enterprise Library 5 (32-bit) is used in a bunch of our apps, so I am under the impression that when we re-compile those in x64, then we will need to pull in a x64 version of EntLib. Does anyone know if that exists? I keep searching and I can't seem to find a straight answer - I find burbs about x64 configuration manager tool, but no info about a installable 64-bit version of EntLib5.
The entlib assemblies are architecture neutral. They can be loaded by either 32 or 64 bit processes with no changes.
On a 32-bit process, they'll run as 32-bit. On a 64-bit process, they'll run as 64 bits. No changes needed.
Remember, they're IL, not native code, and don't call into anything native, so there's no bitness dependencies.
I need to determine whether a particular system has 32-bit Java installed. I'm doing a remote query that only gives me access to the filesystem and registry, so I cannot attempt to run java.exe, or run any Java code.
I also want to make sure I detect both IBM and Sun Java, as well as any other distributions, which seem to put things in different places on the filesystem and in the registry.
The best I've come up with is to check for C:\Windows\SysWOW64\java.exe. Is this a reliable way to test for the presence of 32-bit Java, or are there certain versions that won't put java.exe in that folder?
Update: I'm still looking for a more robust answer to this. Just to be clear, I don't have access to a command prompt. Also, I want to detect Java no matter who the publisher is, what version number is installed, and no matter what path the user chose to install it on.
C:\Windows\SysWOW64\java.exe seems to fit these requirements, but I'd love some confirmation from someone more knowledgeable that every Java installer will indeed put that executable there.
This seems to provide the info on Windows:
1.) Open a windows command prompt.
2.) Key in: java -XshowSettings:all and hit ENTER.
3.) A lot of information will be displayed on the command window. Scroll up until you find the string: sun.arch.data.model.
4.) If it says sun.arch.data.model = 32, your VM is 32 bit. If it says sun.arch.data.model = 64, your VM is 64 bit.
Do you have access to the command prompt ?
Method 1 : Command Prompt
The specifics of the Java installed on the system can be determined by executing the following command
java -version
Method 2 : Folder Structure
In case you do not have access to command prompt then determining the folder where Java.
32 Bit : C:\Program Files (x86)\Java\jdk1.6.0_30
64 Bit : C:\Program Files\Java\jdk1.6.0_25
However during the installation it is possible that the user might change the installation folder.
Method 3 : Registry
You can also see the version installed in registry editor.
Go to registry editor
Edit -> Find
Search for Java. You will get the registry entries for Java.
In the entry with name : DisplayName & DisplayVersion, the installed java version is displayed
Check this key for 32 bits and 64 bits Windows machines.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
and this for Windows 64 bits with 32 Bits JRE.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment
This will work for the oracle-sun JRE.
just write "java -d64 -version" or d32 and if you have It installed it will give a response with current version installed
If it is not Oracle's Java, you may not be able to tell. When I install Oracle Java 64-bit, the files go into C:\Program Files\Java, but when I install a 32-bit version, they default to C:\Program Files (x86)\Java instead. Of course, the person who installed Java could have overridden those defaults.
I tried both the 32-bit and 64-bit installers of both Oracle and IBM Java on Windows, and the presence of C:\Windows\SysWOW64\java.exe seems to be a reliable way to determine that 32-bit Java is available. I haven't tested older versions of these installers, but this at least looks like it should be a reliable way to test, for the most recent versions of Java.
I am trying to implement a virtual camera application in Visual C++ for 64 bit Windows. I started with the code here: tmhare.mvps.org/downloads/vcam.zip which emulates a video capture device using DirectShow filters. It works fine for me on 32 bit windows, but doesn't work on 64 bit windows. I modified the Visual C++ project as follows:
1) changed the platform to x64 and recompiled the dll, linking in the 64-bit version of strmbase.lib
2) changed preprocessor definitions to WIN64,_WIN64 from WIN32,_WIN32;
3) Recompiled the library and registered the dll using C:\Windows\system32\regsvr32.exe
The dll registers successfully and regedit shows three keys for my virtual camera in
HKEY_CLASSES_ROOT\CLSID\{860BB310-5D01-11D0-BD3B-00A0C911CE86}\Instance\{8E14549A-DB61-4309-AFA1-3578E927E933},
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{860BB310-5D01-11D0-BD3B-00A0C911CE86}\Instance\{8E14549A-DB61-4309-AFA1-3578E927E933},
HKEY_CLASSES_ROOT\CLSID\{8E14549A-DB61-4309-AFA1-3578E927E933}\InprocServer32
However, neither Skype nor Windows Live Messenger see the camera on 64-bit windows.
What am I doing wrong? I understand that Win64 has HKEY_LOCAL_MACHINE\Software\Classes\CLSID{guid} for 64-bit applications and HKEY_LOCAL_MACHINE\Software\Wow6432Node for 32-bit applications, but since I am compiling my code as a 64-bit application, it seems to me that its keys are being placed in the right part of the registry. Is there a DirectShow virtual camera filter implementation for 64-bit windows I could use as a sample (I only found one for 32-bit windows)?
I tried out DirectShow a year or so back, and from what I can remember, there isn't support for it in 64-bit applications. So I'd recommend either switching to 32-bit mode, or finding a library which supports 64-bit. This may help you.
http://directshownet.sourceforge.net/
64-bit filters work exactly as their 32-bit peers, no specificity involved. A general rule applies, which is worth mentioning: filter DLL bitness should match the application bitness, e.g. as Skype is always 32-bit regardless of OS bitness, you need 32-bit virtual camera for it. Skype just does not care about 64-bit filters as it never uses them.
Also, I don't understand your #2 above. You only need to create duplicate existing configuration for another target (x64) and visual Studio will update predefined conditionals such _WIN64, no manual changes required in code.