I have windows application build using Visual C++. Its being build and run on 32 bit windows env. Now I need to make sure it works on windows vista / 7 64 bit env. What all things I need to consider for this porting process ??
That's not porting from 32bit to 64, that's just running your 32bit code on a 64bit machine to make sure it still works.
The way to do that is to just test all the functionality on the 64-bit machine, just as you do every time you release a new version, right? :-)
If you really want to port it (i.e., compile it to a 64bit executable), the first step is to just try it. You may find it works as-is. I'd only be worried about porting problems if you try it and then problems appear.
Then, and only then, would I go looking for the causes. Otherwise it's potentially wasted effort.
Porting guide: http://msdn.microsoft.com/en-us/library/aa384190(VS.85).aspx
Before building you project in x64 mode.
Include all necessary 64 bit dll's required for your project
Include Library files in linker - additional dependencies - configuration properties.
Add necessary preprocessors in C\C++ - preprocessors - configuration properties.
Enable the 64 bit warnings - When compiled the compiler shows warnings
Ex
Conversion of datatype from int to size_t there might loss of data
Storing pointer address
Magic no.
refer the below link for more on errors and warnings while porting
http://www.viva64.com/en/a/0065/
One think to watch out for is if you're storing plain old data (POD) into files or passing POD data to other apps via IPC or sockets etc.
We also had code which assumed 4 byte longs and also assumed 4 byte pointers. Needless to say we removed these anachronisms.
Compilers are usually good at spotting the other kinds of errors, i.e. long to int conversions etc. So it's usually just a case of heeding your compilers warnings and altering your code accordingly.
Related
Is it safe to assume that any x86 compiled app would always run under x64 edition of same OS the app was compiled in?
As far as I know, For Windows OS the answer is "Yes". Windows x86 emulation layer is built for the same purpose. But, I just want to reconfirm this from experts here.
What about Unix, Linux? Are there any caveats?
No, for x86 code to run it need to be run in compatibility or legacy mode. If the OS doesn't support running processes in compatibility mode the program would most likely not being able to run.
Linux and IFAIK Windows currently supports compatibility mode and it looks like many more are supporting it too, more or less. My understanding is that NETBSD requires a special module to support this, so it's not necessarily without special care that it will be supported and it shows that it's quite possible that there exists OS'es where the possibility has been dropped completely.
Then in addition there's the possibility of breaking the backwards compatibility in the future, that's already happened on the CPU as virtual x86 mode is no longer available from long mode that is you can't run 16 bits program anymore under 64-bit Windows or Linux.
It could also happen on the OS side, that the developers could decide not to support compatibility mode anymore. Note that this may also have happened as it might be possible to support virtual x86 mode by first switching to legacy mode, but if possible no-one seem to have bothered doing it. Similarly neither Windows or Linux developers seems to have bothered implementing possibility to run kernel code in legacy mode in 64-bit kernel.
The preceding two sections shows that there are future or even present indications on this might not always be possible.
Besides as this is a C++ question you would have to ask yourself the question why you would want to make such a assumption? If well written your code should be able to be compiled for 64-bit mode - for you haven't relied on data types being of specific width, have you?
No. We have a whole bunch of Debian servers which miss the Multi-Arch i386 (32 bits) libraries. On Windows Server Core, WoW64 (the 32 bit subsystem) is optional. So for both Linux and Windows, there are known 64 bit systems that won't run x86 executables.
I have a program that I made in Visual Studio 2010. I built the program in release mode and Win32 solution platform. I then made an executable by following this guide step by step. I then copied the setup.exe that was created onto a new 32-bit computer. I then get this error message when I try to run the setup on the new computer:
Why is the setup not working? I built the program in Win32, so it should work on a 32-bit computer? Am i missing something? Any help would be appreciated.
There are 3 major reasons for this to happen. The Windows executables contain 3 fields that must be matched by the OS: Minimal OS version number, correct CPU type and correct CPU bit-ness. Now you're probably not running into a Windows version issue (I think the error message is different), you're quite unlikely to have the wron CPU type (ARM builds are pretty hard to make by accident) so that leaves as the most likely scenario that you actually made a 64 bits build.
"Win32" is a rather deceiving term here, it doesn't always exclude 64 bits builds. E.g. the macro WIN32 is defined for 64 bits builds as well.
#Mailerdaimon and #MSalters you were correct. Even though I was building the program in win32, the target machine was x64. After changing it to x86 the program ran. Thanks for everyones help!
I am developing a cross-platform application and I need to determine whether machine B will be able to run the application that is compiled on machine A.
I am using Qt and I already understand that I need to either package the Qt libraries with the application or statically link against Qt itself.
I also understand that something compiled on Windows can't run on Linux.
However, there are still some other vectors that I'm not sure to what extent they matter. Here is the summary of my current understanding:
Affects Portability
Operating System (Windows, Mac, Linux)
Availability of third party libraries (Qt, static vs dynamic linking, etc)
May Affect Portability
Flavor of Linux (Ubuntu, Red Hat, Fedora)
Architecture (32 or 64-bit)
Version of Operating System (Windows 7 vs Windows XP, Rhel5 vs Rhel6)
Instruction type (i386, x64)
Of the May Affect Portability items, which ones actually do? Are there any that I am missing?
All. At least potentially.
If two different machines have no binary compatibility (e.g.
they run on different architectures, or interface to
incompatible systems), then it will be impossible to create
a single binary that will run on both. (Or... does running
a Windows program under Wine on Linux count?)
Otherwise, it depends. You mention third party libraries: if
they're dynamically loaded, they have to be there, but there's
always static linking, and there may be ways of deploying with
the dynamic library, so that it will be there.
The 32 bit vs. 64 bit is a difference in architectures: a 32 bit
program will not run in a 64 bit environment and vice versa.
But most modern systems will make both environments available
if they are on a 64 bit machine.
Issues like the flavor and version of the OS are more complex.
If you use any functions recently added to the OS, of course,
you won't be able to run on machines with an OS from before they
were added. Otherwise: the main reason why the low level system
libraries are dynamically loaded is to support forwards and
backwards compatibility; I've heard that it doesn't always work,
but I suspect that any problems involve some of the rarer
functions. (There are limits to this. Modern Windows programs
will not run under Windows95, and vice versa.)
There is also an issue as to whether various optional
packages are installed. Qt requires X Windows under Linux or
Solaris; I've worked on a lot of Linux and Solaris boxes where
it wasn't installed (and where there wasn't even a display
device).
And there is the issue whether it will run acceptably. It may
run on a smaller, older machine than the one on which you tested
it, but it could end up paging like crazy, to the point where it
becomes unusable.
If you compile an application on a 64-bit processor, it wouldn't by default run on a 32-bit processor. However, you can pass options to the compiler to have it compile code to run on a 32-bit processor. For example, if you're using GCC on a 64-bit machine, if you pass -m32, it will compile 32-bit code. 32-bit code by default can run on a 64-bit machine.
Sources
https://stackoverflow.com/a/3501880/193973
Different flavors of Linux or versions of operating systems may have different system libraries. For example, the GetModuleFileNameEx function is only available in Windows XP and up. As long as you watch what functions you use though, it shouldn't be too much of a problem.
The x64 architecture is backwards compatible with x86 ("32-bit"), so programs compiled for the x86 will run on x64 machines, but not vice versa. Note that there are other, less common architectures too, such as the ARM and PowerPC.
I can immediately think of three things that interfere with portability. But if your code is in a file format understood by both systems, an instruction set understood by both systems, and only makes system calls understood by both systems, then your code should probably run on both systems.
Executable File format
Windows understands PE, COFF, COM, PEF, .NET, and others
Linux by default ELF, OUT, and others
MaxOSX uses Mach-O
Linux has extensions to run the Windows/Mac formats too (Wine, Mono...)
Instruction set
Each processor is a little different, but
There is usually a "lowest common denominator" which can be targetted
Sometimes compilers will write code to do a function twice
one with the LCD set, one with a "faster" instruction set
and the code will pick the right one at runtime.
x64 can run 64bit and 32bit, but not 16bit.
x86 can run 32bit and 16bit, but no 64bit.
Operating System calls
Each OS usually has different calls
This can be avoided by using a dynamic library, instead of direct OS calls
Such as... the C runtime library.
Or the CLR for .Net.
note:before down vote or anything like this,this is a general question to understand more how everything is going
the question simply is:
assume I compiled a program with c++11 features (using VS2012 on windows) is there a guarantee that this program will run on older processors?(like core 2 duo;as most laptops got this)
I'm currently working with VS2010,but found libraries that needs C++11 features.
so I want to port the whole work to VS2012,but my knowledge is limited about how this gonna work
correct anything wrong in the question
edit:
another 2 questions:
1 -can I "mix" a compiled c++11 program with older one?
like calling functions which are inside the new version (.dll) from an old version(.exe) so I got 2 files:
1 is compiled with VS2010 the other 1 is compiled with VS2012,with DLL EXPORT can they work like that?
2 -suggest a better environment than VS2012 for windows
As long as the architecture for which the target is built is the same (x86 for 32 bits or amd64 for 64 bits) you shouldn't have any issue.
Of course you will need to provide the older machine with the correct runtime library to run your program (for the current architecture).
Yes, The compiler requires additional libraries to build the program. But this shouldn't affect the ability to run on older processors. The only time this changes is when your trying to run a 64 bit program on a 32 bit processor.
Porting to VS2012 is simple, open the solution in VS2012, and save it as a vs2012 solution. It should all be fine.
Edit: odds are, if your new to programming, all of your programs are compiled for 32 bit processors by default unless you code to change this, so you shouldn't worry. You can run 32 bit programs on 64 bit processors, just not the other way around. If you really want to step it up, you can make a program that can run on both processors ;)
given a compiled executable the usual requirements to run it are:
ABI
platform
libraries
and since Windows is a commercial product, depending on what are you doing, you could add another factor
environment
which means that sometimes a software house intentionally breaks the compatibility with other products to sell more stuff.
In general VS it's not that good, certainly it's not the best the compiler I have ever used and basically anything from GCC to Clang to MinGW can supersede VS easily, but VS it's the official compiler and environment for Windows so this is what you have to deal with most of the time.
If you have fulfilled the listed requirements you are good to go.
By the way a Core 2 Duo it's not that old, and the actual iCore generation it's not that different either.
Can it cause any problem if I use 32 bit library on a 64 bit system?
What could be the incompatibilities?
I know this question is too vague. An example :
I tried to setup FreeGlut 32bit library with VS2010 on windows 7 64bit. There were a lot of issues at first.So, I was looking for 64bit of FreeGLUT, thinking 32bit FreeGlut might conflict with 64 bit windows. But later on I managed to run my 32bit FreeGlut with my 64bit windows without any problem.
Question is, if there are any thing in the program, that we should look into while using those libraries which doesn't match with the system. (32bit library on 64 bit OS)
64 bit Windows is fully capable of running 32 bit applications. In fact, the default configuration for Visual C++ is to build an x86 application regardless of the operating system it is running on.
There are some gotchas you have to be aware of when running a 32bit app on 64bit Windows. For instance, there's registry redirection (to avoid it you pass KEY_WOW64_64KEY to e.g. RegOpenKeyEx). There's filesystem redirection, too. These are important things to have in mind when you are reading system configuration values, for example.
Also, be aware that you can't mix 32 and 64 bitness in the same process. Your 32bit app can't use 64bit DLLs or static libraries.
Visual studio can compile for 32 bit or 64 bit based on the project setting.
Probably, Question you mean to ask is about Linking 32-bit library to 64-bit program
The answer is:
You can't directly link to 32bit code inside of a 64bit program.
The only option is to compile a 32bit (standalone) program that can run on your 64bit platform (using ia32), and then use inter-process communication to communicate to it from your 64bit program.
It's not about the operating system- Windows doesn't care if your code is 32bit or 64bit. It matters that your process is the same bitness as all libraries it cares to load- and they must all be the same bitness.
You might be interested in this link explaining common compiler errors when porting to 64-bit. It might help you solve your problem.
To try to answer your question more directly, there are things that might make 32 bit libraries break in a 64 bit environment, but that's too much information to share in a SO answer.
This link is the MSDN index related to development for 64 bit systems and might interest you as well.
Your question could be about how to develop specifically code that will run natively on 64-bit versus 32-bit hardware. There is info on that here. In particular you would have to follow the instructions here to enable 64-bit build tools.
If you are building 64-bit binaries, you will need to link with 64-bit libraries. Note that 32-bit binaries should run just fine on 64-bit Windows, so you may not need to go to this trouble.