An amiable chap looked at Be.app the other day and asked a two-part question.
WTF is it?
How and why does it do what it does?
Yes, those are legit questions. Discarding what mobiles have done to our sensitivities, let's look back through the fledgling history of Comp Sci and try to arrive at a modicum of clarity.
IN THE BEGINNING WAS THE COMMAND LINE
In the beginning was the command line. Actually that's not true. Switches were even earlier. Like the Altair but earlier still. Valves / vacuum tubes. Then machine code translated into microcode. Assembly languages making machine code palatable. FORTRAN. COBOL. And so forth.
The IBM 3270. Common user access when it was neither common nor accessible. The operator punched in something at the console and away you go.
Programs had a beginning and an end. Dijkstra taught us that programs must have one entry and one exit and they should ideally be the same. (Edsger wasn't talking about GUIs obviously.)
Programs loaded into (preferably) relocatable memory and turned into processes. The computer was in control. The computer always had the lead. Seriously: the idea that the system itself would call a piece of dinky application code? You gotta be kidding.
There were quite a few wizards behind the curtains that day, but he got the point across. Don't forget Steve Jobs' admission that his first look at the PARC LRG was a sort of epiphany for him, so strong that it made him oblivious to all the other great things going on there. Such as Ethernet.
Kay saw the desktop as a swirl of independent sovereign 'things' ('objects') interacting with one another. Like the Universeª. Or the Troggs. No beginning, no end.
(That interaction is called 'messaging' - it's not native to Von Neumann but it works splendidly with the proper runtime. And people find it intuitive.)
Open With
Xerox PARC evidently had action-orientation prototype boxes but, as with most everything there, they never pursued it to market. But one can speculate how it worked. Such as you drag an application icon to a document icon and drop it. And viola, as Kelly Bundy would say, you have your document on screen in a window. Open for viewing and editing by the app you dragged.
The differences can seem to range from subtle to nonexistent, but never forget the words of Uncle Unix himself, Doug McIlroy. That the day Apple can't open your document file because its designated editor can't be found: that's the day Apple's OSes cease to be Unix. And that day is inexorably approaching. Keep up the good fight and destroy it all, as John Siracusa might say.
Today, in object orientation, you look at the document, the object, the predicate, to use grammar terminology, as the main focus, and the application, the action, the noun: that's secondary. False OO prophets were brainwashing adepts into believing that they could fully understand program logic by merely and solely and exclusively looking at the datasets. Which of course is nonsense. But a lot of carpetbaggers got rich quick and got out of Dodge and retired to Cancun before the shit hit the fan.
Nevertheless, you today double-click a document icon to open a document file, and you do this automatically by coupling through to the document type's associated application.
(Speaking of which: Can Microsoft actually have done a leapfrog? See below.)
The traditional method of connecting documents to applications is via a generic document type specification. A mirror of this is found in recent Rixedit logic (this remains in Be for now).
In other words:
Determine the document's type.
Look up the associated application and run.
(Or, as found on Apple context menus, 'Open With'. Saves the system from The Curse of McIlroy.)
The traditional, almost universal method of determining document type is through file extension. Microsoft documentation says so explicitly but Apple fanboys hurled when they saw TN2034 which suggested they start doing things like the rest of the world. Stray Apple apps like TextEdit scrawl random stuff on the 'backside' as a sort of XA.
The document type becomes a 'catch-all' for all types that are supposed to be handled the same way. Be.app's Info.plist inherits the following from Rixedit.
Under the key 'Files', you find how file extensions are melded to specific types.
The keys in that dictionary are treated programmatically as file extensions. The line immediately following each key, eg <string>CODE</string> or <string>TEXT</string>, is what the application's caller gets in return, and that return value tells the client how to go on configuring the coming window.
HKEY_CLASSES_ROOT
Microsoft does the same thing. The Windows Registry key HKEY_CLASSES_ROOT is not a real Registry key, but a shortcut, traditionally equating to HKEY_LOCAL_MACHINE\Software\Classes.
Perhaps you see or sense the fallacy there? Take the following scenario. Jane gets a copy of MS Word. She installs it on the computer she shares with June. Starting now, all MS Word files with the typical 'doc' file extension need only a double-click to open in MS Word. Fine and dandy.
But June, who shares the same computer at work, does not have a licence for MS Word. When June comes to work and double-clicks a 'doc' file, her system tells her it can't open the file, or she doesn't have a valid MS Word licence, or something. This because the system associates the file extension 'doc' with the application MS Word. (And no, nobody's yet thought of providing a mechanism for listing 'second choices'. Give it another ten years.) June reads and edits MS Word 'doc' files, but she uses the cheap variant WordPad already packaged with Windows. So, naturally, June reverts the system settings so double clicks again open the app she usually uses. All fine and dandy.
But then Jane comes back to work.
The culprit is in the use of the real Registry key HKEY_LOCAL_MACHINE. That key really exists. (Microsoft's Registry has essentially only two keys.) Traditionally all document file extensions are organised as if there's only one user on the computer. Those settings apply not to a particular user but to the machine as a whole. (Back in the day, that was the same thing - back in the day when files didn't have access/mode bits, when there was no user login.)
It seems Microsoft have finally caught on. From the official online documentation.
Class registration and file name extension information is stored under both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that can apply to all users on the local computer. The HKEY_CURRENT_USER\Software\Classes key contains settings that apply only to the interactive user. The HKEY_CLASSES_ROOT key provides a view of the registry that merges the information from these two sources. HKEY_CLASSES_ROOT also provides this merged view for applications designed for previous versions of Windows.
Note that HKEY_CURRENT_USER is not a real key either, but a shortcut, but that hardly matters for this discussion. What's important is that they recognise that the system can have defaults which individual users can override, so they don't have to be reset every day.
(How things work with Gnome and KDE isn't known. How things work with Apple's OS isn't known.)
That's for a singleton, admittedly. So nothing more happens with it.
But with multi-document interfaces things suddenly change. The system will use the most recent window coordinates to calculate a 'cascade' for the next window. NeXT understood what was coming but never had the time to think it full-out. They're using settings that are application-specific rather than document or document-type specific.
Apple? They have Pages. And TextEdit. And Stickies. Three apps to do essentially the same thing, but in slightly different ways. (Yes, two of those three also deal in rich text, but the analogy still holds.)
We at Rixstep understood the ramifications of this 'gap' for some time. We began with Xshelf which puts window X/Y/CX/CY right in the shelf configuration. Then we continued on other apps by putting the configuration 'on the backside' as an XA. (See the links at the bottom.)
The mix of application-specific settings with document-specific settings is what this is all about. Microsoft, of all corporations, took a good step in the right direction. Don't expect Apple or open source to do the same.
Some of the points in the intro seem to warrant comment.
'i A hierarchical file system incorporating demountable volumes'
Unheard of at the time. '.' and '..' left people bewildered. Rummaging through VTOCs never is fun.
Original UNIX booted from a single drive. The second drive mounted under /usr.
'iii The ability to initiate asynchronous processes'
Add &.
'iv System command language selectable on a per-user basis'
The shells. Interchangeable. Steve Bourne's original sh, then the BSD csh, today we use zsh. But there are others.
'vi High degree of portability'
94%. Says Steve Johnson. And later Dennis Ritchie. Steve, recently arrived at Bell Labs, runs into Ritchie in the stairwell. (Ritchie himself tells the tale.) The result of that encounter was pccm, another milestone.
We had some of Steve's source on one of our networks. Format-wise it was really sloppy but concept-wise it was of course brilliant.
At a strategy meeting for our nationwide Unix network a fat-arsed female bureaucrat blurted 'and they told us Unix was platform-independent, what a joke'. That reinforces the assessment that 90% of the costs of IT are because there are so many blowhards wasting time and money.
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.