I am developing a 64 bit application. Is it possible to run the 64 bit application on a 32 bit OS?
Please note that the question is generic and not specific to Windows OS. Infact the application in itself is portable across OS.
(We'll assuming your talking about AMD64 (== EM64T == x86_64) and x86 for 64-bit and 32-bit respectively)
You can run AMD64 code on x86 processors only by emulation (e.g. qemu), or some kinds of virtualisation (I believe VMWare might support 64bit guest OS on 32bit host OS on 64
bit capable CPU). However this means running a 64-bit OS as a guest on emulation or virtualisation I believe.
As you're developing the application, it shouldn't be too hard to develop both 32-bit and 64-bit builds of your code.
For Mac you can ship a single binary that has both types of code in it, or Mac OSX can run your 64-bit binary on a 32-bit kernel (only on a x86_64 capable processor though). For Windows and Linux, you'll either have to ship separate installers, or ship some smart installer, that selects the correct binaries at install time. For Linux there is a project for add the ability to run AMD64 code on x86 kernel on AMD64 processor - http://linuxpae64.sourceforge.net/ - but it doesn't look like it's got very far into the mainline kernel.
Is there a particular reason you only want to produce 64-bit binaries?
If it's to access extra memory, then the 32-bit OS wouldn't be able to give you extra memory anyway.
If it's to avoid have to test 2 different versions, then just produce the 32-bit version, it'll work on Windows AMD64, and most Linux AMD64 distributions without problems.
On windows, only using a virtual machine.
On OS X, 64Bit apps run natively (thanks Stephen)
The other way around is fine, bit I dont think you can run a 64bit app on a 32bit OS, you may be able to using a virtual machine or some kind of virtualisation.
There's an easier solution than trying to run a 64-bit program on a 32-bit OS (including executing through an emulated or virtual 64-bit platform on top of the 32-bit OS): recompile it for the 32-bit OS.
When you said it's portable across different OSes, did you also mean non-64-bit OSes? I could not call something portable without qualifying "only 64-bit" if that was the case, and I think many (maybe even most?) programmers also expect that qualification, at least currently.
it is possible using qemu in soft emulation mode
No.
See Microsoft FAQ:
The terms 32-bit and 64-bit refer to
the way a computer's processor (also
called a CPU), handles information.
The 64-bit version of Windows handles
large amounts of random access memory
(RAM) more effectively than a 32-bit
system. For more details, go to A
description of the differences between
32-bit versions of Windows Vista and
64-bit versions of Windows Vista
online.
Understand the difference between 32-bit and 64-bit and you will see why it's not possible.
See this (assuming you're running Windows):
If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)
Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.
On Windows, no. On OS X, yes. I don't know what the state of affairs is on Linux.
In fact, Snow Leopard boots into a 32-bit kernel, but compiles applications 64-bit by default, so this is quite common on OS X.
A 64 bit application does not run on a 32 bit processor period
A 64 bit application uses a 64 bit wide register. It just plain won't fit.
Related
We are moving from CefSharp to WebView2. Because of certain requirements, we are thinking of going ahead with the fixed version where the updates can be controlled by us. Now, on Microsoft's official distribution page we have 3 options available - x86, x64 and ARM64. We have users who use different combinations of OS and CPU architecture. One example is 32 bit Windows 10 Pro running on a 64 bit Intel processor. Here is where I am confused. Which one to ship to agents depending on their combinations of OS and CPU architecture. Can anybody help here? Here are the combinations -
I have not tried out and hence may be a blunt question - can x86 distributable be a safe bait for all these combinations? If yes, then what are the trade-offs?
I think x86 distribution is safe. If 32-bit OS is running, the entire system acts as purely 32-bit. It's impossible to use any 64-bit piece of code, so 64-bit applications won't work. You can also check this thread: If you want to run 64-bit app on 32-bit OS, you have to install a VM or something. I think that's not what you want.
In conclusion, I think you should choose the WebView2 Fixed Version according to the OS version.
Take for example a program downloaded from some website, the different options to pick from are the usual operating systems (Linux, Mac, Windows) but what about CPU architecture? The program is a binary executable. Does it just assume amd64? Or is the program compiled into all of the supported architectures and packaged together with a script on top that chooses the right one?
I'm only interested in C and would like to know how this is accomplished.
On further investigation, thanks to the lovely information provided by the individuals below, I came across Fat Binaries with support on both Mac and Linux. It doesn't seem as though windows supports it.
The Mac OS X binary format includes a mechanism for providing code for multiple architectures in the same file, and so a single Mac application can support 32 and 64 bit x86; in the recent past PowerPC support was possible too, although those are now obsolete. But for Windows and Linux, you generally need separate binaries for each CPU architecture (as comments have pointed out, it's possible to jury-rig something similar, although it's far from standard practice.) The default, and by far the most common, is amd64, but sometimes you'll still see separate downloads for 32-bit machines. The world used to be more interesting in this respect, but nowadays things are more standardized than ever.
On a 64 bit system running a 64 bit OS if I want to run 32 bit programs Ubuntu provides a 32 bit compatibility library, ia32-libs. I guess other OSs will provide similar compatibility libraries.
I am curious to know What exactly the 32 bit compatibility library does to provide the compatibility ?
It doesn't really do anything - it just contains 32-bit implementations of the library functions you might want to call. You need such a library so that the functions you want to call are in an appropriate instruction set and use the appropriate ABI, for example.
When you run a 32-bit process on a 64-bit system, the operating system puts the processor into a 32-bit mode before switching context to run your program.
I have a small C program that I wish to port from Linux to Windows. I can do this with the MinGW compiler, and I have noticed that it has two different prefixes, amd64 and i586. I am on an i686 computer and I was wondering if I compile my C program using and amd64 architecture, will it run on my i686 machine? And vice-versa?
UPDATE:
Is there a compiler that compile C code to run on ANY architecture?
If you compile your code for i586 (actually what is commonly called x86) it should work fine on AMD64 (x86-64) processors, since x86-64 processors can execute "legacy" 32 bit code, as long as the OS supports this - and mainstream OSes usually do; Windows support for 32 bit applications in particular is really good, since most applications installed on the average Windows system are still 32 bit.
The contrary instead does not hold true, since the x86-64 instruction set is (loosely speaking) an expansion of the x86 architecture, so any non-64 bit x86 processor wouldn't know how to interpret the new machine code (and even if it knew it, it wouldn't have the resources to run it).
As for the edit, you can't generate machine code that runs natively everywhere; the usual solution in such cases is to use pseudo-compiled languages that output an intermediate-level machine code that needs an architecture-specific VM installed to be run (the classic example here is Java and .NET). If instead you use a language compiled to "native code", you have to generate an executable for each target platform.
I have a WPF app that uses Flash10c.ocx developed on a 32 bit machine. I didn't have to register the ocx on my dev machine, I just installed the latest flash, added a reference and started coding. When testing on a 64 bit system I get ye old "Class not registered" which I think mean I need to regsvr the ocx. Is it Ok to just copy the 32 bit ocx (I'm pretty sure its 32 bit as its located in C:\Windows\System32\Macromed on the dev system) to a 64 bit system and register it?
Update: regsvr32 /i flash10c.ocx errors out with "The module flash10c.ocx las loaded but the call to DllRegisterServer failed with error code 0x80004005"
Update 2: I've given up on this and decided to run Flash on 32 bit systems only. If anyone has a better answer I'd like to hear it but I'm marking the current suggestion as answered to give due credit for the effort.
The reason it's not working for you is that your WPF application is running as 64-bit.
A .NET application is able to run as 32-bit or 64-bit; and the CLR is JITing your app to whatever architecture the application is running on - in this case 64-bit.
Except you now want your 64-bit application to load a 32-bit dll. This is not possible. A 64-bit process can only load 64-bit dlls. A 32-bit process can only load 32-bit dlls. No amount of fiddling with COM object registration will change this; it's not a question of missing registry entries.
Adobe Flash only comes as a 32-bit dll. Adobe does not now (and hopefully will never) have a 64-bit version.
In order for your WPF .NET application to load the 32-bit flash dll, it needs to be running as 32-bit process. There is a way, in Visual Studio's build configuration, to force your .NET application to only target x86, rather than Any CPU.
The choices of CPU targets are:
Any CPU
x86
x64
Itanium
Flash, for what it's worth, doesn't have an Itanium version, either.
See StackOverflow: Visual Studio “Any CPU” target for more discussion about target cpus.
May be the flash installer is meant to be only for 32 bit OS. Hence it did not install properly on a 64 bit machine. The error means that you will need to manually register the ocx but will it register successfully that's a totally different question.
Edit 1: here is Adobe's statement of support for 64-bit systems (there is none) (I assume you are using 64 bit browser on a 64 bit machine)
Edit 2: Another forum message about Flash on 64-bit Windows.