Apple gets a bad reputation for their supposed lack of backwards compatibility. Nothing is further from the truth: macOS includes tweaks for specific important apps to keep them working on new OS versions.
I read it more as "even Apple is willing to put in patches for backwards compatibility, if your app is important enough." If your app is not, then Apple couldn't care less. MS is more conservative about not breaking things even for relatively obscure apps.
Cocoa would not change from a stable sort, even if undocumented, to an unstable one. There's large compatibility risk and no benefit, since any app that is bound by sorting speed should do something custom anyways.
As to why the sorting hot fix: My first guess is that the app modifies the array from within the comparator. My second guess is that the comparator is not actually transitive, e.g. there can be "less than" cycles. In either case, Cocoa could work around this by employing a naive sorting algorithm.
Might be. I took a look at _CFArraySortValues, and the "normal" path through it ends up calling CFQSortArray. However, the "com.microsoft.*" path performs what appears to be a bubble sort. Interestingly, the public facing version of CoreFoundation doesn't have the special-case paths: https://github.com/apple/swift-corelibs-foundation/blob/df3e...
I can't imagine they're using the OS sort for actual spreadsheet data. It's probably for something else like filenames or whatever, and it ends up not finding the file it's expecting in the place it's expecting.
Agreed, especially since I (the GP) thought about this the wrong way - _Apple_ has chosen to use bubble sort as a compatibility measure for some Microsoft apps, not the other way around.
Which was possible because Microsoft decided to use Core Foundation APIs for sorting instead of their own implementation for spreadsheet data. Or maybe it's not for spreadsheet data, but just their custom file picker or something?
It's a framework-provided sort, not an OS sort. Its use is no weirder than using stdlib sorts, such as Go's "sort" package (which does either a quicksort, heapsort or shellsort, depending on the input length).
However, relying on stability if it is not specified is a bad thing.
While I'm not a big fan of reinventing the wheel, when you're maintaining a 31-year-old cross-platform app that the majority of the planet's businesses rely on for their calculations, I'd be using a custom cross-platform math/sorting/etc engine rather than delegating to any OS, framework, stdlib, third-party anything. Considering this is Microsoft, where Office 4.2 for Mac was as close to WINE as you could get in the 90's, I'm assuming they're doing the same.
They are in platform specific code, manipulating CoreFoundation types (specifically a CFMutableArray), so your cross-platform homebrew sort suggestion is out of scope here. Any sorting function would need to be CoreFoundation (iOS/watchOS/macOS) specific.
When possible, it would of course be best to use stdlib functionality, which would implicitly be cross-platform. Writing it yourself, or pulling in third-party libs to do it ranks way below stdlib, although I can't agree with myself whether doing so is better or worse than using OS-specific standard frameworks. Regardless, it is out of scope in this example.
No, as I wrote, I would assume any use of CoreFoundation types are only used in platform specific code (dealing with UI, system events, etc.), which would be a minority of the code base, and entirely unique to the platform.
Using CoreFoundation in such code is entirely sensible. Generalizing a sort for something like this would be a waste of time with no gains (as long as the functionality is used correctly, like not assuming a non-specified sort to be stable).
However, for the actual business logic, the hierarchy would be:
stdlib > large third-party cross-platform lib > small third party cross-platform lib ≈ homegrown implementation.
Bubble sort is never a good choice unless so extremely lazy or what to impersonate Obama...[0]
There are dual-pivot quicksort, smooth sort (in-place, based on Leonardo numbers and takes O(n) time to process a presorted array and O(n log n) in the worst case, and achieves nearly-linear performance on many nearly-sorted inputs), TimSort (that's stable as plus).
Morealso changing stable to unstable sort is usually a very bad move.
At one point I was implementing managed memory on a highly memory constrained system. The system pretty quickly ran into issues with having enough memory to fulfill a request, but no contiguous block long enough. The solution to this is of course defragmentation. The issue is that allocations are irregularly sized and all swaps have to be done in-place. There was also a need to collect blocks of similar size together so the GC could work faster. Bubble sort was the only way to meet all these constraints cleanly, and better yet it only took 10 lines. It still felt dirty though.
How is it that your data was too big to fit in memory, but small enough that bubble sort ran in a reasonable amount of time? Did you have really tight memory constraints (not sure I'm guessing you'd have to have <100KB of memory)?
The data wasn't too big to fit in memory, but rather defragmentation meant that the amount of free memory available was less than the amount of contiguous space, which will be an issue in any dynamically allocating system that doesn't translate pointers.
That said, bubble sort is only n^2 and computers are fast. The real solution was that defrag was an alternative to crashing, so it didn't matter how long it took. Calling it meant a bug report needed to be filed.
In fact friends don't even let enemies use bubble sort, if they have an ounce of humanity.
Edit to actually answer the question: I wonder if it's something to do with some specific dataset having to be sorted in a particular way? i.e. where you'd normally use a stable sort, but the code accidentally depends on a specific unstable sort.
There are any number of better ways to fix 1, though!
2 occurred to me too, but surely that’s too cynical. It would make Macs look bad more than Excel itself.
Maybe it’s a bit of both. They needed a fix for 1, but they didn’t care about Excel performance at all so someone just spent 20 seconds doing a quick bodge job.
Is it wrong to ask if Microsoft intended it to be slow?
Mac Outlook on a recent MBP is noticeably slower (usability impact) than a similar version of Outlook on my Windows VM on the same machine against the same account (30k items, 5GB-ish)
Nope, bubble sort always performs the same number of ops regardless of whether the array is partially sorted or not. You might be thinking about insertion sort, which has that feature.
I believe the open source Swift versions are not supposed to have any check fixes. They are not the ones that are run on Apple OSes and probably never will be. They’re more meant to help Linux and other non Darwin platforms adapt. Which kinda sucks because it means the repos are a little lacking.
The iTerm2 one is interesting because it came too late. Apple's patch disables Sierra's native tabbing. Version 3.1.3 did not disable it completely. I published a fix in version 3.1.4 which came out on October 22, 2017, about a month after Sierra launched. I guess they must have fixed it in a dot release of Sierra, but I won the race and got the fix out before 10.12.1 which came out on October 27.
Speaking of iTerm's tabbing functionality, are you still using PSMTabBarControl? You make a couple of odd decisions with tabbing, such as blank spot in the tab strip on the right to make way for the overflow indicator, which IMO is inferior to how macOS does it (scrolling tabs). In addition, tab defocusing causes visual discoloration. Does macOS just not provide the API you need, or what?
Um.... Why? 1px Wide Tab is basically a design that forces people not to have too many tabs. Which is great for those who can keep their Tabs Numbered. But even discounting the number of tabs open to be read, a single Feedly section, or in the old days Google Reader section I could easily bump up to 100+ Tabs, and much more in WWDC / Apple Keynote time.
Which makes 1px Tabs annoying as hell.
So I really don't understand why 1px Tab is preferred over Scrolling Tabs.
I'm a tab monster and almost never have less than 100 open at a time, so no, I disagree that it's only great for those who can keep their tabs numbered.
Putting scrolling in a tab bar doesn't allow the user to take full advantage of spatial and muscle memories.
And when those memories fail, because scrolling tabs literally removes tabs from view, the user can't even revert to a visual search to find them! Instead one has to slowly scroll through a list of identically sized tabs, hoping that window #5 is actually the one containing the desired tab in the first place.
Oh dang, it was actually window #4.
Compare and contrast this to non-scrolling tabs, where tab size continually shrinks as tabs grow in number. #1 - you can identify which window is relevant by the tab sizes alone (so even if you move your windows around you're not lost). #2 - you can identify tabs by spatial memory, because you know approximately where, horizontally within the window, your tab exists, cutting your search space down to a few tabs only. #3 - you have visual cues as to when you might need to split out into a separate window for ease of tab management.
Of course, 1px is hyperbole, but 15px-30px is most certainly not, and on a modern display you can fit very many 30px tabs in a row without scrolling.
That's not to say that there aren't limitations to shrink-to-1px tabs, of course there are. But in all circumstances as a UI tool they are objectively better than scrolling tabs, until they shrink to an unusable size. At which point, scrolling tabs still isn't a good solution to the problem (grids, multiple rows, tab lists, tab groups are all vastly better options here).
I guess because you have to do a ton of scrolling to go from one of the first tabs to the last.
Of course, if you don't have scrolling tabs then the tabs get so small that it's basically impossible to find what you want.
I solved this dilemma by hiding my FireFox tabs and using Tree Style Tabs. I find it really helps with keeping tabs organized and I can keep a lot open without worrying. I removed the scrollbar and close buttons, and made the tabs smaller, to further save on screen real estate.
But this is how macOS chooses to deal with a large number of tabs, and I generally prefer applications to match what the system does (which nicely enough means that their behavior updates when the system's does).
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS ... the Windows developers ... added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
> Look at the scenario from the customer’s standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn’t work at all. You’re going to tell your friends, “Don’t upgrade to Windows XP. It crashes randomly, and it’s not compatible with program Z.” Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn’t work because it is using undocumented window messages? Of course not. You’re going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)
windows hardly changes a function contract. most their patches are to support bugged programs that used the api in undocumented ways, not because they changed an api functionality
Back when I looked at the compat fixes in Vista there were about 6000 applications listed there. Granted, a lot of them were games, where the only effect was that they would be added to the (then-new) Games folder. Still, I guess the list has only grown since then.
Bill Gates had the strategic vision to see that software was not only going to be a viable industry, it was likely to be the most valuable computer industry.
It seems like he was good but not a spectacular programmer himself. Barbarians Led By Bill Gates is a great book about the relatively early days of Microsoft--early enough that the book describes some instances of programmers finding and replacing Bill's code with better stuff. IIRC there is at least one story of a new guy going "who wrote this crappy code" and then finding out it was Gates.
The major impact of software and computing was front-loaded, as in, it came with the early hanging fruits: being able to computerize banking, government data, credit card transactions, international trading, etc. This gave a huge boost to market efficiency and globalization.
The rest, with the internet, apps, online sales, etc, is just another outlet for doing business. Whether a 2B2 order happens on the web, or by old-style computer networks, or even by fax, is not that much of a difference.
I don't think that's entirely fair... It's true that computers and computerisation have never been so ubiquitous as they are now, but they've still been having a big impact for a long time.
Off the top of my head, credit cards and ATMs, and the purchase tracking and credit scoring agencies they enabled, have been a big deal since the 60s, says Wikipedia. (I would have guessed later!) Can't do that without a lot of software.
I used to maintain a Finder plugin that added icon overlays to files, and added menu items to right-click menus.
It worked by injecting code into Finder at runtime, and then swapping method implementations for various classes. (Mac developers call this swizzling.)
We basically had to reverse engineer Finder every time Apple shipped a new version of MacOS. Later, as the process grew more common, we had to add tricks to make sure that we could work smoothly with other similar plugins.
I jumped for joy when Apple released the Finder Extension API!
Apple gets a bad reputation for their supposed lack of backwards compatibility. Nothing is further from the truth.
Well, they definitely break a lot of things. Mostly things that were never documented or guaranteed to work, though.
My app [1] regularly broke with new macOS releases between 10.9 and 10.12. So often I actually shivered when they announced a new version.
I was calling Cocoa stuff from separate threads which is almost never guaranteed to work on macOS (the UI is explicitly not thread-safe). It usually worked on older releases though, but since 10.9 or so, it broke a little more with almost every new release.
Not really Apple's fault as it's mosty breaking stuff that was explicitly not guaranteed to work in the first place and which I shouldn't have used. On the other hand, Microsoft seems to keep every quirk from Windows 9x time still working until today.
> I was calling Cocoa stuff from separate threads which is almost never guaranteed to work on macOS (the UI is explicitly not thread-safe)
It seems to me that you know what's wrong here, but just in case you don't, most UI work should be done on the main thread. There are certain lower-lever layer APIs that IIRC do explicitly allow for calls from multithreaded contexts, but other than that stick to the main thread. There's actually a new tool, the thread sanitizer, that helps you adhere to this by flagging all misuse of Cocoa outside the main thread.
> "Note that this is just a list of apps Apple has developed compatibility tweaks to make them run on newer macOS versions. As the list demonstrates, even the best apps often needs some tweaks on newer macOS. In addition, most of these patches are only applied to older versions of apps."
Quite a stretch from this to the clickbait title "These 299 macOS apps are so buggy...".
That’s not fair to say. These apps may very well have done one or two things wrong in their code that required Apple to step in. I have a million such mistakes in my code but no one uses them enough to warrant a checkfix.
Also these apps are huge and push the platform forward more than other apps so the likelihood of this relying on undocumented behavior is much much higher and Apple is some sense shares responsibility for those bugs. So the face that they make these checkfixes makes sense.
This sounds somewhat analogous to what Nvidia do with their graphics drivers. You hear stories about how the driver is full of game specific hacks to work around bugs / poor designs in the games themselves.
While this can be good for performance and stability of these games, it does result in a bloated and complex driver, which I'm certain is difficult to maintain.
You can confirm these stories by downloading Nvidia Inspector which includes the Nvidia Profile Inspector that allows you to view and edit the - hundreds - game profiles the driver knows about and even make new ones (quite useful if you are playing some obscure game that happens to have a similar bug or use the same engine as a more popular game). The available tweaks even include fixes for games released in the 90s.
This imho is how you do this kind of thing. I've seen the contrary to often in production environment where per customer exceptions (if customer-id ==) are made. Instead you have to make the exception itself into a concept en manage the relation between the exception and the customer/application at a different level like nvidea does with the profiles.
It's easy to write these things off as poor designs in games, and I'm sure some are, but it's also likely that quite a few are creative solutions to solve problems with the provided resources at the time. Those creative solutions probably don't stand the test of time well as new API are created, bug fixes are released, and loopholes that were taken advantage of are closed.
Interesting that Firefox made it onto the list; one would have assumed it would have been easier to produce a patch for an open source application than to maintain a compatibility fix in your own code.
For a long time, but not anymore, Firefox Nightly called a function called TriggerQuirks() as the first thing in main() on Mac. The function faked the bundle id as a release build bundle id in order to get the Firefox-specific Mac OpenGL behavior for nightly builds, too.
This happens all of the time. Very common for Apple to reach out to the popular apps.
And if you aren't popular you can just goto WWDC where hundreds of engineers will quite happily talk through issues and give guidance on prerelease software.
> Very common for Apple to reach out to the popular apps
You have to be really popular for this to happen, or be the only adopter of a technology they're trying to push. Basically, the question you have to ask yourself is "could Apple showcase us at a keynote?" Of course, such arrangements have massive NDAs around them.
> if you aren't popular you can just goto WWDC where hundreds of engineers will quite happily talk through issues and give guidance on prerelease software
Yes, but they aren't going to tell you what's wrong with your software…you'll need to go up to them at tell them "so and so doesn't work" and then they'll help you. I think it's unlikely that they'd just outright tell you that they made a special case for your software and you should get around to fixing it.
This is Firefox we're talking about, so yes it's popular. And this does happen far more than you're claiming. I'm not sure why you're still trying to push your angle honestly.
Look at commit email domains some time. Grep for @apple.com in popular projects. I don't have the firefox repository on hand but I would wager they're in there too.
Only things from @apple.com in mozilla-central are a few commits from the auto-syncing of web-platform-tests ( https://github.com/w3c/web-platform-tests ), and a few patches from code shared with WebKit where patches have been copied over. So, uh, no direct contributions.
I believe the PC's point is that you're leaning on "never having heard" about Apple committing compatibility fixes before as justification for that not being something they would do, but prior to reading this article, you would have "never heard" about Apple applying compatibility hacks inside their own runtimes either.
That's my point: Apple reaching out to third-party applications is a rare and secretive occurrence, almost always bound by NDAs. If it wasn't, we'd see more of it (which was basically the evidence I was asking for).
You don’t know if it’s rare because it’s secretive. Apple
doesn’t communicate things that don’t help them. Making the public know they add hacks to make sure their own and third parties’ software doesn’t break doesn’t help them so they don’t talk about it. The perception they want for the public is that the software, both their own and third party software on their platform, doesn’t break.
If this was a common occurrence, I'm sure this would be better known, NDA or not. For example, it's well known that Apple occasionally adds API to iOS exclusively to serve the needs of certain larger companies.
Just because you don’t hear about it doesn’t mean it isn’t happening. You didn’t know about this whole infrastructure detailed in the article yet it existed nevertheless.
Apple actually includes this service with their $99/year development program membership. You get 2 support incidents included and you can buy more for the low low price of $99 for a 2-pack or $249 for 5.
Technical Support Incidents, like WWDC sessions, have you going to Apple to ask how to fix your issues. Apple doesn't come to you and say that you need to fix your software.
> [This] function, which returns true if the current app matches the specified bundle ID and is linked on or prior to the macOS version. Thus, older versions of the app would have the fix applied, while newer versions built with a newer SDK would not.
This it notable. It means Apple is ensuring backwards compatibility. Even if an updated version of your app (as detected by what OS it linked against) fixes things, these patches are still around for older versions of the app people may still be running.
I agree that there's a sound reason for this, but I can't help but think that API versioning would be the more correct way to do it. This is how you pile up unnecessary complexity.
I’d agree, except what Apple is doing here is orthogonal to backwards compatibility. They’re fixing buggy apps, some of which are buggy because they rely on undocumented behavior.
This is an industry standard practice across many different areas. You know those "game ready" video card drivers you download? Inside the driver there's a big lookup table of executable names tied to tuned parameters for the video pipeline. The APIs that are used (DirectX, OpenGL, etc.) don't allow sufficient tuning of the behavior of GPUs, so instead there's a sort of meta layer of programming which gets done by the graphics card makers.
I work on some Mac applications that, at times, try to exceed what MacOS applications are capable of doing.
They almost always break between MacOS releases. Usually the cause is that Apple improved various security restrictions in Gatekeeper. What tends to happen is that older builds work fine, but any new builds don't work well.
But, what's interesting is that the page at https://worthdoingbadly.com/assets/blog/appkitcompat/appkit_... doesn't list any bundle hashes. I always assumed that Apple's hacks for backwards compatibility were tied to the bundle hash, and not the specific application.
Sounds like what you're talking about is what's called a "linked-on-or-after" check. That's where they'll see what version of the SDK an app was built against, and enable or disable specific features or bugfixes. Obviously that could be used in conjunction with your app's bundle id.
"I guess Apple’s using the compatibility system to patch other things/change behaviour for specific system apps."
Sometimes I do think software is doomed - like when a teammate of mine had to manually edit the bundled and minified javascript files right before release, because the bundler-crawler frankenstein code would've taken another eight hours to finish.
When I was at Apple in the mid-90's with access to the (obviously pre-NeXT) MacOS source code, I was amazed at how many of these version checks were in the code; there were always a lot of Microsoft app/version checks in there.
It's done every time app hits a function that requires a workaround. Basically, there are a bunch of calls to _CFAppVersionCheckLessThan sprinkled around Apple's frameworks everywhere. However, the result appears to be cached, so the actual meat of the comparison in the amortized case is a simple lookup.
This is really fucked up: are the app developers made aware of those? (likely not) are they going to experience some "strange" behavior, not like anybody else? if someone at Apple gets aware of a "problem", why not contact the app developers to help fix?
It also means that if some other developers want to make an app with the same kind of feature/behavior, they can't?
Some app developers also use special bundle IDs for testing...
I only see "no-go" reasons for such a thing, not a single valid or positive one!
Yes, it's common for Apple to report a bug against the app; in fact in many cases the bug has already been fixed in the latest version! But that doesn't help users who are using old versions.
Most app developers aren't going to spend resources putting out a dot release for years-old versions of their app. But users use those apps every day.
Check-fixed behavior is not a "feature," it's some sub-optimal behavior applied to work around serious bugs. An example is lying to the app about the OS version, to prevent the app from breaking. No developer wants to opt-into such behavior.
Note that check-fixes are tied to an SDK version, so when the developer switches to the newest SDK, they'll see the normal behavior.
1) (optional) OS vendor release an OS with an API quirk or bug
2) App vendor find out about the bug/issue and works around it, OR uses the API in a weird way that "works" but is non-compliant (see SimCity's use after free)
If only they put as much care into making sure their new laptop keyboards did't start failing after 2 months, I might still consider spending 2-4 times as much for their hardware..
Microsoft Excel/PowerPoint/Word have a patch in _CFArraySortValues to change the sorting algorithm slightly. How do you break sorting?!
To take a wild guess, it could be a change from a stable to unstable sort: https://en.wikipedia.org/wiki/Sorting_algorithm#Stability
Apple gets a bad reputation for their supposed lack of backwards compatibility. Nothing is further from the truth: macOS includes tweaks for specific important apps to keep them working on new OS versions.
I read it more as "even Apple is willing to put in patches for backwards compatibility, if your app is important enough." If your app is not, then Apple couldn't care less. MS is more conservative about not breaking things even for relatively obscure apps.
I authored many check fixes like these in Cocoa.
Cocoa would not change from a stable sort, even if undocumented, to an unstable one. There's large compatibility risk and no benefit, since any app that is bound by sorting speed should do something custom anyways.
As to why the sorting hot fix: My first guess is that the app modifies the array from within the comparator. My second guess is that the comparator is not actually transitive, e.g. there can be "less than" cycles. In either case, Cocoa could work around this by employing a naive sorting algorithm.
Might be. I took a look at _CFArraySortValues, and the "normal" path through it ends up calling CFQSortArray. However, the "com.microsoft.*" path performs what appears to be a bubble sort. Interestingly, the public facing version of CoreFoundation doesn't have the special-case paths: https://github.com/apple/swift-corelibs-foundation/blob/df3e...
I suppose Excel data is often almost sorted with a few new additions, which makes bubble sort an arguably better choice?
I can't imagine they're using the OS sort for actual spreadsheet data. It's probably for something else like filenames or whatever, and it ends up not finding the file it's expecting in the place it's expecting.
Agreed, especially since I (the GP) thought about this the wrong way - _Apple_ has chosen to use bubble sort as a compatibility measure for some Microsoft apps, not the other way around.
Which was possible because Microsoft decided to use Core Foundation APIs for sorting instead of their own implementation for spreadsheet data. Or maybe it's not for spreadsheet data, but just their custom file picker or something?
It's a framework-provided sort, not an OS sort. Its use is no weirder than using stdlib sorts, such as Go's "sort" package (which does either a quicksort, heapsort or shellsort, depending on the input length).
However, relying on stability if it is not specified is a bad thing.
While I'm not a big fan of reinventing the wheel, when you're maintaining a 31-year-old cross-platform app that the majority of the planet's businesses rely on for their calculations, I'd be using a custom cross-platform math/sorting/etc engine rather than delegating to any OS, framework, stdlib, third-party anything. Considering this is Microsoft, where Office 4.2 for Mac was as close to WINE as you could get in the 90's, I'm assuming they're doing the same.
They are in platform specific code, manipulating CoreFoundation types (specifically a CFMutableArray), so your cross-platform homebrew sort suggestion is out of scope here. Any sorting function would need to be CoreFoundation (iOS/watchOS/macOS) specific.
When possible, it would of course be best to use stdlib functionality, which would implicitly be cross-platform. Writing it yourself, or pulling in third-party libs to do it ranks way below stdlib, although I can't agree with myself whether doing so is better or worse than using OS-specific standard frameworks. Regardless, it is out of scope in this example.
The post I was replying to was talking about "Excel data", which I interpret as spreadsheet data.
Do you really think that when you sort a column in Excel, it puts the whole thing into a CFMutableArray and asks CoreFoundation to sort that?
No, as I wrote, I would assume any use of CoreFoundation types are only used in platform specific code (dealing with UI, system events, etc.), which would be a minority of the code base, and entirely unique to the platform.
Using CoreFoundation in such code is entirely sensible. Generalizing a sort for something like this would be a waste of time with no gains (as long as the functionality is used correctly, like not assuming a non-specified sort to be stable).
However, for the actual business logic, the hierarchy would be:
Bubble sort is never a good choice unless so extremely lazy or what to impersonate Obama...[0]
There are dual-pivot quicksort, smooth sort (in-place, based on Leonardo numbers and takes O(n) time to process a presorted array and O(n log n) in the worst case, and achieves nearly-linear performance on many nearly-sorted inputs), TimSort (that's stable as plus).
Morealso changing stable to unstable sort is usually a very bad move.
[0]: https://www.youtube.com/watch?v=k4RRi_ntQc8
Bubble sort is perfectly acceptable when you can only swap adjacent elements, which occasionally comes up in memory management.
That’s the only time it would ever be acceptable, and I don’t think that comes up very often at all.
Hmm, do you have a good example? Even linked lists allow swapping elements at arbitrary positions.
At one point I was implementing managed memory on a highly memory constrained system. The system pretty quickly ran into issues with having enough memory to fulfill a request, but no contiguous block long enough. The solution to this is of course defragmentation. The issue is that allocations are irregularly sized and all swaps have to be done in-place. There was also a need to collect blocks of similar size together so the GC could work faster. Bubble sort was the only way to meet all these constraints cleanly, and better yet it only took 10 lines. It still felt dirty though.
How is it that your data was too big to fit in memory, but small enough that bubble sort ran in a reasonable amount of time? Did you have really tight memory constraints (not sure I'm guessing you'd have to have <100KB of memory)?
The data wasn't too big to fit in memory, but rather defragmentation meant that the amount of free memory available was less than the amount of contiguous space, which will be an issue in any dynamically allocating system that doesn't translate pointers.
That said, bubble sort is only n^2 and computers are fast. The real solution was that defrag was an alternative to crashing, so it didn't matter how long it took. Calling it meant a bug report needed to be filed.
Because the sort is done, not when all memory is sorted, but when there's a memory region large enough to malloc.
The comparator here is "used" or "empty", where "used" is either > or < "empty".
>... size together so the GC could work faster.
So you wrote a non-compacting(copy)/generation garbage collector that used bubble sort?
A compacting gc with zero space overhead and complete memory utilization, yes.
Friends don't let friends use bubble sort.
In fact friends don't even let enemies use bubble sort, if they have an ounce of humanity.
Edit to actually answer the question: I wonder if it's something to do with some specific dataset having to be sorted in a particular way? i.e. where you'd normally use a stable sort, but the code accidentally depends on a specific unstable sort.
Oh, wait, bubble sort is stable so it can't be that. Any other theories?
>Any other theories?
1. Excel needs stable sort but OSX sort is unstable.
2. Performance deoptimisation to make Excel perform worse.
There are any number of better ways to fix 1, though!
2 occurred to me too, but surely that’s too cynical. It would make Macs look bad more than Excel itself.
Maybe it’s a bit of both. They needed a fix for 1, but they didn’t care about Excel performance at all so someone just spent 20 seconds doing a quick bodge job.
Maybe because the software has a race condition around sorting which requires the use of a slower sort?
Is it wrong to ask if Microsoft intended it to be slow?
Mac Outlook on a recent MBP is noticeably slower (usability impact) than a similar version of Outlook on my Windows VM on the same machine against the same account (30k items, 5GB-ish)
Insert sort should also be pretty fast for almost stored list, (and works better for not almost sorted).
Nope, bubble sort always performs the same number of ops regardless of whether the array is partially sorted or not. You might be thinking about insertion sort, which has that feature.
Not true.
(3 2 1) -> (2 3 1) -> (2 1 3) -> (1 2 3) (3 passes, 3 swaps)
Compare: (1 3 2) - > (1 2 3) (2 passes, 1 swap)
Hmm I suppose you're right. My bad!
Bubble sort's number of operations can vary from n, if the list is sorted already, up to O(n*n) if the list is reversed.
If you write it really poorly that might happen - but its easy to add a check to see if any swaps occurred. If none, you are done.
I believe the open source Swift versions are not supposed to have any check fixes. They are not the ones that are run on Apple OSes and probably never will be. They’re more meant to help Linux and other non Darwin platforms adapt. Which kinda sucks because it means the repos are a little lacking.
Windows also ships with a large number of compatibility fixes (‘shims’) and even has a tool to create your own.
I guess I made the big time!
The iTerm2 one is interesting because it came too late. Apple's patch disables Sierra's native tabbing. Version 3.1.3 did not disable it completely. I published a fix in version 3.1.4 which came out on October 22, 2017, about a month after Sierra launched. I guess they must have fixed it in a dot release of Sierra, but I won the race and got the fix out before 10.12.1 which came out on October 27.
I'm glad someone's got my back, anyway.
Speaking of iTerm's tabbing functionality, are you still using PSMTabBarControl? You make a couple of odd decisions with tabbing, such as blank spot in the tab strip on the right to make way for the overflow indicator, which IMO is inferior to how macOS does it (scrolling tabs). In addition, tab defocusing causes visual discoloration. Does macOS just not provide the API you need, or what?
i really hate scrolling tabs...
Agree wholeheartedly. Firefox is basically dead to me because of this (that and it's now trickier than ever to fix it).
I'll take 1px wide tabs over scrolling.
Um.... Why? 1px Wide Tab is basically a design that forces people not to have too many tabs. Which is great for those who can keep their Tabs Numbered. But even discounting the number of tabs open to be read, a single Feedly section, or in the old days Google Reader section I could easily bump up to 100+ Tabs, and much more in WWDC / Apple Keynote time.
Which makes 1px Tabs annoying as hell.
So I really don't understand why 1px Tab is preferred over Scrolling Tabs.
I'm a tab monster and almost never have less than 100 open at a time, so no, I disagree that it's only great for those who can keep their tabs numbered.
Putting scrolling in a tab bar doesn't allow the user to take full advantage of spatial and muscle memories.
And when those memories fail, because scrolling tabs literally removes tabs from view, the user can't even revert to a visual search to find them! Instead one has to slowly scroll through a list of identically sized tabs, hoping that window #5 is actually the one containing the desired tab in the first place.
Oh dang, it was actually window #4.
Compare and contrast this to non-scrolling tabs, where tab size continually shrinks as tabs grow in number. #1 - you can identify which window is relevant by the tab sizes alone (so even if you move your windows around you're not lost). #2 - you can identify tabs by spatial memory, because you know approximately where, horizontally within the window, your tab exists, cutting your search space down to a few tabs only. #3 - you have visual cues as to when you might need to split out into a separate window for ease of tab management.
Of course, 1px is hyperbole, but 15px-30px is most certainly not, and on a modern display you can fit very many 30px tabs in a row without scrolling.
That's not to say that there aren't limitations to shrink-to-1px tabs, of course there are. But in all circumstances as a UI tool they are objectively better than scrolling tabs, until they shrink to an unusable size. At which point, scrolling tabs still isn't a good solution to the problem (grids, multiple rows, tab lists, tab groups are all vastly better options here).
I guess because you have to do a ton of scrolling to go from one of the first tabs to the last.
Of course, if you don't have scrolling tabs then the tabs get so small that it's basically impossible to find what you want.
I solved this dilemma by hiding my FireFox tabs and using Tree Style Tabs. I find it really helps with keeping tabs organized and I can keep a lot open without worrying. I removed the scrollbar and close buttons, and made the tabs smaller, to further save on screen real estate.
> I guess because you have to do a ton of scrolling to go from one of the first tabs to the last.
On a Mac trackpad, this is one swipe. Sure, I see how this can be a problem if you use a scroll wheel, but I've never had this be a problem otherwise.
But this is how macOS chooses to deal with a large number of tabs, and I generally prefer applications to match what the system does (which nicely enough means that their behavior updates when the system's does).
Did they notify you beforehand?
Why would they do that? It only discourages the upstream from fixing things telling them Apple will do that for them.
This used to be Microsoft's shtick, Joel Spolsky wrote an amazing article related to this a few years ago: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
Relevant excerpt (abridged):
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS ... the Windows developers ... added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
Microsoft does this too, though I can't find the article right now.
There are hundreds of special compatibility hacks for various software baked into Windows to make things run smoothly.
Edit: The links are broken now, but a paragraph from the article is quoted here:
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
> Look at the scenario from the customer’s standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn’t work at all. You’re going to tell your friends, “Don’t upgrade to Windows XP. It crashes randomly, and it’s not compatible with program Z.” Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn’t work because it is using undocumented window messages? Of course not. You’re going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)
windows hardly changes a function contract. most their patches are to support bugged programs that used the api in undocumented ways, not because they changed an api functionality
http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...
I think the thing is that MS is well-known to do this, but I hadn't heard that Apple bothered before.
Back when I looked at the compat fixes in Vista there were about 6000 applications listed there. Granted, a lot of them were games, where the only effect was that they would be added to the (then-new) Games folder. Still, I guess the list has only grown since then.
> The links are broken now
https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=...
Reminds me of my all-time favorite Joel Spolsky story about Bill Gates' amazing technical free-diving skills and the Excel date compatibility problem.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
It’s easy to forget that Bill Gates was once the Jeff Dean of his time.
Bill Gates is a genius, maybe even in technical stuff, but he wasn't the Jeff Dean of his time.
Bill Gates had the strategic vision to see that software was not only going to be a viable industry, it was likely to be the most valuable computer industry.
It seems like he was good but not a spectacular programmer himself. Barbarians Led By Bill Gates is a great book about the relatively early days of Microsoft--early enough that the book describes some instances of programmers finding and replacing Bill's code with better stuff. IIRC there is at least one story of a new guy going "who wrote this crappy code" and then finding out it was Gates.
Well of course, in a way, nobody could be, because software didn’t have the impact on the world then as it does now.
I'd say it had more impact then.
The major impact of software and computing was front-loaded, as in, it came with the early hanging fruits: being able to computerize banking, government data, credit card transactions, international trading, etc. This gave a huge boost to market efficiency and globalization.
The rest, with the internet, apps, online sales, etc, is just another outlet for doing business. Whether a 2B2 order happens on the web, or by old-style computer networks, or even by fax, is not that much of a difference.
I don't think that's entirely fair... It's true that computers and computerisation have never been so ubiquitous as they are now, but they've still been having a big impact for a long time.
Off the top of my head, credit cards and ATMs, and the purchase tracking and credit scoring agencies they enabled, have been a big deal since the 60s, says Wikipedia. (I would have guessed later!) Can't do that without a lot of software.
I wouldn't even say Jeff Dean is the Bill Gates of today. But I'd say that would be a more correct statement.
Honestly, I wouldn't be surprised if this is basically the list of apps personally used by Apple employees that broke between releases.
EDIT: Here's a list sorted by number of occurrences: https://gist.github.com/saagarjha/f36b6d99c3b89acfc02624806e...
I used to maintain a Finder plugin that added icon overlays to files, and added menu items to right-click menus.
It worked by injecting code into Finder at runtime, and then swapping method implementations for various classes. (Mac developers call this swizzling.)
We basically had to reverse engineer Finder every time Apple shipped a new version of MacOS. Later, as the process grew more common, we had to add tricks to make sure that we could work smoothly with other similar plugins.
I jumped for joy when Apple released the Finder Extension API!
I know you said you don't maintain this plugin anymore, but does it still exist in some form? It sounds interesting!
Apple gets a bad reputation for their supposed lack of backwards compatibility. Nothing is further from the truth.
Well, they definitely break a lot of things. Mostly things that were never documented or guaranteed to work, though.
My app [1] regularly broke with new macOS releases between 10.9 and 10.12. So often I actually shivered when they announced a new version.
I was calling Cocoa stuff from separate threads which is almost never guaranteed to work on macOS (the UI is explicitly not thread-safe). It usually worked on older releases though, but since 10.9 or so, it broke a little more with almost every new release.
Not really Apple's fault as it's mosty breaking stuff that was explicitly not guaranteed to work in the first place and which I shouldn't have used. On the other hand, Microsoft seems to keep every quirk from Windows 9x time still working until today.
[1] https://github.com/enzo1982/freac
> I was calling Cocoa stuff from separate threads which is almost never guaranteed to work on macOS (the UI is explicitly not thread-safe)
It seems to me that you know what's wrong here, but just in case you don't, most UI work should be done on the main thread. There are certain lower-lever layer APIs that IIRC do explicitly allow for calls from multithreaded contexts, but other than that stick to the main thread. There's actually a new tool, the thread sanitizer, that helps you adhere to this by flagging all misuse of Cocoa outside the main thread.
This is the case for almost every graphical toolkit I’ve developed for.
From the article:
> "Note that this is just a list of apps Apple has developed compatibility tweaks to make them run on newer macOS versions. As the list demonstrates, even the best apps often needs some tweaks on newer macOS. In addition, most of these patches are only applied to older versions of apps."
Quite a stretch from this to the clickbait title "These 299 macOS apps are so buggy...".
That’s not fair to say. These apps may very well have done one or two things wrong in their code that required Apple to step in. I have a million such mistakes in my code but no one uses them enough to warrant a checkfix.
Also these apps are huge and push the platform forward more than other apps so the likelihood of this relying on undocumented behavior is much much higher and Apple is some sense shares responsibility for those bugs. So the face that they make these checkfixes makes sense.
This sounds somewhat analogous to what Nvidia do with their graphics drivers. You hear stories about how the driver is full of game specific hacks to work around bugs / poor designs in the games themselves.
While this can be good for performance and stability of these games, it does result in a bloated and complex driver, which I'm certain is difficult to maintain.
You can confirm these stories by downloading Nvidia Inspector which includes the Nvidia Profile Inspector that allows you to view and edit the - hundreds - game profiles the driver knows about and even make new ones (quite useful if you are playing some obscure game that happens to have a similar bug or use the same engine as a more popular game). The available tweaks even include fixes for games released in the 90s.
This imho is how you do this kind of thing. I've seen the contrary to often in production environment where per customer exceptions (if customer-id ==) are made. Instead you have to make the exception itself into a concept en manage the relation between the exception and the customer/application at a different level like nvidea does with the profiles.
It's easy to write these things off as poor designs in games, and I'm sure some are, but it's also likely that quite a few are creative solutions to solve problems with the provided resources at the time. Those creative solutions probably don't stand the test of time well as new API are created, bug fixes are released, and loopholes that were taken advantage of are closed.
Interesting that Firefox made it onto the list; one would have assumed it would have been easier to produce a patch for an open source application than to maintain a compatibility fix in your own code.
For a long time, but not anymore, Firefox Nightly called a function called TriggerQuirks() as the first thing in main() on Mac. The function faked the bundle id as a release build bundle id in order to get the Firefox-specific Mac OpenGL behavior for nightly builds, too.
still doesn’t fix old releases in the wild
Well, who would write the patch? Someone at Apple?
Yes? Or some regular contributor to Firefox that gets guidance from an Apple engineer?
> gets guidance from an Apple engineer
You do realize that the chances of this happening is next to nil, right? This is doubly true for prerelease software.
This happens all of the time. Very common for Apple to reach out to the popular apps.
And if you aren't popular you can just goto WWDC where hundreds of engineers will quite happily talk through issues and give guidance on prerelease software.
> Very common for Apple to reach out to the popular apps
You have to be really popular for this to happen, or be the only adopter of a technology they're trying to push. Basically, the question you have to ask yourself is "could Apple showcase us at a keynote?" Of course, such arrangements have massive NDAs around them.
> if you aren't popular you can just goto WWDC where hundreds of engineers will quite happily talk through issues and give guidance on prerelease software
Yes, but they aren't going to tell you what's wrong with your software…you'll need to go up to them at tell them "so and so doesn't work" and then they'll help you. I think it's unlikely that they'd just outright tell you that they made a special case for your software and you should get around to fixing it.
This is Firefox we're talking about, so yes it's popular. And this does happen far more than you're claiming. I'm not sure why you're still trying to push your angle honestly.
Outside of the extremely rare occasions that I mentioned above, I've never seen or heard this happen. If you have some stories to share, I'm all ears!
Look at commit email domains some time. Grep for @apple.com in popular projects. I don't have the firefox repository on hand but I would wager they're in there too.
Only things from @apple.com in mozilla-central are a few commits from the auto-syncing of web-platform-tests ( https://github.com/w3c/web-platform-tests ), and a few patches from code shared with WebKit where patches have been copied over. So, uh, no direct contributions.
Have you ever heard of Apple creating compatibility hacks in their OS for specific applications before?
…I don't seem to understand the joke here. That's literally what the article is about.
I believe the PC's point is that you're leaning on "never having heard" about Apple committing compatibility fixes before as justification for that not being something they would do, but prior to reading this article, you would have "never heard" about Apple applying compatibility hacks inside their own runtimes either.
Note the term NDA.
That's my point: Apple reaching out to third-party applications is a rare and secretive occurrence, almost always bound by NDAs. If it wasn't, we'd see more of it (which was basically the evidence I was asking for).
You don’t know if it’s rare because it’s secretive. Apple doesn’t communicate things that don’t help them. Making the public know they add hacks to make sure their own and third parties’ software doesn’t break doesn’t help them so they don’t talk about it. The perception they want for the public is that the software, both their own and third party software on their platform, doesn’t break.
If this was a common occurrence, I'm sure this would be better known, NDA or not. For example, it's well known that Apple occasionally adds API to iOS exclusively to serve the needs of certain larger companies.
Just because you don’t hear about it doesn’t mean it isn’t happening. You didn’t know about this whole infrastructure detailed in the article yet it existed nevertheless.
Apple actually includes this service with their $99/year development program membership. You get 2 support incidents included and you can buy more for the low low price of $99 for a 2-pack or $249 for 5.
https://developer.apple.com/support/technical/
Technical Support Incidents, like WWDC sessions, have you going to Apple to ask how to fix your issues. Apple doesn't come to you and say that you need to fix your software.
> [This] function, which returns true if the current app matches the specified bundle ID and is linked on or prior to the macOS version. Thus, older versions of the app would have the fix applied, while newer versions built with a newer SDK would not.
This it notable. It means Apple is ensuring backwards compatibility. Even if an updated version of your app (as detected by what OS it linked against) fixes things, these patches are still around for older versions of the app people may still be running.
Backwards compatibility never ages out...
I agree that there's a sound reason for this, but I can't help but think that API versioning would be the more correct way to do it. This is how you pile up unnecessary complexity.
> but I can't help but think that API versioning would be the more correct way to do it
I'm not sure what you mean, because to me that's what they're already doing, where the API version maps to the OS version.
When compiling in XCode, you can select which OS version you're targeting, and that essentially gives you which API version you're targeting.
I’d agree, except what Apple is doing here is orthogonal to backwards compatibility. They’re fixing buggy apps, some of which are buggy because they rely on undocumented behavior.
If it worked yesterday and after an OS update it still works how is that not backwards compatibility?
Does it matter to a user if the change was due to some “buggy apps”? If it works, it works.
As noted elsewhere in the thread, Microsoft does this as well, and Opera used to do this for broken high-profile websites:
https://www.opera.com/docs/browserjs/
Edit: Even Chrome and Safari used to do it: https://dev.opera.com/blog/opera-s-site-patching/
This is an industry standard practice across many different areas. You know those "game ready" video card drivers you download? Inside the driver there's a big lookup table of executable names tied to tuned parameters for the video pipeline. The APIs that are used (DirectX, OpenGL, etc.) don't allow sufficient tuning of the behavior of GPUs, so instead there's a sort of meta layer of programming which gets done by the graphics card makers.
I work on some Mac applications that, at times, try to exceed what MacOS applications are capable of doing.
They almost always break between MacOS releases. Usually the cause is that Apple improved various security restrictions in Gatekeeper. What tends to happen is that older builds work fine, but any new builds don't work well.
But, what's interesting is that the page at https://worthdoingbadly.com/assets/blog/appkitcompat/appkit_... doesn't list any bundle hashes. I always assumed that Apple's hacks for backwards compatibility were tied to the bundle hash, and not the specific application.
Sounds like what you're talking about is what's called a "linked-on-or-after" check. That's where they'll see what version of the SDK an app was built against, and enable or disable specific features or bugfixes. Obviously that could be used in conjunction with your app's bundle id.
I don’t understand this pseudo code from the article: if __CFAppVersionCheckLessThan("com.microsoft.Powerpoint", CFSystemVersionYosemite) {
Why are they comparing an app version to an OS version?
It's comparing what macOS version the app is linked against, not the app's own version number.
"I guess Apple’s using the compatibility system to patch other things/change behaviour for specific system apps."
Sometimes I do think software is doomed - like when a teammate of mine had to manually edit the bundled and minified javascript files right before release, because the bundler-crawler frankenstein code would've taken another eight hours to finish.
Makes me very happy to see FOSS software like Blender in the list and not just the big commercial applications as I had expected.
Maybe they fix apps whose complaints are louder than average.
Putting an effort to make people believe the upgrading on macOS is smooth is important to avoid version spread like on other OS's.
When I was at Apple in the mid-90's with access to the (obviously pre-NeXT) MacOS source code, I was amazed at how many of these version checks were in the code; there were always a lot of Microsoft app/version checks in there.
Interesting. I wonder how much this lookup check adds to every app's load time?
I may have missed it in the article, but is the lookup run only upon first time the app is executed, or on every single run instance?
It's done every time app hits a function that requires a workaround. Basically, there are a bunch of calls to _CFAppVersionCheckLessThan sprinkled around Apple's frameworks everywhere. However, the result appears to be cached, so the actual meat of the comparison in the amortized case is a simple lookup.
> I wonder how much this lookup check adds to every app's load time?
Based on the IDA disassembly, not much. A few extra CPU instructions has minimal impact generally.
> but is the lookup run only upon first time the app is executed, or on every single run instance?
It’s done every time the function in question is executed from what I can tell.
_CFAppVersionCheckLessThan is called every time, yes, but the result of the check is cached as far as I can tell.
Well, they can remove those patches for AOL Instant Messenger now, eh?
Why? It's one of the better group chat apps out there these days.
AIM service shutdown in December.
This is really fucked up: are the app developers made aware of those? (likely not) are they going to experience some "strange" behavior, not like anybody else? if someone at Apple gets aware of a "problem", why not contact the app developers to help fix?
It also means that if some other developers want to make an app with the same kind of feature/behavior, they can't?
Some app developers also use special bundle IDs for testing...
I only see "no-go" reasons for such a thing, not a single valid or positive one!
Yes, it's common for Apple to report a bug against the app; in fact in many cases the bug has already been fixed in the latest version! But that doesn't help users who are using old versions.
Most app developers aren't going to spend resources putting out a dot release for years-old versions of their app. But users use those apps every day.
Check-fixed behavior is not a "feature," it's some sub-optimal behavior applied to work around serious bugs. An example is lying to the app about the OS version, to prevent the app from breaking. No developer wants to opt-into such behavior.
Note that check-fixes are tied to an SDK version, so when the developer switches to the newest SDK, they'll see the normal behavior.
Very interesting article, very misleading title.
> Apple gets a bad reputation for their supposed lack of backwards compatibility. Nothing is further from the truth.
Yeah, if you have an app that is used by millions of people, that is.
So what is the reasoning behind Apple's constant breaking changes?
I'm surprised by the downvotes. This was an honest question since Microsoft has been able to move on for years without so many changes.
1) (optional) OS vendor release an OS with an API quirk or bug
2) App vendor find out about the bug/issue and works around it, OR uses the API in a weird way that "works" but is non-compliant (see SimCity's use after free)
3) OS fixes the issue but then app breaks
4) Goto 1
If only they put as much care into making sure their new laptop keyboards did't start failing after 2 months, I might still consider spending 2-4 times as much for their hardware..