One of the more common questions is how to run Wuala as a Windows service. There is a thread describing how to run Wuala as a scheduled task which may satisfy some people – but let’s face it: You probably want a real service, you know, one you can control through “net start” and “net stop”.

Setting up your own services on Windows is pretty easy these days. You either shell out squid for FireDaemon or go the free way with srvany. If you don’t like fiddling around with software this piece of software may interest you. It is a simple service wrapper for Wuala written in C# that installs a new service called wuasrv and starts/stops the client software accordingly.

Installation is dead simple:

– Configure Wuala (i.e. check the “remember password” box)
– Unpack WualaService
– Edit WuaSrv.xml and alter path to point to your wuala.exe
– Run ServiceInstaller.exe
– Open the Windows service manager, select the Wuala service, go to it’s properties and change the account it runs under (running Wuala under SYSTEM account may not be such a great idea)
– Start the service and rejoice.

Configure Wuala to auto-login and enable the Dokan integration to get your W: drive right at boot 🙂 .

I’ll post the source-code to the programs later on, so enjoy 🙂 .

So, I decided to re-install my laptop today.

One thing that got me curious: The NX Client and Sandboxie started showing strange phenomenons.

Sandboxie couldn’t quick-restore files from the sandbox (permission denied error) and the NX Client couldn’t find the default key.

Turns out that both problems have the same root: Cygwin.

After some tries with Try & Decide I pinned down the problem to E Texteditor’s integrated Cygwin installation. Even using the official Cygwin setup and standard install wouldn’t help.

The quick fix for this is to not use an external Cygwin installation in conjunction with these two programs.

Quite a bummer. If anyone has a better fix, feel free to leave me a comment 🙂 .

As you might be aware, I’m a big fan of programs like Fraps or Gamecam. Especially Fraps is a great tool, it works as a FPS benchmark, video capturing program and… no, that’s it.

Gamecam has a similar set of features including an in-game overlay UI that always warns me to not use Steam overlay and Gamecam.

My biggest gripe is that both tools drag down the FPS so much when recording. Of course, a little loss is to be expected. There is a lot of I/O work being done behind the scenes. That’s no excuse for limiting my FPS to the set frame-rate of the video, though.

Fraps has somewhat acknowledged this as a “not-so-nice” thingy and thus you can allow higher frame-rates with newer versions of the software. Now it is debatable whether this really works as intended, the internet is a vast place and many forum posts state that there is no change (my sentiments exactly); recording at 30fps still drags down the game to 30fps, recoding at 60fps keeps the game at 60fps. So there’s no performance issue but… well, I don’t know.

That’s where the Japanese (but available in English) program Dxtory comes in: Dxtory does screenshots, videos, benchmarks and has a broad set of great features many people long wanted for Fraps. You can define multiple save locations and measure their speed, you have the possibility to select two distinct audio recording sources and – most importantly – you have a broad range of options for configuring the video capture. Of course, you’re not very impressed yet.

Well, while Fraps and Gamecam drag down the in-game frame-rate, Dxtory keeps the rate stable while recording. Yep, enjoy your Pangya at whooping 200fps while recording a 30fps video.

Which brings me to another great point: You can create profiles for specific applications. All the settings are configurable per application.

If you don’t know whether Dxtory is for you or not you can grab the free trial from the homepage. There is no time restriction for trial recordings (another great thing over Fraps), so test it to your heart’s content. A license costs 3600 Yen which is about 30 Euros.

Yesterday I mucked about MonoDevelop, part of my reasoning being MonoDevelop presumably failing while compiling my perfect, non-errorous Vala code.

Shame on me, though: The blame is entirely mine, respectively my inability to check first and whine later.

So, what happened? Build yourself a nice crashing Vala application that should send something out to the console before biting the dust. Now build it on Debian Squeeze. Run and check. Well, it certainly does print it’s dying message.

Now repeat the same experiment on Ubuntu 10.4, lo and behold: You won’t see the message.

This is the point where reasonable people would simply check the strings in the produced binary. Didn’t think of doing that, mea culpa; you’ll see the strings are present in the file but not being displayed (ergo: There’s no problem at all, just some unexpected behaviour).