One folder apps: a win for Windows

In the fight to battle malware and piracy, we – the end users – get overlooked.

This is most notable in the way that Windows apps are become so horrendously spread out. C:\Program Data\, C:\Users\Public, C:\Users\myname\Documents, C:\Users\myname\Application Data, C:\Program Data\, C:\Users\Program Files (x86), C:\Users\Program Files\, and then … the registry.

Applications should be Plug and Play – like hardware. The reason they aren’t? Piracy. But there’s a solution for that…

Consider for a moment the notion of “Packages”. That’s a fancy name for a folder that contains an application and all the executables and data necessary to run it. Including its own registry hive and any sub-hives – say for users.

But many applications need the ability to see and interact with other software on your system, which is how we got where we are right now.

So where this system varies from Apple’s solution and the simple “I can run an executable anywhere I like, although it might not do everything I want then” solution, we go distributed.

This fits neatly into Microsoft’s cloud future too…

We add a new kind of value, or a special annotation, to the registry, which only Windows sees: the link. It says “Hey Windows, this registry is stored <over here>”.

But it has to get there…

When Windows first sees a “Package”, it would ask the user if they want to “Integrate” the package. A simple, free-to-distribute package, would then have the necessary core-registry link/redirect added.

\\HKEY_CURRENT_SYSTEM\Packages\xiperware\begm = “%{f:\\gaming\\Battleground Europe Game Monitor}”

To protect commercial interests, the “Integrate” process could offer applications several options for licensing control:

  • none: I run from anywhere,
  • basic: This is my password, ask for it,
  • productkey: An API for evaluating product keys,
  • encrypted: Ask the user to enter some data and use with this public key to establish permission to use,
  • online: Use an API to confrm,
  • registration: Allow the app to run, do its own thing, and possibly disable itself (great for free trials)

Great! So now I can put Visual Studio on my USB key and if I’m visiting a client and something is wrong, I can pop it into a machine, run visual studio, and debug something.

But wait – I don’t want J.J. Blackbeard to have my Visual Studio license! Ok – so you need the ability to “run once” instead of integrate.

Now we’re cooking with gas. But what about security and files and stuff?

Ok: At the top level, a Package behaves like a Program Files directory under Vista and 7. But it also behaves slightly differently… A process running from within a package can never write to its current directory. It can only write to a sub-directory (which must be created for it) and it can’t “see” any package directories above its initial level. This allows for an Application Data directory as well as User Data directories and – below those – specific-user data directories.

The application can store user and per-user data in those directories using the same registry-based linkage system. Say my BEGM Package folder contains a top-level registry file for itself, and it wants to have user registry data; it creates a registry subset key UserData = “%{UserData\\Registry}” and to register a registry subset specific to myuser, %{UserData\\MyUser\\Registry}”

Lets say I’ve been working on a shared machine with J.J. Blackbeard. It’s a secure system. And I don’t have read or write access to his account. I’m being given my own machine, and I want to copy Visual Studio. When I copy the package, I can’t access his sub-folders, therefore I can’t copy them, so when I copy the package, only the code, application data and stuff I have access to – my stuff – gets copied.

Simple, neat and secure.

In addition, our personal registry clutter is never an issue. When VS is running under my user, it can’t see his registry files due to ACL at the file system level, so it isn’t going to affect the memory footprint of my instance of Visual Studio.

Which means you can run packages off a network drive! You can have an enterprise with hundreds or thousands of users operating the same package, and no registry impact. You can also add a new machine to the network and go without any fuss or muss.

But now all your data files are spread out all over the place by package?!? Isn’t that just as bad as having data files spread out by type??

Well, nothing stops Packages from accessing user directories outside the package. So I can store all my files wherever I want. On the other hand, the Windows 7 Libraries concept will make that mostly redundant.

What really makes this a win for Windows users is that it shrinks the burden on – and also the footprint of – the registry. Most applications rarely use the registry for anything but figuring out where they are installed and where the user is saving data to. They might access a few Windows registry entries for localization and such.

But the Windows registry is full of every application and device and mime type and odd or end for everything you’ve got installed. Even if I’m not using Putty, the Windows SSH client, it’s effectively using a small chunk of memory all of the time because its registry entries are always loaded.

This could tie in very nicely with the .NET assemblies concept: like iphone/android apps, Packages could have to stipulate what parts of the shared registry and/or registry of other apps they intend to interop with. The Package integrator process could apprise the user of this, drawing special attention when it wants to interact with anything fishy or dangerous.

As an end user, this means a little bit more hassle when you drop a new package onto a system. But it has a plus: When you download something new off the Internet, you’re going to get a first class advisory of what it is actually likely to do.

If you’re downloading a tool that is supposed to be a photoshop plugin that adds borders to photoshop images, and the integrator says “Wants: Full Internet Access, Access to Network Configuration, Access to System Startup Configuration” – hey… You probably don’t want to install that addon… :)

Of course, there will be cases that defeat the purpose — yesterday I saw a registry cleaner (called registry cleaner I think), and on a whim downloaded it and scanned it with MalwareBytes. Naturellement, the installer contained a trojan :) And all the integrator would be able to tell me is that it wants full access to the system registry.

But you’d have a lot less need for registry cleaners and such if the registry wasn’t the beast that it is today…

One Comment

An interesting concept.

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: