We are shipping application, that is 32b, and, therefore, put into ProgramFiles(x86) directory. There is x64 'plugin' for it, running as a separate process (service), and now we're deploying it into the main application's subdirectory. The plugin isn't deployed on x86 systems.
Now, the question - isn't this (having x64 exectuable in x86 ProgramFiles) considered as bad idea? Can this solution have negative impact on (something)?
Thanks!
It has no negative impact, and in fact, Visual Studio also does this (it installs its 64-bit native compilers into the (x86) directories).
This is only problematic if it's a "real" 64-bit application that expects to be where it's supposed to be (wrt "Program Files"), as certain WinAPI functions that give you this directory work differently for 64-bit and 32-bit applications.
For an x64 program, the %PROGRAMFILES% environmental variables and their analogues are pointing to the Program Files (no x86) directory. So there may be some problems with locating the files that were put in the wrong directory.
Since your app is 32bit, there shouldn't be any problems.
Related
we have a 32-bit .dll working on a remote 32-bit machine without a problem. We have moved our systems to another machine (64bit), also this .dll was moved.
However this .dll is working in the new machine without crash, but not working as intended (returning a custom error message, whose reason is not understandable). Normally it should produce the same result with the other machine. I have used Dependency Walker to check for missing dll's that this dll is depending on. Placed the 32-bit versions of the missing dll's under SysWOW64, but no good.
By the way our dll might not be just depending on another dll, it might be also be depending on any other file type(for example an .ini, etc.). On Windows is there any way that we can keep track of a dll's access of other files, i.e. can we see which files this dll is using?
Does anyone have any opinion about this case?
I'm having trouble installing a 64 bit program on my windows PC.
I'm running windows 7 64 bit.
Looking in regedit after a bit of googling I noticed the files seem to be in the opposite directories to what I think they should be.
Nope, those look correct to me. They are indeed confusing at first, and can be difficult to talk about.
System32 is the native system directory, and happens to be misleadingly named on a 64-bit system.
SysWow64 indicates the system directory for the Windows (32)-on-Windows 64.
Note of course that only a 64-bit application, or one that has disabled redirection, can use a path containing "System32" to reach the 64-bit files it contains.
Our application has up to now only used 32 bit binaries, it was enough.
Slowly we see the need to introduce 64bit versions (in addition to the 32 bit version) for some components, mostly for interfacing with other 64bit components that we didn't write ourselves.
One question that popped up was whether we want to name the 64bit components (EXE + DLLs) identically to their 32bit counterparts and put them in a another directory, or whether to name them differently (e.g. tool.exefor 32bit and tool64.exe for 64bit) and leave them in the same directory.
Microsoft has seemingly gone the route of different directories and identical names for most of the Windows components (WoW64), and if the whole application were 64 bit, we'd also have the case to just use the Program Files vs. the Program Files (x86) directory.
However, in our case we have a largely 32bit application that uses some 64bit components (executables) to do 64bit stuff and for some of these we also have a 32bit version that is also used.
So, do we rename components and put them in the same binary directory or do we keep the binary name the same and put it into a subdirectory?
What are the pros and cons?
If we're talking about a single application, all of its files should be kept in a single directory, per the bitiness. Meaning, either PF, or PF(x86). But not spread around.
Regarding components, ask yourself this.
Are these components used interchangeably, or do are they used in parallel?
If it's one the former, then have them the same name, this will simplify your deployment. But if it's possible that both are used at once, for example, a DLL that is used by both 32-bit process, and your 64-bit helper process, then split the names. Otherwise you will need to split up your directory structure.
Now I had to link to the 64 bit boost library DLLs.
Boost 64 bit DLLs have the same name as their 32 bit counterparts and there is no built-in way in Boost Build to change the output name, creating additional work if you would want them in the same directory.
Looking around, it seems that e.g. Qt doesn't include any platform or bitness tags in their DLL which would again generate problems if you would need 32bit and 64bit in the same directory.
So, it would seem that if you have 3rd party DLL dependencies in your application, and you need both the 32bit and 64bit application installed at the same time, then, no matter how you name the executable (or your DLL) itself, putting them into different directories seems a good idea because then it's easy to work with 3rd party stuff that doesn't "tag" its DLLs with the bitness, because there really isn't a good way of loading different DLLs with the same name from the same directory (unless you put them into System32 / SysWOW64, which you shouldn't).
Just out of curiosity, if I am creating a program installer, how should I decide in which "Program Files" directory to install to? On 32-bit systems, the environmental variable "%programfiles%" is good enough. However, on 64-bit systems, 32-bit programs should not install to that folder and instead to "%programfiles(x86)%", which as I understand points to "C:\Program Files (x86)". My question is: How should the installer decide which environment variable to use? Will the value of "%programfiles%" change for a 32-bit application, or should I always check first whether "%programfiles(x86)%" exists before using "%programfiles%", or should I do something entirely different?
Thanks! This is just out of my own curiosity, as I try to get used to 64-bit operating systems.
When the 32-bit program (installer in your case) asks the system to resolve the ProgramFilePath constant (check the exact name in MSDN), the system does not return C:\Program files, but C:\Program files(x86). So it's the system that decides, not the application.
I'm pretty certain that I read somewhere that Windows did this for you automagically. In other words, if your installer was 32-bits, it would be routed to the x86 directory variant even though you were trying to install into Program Files.
I'm sure I read this on The Old New Thing but here's a link that supports the contention until I can find that one.
Ah, yes, here it is, from the ever useful Raymond Chen.
Commenter Koro is writing an installer in the form of a 32-bit program that detects that it's running on a 64-bit system and wants to copy files (and presumably set registry entries and do other installery things) into the 64-bit directories, but the emulation layer redirects the operations into the 32-bit locations. The question is "What is the way of finding the x64 Program Files directory from a 32-bit application?"
The answer is "It is better to work with the system than against it." If you're a 32-bit program, then you're going to be fighting against the emulator each time you try to interact with the outside world. Instead, just recompile your installer as a 64-bit program. Have the 32-bit installer detect that it's running on a 64-bit system and launch the 64-bit installer instead. The 64-bit installer will not run in the 32-bit emulation layer, so when it tries to copy a file or update a registry key, it will see the real 64-bit file system and the real 64-bit registry.
Is there a way from a 32bit application running on a 64bit system to have access to the default folders for 64bit applications?
For example, using SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES from a 32bit application returns "C:\Program Files (x86)' If the same call was used from a 64bit application, I would get "C:\Program Files". Is there a way of getting that "C:\Program Files" from a 32bit application?
A related question here does not help SHGetFolderPath() 32 bit vs 64 bit nor does supressing the wow64 filesystem redirection before calling SHGetSpecialFolderPath
Answering my own question, it seems it is not possible with SHGetSpecialFolderPath. In Vista and later, using the replacement function SHGetKnownFolderPath allows it with FOLDERID_ProgramFilesX64
I believe the whole reason for having separate folders was to prevent 32 and 64 bit applications from mixing. Therefore, you shouldn't need to see a folder belonging to a different bitness from your application.
You may have a very good reason, but I don't see one in your question as posted.