A while back we found someone on the radar and sent him a complimentary copy of our ACP, no strings.
The gent wrote back and asked rhetorically why he should risk running our software.
Rhetorical question, OK. First, if he really didn't know who we were, he could have looked us up.
Second, he could have run 'find' on something to see what was going on. He could have run 'netstat' to see what connections our apps attempted.
He could have drilled down into any of our bundles to see what was there - if he had the ability to do that with his default 'file manager'.
Had he looked around a bit and checked out Tracker, he could have run Tracker and 'find' to make sure nothing untoward was happening. Then at that point he could have used Tracker to track each of the other apps as well. He could have fired up GD and Xframe to see if any of our apps generated dodgy traffic.
I could have told him all that and more but didn't feel it worthwhile. But he said something else too. He said he already had all the functionality we offered.
That was fast going on his part. Take the download, spend 15 minutes to look about, and already you know what's in that package? 70+ GUI apps, 40-50 command line tools, and you've already reviewed it all in a quarter of an hour?
There's no way he can already have all we offer. No way. No one has anything close to Tracker. No one has anything close to Xframe. Or Xscan. Or Xfind. Or the ACP as a whole.
But that's not the point anyway, if we may say so.
What we postulate is *we can do it better*.
We have a toolbar graphics library of 17 kilobytes, and none of our apps have image files in their bundles, save the app icons.
We have initialisation data handled by our omnipresent ACP Framework so all our apps get automatic and configurable startup settings.
We have three tonnes of super tweaks like this.
We have the universal 'selection flip' for all our tableviews in all our ACP apps. Hit Shift-Cmd-Apple in any of our tableviews and the selected becomes unselected and vice-versa. Anybody could have done it, everyone should have done it, no one did it - only we did it.
And so forth.
Binary footprints. No one beats us at that. Back in the 32-bit days we could produce leaner binaries than anyone - using their own code. Yes, we knew a secret, the kind of thing that requires one to know something about processors. Related to how one sets up a project file. That was all. We could take any project, fiddle around in the configuration file, and rebuild and save 3000-5000 bytes. Just like that. No one else found it. That's how clueless they are. And it should have been obvious to Comp Sci freshmen. It should have but it wasn't. Go figure.
Designable.nib. Remember those? Remember how an ordinary OS setup cost hundreds of megabytes in unnecessary bloat - for no reason at all?
Remember Ankur Kothari? The Australian dental student? With his Trimmit?
We're still in touch with Ankur. He's one handsome dawg, it turns out. And now he's a full-fledged dentist. But he *tours* rather than runs his own practice. He works about four days a week. He still fiddles a bit with computers, but today it's Linux instead.
But remember that? We could shave hundreds of megs of storage off any OS install?
It started when we saw someone shipping with one of the standard three NIB files missing. Objects, classes, info. Well obviously if you could do without the one, one should look closer what's in them - and look into what's in them.
Classes.nib was irrelevant. It's used to help run Interface builder. It's not used at runtime. Info.nib? That's the settings for the main IB window - its screen coordinates, etc. It's only objects.nib that's used at runtime. NeXT always shipped with the files, since back in the 1980s. Apple continued to do so. 20-30 years went by. They were still shipping with them. Everyone was shipping with them. Then we turned up. And Ankur followed after with his Trimmit. Hundreds of megs shaved from any setup.
Not bad.
No one does the file management we do. No one comes close to doing it all. Path Finder gets at most of it, but what a mess. All the others are long gone, leaving only Apple's default, and that's not a file manager.
No one retains selections on refreshes. No one. We did that on Windows too, and no one else did that there either. How are you supposed to get any work done?
Finder and Path Finder crash and hang all over the place. Our file manager does neither.
Finder weighs in at about 50 MB, Path Finder twice that. Our file manager has a binary of less than 50 KB with total bundle size of perhaps 150 KB. That's it. And it does everything the others do and more.
Clearly something is wrong, and clearly it's only us that are doing it right.
.DS_Store files still drop all over the place. 60% of file metadata remains hidden. What kind of file management is that? But we do it - we do it all.
Sneaky sneaky.
Xfile is sneaky in its frugality with RAM. Things can get pretty intense when listing large directories, especially with all the information Xfile offers, far more than anyone else. Some of this is down to the design, some of it the implementation. Fortuitously it works well.
Xscan can't use the same design. It might appear to but it can't. If one stopped to think about it, one would understand. But it's still a design optimised up the wazoo. And yes it's fast. And robust.
There's an early 'Dark Mode' makeover of Xfile performing here. For 59 minutes. We got special status at YouTube to post it.
That took a lot of work to do. A huge cup of coffee was necessary. Along with a lot of patience. And keeping a finger on the arrow up key for an hour.
What it does is scoot through 95,000 directories, listing 350,000+ files, nonstop. The listings just fly by. Nine columns of data are listed on the right, the directory tree on the left.
First off: no other file manager, not Path Finder, not Apple's Finder, could expand and list 95,000 directories anyway. We demonstrated this in an article. We showed that both those programs either crash, hang, or chicken out. No one else can list those 95,000 directories. No one.
But now we scroll to the bottom and start holding down arrow-up. Watch it for a while. One hour.
You know - YOU KNOW - that no other program on Apple's wobbly platform could carry that off. None.
Xfile: it's for all practical purposes as fast as the command line.
For there's a way to design and write applications, and there are evidently myriad ways you don't want to write them. Xfile does it right.
The last crash for Xfile was reported over fifteen years ago. Fifteen. Path Finder? Perhaps an hour goes by and then it crashes. Finder? Things are so bad that users have to freaking reboot their systems all the time. That's serious software?
Xfile never crashes.
The 'crash' fifteen years ago was for a change Apple had made in their messaging underbody. The change in Xfile code was about 15 bytes additional code. 15. And then it didn't crash anymore.
Xfile never crashes.
Does your console (Terminal.app) ever crash? Does Xfile crash?
Your file manager is your most central, most vital, application. It's your 'everything'. It's your 'shell'. It's everything. It can't crash. It has to be robust. It has to be reliable. It has to be straightforward. It's the first and last application you use in any login session. It has to be like Xfile. And only Xfile is like Xfile. No application comes close to Xfile save Xfile. And it comes pretty close.
The modularity of the ACP was also important. Xfile and its ancillary apps pertain to the 'Unix' in the OS. Is there anything in the OS that's not 'Unix'? That's put in a separate app. Gotta port to another platform? Then it's easier. And, staying on the same platform, the modularity means the code is easier to protect and maintain.
You don't go around making software monsters. That leads only to bugs and vulnerabilities. You don't want to get into a mess like that. Things get out of control fast. Keep things under control.
Most of our code sits in our memory anyway. Not computer memory - our own human memory. If something goes south, we can see at a glance where to look in the code. We know how we built the apps. Code changes are easy to get to - we know where to go. Because we keep it modular.
Seventy plus GUI apps built like that. Command line counterparts where applicable.
We built our own documentation system. We had to do that - Apple's own system was so bad. Our is a lot faster and more responsive. Ours was ready and shipping long before Apple's started to work, even a bit.
Our entire ACP is engineered so well that it fits in a 5 MB download. For everything. The 70+ GUI apps, the 40-50 command line tools, the hundreds of documentation files, the ACP's framework files...
If our sneaky friend thinks he already has this...
We just checked when last our productive friend actually produced anything. A program, an article, anything?
Almost a year ago.
But he has a copy of the ACP.
About Rixstep
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.