In March 2011, Virtualization Technologies released a new version of the developer library that makes it possible to use virtualization in applications.
The name of the product is BoxedApp SDK. By the way, the demo version is absolutely free, and you can download it even right now by clicking on this link.
Virtualization? Why do I need it?
I don't think I am going to be wrong if I say that the first things you thought of when you heard "virtualization" were virtual machines, products like VMWare and VirtualBox. But amazes is that virtualization can live right within your application.
Here is a couple of examples. A portable application which is to be run without installation; the problem is that the application uses Flash ActiveX. The problem seems insoluble: you could install Flash ActiveX, but the portable application, writing something to the registry - that's something odd. On top of that, you can simply have insufficient rights to write to the registry.
Another example. The only format a third-party code is distributed as is DLL, but you need to link it up statically to ensure that none of the competitors finds out, what is the essence your product is made upon. Yes, you could have saved the DLL to a temporary file and then load the DLL manually, but in this case the file could be saved by someone else just as easily. And, of course, again you can lack the rights for saving a DLL to disk.
Or, you want to create your own packer, which turns the numerous executable files, DLL and ActiveX into a single executable file. Yes, you can create a product of this kind with BoxedApp SDK.
These are just the tasks virtualization is needed for .
So, how does it work?
Its fundamental idea is intercepting system calls. When an application attempts to open a file or a registry key, we tuck it a pseudo-descriptor. There are plenty of functions, actually: not merely opening files, but many others as well. BoxedApp SDK neatly intercepts them and creates the realistic illusion that the pseudo-files or, to say more precise, virtual files actually exist.
It turns out that one can create a "file", and an application would be able to handle it as if it was real. But since we are developers, here is a sample of the code:
HANDLE hFile =
BoxedAppSDK_CreateVirtualFile(
_T("1.txt"),
GENERIC_WRITE,
FILE_SHARE_READ,
NULL,
CREATE_NEW,
0,
NULL);
See, just one call, and the "file" is ready.
Now we can write some text to this virtual file and then open it in the notepad:
const char* szText =
"This is a virtual file. Cool! You have just loaded the virtual file into notepad.exe!\r\nDon't forget to obtain a license ;)\r\nhttp://boxedapp.com/order.html";
DWORD temp;
WriteFile(hFile, szText, lstrlenA(szText), &temp, NULL);
CloseHandle(hFile);
BoxedAppSDK_EnableOption(DEF_BOXEDAPPSDK_OPTION__EMBED_BOXEDAPP_IN_CHILD_PROCESSES, TRUE);
WinExec("notepad.exe 1.txt", SW_SHOW);
Get numerous other examples now.
Where are virtual files located? Can I store a virtual file in my storage?
By default, virtual files are located in the memory, but sometimes it may be necessary to set a custom storage for such a file. For example, when data is to be stored in a database or somewhere on the Internet. For such cases, a virtual file is created upon the implementation of the IStream interface. You simply place the logics of the storage operations in the implementation of IStream, and the data will be placed there and not in the memory.
An interesting example of the use of such files is playing encrypted media content. For instance, the source video file could be encrypted unit-by-unit and placed in the application's or in a file near the main program. When it's time to play the video, the program creates an IStream-based virtual file. That IStream never decrypts the entire video file; instead, it feeds the data by little pieces (from the IStream::Read method), as demanded.
How about ActiveX / COM?
ActiveX is still widely used; there are many legacy ActiveX. With BoxedApp, you can register an ActiveX virtually, when the program starts, and the program will be able to use it! The registration is really simple:
BoxedAppSDK_RegisterCOMLibraryInVirtualRegistryW(L"Flash9e.ocx");
That's it! All the registry keys required for using ActiveX are now in the virtual registry, inside the application. And this wouldn't anyhow affect the real registry.
What if I create an executable "file" and run it?
BoxedApp will create a virtual process. This could be really convenient if you need to distribute an "all in one" application. You can place all the executable files in the application's resources and then, on demand, turn them into virtual files and run them. The client computer will remain clean, and the processes will run as if they were created from the real files:
HMODULE hModule = GetModuleHandle(NULL);
HRSRC hResInfo = FindResource(hModule, _T("BIN1"), _T("BIN"));
HGLOBAL hResData = LoadResource(hModule, hResInfo);
LPVOID lpData = LockResource(hResData);
DWORD dwSize = SizeofResource(hModule, hResInfo);
HANDLE hFile =
BoxedAppSDK_CreateVirtualFile(
_T("app1.exe"),
GENERIC_WRITE,
FILE_SHARE_READ,
NULL,
CREATE_NEW,
0,
NULL);
DWORD temp;
WriteFile(hFile, lpData, dwSize, &temp, NULL);
CloseHandle(hFile);
WinExec("app1.exe 1.txt", SW_SHOW);
These examples are in C++; what about C#, Delphi?
BoxedApp comes with examples in C++, VB6, C#, VB.Net, Delphi: you can download examples now.
Both 32-bit and 64-bit versions of BoxedApp SDK are available.
Conclusion
It's literally impossible to cover all the tasks where virtualization could be necessary, but I will try to make a list anyway. Virtualization is necessary when:
- Creating an application that must keep all its code in a single file.
- Creating a portable application, which must run instantly, without installation.
- Necessary to keep a portion of code secret, hide the fact of its use.
- Your goal is the creation of a packer application, which creates a single executable file out of a set of DLL, ActiveX and data files.
Feel you really need virtualization? Tell us about your task, and we will offer you an adequate solution with BoxedApp.
Useful Links
