Category: General

VirtualBox – my current favourite desktop virtualisation software – has been released in version 3.0.0 two days ago, so I gave it a try. The most interesting new feature in this new version is the “Guest SMP” support. It finally removes the limitation, that a guest can only work on one host core (which means, when you have a 4-core host CPU, the guest could only run with 1/4 of the speed).

The documentation is not very clear about what “Guest SMP” really does – it could, for example, just show multiple CPUs to the guest, but still only use one host core. To make sure that my assumption of VirtualBox 3 actually making it possible to assign multiple host CPUs/cores to the guest, so that it can actually run faster, I did a quick test. I started by making one of my Linux VMs a dual CPU VM:

In the VM, I then started to build the Linux kernel, once with make -j1 and once with make -j2. This is my CPU usage monitor on the (2-core) host, which shows both cores’ usage combined:

In section 1 of the graph, only one compiler process is running (make -j1). At the end of section 1 I aborted the building process and (in section 2) I typed in make -j2. Thus, section 3 shows the CPU usage when two compiler processes are running simultaneously in the VM. So my assumption was correct, it is now possible to make all of the host’s processing power available in a VM.

Thanks, VirtualBox team! (I won’t address the company behind VirtualBox, since this would probably cause my post to be outdated before I can press the “Publish” button). Lets just hope that this great project will see further development, it is currently the best desktop virtualisation project available, in my opinion. It would be even greater if all of the functionality was available in the Open Source version though. This would ensure that, no matter what the current company behind VirtualBox decides to do with it, development could go on.

Ich verwende seit Jahren unter Linux (X11) eine .Xmodmap-Datei die mir ermöglicht, stressfrei deutsche Umlaute zu schreiben: Drücke ich [Windows]-[o] bekomme ich ein ö. Brauche ich ein Ö, drücke ich [Windows]-[Shift]-[o]. Ein ß gibt’s mit [Windows]-[s]. Das funktioniert hervorragend, nach wenigen Tagen hatte ich mich daran gewöhnt – und die Windows-Taste ist nun endlich mal für etwas gut 🙂

Da ich mich seit längerem im Ausland aufhalte, treffe ich viele Deutsch-Schreibende die auf amerikanischem Tastatur-Layout schreiben. Darunter sind (leider) auch viele Windows-Benutzer. Alle diese Personen umschreiben die Umlaute mit “oe”, “Oe”, “ss”, etc.

Also habe ich heute mal recherchiert, ob es nicht doch eine Möglichkeit gibt, diesen Personen zu Umlauten zu verhelfen. Die offensichtlichste Möglichkeit ist natürlich, auf Linux umzusteigen und meine .Xmodmap zu verwenden. Aber das ist eher etwas längerfristiges, und viele sind dafür einfach zu unflexibel…
Es gibt jedoch noch eine andere Lösung, dank der unter der GPL stehenden Software AutoHotKey. Ungewohnt schön (für Windows-Programm-Verhältnisse) an dieser Software ist, dass sie sogar einen “Compiler” mitbringt, der aus der Tasten-Mapping-Definition eine ausführbare Datei erstellt.

Die AutoHotKey Mapping-Definition (.AHK Datei), die zu meiner gewünschten Funktionalität führt, sieht so aus:

+#a::Ä
#a::ä
+#o::Ö
#o::ö
+#u::Ü
#u::ü
#s::ß

Sehr wichtig dabei ist, dass die Datei ANSI-codiert gespeichert wird, weil AutoHotKey wohl nichts mit Unicode anzufangen weiß. Wenn man sich allerdings (wie ich während meiner Recherche) auf einer Windows-Installation befindet, deren Non-Unicode program locale keine deutschen Umlaute im erweiterten ASCII-Bereich hat, ist das nicht sonderlich einfach zu bewerkstelligen. Man kann die Datei nicht ohne Weiteres mit Windows-Bordmitteln ANSI-codiert abspeichern, sofern man nicht die Locale auf Deutsch (oder irgend eine andere Sprache bei der die o.g. Umlaute im erweiterten ASCII-Bereich vorkommen) umstellt. Und danach ist natürlich Neustarten angesagt – wie könnte es auch anders sein…

Mit etwas Vertrauen in mich kannst du aber auch einfach meine umlauts.exe herunterladen, die ich mit AutoHotKey erstellt habe. Nach dem Ausführen befindet sich das AutoHotKey-Logo im System-Tray und man kann Umlaute wie oben beschrieben tippen. Ich habe keine Trojaner oder sonstige Schädlinge eingebaut (zumindest nicht wissentlich).

Update (2009-05-17): Es hat sich herausgestellt, dass diese ganze Sache in GTK-für-Windows-Anwendungen wie Pidgin nicht funktioniert. Ich habe nun einen Workaround gebastelt, der in Pidgin funktioniert – aber schön ist was anderes. Die AHK-Datei ist dadurch etwas länger geworden: umlauts.ahk

Die umlauts.exe habe ich aktualisiert.

Update (2010-03-12): Als (verspätete) Reaktion auf jan und Daniels Kommentare habe ich nun das Script umlauts.ahk verbessert, und auch eine neue umlauts.exe gebaut. Ich verwende weiterhin die [Windows]-Taste. AltGr ist keine Option, da es diese Taste auf vielen Tastaturen (z.B. US-Layout) nicht gibt.

Update (2011-04-09): Auf mcmusics Wunsch habe ich eine Version erstellt, die zusätzlich noch die Y und Z Taste vertauscht, für Leute die sich schwer tun, sich an diese Vertauschung beim QWERTY-Layout zu gewöhnen. Hier ist das umlauts-yz-swapped.ahk Script, und hier die umlauts-yz-swapped.exe.
Übrigens, beim Herunterladen von AutoHotKeys habe ich gesehen, dass es jetzt eine neue Version gibt, die auch mit Unicode klarkommt – vermutlich ist es damit möglich, eine umlauts.exe zu bauen, die auf den Clipboard-Hack verzichtet. Kann ja mal jemand mit mehr Zeit testen und dann hier berichten.

Update (2012-02-14): Die alte umlauts.exe funktionierte in Lotus Notes recht unzuverlässig: Manchmal kam der richtige Buchstabe (vor allem beim ß), aber manchmal kam irgend ein anderes Sonderzeichen. Daraufhin habe ich mal versucht, das selbe Script mit dem neuen AutoHotKey L (mit Unicode-Unterstützung) zu compilen, und nach einer Konvertierung des Scripts nach UTF-8 hat das auch gleich perfekt funktioniert. Bisher konnte ich damit in Lotus Notes noch keine Fehlfunktion feststellen. Der Clipboard-Hack ist übrigens für GTK-Anwendungen weiterhin notwendig. Die UTF-8-Variante des AHK-Scripts gibt’s hier: umlauts2.ahk, und gebaut als EXE (nun knapp 800 anstatt früher 200 KB) hier: umlauts2.exe.

Update (2013-01-04): umlauts2.exe funktionierte nicht mehr in Thunderbird, weil Mozilla die Window Class geändert hat. Ich habe nun den Check auf die Window Class rausgeworfen, und benutze immer den Umweg über die Zwischenablage, was bisher in allen getesteten Programmen zuverlässig funktioniert hat. Weiterhin habe ich [Windows]-e mit dem Euro-Zeichen (€) belegt, und [Windows]-y mit dem Yuan/Yen Zeichen (¥). Zu guter Letzt habe ich den Code etwas umstrukturiert und kommentiert. umlauts3.ahk, umlauts3.exe