Hacker News Reader

Comment by acomjean | Hacker News Reader

A lot of apps never made the switch on ios. I have some useful ones that were orphaned. I feel like only the mac original intel chips were core2 32bit one, and those long lost os support.

Its weird that dos (box) and old windows programs are often still runable, but somehow mac applications just don't age nearly as well.

I really think if some linux distros can get it together and get some good application support, now is the time for them on the desktop/laptop.

going to Apple-Menu->about this mac->system report ->software applications

will show a list of applications with the right most column indicating 64 bit support. 95ish % of mine are currently 64 bit

View on HN

Microsoft and Apple have different approaches to backwards compatibility based on the markets they're in. Microsoft makes most of their money on enterprise, whereas Apple makes most on consumers. Enterprise values running old apps, consumers value running today's apps. Each makes sense for their market... and desktop Linux doesn't make sense for either.

lol, nice little zinger there at the end for "the year of Linux on desktop".

Haha I mean we've been talking about it for two decades and in that time the market has reached maturity and is now in decline. It's always been a pipe dream.

Is the Apple/consumer thing still true? Not questioning your general business-model assumptions, but anecdotally all the “consumers” I know with Macs are holding onto them for six years, while every dev shop I’ve worked in in this decade goes through new MBPs like commodity office supplies. I’m just curious if there are recent stats on who Apple is selling computers to (I haven’t seen any for a while.)

Apple doesn’t really have a product combo to replace AD+SCCM. Macs are popular in companies that are still small enough to have people manage their own machines.

Is that really true?

We have 20000 Mac users in a company of 90000, I don’t think this is a corner case for large technology companies.

My machine is managed in the sense some things are preinstalled and IT has a way to push software updates.

What more management is required? Anything more and IT would probably fuck it up like they did when our division was still on Windows.

Unified image on all machines, auditability of installed software, etc. End users absolutely do not have admin rights.

Not saying your company has to be like this. Just saying 1) this is where MS has very little competition, and 2) where they make absolute bank.

> in companies that are still small enough to have people manage their own machines.

Company size doesn't have much to do with this. Macs are popular at IBM.

Last time i read anything about that, those computers were still largely self-managed (though with a in-office wiki for collected solutions).

Our macs are integrated with AD and are remotely managed similarly to windows.

> Macs are popular in companies that are still small enough to have people manage their own machines.

140,000+ employees in this company. Macs outnumbers Windows boxes. Pretty much the only place you see Windows machines are in the various accounting departments, and in the call centers where they're just used as terminals to big iron.

Frankly i think consumers value backwards compatibility as much, if not more, as companies.

At least as one gets older and just want to get that thing done that they always have (a certain big name author still writes using WordStar in DOS i believe).

Backwards-compatibility is an interesting story on the mac. The Objective-C ABI on 32-bit macOS is what is called the "fragile" runtime because it has the fragile base class problem. Originally Objective-C had the same design flaw as C++: the ivars of every class had to be in the header for all to see so the compiler could rely on the binary layout. A subclass' ivars would be offset by the compiler by examining the layout of every superclass, then baked into the binary.

In the modern (all iOS and 64-bit macOS) runtime the ivar offsets are patched up at runtime so the layout of classes (including base classes) can change without breaking compatibility.

Working around the limitations of the 32-bit Objective-C runtime imposes significant costs, it is far from a simple recompile with a different pointer size. It also adds a lot to the size of the installed OS.

It's kind of sad we're in this state in 2018 because Apple launched 7 low end machines [1] back in 2006 that didn't have 64-bit support. Even though those are long gone, their software support legacy remains. Apple could have transitioned directly to x64 and saved themselves the headache (afaict, maybe these problems would have persisted?).

[1] http://lowendmac.com/2006/core-duo-macs/

Apple couldn't have gone straight to 64-bit apps on Intel--the OS and frameworks just weren't ready yet. The Intel machines shipped starting with 10.4.3, which only supported 64-bit command-line apps/daemons. Only with 10.5 (released in late 2007, 18 months after the first Intel machines) were full graphical 64-bit apps supported (on both ppc64 and x86_64).

Firmware was an issue, too. The first generation of Macs with 64-bit processors still used 32-bit EFI and booted a 32-bit kernel that could run 64-bit applications.

True, it wasn't until 10.6 that a 64-bit kernel was available, and only newer machines got to use it.

https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/5/

I had a blog article about the entire mess that was often confused (there was actually three modes): http://yuhongbao.blogspot.ca/2009/09/mac-os-xs-64-bit-modes....

The oldest Macs that support Sierra (10.12) or High Sierra (10.13) are from 2009. You may be able to bypass these restrictions which are often based on graphics chips through kernel extensions, but discontinued support for 32bit probably has much more to do with older software than older hardware.

If you want to find unusual problems with older Apple hardware for the sake of reusability, take a look at the firmware from around that time. It was just weird enough to make it similar to standards but often too difficult to support a decade later. In a decade, people are going to say the same about the not-quite NVMe SSD interfaces in current Macs.

They wanted to avoid NetBurst (including Prescott and Cedar Mill) and picked Yonah which was 32-bit only instead.

What's worse is that they had already been transitioning to 64bit hardware with the PowerMac G5 and iMac G5 models since 2003.

Anyhow, I doubt they'd have had time to make a solid 64bit x86_64 SDK even if they had delayed the hardware to late 2006. They had never stopped maintaining the x86 port of OS X (aka Rhapsody, Open Step, NeXT Step), just stopped shipping it as a product, because their strategy was and still is to package their OS in hardware boxes. They started shipping x86 boxes to developers in the form of the x86 development box, which was a (32bit) Pentium 4 shoehorned into a Power Mac G5 case. Its OS is also what leaked to the early x86 hackintosh scene; before Apple shipped their own x86 Macs. I ran it on an custom Athlon64 box and a ThinkPad T42.

Since they already had the x86 port, it was an easy switch at a time when all x86 hardware from Intel was still 32bit. If they knew Intel would adopt x86_64 from AMD, one option could've been to ship with AMD CPU's on the first models, but I'm not sure how well that'd have turned out logistically or whether it'd have made a huge difference.

There are also a whole bunch of APIs left out of 64-bit macOS, including almost all of Carbon that dealt with UIs (HIToolbox, ATSUI, QuickDraw, Nav Services, Dialog/Menu/Font Manager, etc). None of these APIs have received anything more than bare maintenance in the last 10 years, and evolving the system while keeping them operational has not been easy.

In a way, this is the true last step of the Mac OS X transition that started in 2001--the removal of the transitional APIs that made it possible.

I find it interesting in perspective of the Swift language their are now pushing.

Theoretically would’nt programms written in pure Swift today be able to compile for any new hardware plateform, thus avoiding the kind of issues that 32/64 switch faced?

Instead you get issues with updating from Swift 1.x to 7.x.

The educational story of this sort is the transition between python 2 and 3... not ever done for some packages.

So much this. When you're a small team, this sort of thing can basically mean having a product vs not.

Swift is a new language, so it’s sure to have source breakage in the first few versions. The compiler is now backwards compatible, though.

I never did understand why this couldn’t be backported to 32-bit. Was it something like a lack of bits for tagging, or something more mundane like nobody wanting to support 32-bit?

For development purposes I'll take a Ubuntu loaded Dell laptop over anything windows, and wouldn't even consider a MacBook.

It all depends what one understands by development.

My Ubuntu netbook is nice for travelling purposes, but for the kind of work I get paid for, it is Windows and occasionally macOS.

If I am developing for a Ubuntu server, I'd rather just use Ubuntu directly. Plus the user experience is just as good if not better than osx or windows, but that is a highly personal opinion. I've been using gnome and kde for two decades now. Windows just just has nothing to offer me, and Macs have always been fairly "meh" in my opinion since I had to deal with classic "hard crashes" and those ugly jelly beans

Enterprise values running old apps, consumers value running today's apps.

Do they really, or is it just that consumers are more likely to be persuaded by Apple's marketing?

Personally, I have some apps which I use regularly, and are at least 20 years old. I use mostly Windows for that reason too.

Consumers like it when their 10 year old video games still work, but those users probably weren't buying Macs to begin with.

Someone else will know the details a lot better, but Apple has changed the licensing details on many of its older OS X versions to legally permit virtualization if the host is a Mac. Which OS version images I can download for free in the store right now appear to be linked to which ones I had ever used under my current Apple Store account.

Given that a lot of current Macs come with only 8GB of ram it is not ideal to run a lot of applications in a virtual machines, but applications that need much RAM have almost certainly moved to 64bit anyway.

Again, someone else will understand it better, but I think products like Veertu were built on Apple's built in hypervisor framework, and it would not be difficult for people to build additional free virtualization options in MacOS. My point is that the reasons for choosing Linux over MacOS are already sufficient without targeting users of older Mac software, and that people who are using older Mac software probably also use new Mac software, and won't have too difficult a time using the older stuff too.

A while ago I would have said that something like Wine would be great for using the best software I can ever remember which only ran on early Macs. Except that these days you can do that in Javascript in any browser, and while the software was good, I've already spent a few weekend afternoons playing with them, and I don't need to anymore.

I miss my 32bit iOS games more than I'd miss any 32bit MacOS applications, which I could run anyway through virtualization. I also wish they'd stop disappearing features from Apple software in general, but I think sunsetting 32bit apps or Carbon are generally better for the Macintosh ecosystem.

Re: iOS, yeah, I was looking at my purchased app history to get inspiration for a new project and a decent chunk of apps I bought around the time of the first iPad (as well as newer ones) are no longer available, which is a shame. I can’t really blame the authors for not going back and updating a £1.99 app 6 years after the fact, but it’s a shame and I hope there won’t be another “extinction event” like this. Am I right in understanding that Bitcode should make architecture changes much less of an issue for iOS in future?

Apple is pinning a lot on bitcode, but they really aren't willing to do what Linus does and take a firm stance to not break userspace. Microsoft does that to a fair degree, hence old WinXP apps still running on Windows 10. When you get back to the DOS era tho, better to just use DosBox!

Due to the closed ecosystem for iOS, this type of abandoned app preservation will be extremely hard to do :c

The only ones I have that aren't 64 bit are games interestingly enough. And Calculator and DVD Player, which is odd, I'd expect that to have been ported by apple by now. That said the DVD Player app is not a big deal as I don't have any dvd drives any longer I realize, oh wait i bought a usb one, would have to find it.

I wonder if they whitelisted Apple 32 bit apps so that they won't trigger the new warning message. It would look a bit janky if they didn't.

My report shows Calculator as 64bit. (Version 10.13)

So the calculator I had as 32 bit turned out to be from some iOS app I compiled god knows when or how long ago, oops. :)

Calculator:

  Obtained from:	Unknown
  Last Modified:	12/27/16, 9:00 PM
  Kind:	Intel
  64-Bit (Intel):	No
  Location:	/Users/mitch/Library/Application Support/iPhone Simulator/6.0/Applications/610B1057-FF52-4D59-AE7D-DDD406E83F18/Calculator.app

Looks like you started the Stanford iTunes U course

Sounds about right actually, good call.

Somewhere in the recesses of internal Apple email exchanges, there's probably a debate about whether they should just drop support for DVDs when they do the 32-bit transition. They're ruthless about old formats.

Calculator is 64-bit

Apple still sells a USB CD/DVD burner, I don't think they'll be dropping DVD playback any time soon. I think it's more likely that they've had an intern rewriting DVD Player.app in Cocoa and Swift, and it'll ship in 10.14.

https://www.apple.com/shop/product/MD564LL/A/apple-usb-super...

Do you suppose it'll support BluRay, by any chance?

The current version 1.21 of Kindle is only available in 32-bit.

Ah, good old Android File Transfer isn't 64-bit. This should be fun.

Looking a the list I see: Steam stuff, Blizzard stuff, WebEx and something for the logitech mouse. Sadly unsurprising, the biggest players are the slowest to move.

The only 32-bit apps on my machine are a bunch of Adobe helper apps...

Reply on news.ycombinator.com