Cameyo 2.0 (geeks only!)

Cameyo 2.0 is now out of Beta. It is now linked to the cloud Cameyo Online service & library, supports Windows 8, and brings many goodies which you can read here. I won’t go over these in this article.
Instead, I would like to take you on a tour into an advanced aspect of Cameyo 2.0 usage. I saved this for the geeks among you: the different ways in which you can customize Cameyo virtual apps‘ behavior.

Let’s say you want to modify the behavior of a Cameyo app. Be it for changing its startup menu, its repository location, its expiration date, or even its environment variables.

If you’re a Cameyo geek (a “Cameyozi”), you already know about the Package Editor and I would be insulting your intelligence if I went over this here. But here are a few other methods which you may not know about:

1. Environment variables (dynamic app configuration):
With Cameyo 2.0 apps, you can now configure every INI setting through environment variables. For example, let’s say you have an application called “Appname.cameyo.exe” and you would like to use the same executable with different configuration each time (for each different user, different machine or each script that may run it).
Since you are a Cameyozi, you already know that the different parameters of the application are contained in VirtApp.ini (which is really most of what the Package Editor configured, despite its fancy UI).
But you can also change these variables by declaring environment variables with the same name, prefixed by “CAMEYO_”.

Playing with the virtual repository’s location
For example if you want to force the repository dir (BaseDirName INI variable) to be in \\\Server1\MyRepository, you can set an environment variable like this:
Then, run the virtual app and its repository will go there.
Note that the repository path can always include Cameyo / system variable names. For example if you want the repository to go to the Cameyo-defined variable (“%”) documents folder:
If you want it to go to system-defined variable (“%%”) HOMESHARE folder (thanks to MHo for the trick):

Changing the startup menu on-the-fly
As another example, let’s say you want to change the startup menu of an application from a script:
CAMEYO_AUTOLAUNCH=%Program Files%\Soft1.exe>>First menu item;%Program Files%\Soft2.exe>>Second menu item
and run your app.

Here’s what you’ll see:
(with “First menu item” executing %Program Files%\Soft1.exe etc, within the virtual context)

Even geekier
Want to change the startup directory of a virtual app (instead of leaving it to the virtual exe’s directory)?
Want to add two environment variables to the virtual app’s context?
(“:==:” is the separator, for allowing you to use both the “:” and “=” characters in your values)
(“%ExistingValue%” is substituted by the variable’s existing value, if any)

OK, let’s stop here. One last note: if you work through cmd.exe or BAT files, be aware that “%” and “>” are special characters and you need to make sure DOS doesn’t replace your values with something else.

2. Persistently modifying a virtual package, without the Package Editor
Want to modify a package persistently, but from a script? Find Cameyo’s Packager.exe (C:\Users\me\AppData\Roaming\VOS\Cameyo\%Program Files%\Cameyo) and launch it with:
Packager.exe “-SetProperties:AppID=NewAppID,,Expiration=31/12/2012” “C:\AppName.cameyo.exe”
(“,,” is the separator, for allowing you to use single “,” characters in your values)

Note that you can add a “-Quiet” as a first parameter to Packager.exe, to avoid messages (exit codes indicate success / failure).

3. SDK
You know that there is a C++ / .NET SDK for manipulating Cameyo packages and processes, right?

4. Streamed on-the-fly INI (Web / ASP.NET)
OK, this one is not totally useful for most of you, since it is not completely exposed in the SDK and is used only internally for now (by Cameyo Online servers), but just for your Cameyozi-culture, here’s how it works:

The Cameyo Web servers are capable of providing the same virtual app executable, but with different configurations / behavior for different cases. Here’s how it works: the Web server provides the binary
executable file. At the end of it, it calls an obscure Cameyo SDK function named “QuickBuildAppendiceIndexFile”. This function, along with some database-stored information about the package, is capable of plugging an entire INI string at the end of the executable package string. So by streaming AppName.cameyo.exe + a dynamic INI string + the header returned by this function, the downloaded executable will behave with the new INI behavior.
Neat, isn’t it? What, you don’t care? Oh well!
Actually when you think about it, there can be a number of interesting applications to this: providing a single EXE app with dynamic metadata (logins, encryption keys, expiration dates, launch parameters…)

Oh oh, hopefully I didn’t go too geeky this time. Hopefully you could pick something interesting / useful for your Cameyozi culture. As always, leave a note if you have some smart ideas.

I’d like to dedicate this article to Max who has been helping me with communication and localization during my work on Cameyo 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *