I am trying to test my static library that i used to build in win xp 32bit. So, I made a test application that utilizes the static lib to print out a code.
Now, i wanted to see its behavior on a 64 bit OS. How do i go about doing that?
Do i need to install vs2008 on that one and create my test application on it then port my static lib and build it there? Or is there a way where i can just port my existing application exe and static lib to a 64 bit machine?
Also is it true that on a 64 bit OS i need to have a 32bit app in order to run a static lib that was created in a 32bit environment?
The goal is to check to see if my static lib would work in a 64bit environment. Also, please note they will be installing this static lib on multiple computers so I do not expect any network access per se.
The one API that i am giving to them uses const char * as an input parameter since I use strings internally. Not sure if I need to create an optional parameter of __int64 and then convert that to a string internally as well.
Using VisualStudio, you can build 64-bit binaries on a 32-bit box. You just can't run them there. Whether it is a good idea to use a 32-bit machine as your build machine is a whole other story, but yes, it can be done.
So you build your 64-bit app on OLDCLUNKER32, which is a 32 bit box. Move those binaries over to NEWHOTNESS64 which is a 64 bit box, install any Visual Studio redistributable packages you might need, and run your app. You can run 32-bit code on a 64-bit box, but you can't mix 64-bit and 32-bit binaries in a single application. For example, your EXE and all DLLs must be the same, weither 64 or 32 bit.
Your clients don't need to install VisualStudio to run your app, right? Well, neither do you. Install the appropriate redistributable for your platform, and you should be able to run your app.
Write good unit tests, build them on 64-bit platform and execute. If some unit tests fail, you have a problem.
Related
Is it possible to make this library as 32bit? By default, this builds as 64bit.
How can i include this library in my 32bit application?
There's ways to cross-compile libraries, but it's usually easier to build from a 32 bit system if you don't know how. You can debootstrap a 32 bit userspace on your own system and use chroot to access it.
https://jblevins.org/log/ubuntu-chroot
It certainly is possible. Actually, one of gRPC's continuous tests is testing that the 32bit build works well.
We are using this 32bit dockerfile to build:
https://github.com/grpc/grpc/blob/5059fd195753d0c18e51efa930aebd7e0461ed51/tools/dockerfile/test/cxx_jessie_x86/Dockerfile
You can also crosscompile as others are mentioning above. You're not mentioning if you are building on linux, windows or macos, so I assumed you're on linux but building a 32bit grpc is possible on windows and macos too (and perhaps easier than on linux).
How do I know if the program I am writing in C++ will run properly in a 32-bit OS or not?
(without manually testing in one)
I am using Visual Studio and compiling in a 64-bit machine. Will that stop the program from working in other machines?
And what about the processor and Windows version? Will the binary be compatible with most Windows versions and processors, if the program just does a few simple things such as web requests and calculations, with a simple user interface?
My program doesn't have to be 64-bit. I would just like to create one binary that runs in most computers, like those I download every day on the Internet. How could I do that?
If you are building your code specifically for 64-bit Windows, you can't expect the binary to work on 32-bit Windows. That will require a separate build.
An executable compiled and linked for 64-bit will typically also require 64-bit libraries.
Use tools like the Dependency Walker to find out, if a given executable is refering to 32- or 64-bit libraries.
In Visual Studio, the "target platform" decides which CPU architecture you are targeting. It is perfectly feasible to create 64-bit executables on a 32-bit system, but you can't actually run them on such a machine.
You can do what's called cross-compiling i.e compiling on one machine for another. How to compile a 32-bit binary on a 64-bit linux machine with gcc/cmake This is what you're after if I read you correctly. There should be a Windows equivalent.
Google gave me a clue that it is possible to compile code into a single executable that will run as 32bit on a 32bit OS and as 64bit on a 64bit OS. Is it really possible for the executable to determine its bitness at runtime?
In my case the target systems would be Windows 7 Professional x64 and Windows XP SP3 x86.
So what I read on various articles (I think there was even answers to similiar topics on SO) is that one has to go to the Soltuion's Configuration Manager (RMB onto Solution -> Configuration Manager) and set the Platform to Any CPU.
Now all of these articles described a setup for older MSVS or MSVC++ versions, but I think there are no major changes to the Configuration Manager in the 2013 RC version (which I have just recently installed).
In the Active Solution dropdown I do not have the option Any CPU, so I followed this recipe that I found on SO. Following this little guide fails in my case, I still do not have the option to select Any CPU when following step 5:
5) Make sure "Any CPU" is selected under New Platform. If there was
no Any CPU solution platform in step 3, then make sure the "Create
new solutions platform" checkbox is checked. Then click OK.
The dropdown items that are available to me are x64 and ARM (Win32 too but that is already added by default), I can not chose Any CPU.
Adding target platform x64 and compiling the executable works fine, the program is ran as 64bit on Windows 7 x64 but ofcourse it can not be run on the 32bit Windows XP machine.
How do I set the target platform to Any CPU in Microsoft Visual Studio Professional 2013 RC?
No it is absolutely not. You need to define separate executables.
The "Any CPU" dropdown is there to allow you to set compiler settings for more than one platform (e.g. a _DEBUG processor for x64 and Win32) You cannot actually build to that target.
AnyCPU refers to .Net programs, not C++. C++ must compile down to native, either x86 or x64. You could build 64 bit program and bundle it into your 32 program, extracting it at runtime. This technique is used by ProcessExplorer.
Perhaps not a true answer, but for MOST things, running 32-bit code on a 64-bit system works absolutely fine. Of course, it may run a little slower, but compared to having to deal with (and thoroughly test) two different binaries, unless it's significant performance benefits in 64-bit mode (or your application uses more than around 2GB of memory space), I'd be very tempted to use 32-bit mode.
MacOS supports something called "fat binaries", where the program is compiled twice and both versions are packed into a single file. The OS decides which version to actually launch.
Windows doesn't have anything like it.
You can compile the .NET wrapper (Any CPU) and the rest of program as yourprogram86.dll and yourprogram64.dll
[DllImport("yourprogram32.dll", CallingConvention = CallingConvention.Cdecl, EntryPoint = "open")]
public static extern void open32();
[DllImport("yourprogram64.dll", CallingConvention = CallingConvention.Cdecl, EntryPoint = "open")]
public static extern void open64();
static bool Is64()
{
//.Net 4.0
//Environment.Is64BitOperatingSystem
//.Net 2.0
return IntPtr.Size == 8;
}
static void open()
{
if (Is64())
open64();
else
open32();
}
Is there any way to build a VC++ project so that the dll/exe created by it will work as a 32 bit application on a 32 bit Windows OS and as a 64 bit application on a 64 bit Windows OS (not in WOW64).
I know that is possible for C# applications using the /ANYCPU option.
The CLR has special loader support for the /ANYCPU option.
If you really want to do this for native, the best way to do it is to:
Build your binary for both 32- and 64-bit
As part of building the 32-bit binary, include the 64-bit binary as a resource
On 32-bit machines, just run the 32-bit binary
On 64-bit machines, when the 32-bit binary runs, unpack the 64-bit binary resource, write it to disk, and run it from there
This is how the Sysinternals tools work (download Process Explorer onto a 64-bit machine and run it: you'll see that it writes procexp64.exe to disk and then runs it from there). It's a hack, but it works.
Not AFAIK - the problem is that
you'll need separate code; this works for C# because you're generating .NET IL which gets converted to native code on the target system
the windows PE format only has one image header and no way to chain through to another header later on to put both sets of code in the same library.
The best you could do for an .EXE was to ship a 32-bit .exe that checks if it's running WOW64 then spawns the 64-bit version instead. I can't think of an equivalent trick for libraries, though - it has to match the bits of the host process to load in the first place.
Here is my problem:
I have developed an application which can be run on various platforms, including Windows and Unix. This app runs well on pure Win32 box (WinXP) or a pure Win64 (Win2K3 x64 edition) and other unix platforms.
It only fails when running on a 64 bit Win2K3 in 32 bit mode. This app invokes a third party dll at the runtime. And the third party dlls are not formally installed, but just copied to a location in the same env. I'm also sure I'm having the right version of these 3rd party dlls (I mean 32 bit version for 32 bit mode). Even I manually set the "path" in this testing box, it still doesn't work. The app is compiled and built in 32 bit mode in this Win2K3 box.
I run dependency walker and see the same error. Cannot find that 3rd party dll.
Can anyone shed some lights on this? How do I make that 3rd party dll path visible to my app or the system?
I would suggest you to do the following:
ensure that you are using 32-bit
version of the problematic DLL with 32-bit app
use filemon to see what paths your
application tries while loading that
DLL
check whether it works if you place
that DLL into one of those paths
use dependency walker with that DLL
itself - it might have its own unresolved
dependencies
WOW64 redirects all calls by 32 bit applications to the System32 folder to the SysWOW64 folder. Is the third party DLL in the system32 folder? Because the system32 folder, contrary to what you'd expect, contains ONLY 64bit DLLs on Windows x64.