There are four options
1- armeabi-v7a
2- arm64-v8a
3- x86
4- x86_64
Do I need to select them all if I want my application to support devices running from Android Q to Android Ice Cream Sandwich.
I want an explanation about them
Sorry about my bad English
armeabiv-v7a: 7th generation and above ARM processors. Most Android devices manufactured after 15th of 2011 use it.(support armeabi and armeabi-v7a)
arm64-v8a: 8th generation, 64-bit ARM processor, Most of new android devices use it(Contains two execution states of AArch32 and AArch64 corresponding to 32, 64bit ,support armeabi-v7a,armeabi and arm64-v8a)
x86: Intel 32 bit, generally used for tablets (support armeabi (performance loss) and x86)
x86_64: Intel 64 bit, generally used for tablets (support x86 and x86_64)
Do I need to select them all if I want my application to support devices running from Android Q to Android Ice Cream Sandwich.
Based on your description Please select all of them.
Here is a helpful article about it.
https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/cpu-architectures?tabs=windows
Related
I was curious about the ARM32 architecture (the 32-bit only version) and it's future: according to the wiki page, the Windows 8 variant Windows RT was ARM32, but it is deprecated now.
Windows 11 seems it will be ARM64-only.
What about devices released in-between?
I could not find any information/statistics related to this.
As far as I know ARM64 can run ARM (32-bit) applications, but one developing a system driver or working low-level has to support both platforms.
For comparison as far as I know, majority of current android phones are 64-bit already and with the 32-bit architecture having the 4GB limitation, logic would dictate, that outside of niche scenarios we should not really see 32bit-only ARM systems.
Anyone has any information regarding this?
There is absolutely no reason for MS to release ARM32 version:
No chip vendor is launching high end ARM32 chips
aarch64 is vastly superior to aarch32 while not much more expensive for licensees (if at all)
aarch64 is NOT backward compatible.
Why would MS want to fragment their Windows eco system more than necessary?
This question already has answers here:
Why can an executable run on both Intel and AMD processors?
(2 answers)
Closed 2 years ago.
I hope this isn't the dumbest question ever, but on my journey to learning about creating an OS, I thought about this and no amount of research is getting me anywhere.
How is it, when you install Windows on your computer, it just works, regardless of the underlying processor?
Let's say you have a 32-bit copy of Windows. How is it able to be run on every 32-bit CPU if the architecture is different per CPU? I see alot of resources saying bootloaders (where your OS starts booting), are written in assembly (which is tied to your processor instruction set). In that case, why is a Windows 32-bit OS able to run on Intel x86 as well as AMD?
For example, if I wrote a bootloader in x86, I can eventually make an ISO and boot it as my "primary" OS. But wouldn't that be tied to the CPU I wrote it for? So if I was a big company, how would I make my bootloader work for other CPUs?
Thanks! Sorry if it's a vague or repeated question, but I honestly could not find the answer.
"32 bit Windows" only runs on PC's with X86 32 bit processors. Windows includes drivers for various motherboards and devices, and can install drivers from CD or USB for devices not already supported by drivers included with the Windows install.
Some versions of Windows can run on multiple platforms, but require a Windows built specifically for that platform. The most common case of this is current versions of Windows that are either 32 bit (runs on X86) or 64 bit (runs on X86 X64). Windows NT 4.0 has versions for Alpha, MiPs, PowerPCs and PCs in 32 bit mode. XP was the first Windows to have a X64 version, and it can also run on Itanium. Windows 10 has versions for ARMV7 and ARM64 in addition to its 32 bit (X86) and 64 bit (X86 X64) builds.
I just spent all day loading up my new windows 8 laptop with all my dev tools. Only to find out that my OS version was the 32 bit version.
When I tried to run the emulator for my windows phone 8 app I got an error saying I needed "Hyper-V". Apparently "Hyper-V" is only available on the 64 bit version.
I have a two part question. How do I develop using my current 32 bit OS and dev tools? From what I'm reading I can still test with a registered phone. Any information on how to do this?
The other question is, do I bite the bullet now and upgrade to the 64 bit OS (which is a reformat and re-installation of everything)?
Thanks
I would bite the bullet and upgrade to 64 bit now. The full system requirements for Windows Phone 8 development are here. Besides needing 64-bit Windows 8 Pro or higher to use the Windows Phone 8 emulator, the other "gotcha" is needing a processor that supports Second Level Address Translation (SLAT).
PCs that support SLAT are Intel-based processors that start with i (e.g., i3, i5, i7, i9) or any CPUs based on the Nehalem, Westmere, or Sandybridge micro-architectures.
To determine if your machine supports SLAT, perform the following steps:
Download SysInternals/TechNet CoreInfo at http://technet.microsoft.com/en-us/sysinternals/cc835722
Run "coreinfo -v"
If you have "*" next to "EPT", you should be good. If you have a "-" next to EPT, your processor doesn't support SLAT.
If you hace a Windows Phone 8 device you can "unlock" it and deploy and debug apps in it, so you can keep your 32 bits OS.
Otherwise, you need to format and install a 64 bits version of Windows 8.
Is it possible for me to compile Haiku OS (a BeOS descendant) for mobile devices, for example, a phone? If yes, has anybody done it yet? Are there any examples?
At this stage it's not possible, unless you find a phone with an x86 chip in it of course ;)
There have been attempts to port the kernel to the ARM architecture and this would be the first stage in the process, devices such as the DS, some phones etc. use ARM chips. However I can't see it running on an ARM machine in the near future (read: 1-2 years) and even then there would be so many more things required - support for the phone features for instance.
For now all the effort is being spent getting it ready for the desktop, and rightfully so!
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.