Investigating the bit width of DLLs on my Windows 10/64 bit box with Visual Studiop 2013 installed.
dumpbin /headers C:\windows\system32\msvcp120.dll | findstr machine
reports: 8664 machine (x64)
but
cd C:\windows\system32\
dumpbin /headers .\msvcp120.dll | findstr machine
reports:
14C machine (x86) 32 bit word machine
I've tried it on several machines with the same result. What's going on ?
This is the file system redirector at work, always active on a 64-bit OS when you look at the c:\windows\system32 directory. You are actually looking at c:\windows\syswow64\msvcp120.dll, thus the machine type is x86. Caused primarily by running the 32-bit version of dumpbin.exe, like most users would. Only the 64-bit version (vc/bin/amd64 directory) does not get redirected.
I was puzzled a bit and discovered one aspect of the redirector I did not know before. It redirects only relative paths. So .\msvcp120.dll or ..\system32\msvcp120.dll. But not a full path, like c:\windows\system32\msvcp120.dll. Drive letter is not actually important.
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'm asking and answering my own question to find the answer later (and to help anyone stuck using the ancient Borland C++ 5.02 compiler for some reason).
I have Borland C++ 5.02 installed in a 32-bit Windows XP virtual machine, with a BC++ project residing in a folder shared with the host computer (mapped to drive letter H: in the VM). The project compiles successfully, but always fails the final step with this message:
Could not load: tlink.exe
My compiler is installed in the usual C:\BC5 location in the virtual machine, but it turns out that it can't handle project folders on paths that contain spaces in their names. So I copied the project from that shared H: drive to C:\BC5\[project] and voilà! it compiles and links with no problem. I've also copied the project folder to my virtual machine's root C:\ and that works as well.
I installed Cygwin on windows 7 64 bit ultimate and after starting cygwin terminal it crashes and creates a file named mintty.exe.stackdump, and in this file there is a line i.e
Exception: STATUS_ACCESS_VIOLATION at eip=61004DF6
After searching it on google; it seems that this exception occurs if their are two cygwin1.dll in system. There is only one that is inside the installation directory of cygwin.
I had installed mingw, but even after uninstalling mingw it still crashes. I didn't worked on cygwin before can anybody guide me how I could get rid of this problem
cygwin1.dll gets installed by some other programs that get ported from Linux to Windows, such as OpenSSH. It's possible that you have another version of it somewhere else on your system that was installed by a different application.
It doesn't necessarily need to be in your Cygwin install dir either. Just being in a directory that's in your PATH env variable, for instance, would be enough for it to cause confusion for Cygwin.
If you know exactly of a likely culprit (think Windows ports of traditionally Linux programs and tools), I would check those first. Otherwise, try digging in the different directories in your path var (you can see them by firing up a cmd.exe terminal and running the command echo %path%).
I am writing a launcher in C++ to launch my java based GUI application on Windows. I am using CreateProcess to launch "javaw.exe". Everything works except for the fact that 32-bit version of "javaw.exe" is always launched.
When java is installed, it puts the executables "java.exe" and "javaw.exe" in %windir%\System32 on 32-bit windows. On 64-bit windows, it puts the same executables in %windir%\SysWow64.
There are 3 possibilities:
32-bit launcher executed on 32-bit windows: %windir%\System32 is in search path, and 32-bit javaw.exe is found. The GUI launches. Everything works.
32-bit launcher executed on 64-bit windows: %windir%\System32 is in search path. %windir%\System32 is redirected to %windir%\SysWow64 (since my launcher is 32 bit in this case). 32-bit javaw.exe is found. The GUI launches. Everything works.
64-bit launcher executed on 64-bit windows: %windir%\System32 is in search path. No redirection happens. It does not contain the executable javaw.exe. The launcher fails.
How do I launch 64-bit javaw.exe in the third case?
I finally found a solution (by digging through various posts on stackoverflow).
Recent versions of JRE when installed do put a copy of "javaw.exe" in System32. The previous versions of 64 bit JRE probably didn't (not sure).
In any case, the registry key HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Java Runtime Environment has a property CurrentVersion which points to the key for the default JRE for the system. The sub-key corresponding to the version number has a property JavaHome which points to the location of JRE installation.
If JRE/JDK is not installed, then the Java Runtime Environment key won't be found.
I have a cmd file that runs on 32 bit Vista system.
I notice that the code has references to the system32 driver folder.
I'm wondering whether the code could potentially run on a 64 bit Windows 7 system. So I guess my question is
Does a 64 bit system contain a system32 folder?
Be very grateful for any replies.
The System32 folder in 64-bit Windows actually contains the 64-bit files, and 32-bit programs running under WOW64 would generally go looking in System32 for the 32-bit DLLs etc. that they can call - but they'll find the 64-bit ones instead. Therefore the OS redirects all 32-bit applications' requests for the System32 folder to the SysWOW64 folder, which contains 32-bit system files.
Windows has a technology called WoW 64 (Windows-on-Windows 64-bit) that allows 32-bit applications (even compiled ones written in C/C++, etc.) to run on 64-bit Windows.
In addition to the System32 folder, a 64-bit Windows installation has a SysWow64 folder that has 32-bit versions of the files that you'll find in System32.
To be clear, references to System32 get redirected when running from a 32-bit process (unless the process disables this redirection, which is possible). As a result, if you have a .CMD file that references System32, it's actually going to read from the SysWow64 directory.
System32 is the name of the folder that contains important operating system files.
Early versions of 64-bit Windows XP only ran 64-bit applications. This made sense:
you run 16-bit applications on 16-bit Windows
you run 32-bit applications on 32-bit Windows
you run 64-bit applications on 64-bit Windows
And early versions of 64-bit Windows XP were 64-bit, and only supported running 64-bit applications.
And since all the folders names stay the same, you can simply recompile your application as 64-bit (and not have to change anything else - including your accidentally hard-coded paths), and it will just work.
Emulate 32-bit OS on 64-bit Windows
Very quickly it became obvious that only being able to run 64-bit applications on 64-bit Windows, would prevent some people from upgrading to 64-bit Windows. So an emulation layer was created to allow you to run 32-bit applications on a 64-bit operating system.
It was called WOW64: Windows on Windows64:
This emulation layer simulates the x86 architecture, virtualizing the CPU, the file system, the registry, the environment variables, the system information functions, all that stuff.
If a 32-bit program tries to look at the system, it will see a 32-bit system.
For example, if the program calls the GetSystemInfo function to see what processor is running, it will be told that it's running on a 32-bit processor, with a 32-bit address space, in a world with a 32-bit sky and 32-bit birds in the 32-bit trees.
And that's the point of the emulation: To keep the 32-bit program happy by simulating a 32-bit execution environment.
The problem is where should these 32-bit applications store all their 32-bit files, and configure the locations of their 32-bit DLLs, and load 32-bit operating system support files?
We already know where native applications store their stuff.
| Native Application |
|---------------------|
| C:\Windows\System32 |
| C:\Program Files |
| HKCU\Software |
This is all correct and right; if you simply recompile your 32-bit application as 64-bit: everything works. All these locations are still correct.
32-bit in a 64-bit world
But now since we're going to bend-over backwards in order to accomdoate non-64 bit applications, we have to find someplace for them to have their old 32-bit OS files, and store their 32-bit data, and have their 32-bit programs, with 32-bit shared components:
| Native Application | Emulated 32-bit |
|---------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software\Wow6432Node |
A problem is that:
if a 64-bit program asks for C:\Windows\System32, it damn well better get 64-bit files
if a 32-bit program asks for C:\Windows\System32, it damn well better get 32-bit files
This means that if a 32-bit process ask for some of these file locations, Windows has to transparently redirect the call to the 32-bit folders and registry keys.
If a 32-bit program, that thinks it's running on an old 32-bit operating system, asks for a 32-bit location, it needs to be given the "real" location:
| Native Application | Emulated 32-bit asks for | Is actually given |
|---------------------|---------------------------|---------------------------|
| C:\Windows\System32 | C:\Windows\System32 | C:\Windows\SysWOW64 |
| C:\Program Files | C:\Program Files | C:\Program Files (x86) |
| HKCU\Software | HKCU\Software | HKCU\Software\Wow6432Node |
If you don't want your 32-bit application to be subject to all this emulation and thunking, then the solution is obvious:
create a 64-bit application for a 64-bit operating system
Stop creating a 32-bit application, and then complaining when the emulation layer causes you to go through emulation. Your application is the misbehaving oddball; fix it.
Windows 7 64 bit has a System32 folder.
Whether your file will still run, however, is a more complex problem. It might, and depends entirely on what it relies on; if it's relying on drivers in the wrong way, it will fail as 32 bit drivers just don't work on 64 bit systems.