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).
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?
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.
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.
We have an application which, for various reasons, needs to be compiled as both a 32-bit and 64-bit app. The thing is, we want to distribute both setup files (msi) on a single CD. Is there a launch condition or autorun.inf entry that we can use to know which setup.exe to launch? Or do we need to write a separate little exe that gets called by autorun, and which determines the OS, and calls the appropriate setup.exe?
There does not appear to be any 32/64bit detection support inherent in autorun.inf files.
The convention that most applications which supply a 32 and 64 bit MSI follow is similar to the second option you mention.
Create a single 32bit setup.exe application (so that it will run on either platform). Ideally this will be written in C/C++ so that it is as small and quick as possible, and has no dependencies on other libraries/frameworks (eg. static linked).
Detect if you are running on 64bit or not (see sample code for Windows API IsWow64Process function
Execute the appropriate MSI
You can use a custom action to detect the OS, then call the right installer.
I've given an example here: Single MSI to install correct 32 or 64 bit c# application
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.