I want to activate IIS on Windows Server 2012 via InstallShield setup. I tried the following DISM command:
DISM.EXE /enable-feature /online /featureName:IIS-WebServerRole /featureName:IIS-WebServer
Described here: Installing IIS 8.5 on Windows Server 2012 R2
When I execute my Setup, an error occurs:
The Process Monitor says, that DISM will be executed in C:\Windows\SysWOW64\DISM.EXE and results in Exit Status 11. As File Location I used [SystemFolder]. When I define File Location C:\Windows\System32 it also uses C:\Windows\SysWOW64\DISM.EXE.
What is a tough way to activate IIS?
Per this post, error code 11 indicates that the 32-bit version of DISM is being used on a 64-bit system. This corresponds with installing a 32-bit MSI on a 64-bit system and using it to locate and launch DISM. Windows Installer does not allow you to refer to 64-bit locations from a 32-bit MSI. Heath Stewart's article Different Packages are Required for Different Processor Architectures touches on this, but mostly from the angle of installing to 32- or 64-bit locations. As it turns out, finding files there is just as hard.
In order to launch a 64-bit DISM from a 64-bit location, you will need some other code. It may be possible to locate the 64-bit system folder from 32-bit code, but I know some 64-bit locations can only be correctly queried by 64-bit code. As such I would suggest you write a 64-bit helper exe to find and launch the 64-bit DISM. Then you will need two variants of your custom action so that you only try to use the 64-bit wrapper on a 64-bit system (when VersionNT64 is defined) and use a 32-bit wrapper or direct call on a 32-bit system.
Alternately, if upgrading and using an exe is an option, InstallShield 2013 and later include support for installing Windows Features as part of the Suite project type, which will thus handle this work for you. (Disclaimer: I am paid to work on InstallShield.)
Related
I have 64-bit Oracle Database Server (11.2.0.3) installed on Windows 2008 R2, and naturally, it automatically installs the 64-bit client. I have to install an application onto this server that is 32-bit and requires the 32-bit Oracle client. (Don't Ask - I can't install the 64-bit version of this app, it won't work with the 64-bit client, and I can't install it on another server.)
Now i have tried installing the 32-bit Client into a different physical folder and selected a different value for the Oracle Base and Software Location when installing and it installed just fine. And it put the BIN folder of the 32-bit Client installation at the head of the PATH statemtn.
However, when i tried to run "SQLplus system/system" with the 32-bit version it gives me the "ORA-12560: TNS:protocol adapter error". When I go into the folder with the 64-bit sqlplus.exe and ran it (directly and not through PATH), the "system/system" credentials worked fine.
I copied the TNSNames folder from the Oracle Server's NETWORK/admin folder to the Oracle Client's NETWORK/admin folder, and rebooted the server. Same results.
This is the extent of my troubleshooting knowledge for Oracle.
How can i get the 32-bit Client to run on the same server as the 64-bit Oracle Server?
I know in linux/Unix, you simply put in the lib32 folder into the the 64-bit client folder and set a couple of environment variables, but i'm pretty sure it's not that simple in Windows.
If there is a way to do this, please be descriptive in you answer as I will need step-by-step instructions.
Thanks in advance.
Here is an instruction how to install 32-bit and 64-bit Oracle Client on one machine. Follow the instruction, then it should work.
Assumptions: Oracle Home is called OraClient11g_home1, Client Version is 11gR2
Download and install Oracle x86 Client, for example into C:\Oracle\11.2\Client_x86
Download and install Oracle x64 Client into different folder, for example to C:\Oracle\11.2\Client_x64
Open command line tool, go to folder %WINDIR%\System32, typically C:\Windows\System32 and create a symbolic link ora112 to folder C:\Oracle\11.2\Client_x64 (see commands section below)
Change to folder %WINDIR%\SysWOW64, typically C:\Windows\SysWOW64 and create a symbolic link ora112 to folder C:\Oracle\11.2\Client_x86, (see below)
Modify the PATH environment variable, replace all entries like C:\Oracle\11.2\Client_x86 and C:\Oracle\11.2\Client_x64 by C:\Windows\System32\ora112, respective their \bin subfolder. Note: C:\Windows\SysWOW64\ora112 must not be in PATH environment.
If needed set your ORACLE_HOME environment variable to C:\Windows\System32\ora112
Open your Registry Editor. Set Registry value HKLM\Software\ORACLE\KEY_OraClient11g_home1\ORACLE_HOME to C:\Windows\System32\ora112. Using C:\Oracle\11.2\Client_x64 should also work.
Set Registry value HKLM\Software\Wow6432Node\ORACLE\KEY_OraClient11g_home1\ORACLE_HOME to C:\Windows\System32\ora112 (not C:\Windows\SysWOW64\ora112). Using C:\Oracle\11.2\Client_x86 should also work.
You are done! Now you can use x86 and x64 Oracle client seamless together, i.e. an x86 application will load the x86 libraries, an x64 application loads the x64 libraries without any further modification on your system.
Probably it is a smart idea to set your TNS_ADMIN environment variable (resp. TNS_ADMIN entries in Registry) to a common location, for example TNS_ADMIN=C:\Oracle\Common\network\admin
Commands to create symbolic links:
cd C:\Windows\System32
mklink /d ora112 C:\Oracle\11.2\Client_x64
cd C:\Windows\SysWOW64
mklink /d ora112 C:\Oracle\11.2\Client_x86
Notes:
Both symbolic links must have the same name, e.g. ora112.
Despite of their names folder C:\Windows\System32 contains the x64 libraries, whereas C:\Windows\SysWOW64 contains the x86 (32-bit) libraries. Don't get confused.
Background information, why this works: Registry Redirector and File System Redirector
I had the same issue. Both 32 and 64 bit ORA clients installed on same Windows 10 machine (separate folders) and 32 bit apps stopped working. All I had to do was edit the System Environment variables and DELETE the ORACLE_HOME entry, then re-boot. Windows/Oracle do the rest based on the registry entries. Just need to copy the tnsnames.ora to both installations.
I have a program compiled in Visual Studio 2005 in an x86 System (32-bits), but when I try to run it in x64 OS (64-bits Windwos 7, Windows 2003, Windows 2008) it doesn't execute, I only get the following message:
"myapp.exe has stopped working
Windows is checking for a solution to the problem... "
I installed the Microsoft Visual C++ 2005 Redistributable Package for 32 and 64bits both(vcredist_x86.exe and vcredist_x64.exe) on the execution machine but the application still doesn't run.
I have also changed the option on the Development machine in the Configuration Manager Window to generate from 'Any CPU' to 'x86' platform, with the same result.
Is there any other configuration option, dll, lib, or package that allows to compile myapp in 32-bit and execute in 64-bits?
Thanks for your suggestions.
Eugin.
You don't need to recompile your program to run on a 64bit OS, there is some other bug that is causing it to crash.
When compiling code with VC++, MSDN gives you the option between using the x86_amd64 toolset or the amd64 toolset (when calling vcvarsall.bat).
How do I choose between those two when compile x64 code? Will the amd64 option churn out more efficient x64 machine code than the cross compiler?
It has nothing to do with efficiency. The native and cross-compiler will both generate the same machine code. You will however gain some benefits by running a native 64-bit compiler process on a 64-bit workstation (larger registers, larger memory space, etc...).
The native compiler will only run on an 64-bit copy of Windows, so if your workstation is 32-bit this compiler won't even run.
The cross-compiler is meant to run on x86 machines even though it will run on a 64-bit copy of Windows via WoW; however, there is no reason to do this.
The page you link says it quite well:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Thanks to Brian R. Bondy for the quote formatting
From what you linked:
x64 on x86 (x64 cross-compiler)
Allows
you to create output files for x64.
This version of cl.exe runs as a
32-bit process, native on an x86
machine and under WOW64 on a 64-bit
Widows operating system.
x64 on x64
Allows you to create output
files for x64. This version of cl.exe
runs as a native process on an x64
machine.
Paraphrased:
If you use x86_amd64, then you are typically developing on an x86 machine and you want to create x64 files that run natively on x64. You could also use this option on an x64 machine but your compiler will be running under WOW64 emulation.
If you use AMD64, then you are developing on an x64 machine and you want to create x64 files that run natively on x64. The compiler is running natively in x64. This option is more efficient to build x64 programs.
You may wonder why you would ever develop an x64 program on an x86 computer, since you can't run it you can't debug it. Well it's still useful for example if you have a build server which is x86 and that build server needs to generate both x86 and x64 outputs.
How is it possible for a compiler to run under x64 if it is an x86 based program (x86_amd64)? That is the same reason you can run any x86 program on your x64 machine... Thanks to WOW64 emulation.
What is WOW64 emulation:
WOW64 emulation happens when you run an x86 program on an x64 computer (or IA64). WOW64 stands for Windows 32 on Windows 64. It is an emulation layer on top of x64 machines which allow you to execute x86 programs.
Your file system operations will be redirected to WOW64 folders and your registry will be redirected to a subnode as well. For example when you try to obtain the folder for program files it will return c:\program files (x86)\ if you are using WOW64 but it will return c:\program files\ if you are using x64.
Another example, for the registry if you try to write to HKLM\Software\Something it will really redirect you to HKLM\SOFTWARE\Wow6432Node\Something without your x86 program's knowledge.
Running a native x64 build will be more efficient than running through WOW64 emulation Why? Because you don't have that extra emulation layer of transforming your 32bit calls into 64bit ones.
By the way if you are running the x64 version of Windows you can see which processes are running through WOW64 because they will have a *32 appended to the process name in the process list.
I just installed tortoisesvn on windows server 2008 but it is not showing any menus for tortoise when i right click any folder. can anyone help?
You probably have a 64-bit Windows and installed the 32-Bit version of Tortoise.
Install the 64-Bit version as well. Both versions can be installed parallelly. It even makes sense to do so: 64-Bit Explorer needs 64-Bit Tortoise, but other 32-Bit apps may need 32-Bit Tortoise.
I have a Windows 2008 64-bit server and I have to install a 32-bit JRE, because my Java application uses 32-bit DLLs using JNI.
Unfortunately the java.exe is installed to C:\Windows\SysWow64 and when I start a console window or a batch file the installed java.exeis not found. (Because cmd.exe is a 64-bit application and sees the 64-bit version of the system directory which has no java.exe)
How can I make the installed java.exe available to batch files and the command line without to much messing around with the system configuration, causing other problems or preventing future updates to the JRE?
Don't rely on the java.exe that's in a Windows system directory; add the bin directory of your Java runtime environment to the PATH environment variable (if that's not too much "messing around with the system configuration").
Known issues when you install a 32 -bit JRE on a 64- bit Windows architecture machine:
Online Installation and Java Update features are not applicable to 64-bit architecture
The public JRE installed with the 32-bit JRE is not registered. You must set the PATH environment variable to point to JAVA_HOME \bin to register the JRE
http://www.oracle.com/technetwork/java/javase/install-windows-64-142952.html