Self Contained Executable folder

[terra]

Hi,
Would it be possible to get a self contained executable folder for Windows (i.e. instead of an installer, as it is right now, it will be a zipped folder with the instructions of where to put the drivers).

[socratis]

I don't think that this is possible with the kernel drivers that VirtualBox wants to install, register and use. It's not a "portable" application, it's a heavy-duty application that talks to hardware resources. Can't say that I know of any program that talks to hardware that comes up as a zipped package.

[terra]

I think the "vBox Portable" people were able to do it. They "extracted/semi-installed" the executable Virtual Box Setup file and then encapsulated the program so that the needed drivers/registry keys were moved to the needed locations before the program starts and are removed after the program exits.
Their were no other modifications, like recompiling the code, as such tagging vBox Portable as a separate fork of the project is incorrect as the code was not touched.
As such I was wandering if Virtual Box developers were able to provide the same thing ("extracted" Virtual Box director setup with the drivers in separate folder and if possible needed/program initiated Registry Key changes explained in a file).

[socratis]

I think the "vBox Portable" people were able to do it. They "extracted/semi-installed" the executable Virtual Box Setup file and then encapsulated the program so that the needed drivers/registry keys were moved to the needed locations before the program starts and are removed after the program exits.

You are reading it wrong. Or you read half their website. From their website:

Note
VirtualBox needs several kernel drivers installed and needs to start several services: if the drivers and services are not already installed you’ll need administrator rights to run Portable-VirtualBox.

Which translates to "you need to install it before you run it". And no, the services and kernel drivers are not "removed" after you run it. I've tried it. More than once.

Their were no other modifications, like recompiling the code

Compiling and installing are two completely different and unrelated beasts.

"extracted" Virtual Box director setup with the drivers in separate folder

That "separate" folder would have to be the %Windows%/System32 folder. No default access unless properly authorized.

if possible needed/program initiated Registry Key changes explained in a file

The default permissions would not allow a simple user to mess with the Services branch of the Registry.

But if in doubt, you can always ask at their website...

[terra]

I have worked on portabalising applications in the past, and know that moving files in and out of registry and system folders is possible, as well as starting and stopping them. I might need admin rights for some things but not always. In addition, Registry keys for HK Local User could be created and destroyed without any Admin rights required.

[socratis]

I might need admin rights for some things but not always.

You'll always need elevated admin rights (even if you are an admin) to install VirtualBox. No way around it.

In addition, Registry keys for HK Local User could be created and destroyed without any Admin rights required.

Very true. But I'm afraid it doesn't apply to VirtualBox.

VirtualBox creates keys in HKLM, Services (mostly). You need admin rights for that, as stated already. The HKCU (Current User, not Local User) is not used at all, mostly because of VirtualBox's multi-platform personality. Not that may OSes have a registry. But in all OSes that VirtualBox supports, it does require the installation of drivers to make it work.

PS. There is no need to quote the whole discussion, only the relevant parts. It makes it less easy to read.

[terra]

You'll always need elevated admin rights (even if you are an admin) to install VirtualBox. No way around it.

Which if you own the hardware is easy to obtain. I always experienced reduced performances on my USB drives after installing any of virtualization software, and don't use it often enough to justify it. As such having to install it followed by uninstalling it takes time and also leave stuff in the registry which have to be cleaned up.

Not that may OSes have a registry.

That is why I specifically stated Windows.

But in all OSes that VirtualBox supports, it does require the installation of drivers to make it work.

That's not a problem when you own it.

I only asked for the possibility of getting the extracted files with the drivers on the side and registry codes/changes listed in help file.

PS. There is no need to quote the whole discussion, only the relevant parts. It makes it less easy to read.

[socratis]

OK, let's compare the "standard" installation method, vs your proposed method:

Standard

1. Dbl-click on the installer.
2. Accept the UAC warning.
3. Potentially click to allow the installation of Oracle-signed drivers. I say potentially, because you can choose to Always Trust them, so you won't be bothered again. Ever.
4. Done.
5. Chances of things going wrong at around 0%.

Your proposal

1. Unzip/unpackage the contents of the archive.
2. Move the contents of "Oracle\VirtualBox\" sub-directory to "Program Files", potentially overwriting the existing ones.
3. Accept the UAC warning.
4. Move the contents of "Drivers" sub-directory to "%Windows%/system32", potentially overwriting the existing ones. You'd better hope they're not in use, or else ... epic failure. And by that I mean that you have to stop the services, unload the drivers and then replace them. Several steps and instructions involved, have been omitted for simplicity's sake.
5. Accept the UAC warning.
6. Merge the registry information for the drivers and services.
7. Accept the UAC warning.
8. Start the appropriate services. It would be easier with a batch file. It will save you several steps.
9. Accept the UAC warning.
10. Done.
11. Chances of things going wrong at around 90%.

Of course, you could automate your whole proposal with a batch file of sorts (or a program). Kind of like ... an installer, you know.

I'm sure that the developers will consider the merits of your proposed solution and act accordingly. As far as I'm concerned, I'm done with this thread...

[socratis]

One final thought, not about your proposal, but about PortableVirtualBox (PVB), which has been mentioned.

I've never, for the life of me, understood what's the benefit of it. And this is assuming that, in theory, it enables you to walk with a flash drive on someone else's computer and run VirtualBox (VB) from a USB stick with no installations or alterations to said computer. That's what "portable" is all about, isn't it? Let's see:

• If VirtualBox is not installed, you'll need to install PVB using a local admin account. So, why not install it properly then? How's that any different?
• If VirtualBox is already installed, you might run into version conflicts if you run VirtualBox from the stick, since you don't know what's the local installed version. Programs that depend on kernel drivers and system services do not particularly like version mismatches. So, why not run the local version then? How's that different?
• If the goal is to keep your VMs on the stick and run them at will, you can do that in any case. You just need the VM folder on the stick and then you can add it temporarily to the local VB. Once you're done you remove the VM (if you want to) without deleting the files. Done.

To me the PVB project was created just to be created. What exactly it brings to the table is highly questionable. Unless I'm really missing something...