I am coming from windows development. I have known that a binary can either be a 32bit or 64bit. But not both. And also that on a 64bit platform I can run 32bit binary but not viceversa.
In mac I am seeing a combined architecture like i386 x86_64 which is a bit of surprise for me. Why and when exactly do we target an app on mac osx for this architecture , what is the benefit of this ? why not a 32bit only which per my understanding of windows can run on 32bit as well as 64bit ?
It's not that the code is compiled for a "mixed" architecture - it's just that it's compiled for multiple ones.
The reason for compiling it for both 32 and 64 bit is that 64-bit programs generally perform better on a 64-bit architecture (most modern Macs) than 32-bit ones.
Related
I'm working on windows applications. I've created a application for windows(64-bit). But when I have installed that application on my system. In services, it is showing something.exe * 32. But I want to make that application only compatible with 64-bit windows, not with 32-bit.
Q1. Is it possible for make application only compatible with 64-bit, not with 32-bit architecture?
Q2. if it is possible, then please tell me the factors which make it 64-bit compatible only, not 32-bit.
Q3. What changes i need to make for compatibility with 64-bit Windows only.
Yes it is possible. Compile it using 64-bit op codes and 64 bit registers and it will not run on a 32 bit Windows system. For example, using GCC, you can add the -arch x86_64 option to force 64 bit compilation.
You, however, have not stated which language you're using. If you're using Java or some other byte-code style language then there's nothing that you can do.
I am confused what setting of target platform should be chosen to enable my application to run on all computers, regardless of the processor type. I tried All CPU but it did not work on a few computers.
Thanks
The x86 works on 32bit OS as well on 64bit OS, the same for AnyCPU. So what is the difference?
The difference lays in the way the JIT compiler emits the code of your application on the target computer.
When you use x86 platform the code emitted by JIT is always a 32bit code, also on 64bit systems.
This could be a problem if you don't have installed the correct 32 drivers/dll needed by your applications (The Microsoft.ACE.OleDB is one of these problematic libraries).
Conversely, when you use the AnyCPU platform the JIT emits 32bit code on 32bit systems and 64bit code on 64bit systems. And this is more problematic than x86 because you need the correct drivers for both systems. So I suspect that the reason your app fails on some systems is due to the lack of the correct (for the system bitness) libraries used by your app.
In doubt I think is better to use x86 platform unless you have very specific requirements for 64bit systems.
Hi everyone :) am a newbie to develop applications for Mac. My questions are regading to different OS architectures in Mac and am greatly confused in this. Kindly bear with me if my questions are very cheap. Thank u all:)
I know that there is 32 bit support for 10.6(SnowLeopard). I would like to know if there is 32 bit support for 10.7(Lion)??
I have a 64 bit machine. I want a 32 bit 10.7 on it. How would i do so??
I have a 32 bit iMac and I have 10.6.8 in it. I have built an application on it; the application uses a user developed library which is also 32 bit. Now I carry on this application to another Mac machine which has 64 bit processor with 10.7(Lion). Will I be able to execute the same application as such in 10.7(Lion)?? I was not able to do so.
OS X uses a binary format that can support multiple architectures (e.g. 32- and 64-bit Intel, as well as PowerPC, etc) in a single executable or library. Most of the binaries and libraries in Lion are dual-architecture 32&64-bit Intel. So, yes, there is 32-bit support in Lion.
There is no such thing as 32-bit Lion; it's a dual-architecture OS. It can boot the kernel in either 32- or 64-bit mode, and run programs in 32- or 64-bit mode. Unlike most other OSes, it can even run programs in 64-bit mode under a 32-bit kernel. Whenever you run a program in Lion, it checks what architectures the program includes and what the CPU is capable of, and picks the "best" mode to run that program in.
There's no obvious reason this shouldn't work. If you were trying to use a 32-bit-only library from a program that was running in 64-bit mode, or a 64-bit-only library from a program running in 32-bit, it would fail. But if the program is 32-bit only it'll obviously run in that mode, your user developed library is 32-bit, and all of the libraries supplied with the OS are 32+64-bit.
There are a few things that might cause your 32-bit program to fail under Lion. First, does it depend on any libraries other than the one you mentioned and those supplied with the OS (e.g. libraries compiled locally by something like MacPorts, Fink, or Homebrew)? If so, those libraries might've been compiled 64-bit only. IMO libraries should always be compiled for all relevant architectures to avoid this sort of problem, but that's not the default.
Another possible source of trouble is if your program isn't really a program, but something that loads into another program (e.g. a plugin of some sort, screensaver, etc). In that case, your plugin needs to support whatever mode the program that'll load it is running in. You can actually get this issue with Java programs, since the java runtime will start in 64-bit mode (when the CPU supports it) in Lion.
Telling us more about your program and what specific error you get would probably help a lot...
What are the differences between compiling a Mac app in Xcode with the Active Architecture set to i386 vs x86_64 (chosen in the drop down at the top left of the main window)? In the Build settings for the project, the Architecture options are Standard (32/64-bit Universal), 32-bit Universal, and 64-bit Intel. Practically, what do these mean and how does one decide?
Assume one is targeting OS X 10.5 and above. I see in the Activity Monitor that compiling for x86_64 results in an app that uses more memory than one compiled for i386. What is the advantage? I know 64-bit is "the future", but given the higher memory usage, would it make sense to choose 32-bit ever?
32/64-bit Universal -- i386, x86_64, ppc
32-bit Universal -- i386, ppc
64-bit Intel -- 64 bit Intel only
ppc64 is no longer supported.
x86_64 binaries are faster for a number of reasons; faster ABI, more registers, on many (most & all new machines) machines the kernel is 64 bit & kernel calls are faster, etc.etc.etc...
While 64 bit has a bit of memory overhead directly related, generally, to how pointer heavy your app's data structures are, keep in mind that 32 bit applications drag in the 32 bit versions of all frameworks. If yours is the only 32 bit app on the system, it is going to incur a massive amount of overhead compare to the 64 bit version.
64 bit apps also enjoy the latest and greatest Objective-C ABI; synthesized ivars, non-fragile ivars, unified C++/ObjC exceptions, zero-cost #try blocks etc... and there are a number of optimizations that are only possible in 64 bit, too.
iOS apps need to run on many different architectures:
arm7: Used in the oldest iOS 7-supporting devices[32 bit]
arm7s: As used in iPhone 5 and 5C[32 bit]
arm64: For the 64-bit ARM processor in iPhone 5S[64 bit]
i386: For the 32-bit simulator
x86_64: Used in 64-bit simulator
Xcode basically emulates the environment of 32 bit or 64 bit based on what is set in the Valid Architecture - i386 or x86_64 respectively
Every architecture requires a different binary, and when you build an app Xcode will build the correct architecture for whatever you’re currently working with. For instance, if you’ve asked it to run in the simulator, then it’ll only build the i386 version (or x86_64 for 64-bit).
Unless you have a reason to compile for x86_64, I recommend just compiling for i386 (and PPC if you support that). Read Apple's stance on the matter:
Although 64-bit executables make it
easier for you to manage large data
sets (compared to memory mapping of
large files in a 32-bit application),
the use of 64-bit executables may
raise other issues. Therefore you
should transition your software to a
64-bit executable format only when the
64-bit environment offers a compelling
advantage for your specific purposes.
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.