|Home » Industry Watch
Apple's Property Lists
ANKARA — It's hard to ruminate about things like this when Turkey and Syria have been so devastated, but we must try.
We haven't checked the Western MSM, aside from RT who of course covered it excellently, but, judging from the headlines seen on social media in the West, most zombies know nothing about it and could care less, which is a real shame. Anyway.
Property lists are great. Windows doesn't have them and, last we looked, the sycophantic copycat Linux GUIs don't have them either. Microsoft's feeble INI file is just that - feeble. The standard Windows API provides for two ways of obtaining data from an INI file. The one way presumes the data is a character string and the other hopes the data, which must still be a character string, can be interpreted as an integer.
And that's integers only. Not floating point. Heavens no. And absolutely no complex data types of any sort at all. Binary data? Nope. Never. No arrays. No nothing. Just integers and strings. Suck it up, Windows fanboy.
[Sorry, but regrouping at the Cutler Registry API won't help. Ed.]
NeXT's property list builds on the XML format. There are three ways to save a property list file. The oldest, the original NeXT way, is no longer supported. The second way is as text only, and the third and final way is as binary. This is the most efficient and therefore it's suitable for use with extended attributes.
Being able to read property list files with default system tools is as essential as having REGEDIT.EXE at hand on Windows. Sir Tim BL wrote a few years back about a W3C proposal to make binary XML the default standard. We objected and wrote about it, and asked our readers to protest, and they did. Someone very close to Tim (we never revealed anything further but you can guess) wrote to us to ask us to please call off the hounds. We did and we got a letter back saying 'thanks'.
We already had a solution to the binary XML issue onboard with our xattr tool and our Xattr.app Cocoa app, so we and our clients at least could see into those files, even if no one else could.
Seeing into files with Xattr is essential - it's how you find out how badly Apple screwed you over.
As in the screenshot below. The readout on the right shows there's a property list embedded with a file. Embedded and embedded, actually: Apple, always sparse on information and documentation, can at least reveal that extended attributes are stored in a separate location, meaning a simple file I/O is as egregious as it was back in the days of Beige Box Bliss™ when there was one folder for one computer to store one thing.
[Yes the intro string probably stands for 'binary property list version 0.0', Victoria.]
Of course Apple finally got around to cleaning up. After the brilliant - and therefore by hysterical fanboys castigated - TN2034, things began moving towards acceptance of the file extension as a general way of identifying things. Apple's old system with creator codes etc was hopelessly outdated and under-dimensioned anyway. (Creator codes could only be guaranteed collision-free if only Apple employees and their gender-fluid cocker spaniels used them.)
So RESOURCE_FORK made it to the compost heap out back of Steve's garage, as did FinderInfo (well almost). So Apple's OS X was almost a real UNIX™ (well not quite).
What happened next was random. It was not planned. Anyone who followed things in the latter half of the nawties can attest to that. They were just being Apple at Apple. But then some unknown emissary of darkness and corporate greed stumbled onto it.
Why not, postulated this unsung specimen of misanthropic Sithiness, tag things on the download? Like everywhere we can? Through our own browser Surfin' Safari to start with, then we'll call in some real engineers to wire it all deep into the system?
We'll call the tag com.apple.quarantine - how's that for Apple crackers?
The contents of the extended attribute (XA) itself isn't important. The important thing is we tag the bastard. Then our launch services can pick up the tag and warn the fanboys peeing in their pants with 'WARNING WARNING WARNING PROCEED WITH CAUTION ARE YOU SURE ARE YOU SURE ARE YOU REALLY REALLY SURE'. That'll freak them out.
Then we tell the ISVs they can upload to our servers (for a fee) and then they'll see those scary warnings disappear Like Magick™ and all will be well again in the Walled Garden.
[Notice how that's just a bit like Bill's infamous AARD code? Just a bit?]
That cute idea transmogrified into a Belgian Blue class cash cow like none ever seen like anywhere ever in the industry. Estimates are that, of late, Apple Inc can profit to the tune of $80,000,000,000 (EIGHTY BILLION USD) per YEAR just by forcing indy companies to route their deliveries through Apple's servers, and that estimate is a few years old now: they're most likely up to over 100 billion today. No wonder that Forbes, Fortune, and the New York Times called them out on it, and called them evil.
Apple are no longer the darlings of IT. Today they're the monsters - the sweet monsters, the sugar-sweet monsters. If you like your coffee black, forget it.
Do the Apple fanboys ever protest? Guess. The Apple fanboys protest about why their dear benevolent Apple could deign to block a specific app title at the App Store, but they'd never challenge the ethics of the App Store itself or Apple. No one wants to be cancelled. Apple fanboys are too pussy for that - too much soy in their backbone marrow.
So naturally, as y'all know today, having invested way too many years in what was once a rather brilliant technology, worth roughly $429 million some 25 years ago, we devised a way to crack open teh Apple. This took a lot of study and research of course, but good things often do.
Ridding a system of unwanted Apple traps is all good and fine, but what if you simply want to use extended attributes for your own purposes? The APIs are agnostic, neither good nor evil in themselves. It's just that things have become so sick and degenerate that Apple will now waste precious clocks stamping every fucking one of your files as soon as you access them. Trust us: You do not, repeat do not, want to look at the naked box of a Mac user. Not when you can see the cruft and mold and shite we can see with our tools. Not pretty.
So - theoretically supposing - if we want to stamp files with XAs of our own but will not tolerate Apple droppings at the same time? We've worked on it for weeks now. We have a solution, but it's not recommended for general use - it's a bit of a 'hack'.
We're using it on our new app Be.
On the way to that achievement, we discovered something.
A new Apple DEPRECATION.
They love to 'deprecate' stuff at Apple. As if they'd never built a real living operating system of their own (which they haven't). They're dreaming of a static API that's absolutely perfect and never needs changing again. Something that's perfect even when the time's come for additional permutations.
[There is nothing like that anywhere, but don't tell them at Apple and spoil the fun.]
Take a random example. Completely made up. Let's assume one of those Apple pinheads thinks it's time to add a macro to a system header file. He writes like this.
#define DEFAULT_X (1.2345)
And he's happy. Then, say two months later, his boss comes along and tells him to change the macro to the following.
#define X_DEFAULT (1.2345)
So just add that on, right? Not at Apple! At Apple your header file now looks like this. For real.
#define DEFAULT_X (1.2345) // Gobbledegook to trigger the compiler
#define X_DEFAULT (1.2345)
And they'll have that additional compiler directive to generate diagnostics if the code uses the wrong macro.
Because, obviously, this company known as 'APPLE' wants to be able to save 25 (twenty-five) bytes in a header file. (Don't forget the carriage return if you're counting.)
Because, obviously, someone at 'APPLE' is very upset that you may be using the wrong macro (DEFAULT_X) instead of the right macro (X_DEFAULT).
They actually do this at Apple - no joke - they actually warn ISVs at those huge conventions of impending macro changes.
All the while, of course, they were completely fine with shipping tonnes of megabloats (300-400 MB) of classes.nib, info.nib, and designable.nib files.
Hey, who cares, right?
So when honing and tweaking Be to perfection, we happened upon yet another Apple deprecation. Try searching Apple's online documentation for 'DEPRECATED' if you can. You'll find TENS of thousand of hits. At least. And we found one (two actually) concerning so-called property list serialisation. (Don't mind the name - that's how you store property lists in different formats.)
The traditional method, dating back to the days of NeXT, was:
That's now changed. To:
From 'From' to 'With'. Obviously the one is more appropriate. Obviously.
The old method took two arguments, format: and errorDescription:. The format is just a number that indicates whether you're after text or binary. The errorDescription was just a character string supplied by the system in case something went wrong.
That's changed now. Now you have format, as before, but 'error' instead of errorDescription, and it refers to a new type of data which means basically you have yet another hoop to jump through to get at what you want. But here's the kicker: it's 'nullable', meaning you don't have to use it at all.
[You might be suffering under the illusion that the human race is growing more intelligent. This is a dangerous falsehood. It only appears that way from some angles because so many of the really dumb nuts floating around are in hiding at IT coding factories in California. So now you know. Glad to help.]
The absolute crowning achievement, however, was adding a NEW ARGUMENT to the method.
That argument is called options:.
What values can that argument currently take?
None. It's not used.
The NeXT Challenge
So let's compare.
Same length. (Why is this important? Because those very strings have to be embedded. This isn't standard relocatable linking with static libraries.)
So the new version is four characters shorter.
(That's good. Just think if some eager beaver renamed 'errorDescription' to 'currentValidThreadsafeErrorDescriptionAsReadableUnicodeString'. Knock on wood that it doesn't happen to you.)
(And nothing is mangled, Bjarne. ObjC uses dynamic binding, Bjarne. That might be a bit over your Scandinavian head. That's one of the reasons your own language sucks.)
So, in this isolated particular case, Rixstep wins. Only fourteen modules (applications) to undergo a quick makeover, making them additionally future-safe and Apple-safe. So why not? It's a win-win.
But is there still cause to worry? Actually, yes there is. Because the critter 'DEPRECATED' is on the loose again.
Removing tested NeXT APIs that have worked flawlessly for decades, written by people decidedly smarter than anyone there today, shows how stupid they are at Apple. There's no reason to remove old APIs. Come with new APIs, sure. But remove old ones? Only Apple could ever do something that stupid.
There's essentially not a thing different with the new NSPropertyList method. Nothing. They've changed the name. Pedantically one can claim that the new method takes more CPU clocks: there's another argument to push onto and pop off of the stack. For an argument they can't even justify because it's not even used.
Apple software engineers: not pros. Not even 'second sort'.
Dear clients. We know you're out there, wondering. Yes, this update is coming your way. But we want to test things properly first. As most of you understand by now, we don't do yuge bug-fix bonanzas where new versions, after being touted for years, are suddenly and finally released, with fanboy declarations that there are no bugs, except whoops here come a few hundred bugs! All those fanboys do for a fortnight is update again and again.
That's not professional. We're professional. We train the professionals. To make them professional.
It's almost as if the Apple ISVs don't know how to test. Or how to eat their own dog food. Or else they ended up in the wrong career.
So we'll be testing for a while. And we'll also be having some other surprises for you. Such as our new software archives and automatic elevation from 'Tier 2' to 'Tier 1'. But you'll be getting private notifications to that effect.
Plan on Valentine's Day. Because we love you all so much.
Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.
Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.
All Content and Software Copyright © Rixstep. All Rights Reserved.