Developing for U3

This article was originally published in VSJ, which is now part of Developer Fusion.
U3 is a new platform, and the good news is that it presents us with a huge new potential market, and it’s very easy to develop applications for. In fact you don’t have to learn very much that is new, and you can continue to use whatever technology you have adopted – Java, C++ or .NET. This article is about creating .NET U3 applications because it’s a topic not touched on by the standard documentation, but the ideas can easily be adapted to other languages and systems.

First, what exactly is U3? The idea is simple enough. Take one USB flash memory device and turn it into a platform for portable applications. A user can make a copy of their desktop environment in the U3 device and install U3 applications. The clever part of the idea is that part of the device is formatted to look like a CD, and this auto-runs when the device is plugged into a USB socket. This then installs the U3 Launchpad in the system tray. The user can use this just like a start menu and run U3 applications, configure U3 applications, and work with the flash memory filing system.

The key thing is that a U3 application is designed to leave no trace of its activities on the host machine. A sequence of start up and shut down states are designed to customise the host environment and to clean up when the U3 device is ejected. It’s the ideal mobile environment, and it means you don’t need to carry a laptop just to move from one location to another. U3 has the potential to remove the “personal” from the PC, because if we all have our working environment, applications, files, emails etc. on a U3 device, then any old hardware can be used as if it were a personal machine. After all, you don’t have a personal TV, fridge or toaster – you just use the hardware that happens to be around in the house, hotel room, friend’s apartment, or wherever. It could be the same with computer hardware in the future. At the moment U3 only works with Windows XP and 2003, but a U3 device does work as a standard Flash memory stick on other hosts.

Figure 1
Creating the manifest

If you want to find out more about U3 then visit, where you can sign up and download the SDK and lots of other useful software. You can also browse U3 Software Central where users can download U3 software directly to their device. Much of this software is free, open source even, and this is good because it acts as a bootstrap to get the U3 market started. However, many of the free programs are tasters for paid-for professional versions.

What you need

Before you start you need to download the deployment kit, which describes how the U3 platform hosts an application. Surprisingly you probably don’t want to tackle the SDK until later on in your U3 development because it provides interaction with the U3 device, which some applications might never need to use. There are two other important utilities that you need to download to get started, and at the time of writing these aren’t included in the SDK (they should be). You need the Manifest Creator and U3Action, both found in the Tools section of the download area. You can create U3 applications without these, but it’s more difficult and there is enough to do when mastering any new technology. The Manifest Creator also needs MSXML 4.0 installed as a U3 Manifest in an XML document.


A U3 application has to be a runnable .EXE file, there are ways of running other types of program but it needs additional work. Fortunately .NET applications are pure .EXE files, which can be run from a command prompt if you really wanted to. The only problem with them as U3 applications is that they will fail to run if the host machine doesn’t have the .NET framework installed. In a production program you would need to check that the host machine did indeed have the correct .NET framework installed, and either abort or offer to install it if this wasn’t the case. In an ideal world the installation would be from the U3 device, and to conform to the U3 philosophy it would also have to be uninstalled when the device was ejected. In my opinion this is taking “leave no trace” a bit too far, and I’d also give the user the option of making a permanent update. Given the widespread use of the .NET framework the chances of encountering a machine that doesn’t have it installed are reasonably low. For this example it will be assumed that it is indeed installed and part of the standard operating environment.

Figure 2
The lifecycle of a U3 application

A U3 application is packaged as a .zip compressed file, but with the extension .u3p. You can’t use any other compression method, and the simplest way of creating a .u3p file is to use the Send To Compressed (Zipped file) context menu command and then manually change the extension – making sure you are not hiding known extensions.

The U3 package file contains a number of standard directories:

  • Manifest – This is used for configuration files – notably the U3 manifest and the icon used in the Launchpad. The files in this folder are used when the application is installed.
  • Host – The Host exec directory contains the executable and any other files needed to run the application on the host machine. When the U3 application is run, the Launchpad copies the files in this directory to a temporary directory on the host. This is where you would also store any DLLs that are not part of the core operating system. The reason for making a copy on the host machine is so that the application can continue to work even if the U3 device is removed. A runtime variable called U3_HOST_EXEC_PATH is available to the application should it need to know where it is stored. When the U3 device is properly ejected by the user, the temporary directory is removed from the host. As the temporary directory isn’t copied back to the device, any changes are not persisted.
  • Device – The Device exec directory holds auxiliary application files. Unlike the host directory, the files in the device directory are not copied to the host when the application starts. You can use this directory to store help files, media files and anything that is accessed infrequently. Also, as these files are stored on the device at all times, any changes that are made as the application runs are persisted and move with the device at is used in different hosts. A runtime variable U3_DEVICE_EXEC_PATH is made available to the application if it needs to know the location of this directory.
  • Data – The application data directory is the place to store all data and configuration files that need to be persisted. The contents of this directory are not copied to the host and hence any changes are made to the data in the device and carried from host to host. The runtime variable U3_APP_DATA_PATH can be used by the application to locate its data.
Apart from the manifest directory the others are optional. Clearly the difference between them is what happens to them at runtime, but they are also treated differently when a U3 application is updated. Notice also that there is a Documents directory on the U3 device – identified by the runtime variable U3_DEVICE_DOCUMENT_PATH – and most U3 applications will need to create a sub-directory of this for the user to store application documents. The package directories are really only supposed to be used for files that are in some sense internal to the application. To be clear – you don’t give the user the opportunity to save data in the package directories using File Save, which should default to the standard Document directory or a custom subdirectory.

Figure 3
The U3 installer at work


A U3 application has a precise life cycle that corresponds to various “actions”. When the package has to be installed to the device and the action stores the directories on the device. Similarly when the application is uninstalled, the deviceUninstall action cleans up the device. When the U3 device is inserted into a host, the application is made ready to run and ready for the appStart action. When the application is stopped the appStop action is run and when the U3 device is ejected the hostCleanUp action removes all trace of the application. Each of these actions can be implemented by a custom .EXE file, and exactly what these do to install, run, clean up etc. is up to you to work out and implement. Not all of the actions need to be specified, but you do need executables for appStart, appStop and hostCleanUp. The good news is that a standard .EXE file implements the three essential actions. You can customise what the Start, Stop and CleanUP U3 actions do, but for the moment we can treat the U3 Actions utility as a black box that gets our application started and stopped.

Hello U3 World

It’s time to write our first U3 application. Create a C# or VB application called HelloU3, and place a button on the form. Change the button’s Text to “Click Me” and its event handler to
private void button1_Click(
	object sender, EventArgs e)
	button1.Text = “Hello U3 World”;
Check that the program works by running it and then using the Build,Build Solution command to create a final .EXE file. You need to navigate to the bin\Release directory within the project and find the HelloU3.exe file. Double click on this to make sure that you can run the application. Next create a U3 packet directory called VSJU3 and create three folders in it called device, host and manifest. As we are going to use U3Action to control the lifecycle of the application this U3Action.exe has to be stored in the host directory, i.e. download U3Action.exe and copy it to the host directory. We also need to store the HelloU3.exe file, i.e. our U3 application, in the device directory, i.e. locate it in the .NET project in the bin\Release and copy it to the device directory. You might find this a little odd given how the directories are used, but it is the U3Action that needs to be copied to the host machine to supervise the application’s lifecycle. The actual application really only has to be loaded once from the device and doesn’t need to be copied to the host machine.

Now we have the only two executables we need stored in their appropriate directories, all that we have to do is create the manifest. This can be done by hand as it’s an XML file, but it’s much easier to download and use the Manifest Creator. If you start this running you will see a tabbed dialog box that allows you to enter the details of your U3 application. You need to enter suitable text for Product Name, Vendor Name, Short Description, and product description. You also need to enter the minFreeSpace needed on the U3 device for the installation to proceed and an application version number. You need to specify a 32x32 24 colour icon file – for a demo you can simply search your hard disk and select any reasonable .ICO file you encounter. The icon file has to be stored in the manifest directory, and once you have done this you can use the Browse button to enter its name. Finally, every U3 application is identified by a UUID. This can be generated any way that you like, but the simplest thing to do is to click on the Generate UUID button. Other entries on the Manifest Entries tab are optional.

Figure 4
The finished U3 application ready to run

The only other page we need to attend to is the Required Lifecycle action. Leave the “Use U3P project folder” option ticked and use the Browse button to navigate to the folder that stores the U3 folders, i.e. device, host and manifest. Select the Use U3Action option and with appStart selected use the “Browse for action executable” button to specify the HelloU3.exe file in the device directory. This is all you have to do because the other essential lifecycle actions are taken care of by U3Action. If you now click the Current Data tab you can see the XML generated, and you can see the command lines used for each of the required lifecycle actions. You can use the File,Validate current entries command to check that the manifest is valid XML. Finally, save the manifest in the manifest folder.

With the manifest and the icon stored in the manifest directory we are ready to create the U3 package. To do this you select each of the three directories – i.e. device, host and manifest – right-click and use the “send to compressed folder” option. Don’t make the mistake of zipping the top level folder that the U3 directories are stored in. Finally, rename the zip file to Hello.u3p. Now we are ready to install it in a U3 device.

Plug a U3 device into the machine and, when the Launchpad has installed itself, open it and select the Add Programs option followed by “Install from My Computer”. Navigate to the Hello.u3p package file and select it. The Add Program Wizard should then take you through the installation – if there is anything wrong with the manifest or any of the executable files it will abort with a suitable error message.

When you next open the Launchpad you should see your application and its icon, and as long as the .NET framework is installed you should be able to run it on any host machine in the same way, i.e. by clicking on the icon.

Where next?

Of course this is just a starting point. Our simple application doesn’t change anything on the host machine and cleanup is minimal. Also interaction with the host machine and the U3 device is minimal. Clearly there are lots of subtle points that arise when converting an existing application, but the key idea is to write truly mobile applications that use resources that are available and leave no trace when they are removed. The U3 documentation is helpful, but it suffers from the usual problem of being written by experts who really don’t have much idea of what beginners misunderstand. It’s also very short on examples and .NET support in particular. Clearly we need a Visual Studio add-on to create U3 applications. Even so, the challenge of creating U3 applications isn’t too taxing, and the potential is enormous. As U3 devices grow in size (currently 1Gb costs less than £15), it could become the only platform we need.

Harry Fairhead is the author of various books and articles on computer architectures. His current interests include systems and embedded programming.

You might also like...



Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“It works on my machine.” - Anonymous