 Hello. Yes, it works. Excellent. So, like I said, my name is Stephen. I'm a first-year math student at the University of Warwick in the UK. And in my spare time, I'm both a developer and a moderator on portableapps.com. I'm just going to give you a quick introduction to our platform. You might have heard of us because we won the SourceFillage Best Project of the Year last year. And I suspect a number of you use our software to get around whatever crazy limitations your administrator puts on your PC wherever you work. So, before I get started, what is a portable app? It might not be what you think. I'm not, at the moment, talking about a program that runs on both Windows and Linux and Mac, or one that runs on X86 or ARM or MIPS. I'm talking about one that runs for you installed onto some mass storage device. And as you take it between PCs, it keeps its settings and your bookmarks, in the case of a browser, and allows you to take them basically wherever you work. And even if your device changes drive letter on Windows, for example, that it's going to keep going. And also that it's not going to leave files and folders and registry entries basically everywhere you go so that you just leave a mess everywhere. PortableApps.com, we were originally founded in 2005 by our developer lead, John T. Haller, from New York. Although before that, we actually existed on the MozillaZine forums, there were a few others hanging about. And we actually started with a portable version of Firefox, which is still easily our most popular app. Although currently we have about 90, 90 programs of both open source and freeware in our directory. And that's actually expanding all the time. We've had over 100 million downloads with a rough three to five million users worldwide. It's hard to get a sure number on that, but we've actually got over 100,000 registered users on our forums. But our main focus really is the platform. And that's what I'm going to be talking about. We've recently expanded into freeware as well. So this being false, it's the free and open source. So we do freeware and we're probably quite unusual here in the fact that our main platform is Windows, but we actually fully support Wine as well. If you've got any Linux developers who would like to help us become more platform neutral, I'd love to talk to you at the end and I'm sure we can sort something out. So the platform, we have four components. The menu, format, the installer and the actual launches themselves. And I'm going to give you a brief, brief run of each of those. The platform, where's the wrong one? So the platform, the menu rather is probably the least interesting part to you guys. But it's actually what the users see most of the time. You can see a screenshot of version 1.6, which was released last week on the right hand side. We've got a couple of applications pinned to the top, Firefox and Thunderbird and OpenOffice, Pigeon. We do Inkscape and things like that as well. It's got built-in functions for adding and removing applications, backing up data using the format, which I'll talk about in a minute, integrates fully with the installer, themes. There's actually quite a thrive, a fright. There's a big theme community as well and a huge localization attempt. We're currently in 51 languages for the menu, so basically whatever you speak, you can probably have it in your language. Like I said, 1.6 was released last week. We've got 2.0 already in beta testing, and we're hoping that should incorporate an update similar to apt. So you can grab new apps from the website and update the ones you've already got completely painlessly. So the format is kind of the main way that it all works on the top level. So this is involved, so you replace this with the name of your program. In the case of Firefox, we've got Firefox Portable. In the top level directory, you have Launcher, which I'll talk about in a minute, and the Help file. And then all our applications are split into these three folders. App is where you've got AppInfo, which literally has a couple of files that I'll also talk about. And they describe your program so that the menu can show up properly, and they describe the installer, so the installer generated can create it properly. AppName, in the case of Firefox, is Firefox. The key with this is that it's an exact binary copy of your normal installation. So we've actually got an exact copy of Firefox in there, or an exact copy of Thunderbird. The idea being that when you update your program, if the Portable version isn't updated at the same time for whatever reason, the users can literally grab your normal installed version, extract it, drop it straight in there, and as long as you haven't made too many changes to your program in the way it says it's settings, it should work no problem at all. Default data being in an oval is optional. For example, with Firefox, Firefox does require a profile to be there when it's run, but the data folder, when we package stuff up in the installer, the data folder is left intentionally empty, so it doesn't overwrite anything with the users. So basically, your launcher on first run checks to see if there's anything in the data directory, and if there's not, it copies it straight over from the default data. As I mentioned, data is normally, when you package stuff up in the installer, it's completely empty because overwriting user settings is never, ever a good thing at LHE. And then the other folder, which kind of is just other, really. There's help file, and because we're GPL, we've got source and stuff like that in there. Just odd bits and pieces that don't really fit anywhere else. The installer. The installer's quite nice in that you get it for free once you're in the format. Once you're in the format, you can run the installer creator, and it'll create your installer. It's for all open source and freeware at the moment because it's GPL with exception, and if you contact us, it can be used commercially as well. The idea being that you can sit down there, it automatically searches for the platform when you run the installer so it fails in the right directory for the user so they have as little to do as possible. And we're actually built on NSYS, the installer language NSYS, by Nullsoft, the people behind Winamp. And the idea behind that is that actually it gives us an incredibly small footprint in the order of kilobytes and allows us to have customizations in there, like optional components and things like that. Install is actually more widely translated from the menu with 58 languages. And I'll talk a little bit more about that in a minute. Here we go. So appinfo.ini and installer.ini are basically the two files that describe your program to the platform. On the right-hand side, you can see a copy of the appinfo.ini file from the program I work on to. Appinfo.ini literally describes to the menu your program. It tells it what version for the app data, your home page. So you can easily visit that, a brief description and various other names like that. For example, if your program has multiple Xs, you can get them all to share up in the menu if you want, or only one or two of them with various icons as well. So that basically describes that and also language so that when you run your program from the menu, you can have it start in the correct language. Installer.ini is basically exactly the same except it describes stuff for the installer, so specifying optional components and languages. There's not really a lot of point having your installer translated into a random language if your user then runs the program and finds it's not actually in their language at all. It's kind of off-putting for everyone and makes people unhappy. The launcher. The launcher is kind of the main focus of the platform. And at the moment, it's the most variable part. So the launcher is what makes your app run in a portable fashion. And because all programs are different, they obviously vary an awful lot. So for example, if you've got a program that's been designed to run in a portable fashion, you'll find that actually all you need to do is run it and then exit and everything carries on all right. In some other programs, for example, you might have to tidy up registry entries after the program is finished or tidy up settings, move them to the USB drive if they're saved automatically on the local PC, stuff like that. We also write these in NSys. You can see a short section from the Firefox one there. It's probably one of our more complex examples, although actually in the last week or so, we've taken a very similar, similarly to the way the installer and the platform are specified with the ENI files. We've now actually got a universal launcher that's currently in alpha testing. The idea being you fill in another file that basically says, my program writes to the registry here, here and here, and it says it's settings here and there. And it'll basically create a launcher for you that tidies it all up afterwards. The idea being that by reducing the number of launches we've got, we can clamp down on bugs basically. So that's kind of that. NSys again is used because it's got a really small overhead. The main problem with NSys is that it isn't cross-platform, and that is something that is actively being looked at because it is a problem. You're probably all working on some apps that you might have a Windows build. If you did, it would be good. There's a number of changes you can actually make to make your app run in a more portable fashion. By accepting a command line or an environment variable, just something that says, please save your user settings here, then that is basically the number one thing you can do to make portable apps users happy. By taking, say, a command line path, you can say your launcher will then pass it the correct path, the correct location, your program will save it, and your users won't then have to copy your files across when your program is finished running, which is good. Making the registry optional, if you're very Windows focused or if you have a Windows port is good. If you use Q or WX widgets, there's specific ways of doing config files, and it'll manage those automatically for you without any problems, basically using the path you've been passed in and stuff. If possible, with your language, reduce the number of requirements, statically, if you use C++ is also good because, you know, DLL hell is a big problem still. Also, stuff like making sure your program is friendly after being put through a compressor like UPX can make a big difference. Drives, unfortunately, although flash memory is still very cheap, you do have users who do try and fit as much as they possibly can on the 32-megabyte stick they got free some years ago, and the more apps they can fit on there, the better. So we do use things like UPX to compress X's. If your program is friendly that way, it's also good. I'm kind of at the end, to be honest. If you've got any questions, I'm going to be here most of the rest of the weekend. The forum is a great place. Like I say, we've got about 100,000 registered users of which there's a fair proportion of people who have actually written and launched themselves programs. So there's a lot of knowledge out there. We have a pretty active IRC channel as well. There's always people to talk to on there. And that's about it. So if there's any questions, I'll either take them now or I'll be down there afterwards. Thank you.