|Home » Learning Curve
Your Internet Can Be Your Computer
'An address space for everything and everything in its own address space.'
'An address space for everything and everything in its own address space.'
That's how you might sum up personal computing (mobile computing) of today. But things weren't always like this. Gramps might have an old Mac around. The kind that ran everything - literally everything - as one single process and then hoped for the best.
The way it worked was like this, taking from Windows architecture.
- You set up your app to run. Customise its windows, its menu, and so forth.
- You sit back and wait. For something to happen. A system notification (perhaps someone wants to shut the system down) or a user command (edit something, copy something, paste something, close something).
As you wait, you wait in what's known as a 'message loop'. You just sit and wait. You literally tell the system you want the next message. But your call effectively returns control to the system itself. So the system will look around, see if there's anything that needs to be done, queue some other message or two to you perhaps, and then and only then reply to your request for a new message. (At which point total control of the system goes back to you, to your app.)
That's the way it was in the days of 16-bit. You need at least 32-bit to run protected memory (with genuine time-slicing). You need something like 24 bits for the internal page table addressing and the remaining 8 bits can be used to tidy up the page table list.
For once you enter into protected mode, an address is no longer an address. Userland code can't access raw RAM addresses. That's off limits. That would result in an access violation exception. No, the addresses you send along to the system are interpreted as 'virtual' addresses, and that good old CPU interprets them as such, looks them up in its trusty page table dictionary, then hopefully does what you want.
The beauty of this system, from the programmer's POV, is that nothing changes: the programmer is to go on treating those addresses as real (when they're not).
You can't get into the address space of another application either. Even if you could find it. Put another way; there's no way for you, from inside one app, to access something that's inside another.
So that makes for super security. Ain't that the greatest?
Yes it is. But how about if you really really want your apps to interact with one another?
If Ken Thompson heard you ask that, you'd probably get a rap on the knuckles. Unix was specifically and deliberately designed so processes cannot communicate with each other. All a process can do is hang and wait for another process to exit, then wake up itself. And all it gets back is the exit code of the other process. And that's not sent to you from the other process anyway. So it's no true 'IPC' ('inter-process communication') as it's called - in Unix, IPC is hanky-panky.
OK, so how about if you really need it? The gurus at NeXT figured out a way. Using their near-universal 'AppKit' framework (shared library). Code in that module can somehow magically see calls coming in from other apps and send data onto you, and vice-versa. The NeXT gurus invented something they call Services. There's a lot that goes into a call (message) to this Services module. Here's a quick peek from our own ACP Service Manager Pro. All those data fields are part of what your app can send to the AppKit Services module.
Executable - you don't need it. Let's keep this simple.
Key - the actual keyboard shortcut you want to assign. Cmd is assumed. Note that Services shortcuts can collide with shortcuts already in use in your application, so it's your responsibility to avoid collisions.
Menu Item - precisely. Exactly what you want to appear on the Services menu. (Remember: there's no longer any hierarchy. This is all you get.)
Message - that's actually the name of the internal method in your code.
Port - don't worry about that for now.
Return Types - ah. For the AppKit wants to know what data types it can send back to you. Image formats, plain text, and so forth. This one's set to 'NSStringPboardType' and you'll never guess what that means.
Send Types - the Services module is going to look to see if you have something selected in your application, something it can send. But what type of something? This particular service is prepared to offer the same 'NSStringPboardType'.
Timeout - you can have a service request time out after a while, in case something goes wrong at the other end, or you just tired of waiting. This value is usually expressed in milliseconds.
User Data - ah. The key to it all. This field was rarely, if ever, used by NeXT, and it can literally be anything you want. And isn't that convenient? This field is used in different ways for the ACP Text Services (ATS) and the ACP Web Services. The ATS are some pretty (lean and) mean code, so let's look at the AWS instead.
Let's look around to see what we can find for DuckDuckGo's acronym DDG. It's probably not what you wanted, and the search string in your location bar might look like this.
Can you see the question mark in that URL? The question mark signals the start of a query string. The full query string here is:
So you could theoretically (more than theoretically) swap out the 'DDG' in that query string for 'DuckDuckGo' and see what you get. You could change the full URL to this:
But how to automate something like that? Sure, you can surf to DuckDuckGo and input anything you want, then fiddle with your search options, but that takes a lot of work. Is that what you want to do each time? (Is that what you're currently doing?)
The Network is Your Computer
To quote one of the founders of Sun Microsystems: 'the network is your computer'. Wouldn't it be nice if all you had to do was double-click some text somewhere - anywhere - and then hit a keyboard shortcut and there you'd be, without further hassle, off to the races, instantaneously purveying a selection of, for example, images? Or dictionary definitions of whatever you'd selected? Or literally anything at all, for that matter?
Of course it would. But how do you do it?
Save the best for last
You save the best for last. You muck about with that query string so the actual (variable) query is at the end.
Let's look again at that DDG/DuckDuckGo URL.
According to the ACP applet NSURL.app, it breaks down thusly.
All you have to do is move things around so your one variable - what follows 'q=' - comes last. Wanna do it? Let's break that sucker down.
Note that the first part of a query string always begins with '?' and the other parts are separated (not prefixed) by an '&'. With that in mind, it should be easy to rearrange things.
Or try putting something else at the end.
So - basically - if you could just find some way to leave off that final part:
And then send that to your AppKit Services module...
Oh but gosh, look!
For that's exactly what the ACP Web Services do. You select the word 'Baywatch' somewhere (or any word or phrase or paragraph) anywhere and then hit a keyboard shortcut and 'viola', as Kelly Bundy used to say. You're there!
You didn't have to fire up your browser (or open a new tab on it). You didn't have to type in 'duckduckgo.com' and then click around until you got the parameters you wanted. You didn't have to paste in (or type) the word 'Baywatch'. You just double-clicked the word 'Baywatch' locally and then hit a keyboard shortcut. Because the ACP Web Services added the word 'Baywatch' to your query string, after the 'q=', right where you wanted it. Easy, huh?
The Internet is your computer.
So it's that easy?
So it's that easy? Yes. The difficult part is only in the beginning - if, somehow, the search you want isn't already available. (There are thousands upon thousands readymade by us.)
On Apple's Mac, you just go into your 'Keyboard' section of your System Preferences and make sure the item's box is ticked. Then you're ready to (rock 'n') roll. The ACP Web Services assemble the data (see image above) and then send it to the AppKit which then 'marshals', as it's called, the request, into another address space (to that of your web browser) and off you go.
Both your own app (with the string, in this example, 'Baywatch') and your web browser are still operating in their own address spaces - and yet the call gets through, and you see the results onscreen (in your web browser).
Nifty! Wouldn't you agree?
Here's the catch. (You sort of suspected there was a catch, didn't you? There is a catch, but it's probably not the kind you anticipated).
The catch is that the people inhabiting that bubble known as the 'Mac community' think it's still too difficult. (Yes. True. Sad.)
Too hard for what? Good question. Nobody really knows. Do they really prefer working harder, working the traditional tedious way, to get the same results, only much much later? Evidently. But why? No one knows.
Perhaps it's too much of a hassle for them to move their cursor all the way to the left to access their 'Services' menu (if they haven't assigned a keyboard shortcut). No one really knows.
But those who use the ACP Text Services and ACP Web Services know. They know how much easier things are. How much their 'workflow' improves. Double-click to select text, then hit a keyboard shortcut, and instantaneously you're there. You've arrived. It's that fast. It's that easy.
There's no reason similar functionality cannot be written for other platforms. (Perhaps it already has.) The mechanism is simple enough, but one does need a bit of support code in the system itself. Yet that shouldn't pose too much of a problem, shouldn't be too much of a stumbling block.
Anything to make computers, mobiles, all computer devices for all users act more like the Internet is truly their computer.
PS. You can of course search for anything you want, not just Baywatch (or images from Baywatch). You don't have to get caught in the current of love.
PPS. Discussion of this led to a suggestion for a 'speed bar' - a sort of floating panel that can be activated on screen in any context. This can become a new applet. So stay tuned.
You've obviously heard of us, otherwise you wouldn't be here.
We're known for telling the truth even if it's not in our interest.
We're now telling you to beware Apple's walled garden. Don't get locked in.
What you've seen so far may be only the beginning of something far far worse.
Download our Test Drive and at least check out our free Keymaster Solo.
That's the first step to regaining your freedom. See here.