Under MacOS, you can change a little option for 32-bit executables called "Open in 32-bit mode". Wouldn't it work directly? And it works, but for some applications you had to select this option in order to run without problems. This was frequent in Safari, where some add-ons required a 32-bit environment.
I can't understand what makes an 32-bit executable not able to run directly in 64-bit, so what exactly changes in 32-bit mode?
This is really only of historical interest. In the transition period from 32 bit to 64 bit many apps were built as universal with 3 or sometimes even 4 architectures combined into one fat binary (aka "Universal Binary"), typically ppc, x86 and x86-64. In a 32 bit x86 environment the 32 bit x86 executable would be used. In a 64 bit x86-64 bit environment the 64 bit executable would be used. However in some cases you might want to use the 32 bit x86 executable even in a 64 bit x86-64 environment, e.g. in the case you mentioned where you have older plug-ins which are 32-bit only and can not be used with a 64 bit executable. Hence the option to launch an app in 32 bit mode.
Obviously a 32 bit app uses 32 bit APIs and has a 32 bit address space, whereas a 64 bit app has a 64 bit address space and uses 64 bit APIs.
Related
If I use a variable of type Int64, will it work on all Windows versions: win95, 98, 2000, nt, xp, vista, win7? No matter what OS it is 32bit or 64bit? And no matter what CPU they are using?
I just want to be sure, that my program will work on all Windows versions.
The size of datatypes provided by a language is not constrained by the operating system or hardware platform. I can have 64-bit integers on 32-bit platforms (or 16- or 8- or 11-bit, for that matter).
Int64 variables are supported by the 32 bit Delphi compiler. All operations on Int64 operands will give identical results no matter what platform (machine, OS etc.) the code executes on.
On 32 bit platforms the compiler has to use special routines to perform 64 bit arithmetic using the 32 bit machine instructions that are available. When targetting a 64 bit machine the compiler can use native 64 bit instructions. No matter, the end result is indistinguishable to you.
Note that if you execute a 32 bit Delphi executable on a 64 bit OS, you will still be using the 32 bit emulator, a.k.a. WOW64. From the perspective of the executable, you are running on a 32 bit machine. Unless you are using the new 64 bit compiler introduced in XE2, you will be producing 32 bit executables.
The 64bit integers will work fine on a 32bit operating system.
Performance gains in using these data types however will only come when using code compiled for a 64bit operating system - for this you would need Delphi XE2.
Meanwhile you have the benefits extra data capacity, but not extra execution speed (although this would not normally be a consideration for most applications).
We have an application written in C/C++ code running on 32-bits windows with 32-bit Hardware. My question is that if we upgrade our hardware to 64-bit and keep our OS 32-bit, does my application need a port to 64-bit? If it requires, what benefits will be there on a 32 bit OS?
Hardware doesn't count -- the OS does. Ergo:
32 bit hardware with 32 bit OS will run only 32 bit ports
64 bit hardware with 32 bit OS will run only 32 bit ports
64 bit hardware with 64 bit OS will run both 32 bit and 64 bit ports
The advantage of recompiling for 64 bit is access to more than 3GB ram and a speed increase if you operate on 64 bit datatypes or take advantage of compiler intristics (and a few others, but do not count on a immedate gain).
If you keep the OS 32-bit, you must keep the app 32-bit, for many common values of OS. We, of course, cannot use telepathy to tell which OS you are using.
32-bit x86 is a superset of 16-bit x86. Suppose I write a code in 16-bit x86. It should ideally work on system with 32-bit x86 without any hitch. But that is not the case. Compatibility is an issue here. But why exactly? Is it because 32-bit OS installed on 32-bit x86 machine loads the programs differently in the memory and manages the memory differently?
Are different memory-management requirements the real difference between 16-bit and 32-bit applications?
In Windows:
The major problem with running 16bit program in 32bit OS is that most of 16bit programs used to run on Real Mode, which is not supported anymore(by the OS). These modes are fundamentally different and therefore require software emulation. Also since all of the 16bit API stubs, DOS functions, and BIOS calls are not available, programs would not really be able to interact with the operating system, thus making them unusable without some kind of emulation. In case of Windows, NTVDM does all the emulation starting from Windows NT3.1.
Of course, if your program does not require any interaction with the OS, you should be able to run it. In terms of the opcodes and instruction set, it is true 32bit x86 is superset of 16bit x86. It's just that the environment in which the code usually runs on is completely different.
The only one difference between the 32 bit - and the 16 bit addressmode is the meaning and the usage of those operandsize- and addresssize prefixes.
what is meant by 32-bit application?
Operand size prefix in 16-bit mode
There's a related (16bit on 64bit OS) discussion at superuser here.
I was reading about WOW 64 here
http://en.wikipedia.org/wiki/WOW64
and learnt that its a layer in 64 bit Windows OS to run 32 bit programs.
So can I assume that 32 bit programs run relatively slower on 64 bit OS against when they are natively run in 32 bit OS.
I can see the advantages of memory access of over 4 GB in 64 bit OS. But does this advantage necessarily offset the small overhead added by layer of WOW64 ? Are there any other advantages of 64 bit which offset this.
The main advantage of a 64-bit system is that it allows applications in 64-bit mode, which, in turn, is primarily useful if you need to access more than 4GB memory. If you have that requirement, using a 64-bit system is your only choice. Your application would be using 64-bit code, so WOW64 would not be used, and thus not cause problems.
If you don't really have the requirement to use more than 4GB of memory in a single process, it becomes debatable whether 64-bit Windows is really an improvement. You might need 64-bit Windows if you want to use more than 4GB of main memory at all (although you can also use PAE for that, which has its own disadvantages). Still, on a 64-bit system, you can run 64-bit applications. With AMD64 processors, 64-bit mode might be faster than native 32-bit mode, because the processor has more registers. Whether this slight gain outweighs the slight loss wrt. WOW64 depends on your application mix.
Personally, I think many people install 64-bit Windows because they don't fully understand the consequences of doing so, but feel they are on the safe side (which they may not, due to the lack of drivers).
I initially thought that 64 bit instructions would not work on OS-X 10.5.
I wrote a little test program and compiled it with GCC -m64.
I used long long for my 64 bit integers.
The assembly instructions used look like they are 64 bit. eg. imultq and movq 8(%rbp),%rax.
I seems to work.
I am only using printf to display the 64 bit values using %lld.
Is this the expected behaviour?
Are there any gotcha's that would cause this to fail?
Am I allowed to ask multiple questions in a question?
Does this work on other OS's?
Just to make this completely clear, here is the situation for 32- and 64-bit executables on OS X:
Both 32- and 64-bit user space executables can be run on both 32- and 64-bit kernels in OS X 10.6, without emulation. On 10.4 and 10.5, both 32- and 64-bit executables can run on the 32-bit kernel. (This is not true on Windows)
The user space system libraries and frameworks are built 32/64-bit fat on 10.5 and 10.6. You can link against them normally, whether you're building for 32-bit, 64-bit, or both. A few libraries (basically the POSIX layer) are also built 32/64-bit fat on 10.4, but many of them are not.
On 10.6, the build tools produce 64-bit executables by default. On 10.5 and earlier, the default is 32-bit.
On 10.6, executables that are built fat will run the 64-bit side by default. On 10.5 and earlier, the 32-bit side is executed by default.
You can always manually specify which slice of a fat executable to use by using the arch command. eg. arch -arch i386 someCommandToRunThatIWantToRunIn32BitMode. For application bundles, you can either launch them from the command line, or there is a preference if you "get info" on the application.
OS X and Linux use the LP64 model for 64-bit executables. Pointers and long are 64 bits wide, int is still 32 bits, and long long is still 64 bits. (Windows uses the LLP64 model instead -- long is 32 bits wide in 64 bit Windows).
Mac OS X 10.5 supports 64-bit user-land applications pretty well. In fact, Xcode runs in 64-bit in 10.5 on a compatible architecture.
It's only the built-in applications (Finder, Safari, frameworks, daemons etc.) also have the 64-bit version in 10.6.
Meta: I don't like to see answers deleted. I guess this has been discussed somewhere.
Anyway, KennyTM and the other kind sole got me started and although one answer was deleted, I appreciated your efforts.
It looks like this is expected behaviour on the Mac, and it even seems to work on a 32-bit Linux as well (although I have not tested extensively)
Yep. GCC behaves different (at least in my limited observation) for 32 (-m32) and 64 (-m64) bit modes. In 32 bit, I was able to access variable arguments using an array. In 64 bit mode this just does not work.
I have learnt that you MUST access variable parameters using va_list as defined by stdarg.h because it works in both modes.
Now I have a command-line program that runs and passes all of my test cases in 32 bit and 64 bit modes on Mac OS-X.
The program implements a linked list garbage collector sweeping 16-byte aligned malloc-allocated objects from a global list as well as machine registers and the stack - actually, there are extra registers in 64 bit mode, so I still have a bit of work to do.
Objects are either a collection of 32 or 64 bit words which link together to form LISP/Scheme-like data structures.
In summary, it is a complex program that does a lot of messing with pointers and it works the same under 32 and 64 bit modes.
Asking multiple questions does not get you all the answers you might want.
It seems to work, as I wrote, on Linux.
Again, thank you for helping me with this.