This article is in the Product Showcase section for our sponsors at The Code Project. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers.
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);
// Inject BoxedApp engine to child processes
BoxedAppSDK_EnableOption(DEF_BOXEDAPPSDK_OPTION__EMBED_BOXEDAPP_IN_CHILD_PROCESSES, TRUE);
// Now notepad loads the virtual file
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");
Posted via email from Jasper-net
Posts
