Most active commenters

    ←back to thread

    176 points Brajeshwar | 14 comments | | HN request time: 1.685s | source | bottom
    Show context
    doomlaser ◴[] No.42157271[source]
    Come on, Apple. What are you doing? I was thinking just the other day that Apple should virtualize older iPhones within the latest iPhone system software, so you could seamlessly open old apps and games (32-bit, anyone?) in their own containerized environments. I can't think why they haven't added this feature for any reason other than money grubbing.

    You could even customize the containers to be completely closed off from the rest of the iPhone—no contacts, no Internet access (or high security Internet access), etc.

    Come on, Apple. Do something good for once. Oh and bring back the headphone jack.

    -Mark

    replies(9): >>42157308 #>>42157317 #>>42157329 #>>42157337 #>>42157360 #>>42157361 #>>42157383 #>>42157388 #>>42157560 #
    1. InvaderFizz ◴[] No.42157361[source]
    32bit ARM and aarch64 are wildly different instruction sets. 32bit ARM may as well be x86 or MIPS as far as running it on aarch64 hardware, it is going to require just about the same level of emulation(memory models may be similar which would help, but that's about it).

    Unlike x86/64, the 32bit silicon is entirely gone in most aarch64.

    replies(2): >>42157386 #>>42158287 #
    2. DeathArrow ◴[] No.42157386[source]
    I wonder why Intel and AMD still keep the 32 bit and even 16 bit parts. Are there people still running many legacy apps?
    replies(5): >>42157397 #>>42157423 #>>42157443 #>>42157494 #>>42158054 #
    3. deafpolygon ◴[] No.42157397[source]
    Yes
    4. jerdfelt ◴[] No.42157423[source]
    Intel has proposed dropping 32-bit and 16-bit support in the future.

    https://www.intel.com/content/www/us/en/developer/articles/t...

    replies(1): >>42157515 #
    5. adamc ◴[] No.42157443[source]
    As a consumer, yes. Old steam games are a big deal.

    In business... not where I work, but I hear stories of shops that still have lots of old 32-bit COM stuff, etc.

    6. layer8 ◴[] No.42157494[source]
    32-bit applications are still pretty ubiquitous, including Office add-ins, and there is no particular benefit on x86 in removing support for 32-bit on the application side.
    7. layer8 ◴[] No.42157515{3}[source]
    The proposal doesn’t remove 32-bit user land or (I think) virtualization.
    replies(1): >>42158531 #
    8. monocasa ◴[] No.42158054[source]
    On windows, a lot of installers are 32-bit even if the application they're installing is 64-bit so that they can fail gracefully on 32-bit OSes.
    replies(1): >>42158412 #
    9. lowbloodsugar ◴[] No.42158287[source]
    >32bit ARM and aarch64 are wildly different instruction sets

    Maybe for the CPU implementation, but having written a lot of ARM2 assembly, the disassembly of Aarch64 is far more readable than x86_64 to me.

    10. pishpash ◴[] No.42158412{3}[source]
    Why would you care that the installer fails gracefully?
    replies(1): >>42158600 #
    11. wtallis ◴[] No.42158531{4}[source]
    X86S allows 32-bit ring3 (userland) but even VMs are stuck in long mode and only support 32-bit code for userland. Booting a VM for a 64-bit OS that has a legacy bootloader with 16-bit or 32-bit code would require software emulation of that code.
    12. solardev ◴[] No.42158600{4}[source]
    It's helpful for the users
    replies(1): >>42159615 #
    13. pishpash ◴[] No.42159615{5}[source]
    The OS already throws a specific error message, and it is the OS that should be responsible for this.
    replies(1): >>42160684 #
    14. tom_ ◴[] No.42160684{6}[source]
    This gives you no opportunity for a customized product-specific upgrade UI!

    Choosing to install the 32-bit version could also be an option I suppose.