Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com) 180
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.
Apple compatibility is a joke (Score:4, Interesting)
I can still run Windows apps originally compiled in 1992 on Windows 10.
Just sayin'.
Re:Apple compatibility is a joke (Score:4, Insightful)
Re: Apple compatibility is a joke (Score:2, Funny)
Once had a woman laugh at me because I used the WSDOT webpage to view Seattle traffic maps. Literally said "Your 'app' looks so old fashioned" and remarked how quaint it was, like I was using fucking Gopher or something.
She was an Apple user.
Re: (Score:3)
I still use Gopher, you insensitive clod!
(Well, actually I've never used Gopher, but apparently some people still do: Gopher protocol [wikipedia.org]:
... Gopher has been described by some enthusiasts as "faster and more efficient and so much more organised" than today's Web services. The Gopher protocol is still in use by enthusiasts, and although it has been almost entirely supplanted by the Web, a small population of actively maintained servers remains. ...)
Re: (Score:2)
I downloaded porn with Gopher.
Now get off my lawn!
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
Final Cut Pro 7 (the last version before X) is already incompatible with High Sierra, but it's also 32-bit. I'm going to have to keep around a machine with Sierra if I want to keep using this expensive ($999 originally) software package.
Re: (Score:2)
Unless there's Firewire passthrough and decent video performance, I think it would be a rough battle for video. I am using CS5.5 successfully on Sierra (though not Premiere). What happens with CS5?
Re: (Score:2, Informative)
Re: Apple compatibility is a joke (Score:5, Interesting)
While I do feel Apple can be too eager in breaking backwards compatibility, I also think Microsoftâ(TM)s model is equally absurd.
In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?
Re: Apple compatibility is a joke (Score:4, Informative)
You should go to Raymond Chen's Old New Thing blog and tell him this. I'm sure he'd be eager to hear one liner technical advice from Slashdotters on how Microsoft should handle back compatibility.
https://blogs.msdn.microsoft.c... [microsoft.com]
Re: (Score:2)
Re: (Score:2)
I've got a Mac and I run Windows 10 in a Parallels VM. It's true that Parallels has a number of technical advances on the XP mode for Windows 7. However much of this paragraph would still apply
Since the virtual machine is running its own operating system, you can't easily share information across the virtual machine boundary. For example, suppose somebody double-clicks a .XYZ file, and the program responsible for .XYZ files is set to run in a virtual machine.
* Start the virtual machine.
* Log an appropriate user on. Hopefully, the user has an account in the virtual machine image, too. And of course the user will have to type their password in again.
* Once the system has logged the user on, transfer the file that the user double-clicked into the virtual machine's hard drive image somehow. It's possible that there are multiple files involved, all of which need to be transferred, and the identities of these bonus files might not be obvious. (Your word processor might need your spelling exceptions list, for example.)
* Run the target program with the path to the copied file as its command line argument.
* The program appears on the virtual machine operating system's taskbar, not on the main operating system's taskbar. Alt+Tab turns into a big mess.
* When the user exits the target program, the resulting file needs to be copied back to the main operating system. Good luck dealing with conflicts if somebody changed the file in the main operating system in the meanwhile.
The hassle with copying files around can be remedied by treating the main operating system's hard drive as a remote network drive in the virtual machine operating system. But that helps only the local hard drive scenario. If the user double-clicks a .XYZ file from a network server, you'll have to re-map that server in the virtual machine. In all cases, you'll have to worry about the case that the drive letter and path may have changed as a result of the mapping.
And that's just the first problem. Users will expect to be able to treat that program in the virtual machine as if it were running on the main operating system. Drag-and-drop and copy/paste need to work across the virtual machine boundary. Perhaps they get information via e-mail (and their e-mail program is running in the main operating system) and they want to paste it into the program running in the virtual machine. International keyboard settings wouldn't be synchronized; changing between the English and German keyboards by tapping Ctrl+Shift in the main operating system would have no effect on the virtual machine keyboard.
Isolating the program in a virtual machine means that it doesn't get an accurate view of the world. If the program creates a taskbar notification icon, that icon will appear in the virtual machine's taskbar, not on the main taskbar. If the program tries to use DDE to communicate with Internet Explorer, it won't succeed because Internet Explorer is running in the main virtual machine. And woe unto a program that tries to FindWindow and then SendMessage to a window running in the other operating system.
If the program uses OLE to host an embedded Excel spreadsheet, you will have to install Excel in the virtual machine operating system, and when you activate the object, Excel will run in the virtual machine rather than running in the main operating system. Which can be quite confusing if a copy of Excel is also running in the main operating system, since Excel is a single-instance program. Yet somehow you got two instances running that can't talk to each other. And running a virus checker in a virtual machine won't help keep your main operating system safe.
As has already been noted, the virtual machine approach also doesn't do anything to solve the plug-in problem. You can't run Internet Explorer in the main operating system and an Internet Explorer plug-in in a virtual machine. And since there are so many ways that programs on the desktop can interact with each other, you can think of each program as just another Windows plug-in.
In a significant sense, a virtual machine is like having another computer. Imagine if the Windows compatibility story was "Buy another computer to run your old programs. Sharing information between the two computers is your own problem." I doubt people would be pleased.
Even with a Parallels type VM where the VM windows appear on the host machine's desktop, copy paste works and drives are shared you've still got the fundamental feature that what happens in the VM stays in the VM.
Now for me, that's actually something of a feature - I want to be able to run a separate Windows 10 machin
Re: (Score:2)
In many ways I imagine the better model would be to to break backwards compatibility and then run legacy apps in a transparent VM. Maybe something like Wine for Legacy Windows?
You mean like Windows XP Mode for Windows 7? It was a Virtual PC environment that ran a copy of Windows XP which was viewed with Remote Desktop to appear as if the application Windows ran on the main desktop. It was a good way to run 16-bit applications on a 64-bit version of Windows.
Of course, the way that you run 32-bit programs on 64-bit Windows is through a layer called WoW64. This quite literally stands for Windows on Windows. It is a subsystem that translates the differences between 32- and 64-bit API
Re: (Score:2)
If you read Raymond Chen's Old New Thing blog he explains how the compatibility stuff is mostly in shims that get loaded only when an application needs them. So the notion that worrying about compatibility held back Microsoft is dubious.
Despite that Microsoft did abandon back compatibility around XP SP3 and Vista which both broke insecure code. And then they tried to convince people to stop writing Win32 code and start writing code for their newest API which changed every year. Joel ranted about this memora
Re: (Score:2)
Weird because we have lots of Windows XP, Win7 and Win8 Apps that fail to run under Win10. Just sayin'
This! I've always wondered what world the backwards compatible people live in. Probably using XP and only think that everything they have is forwards compatible.
It's hard to get happy about, but Windows does the same thing as Apple. It even removes apps without asking. If they pray at the altar of backwards compatibility, they should just leave the programs like WMP alone.
This isn't to excuse Apple. The High Sierra update killed my Final Cut Studio suite's Apps.
So I installed them on a Core2Duo 27 i
Re: (Score:2)
The High Sierra update killed my Final Cut Studio suite's Apps.
Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.
Re: (Score:2)
The High Sierra update killed my Final Cut Studio suite's Apps.
Sierra killed Motion first. I might have to buy an ancient iMac for FCP, since I don't do enough video work to buy new software - or worse, subscribe.
Yes, that was some years ago, and I forgot. I used Motion fairly often too. My old iMac with dual core isn't a speed demon by today's standards, but fast enough.
Re: (Score:2)
Re:Apple compatibility is a joke (Score:5, Informative)
Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.
How much 'cruft' and security holes exist in Windows because of that backwards compatibility? Let some things die. If you want to run an app on Windows 3.1, run a VM of Windows 3.1.
Re: (Score:2)
Re: (Score:2)
Which ones? No really... serious question. Can you think of any titles?
Don't get me wrong... I have a fair assortment of classic games. But most are purchased from GoG and run in dosbox, which I have no doubt will be updated to support 64-bit Macs, assuming it hasn't already. (Sid Meier's Alpha Centauri still gets regular gameplay and is still much better than the disappointment that is Civ: Beyond Earth.) But in the last decade and a half, going from old versions of OS X that included Classic OS 9 emul
Re: (Score:3)
A lot of the games (including a lot of the ones bought from GOG) that I run are 32-bit Windows binaries running in WINE. That said, it's not clear that WINE needs to actually be a 32-bit Mach-O binary: it already includes its own PE loader and a bunch of translation layers that turn Windows structures into host system structures. It could probably be a 64-bit binary that would switch to 32-bit mode before jumping into Windows code and back to 64-bit code before switching out.
I doubt that Apple wants to
Re: (Score:2)
That was my question. I have a win32 app that runs on the Mac under WINE, and I've seen no reason to port it to be Win64 code. It still works fine on Windows and Linux/WINE, and to tell the truth, requests to run it on Macs have been pretty few and far between - though it works well there under WINE too.
Are you saying a 64-bit version of WINE will retain the ability to run 32-bit windows apps - or will this mean WINE can only run 64-bit windows apps in the future? What about Parallels? Will it run 64-bi
Re: (Score:2)
And I'm sure the important thing is that it doesn't rely on any 32-bit macOS APIs.
Re: (Score:2)
I still wish Bugdom and Deimos Rising didn't stop working, even before Apple switched to x86. Stuff gets broken by OS updates all the time.
Re: (Score:2)
By fairly well you fail to acknowledge the massive fuck you that was given to it's core audience (content creators) as companies like Adobe struggled to produce versions of their software thanks to the change. There were whole versions of Photoshop not available on Mac (THE platform to have if you used Photoshop professionally) because of the "fairly well" handled transition.
Cruft? Definitely. When the Windows source code leaks happened years ago there was a lot of comments in security circles on how much c
Re: (Score:2)
Apple has handled 68k -> PPC -> PPC64 -> x86 -> x64 -> arm -> arm64 fairly well.
IMHO, it was idiotic for Apple to go x86, because x86-64 was already available at the time. Soon after their first x86 machines, they moved on to Core 2, but the performance was crippled for a long time due to compatibility. And now they need this final transition stage to clean it all up.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM.
Some really clunky old kit requires obscure features of RS-232 that aren't all that well supported on USB-RS232 adapters. Fortunately you can buy PCIe RS232 cards which present a full UART and pass that through instead in those odd cases.
Re: (Score:2)
About 10 years ago, I visited a company that had just moved their old DOS-based control software into a VM for precisely this reason: they could install a USB RS-232 adaptor on their host and expose an emulated RS-232 device to the VM.
Some really clunky old kit requires obscure features of RS-232 that aren't all that well supported on USB-RS232 adapters. Fortunately you can buy PCIe RS232 cards which present a full UART and pass that through instead in those odd cases.
It isn't just the lack of emulation of obscure features. I gave up on USB-RS232 adapters long ago when they could not even handle a three wire connection to my GPS. If the RS-232 is not on an expansion card with a full UART interface, then I am not interested because it is a waste of time.
Re:Apple compatibility is a joke (Score:4, Funny)
He's clearly from the future.
Wait for Apple to unveil the MacBook Air and Mac mini replacements and you'll understand.
Re: (Score:2)
You mean Apple will release an iPad Pro running OS X, ;-)
As us Apple-haters have been demanding all along?!
Re: (Score:2)
You mean Apple will release an iPad Pro running OS X, As us Apple-haters have been demanding all along?! ;-)
Or even MacOS?
Re: (Score:2)
When they do, it'll be their idea.
Re: (Score:3)
Do a diff of find / on both iOS and MacOS. It's just BSD with a pretty paint job. People pay for the paint job not the BSD.
Re: (Score:2)
Do a diff of find / on both iOS and MacOS. It's just BSD with a pretty paint job. People pay for the paint job not the BSD.
MacOS is Unix, and, as my Linux Guru told me once, " Just think of it as the sllckest, shiniest version of Linux you've ever seen."
Noting this drives some Slashdotter Linux lovers crazy. Just watch the responses.
Re: (Score:2)
Re: (Score:2)
Windows 10 is just Windows NT with a paint job or two.
Windows ME was the last legacy 9x OS that ran on top of MS-DOS.
Re: (Score:2)
Um, x64 -> arm -> arm64? You're having bad hallucinations again, stop snorting oven cleaner, fucking moron.
Naw, he probably just reads techradar: http://www.techradar.com/news/... [techradar.com]
Re: (Score:2)
They already put an ARM chip in the latest Macbook Pros and the iMac Pro. They are already testing the waters.
Re: (Score:2)
I can still run Windows apps originally compiled in 1992 on Windows 10.
Just sayin'.
But you deal with the consequences in the limitations legacy support has put on windows development over the last 20 years.
Re: Apple compatibility is a joke (Score:2)
Any OSX app going back to the start of the intel era still runs, so this is the first break in compatibility. However itâ(TM)s entirely reasonable , itâ(TM)s been a very long time since apples actually made a 32bit machine and weâ(TM)re talking about 12 year old software
Re: (Score:2)
Re: (Score:2)
Almost 13, if you include the developer reference platform hardware. The first 64-bit 10.5 seeds were first available in June of 2007 at WWDC, IIRC, so anybody writing new apps in the past ~11 years should have been using 64-bit. So saying that 32-bit apps are 12 years old really isn't that far off.
Going to be some resistance to this one (Score:4, Informative)
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.
Re: (Score:3)
Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.
Opensource (Score:4, Insightful)
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.
Re: (Score:2)
Much more difficult with binary 68k machine code.
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.
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.
Mac users seem more accustomed to having old software getting obsoleted into oblivion. I don't even know how I'd go about running some PPC-era app now if it wasn't open-sourced or modernized. They had Rosetta on early Inte
Long term compatibility (Score:2)
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.EX
Re: (Score:3)
A MS-DOS batch file is a text file ... obviously it runs on modern windows.
Posts like this show how less clue you have about computers ...
Re: (Score:2)
More specific to my OP - for a while, Apple included a PPC to x86 translator to allow applications compiled for PPC to run on x86. They dropped that too, deliberately breaking backward compatibility. Apple has a short attention span and doesn't give a shit about protecting their customer's investments. (see: recent deliberate slowing of older iP
Re: (Score:2)
A batch file is a program. That's it's in human readable ASCII text has no bearing on that. ... ... go figure.
Comments like this show how much clue you have about the working of computers
A human readable text filed does not (need to) know if the kernal is 32bit or 64bit
Re: (Score:2)
Re: (Score:2)
We nave no CS 101 in my country :) And I doubt CS 101 in your ccountry covers EBCDIC etc.
And yet again: no, the text filed does not (need to) know if it ASCII or any other format. The interpreter needs to know ...
And now stop this farce.
Re: (Score:2)
Re: (Score:2)
You said so ... or do I remember wrong?
As an atheist, I have no religion. And before you start nitpicking again: no, Atheism is no religion.
Re: (Score:2)
Re: (Score:2)
Bend over and take it. Macs haven't run my 68K apps for years. 8088 MS-DOS 3.1 batch files still (mostly) work in Windoze, though.
Let me tell you about my copy of Visual Studio 2005 that will not work on W10. But at let you have those mostly working files.
Re:Going to be some resistance to this one (Score:5, Insightful)
If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit"
You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users. Version 13.4 of OSX will simply be warning you in advance that OSX 14 will no longer support 32 bit Apps. You can then either choose to stay on 13 and get support for another couple of years or move to version 14 and upgrade your Apps.
Apple is not going to kill anyones tools, they will continue to function tomorrow just as they did today.
For example my old iPad still works today even though Apple no longer supplies updates for it. It is stuck at IOS 9.
Bento on it however works fine and is still useful.
Re:Going to be some resistance to this one (Score:5, Interesting)
Having developed on both platforms (addmitedly only some on Apple), I have to say that Apple has a tendency to add a lot of little "programmer shinies" with every new update - handy new utilities, programming features, etc. that tempt developers to use them. Which then makes their software incompatible with older versions of the OS. So, if you want to keep running the latest versions of all your modern apps you pretty much need a fairly recent version of the OS.
Contrast that with Microsoft, whose "go suck it" attitude to developers, and tendency to try to replace old, reliable components with newer, more annoying ways of doing things, combined with their commitment to maintaining backwards compatibility, means that developers tend to stick with the old tried-and-true standbys, unless there's some compelling reason to move forward (e.g. powerful new features added in DirectX 10 and 11).
Apple's approach does a lot more to create a constantly improving programming environment (or at least the impression of one), but also keeps their users on a more vigorous upgrade treadmill.
That said - at this point I suspect most 32 bit-only Apple software can probably run in an "emulated" compatibility layer with plenty of performance, much as older XP apps can do on modern windows. But such compatibility is always imperfect, hence "will be the last macOS release to support 32-bit apps without compromise."
Re: (Score:3)
Re: (Score:2)
Yep, that's the impression I got - one of the reasons I didn't stay long - I'd rather spend most my time making new and useful tools than constantly learning how to use the new tools in my toolbox, even if they really are superior to the old ones.
Still, they've obviously got enough of a developer base willing to jump through those hoops to let them get away with it, and it's probably letting them evolve much faster than they otherwise would. Almost Linux-like in a way, with new better technologies constant
Re: (Score:2)
Where do you see any support for Jobs? I always disliked him and consider his "look at the shinies" brand of evil preferable only to Microsoft's mafia-esque behavior. And used Windows anyways because that's where all the decent software was, and Macs were way too focused on shiny at the expense of interface functionality.
Re: (Score:2)
Re: (Score:2)
If you don't behave loke an idiot in the internet, the OS version has not much to say.
My 17" runs happily on 10.6.8.
Re: (Score:2)
What the hell are you talking about ???? If you do not move to the new OS, all you existing Apps will work just fine, there is no "hit" You do NOT have to move, you do NOT have to upgrade, these choices are 100% the end users.
To be certain, I didn't see any warnings when High Sierra nuked my Final Cut Studio.
I would have taken the day's loss effort to go back to the previous OS, but I had an older Mac that isn't supported any more, so I just installed the programs on that.
But this is the bigger issue to me, not ancient MS-DOS batch files or 68K programs. Having been bit both on the Mac end and the Windows end, it's just screwed up that perfectly functional ad expensive software gets cast aside.
Re: (Score:3)
http://osxdaily.com/2018/01/22... [osxdaily.com]
Re: (Score:2)
https://discussions.apple.com/thread/8181588
Re: (Score:2)
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.
The way I see it, if it's a great app that been abandoned, this is a great time for developers to modernize them. If there are apps out there that are laden with patents/copyrights and can't be modernized... there's always virtual machines, which may be a better place for these apps to live.
Re: (Score:2)
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.
Which ones are those? I'm not trying to be a smartass - I'm genuinely curious. I can't recall the last time I used a 32 bit Mac Application.
Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.
True, and not true. At this time, a warning is issued that it will eventually not work. Now the true part isn't related to 32 versus 64 bit. When I upgraded to High Sierra, it killed my Final Cut Studio install. Not wanting to spend the bucks for an already functioning software that got botched, I had a Core2Duo iMac sitting around that now runs Final Cut Studio.
The
Re: (Score:2)
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 fr
Linux distros still run 32 bit apps. Firefox was (Score:2)
Linux distros still run 32 bit apps. Firefox was 32 bit only (main line builds) for a long time.
Re: Nope. Don't you remember PowerPC? (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re:Going to be some resistance to this one (Score:4, Informative)
They don't have any sort of a versioned library subsystem where you can state that "I need the 10.6 version of Cocoa" and have the OS provide that to you, which is because OS X as a whole is so tightly coupled together with itself that you literally cannot have multiple versions of Cocoa sitting on the same machine.
This is so laughably untrue that I don't know where to start.
First, the OPENSTEP bundle format that Apple inherited from NeXT includes a concept of versioning in the loader. You can link either to the latest version of a framework, or explicitly to an older one, and you can ship multiple library binaries for different versions in the same framework, with the linker correctly finding the right one.
Second, each Mac application embeds a MacOS deployment target, which will put some APIs into compatibility modes if you invoke them on a newer system.
Third, all of the Apple headers include annotations about which versions of each of their operating systems introduced, deprecated, and removed APIs, so you can explicitly target older versions and get compiler errors if you use a newer API. I'm not sure why you think it's better for them to provide copies of older headers instead of doing this.
Fourth, a bunch of the APIs include constants that tell specific subsystems about the expected version. For example, each time they improve the line-breaking algorithm in the text layout engine, they bump an enum value so that code compiled with an older deployment target, or code that explicitly opts into the older behaviour for compatibility, will get the old behaviour.
Re: (Score:2)
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.
How the hell am I supposed to (Score:4, Funny)
do anything useful using only numbers larger than 2,147,483,647?
Re: (Score:2)
Hey man, the new OS is 64 bit, not 33 - you can only use numbers greater than 9,223,372,036,854,775,807.
Quicken 2007? (Score:2)
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 c
Word to the wise (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
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 pap
Re: (Score:2)
Re: (Score:2)
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 wher
Re:32-Bit is like what 16-Bit was in the late 90s (Score:4, Interesting)
>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.
Re: (Score:2)
Re: (Score:2)
As far as I understand it, the Core processors are more related to the Pentium M.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
At 5GHz, the P4 would have smoked
I think you can stop right there.
Re: (Score:2)
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.
Re: (Score:2)
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.