VirtualBox schafft 16GB RAM, mehr ist nicht enstellbar und nicht spezifiziert. Läuft, aber das reicht nicht für das Preprocessing. Eine Anfrage im VirtualBox Forum ergab, dass es wohl einen Patch für das Heraufsetzen der RAM-Grenze gibt, aber das ganze auf der angealterten RHEL5-Plattform nicht trivial ist und letztlich nach stundenlangem Compilieren auch fehl schlug.

Auf Anfrage teilte mir vmWare mit, dass ihr vShpere das kann, ich aber die Befürchtung hatte, dass die Software so tief in das System reingreift, dass danach nichts mehr von dem Rechenknecht übrig ist, und die nVidia-Dualhead-Grafikkarte mit closed Source Treiber und andere Spezialitäten auch nicht mehr funktionieren.

Und mitten in der Depression hatte ich die Idee, mir die VirtualBox-Konfigurationsdatei des Windows-Gastes zunehmen und dort statt der 16GB eben 64GB RAM einzutragen. Klappte. Und beim ersten Testlauf hat der Windows-Gast auch mehr als 30GB Speicher belegt. Und lief ohne Absturz durch. Nun stehen noch ein paar ausführlichere Tests mit dem FEM-Preprozessor an, aber es sieht aktuell gut aus. Und das Problem der RAM-Begrenzung scheint auch nur virtuell zu sein.

Update: Ein ausführlicher test hat nun ergeben, dass Windows die 64GB RAM wahrnimmt und sie laut Taskmanager auch nutzt, aber das trotzdem nicht korrekt funktioniert. Jedenfalls ist der Windows-Gast (erwartungsgemäß) instabil und hat auch einmal den Neustart des Hosts erfordert. Schade! Fazit: Rollback.

Es dauerte 15min und zwei Reboots (!!), bis ich die Aktion bereute. Beim Kaspersky fror mir jedes mal nach spätestens 5min der gesamte virtuelle PC ein. Wenn ich Outlook startete (dafür habe ich den virtuellen PC hauptsächlich), dann lies sich die Zeit bis zum Showdown noch gut verkürzen. Ich habe dann versucht, die 5min zu nutzen, um den Virenscanner wieder zu deinstallieren, aber auch das klappte nicht. Bei 90% Deinstallation fror er ein. Grrrrrr.

Ein Wiedereinspielen der virtuellen WinXP-Harddisk aus dem Backup rettete mir die Situation. Danke sbackup! Das dauerte ~30min. Immer noch besser als beim Wiederaufsetzen eines echten PCs. ;)

Bei heise online war heute morgen zu lesen, dass Windows 7 RC1 zum freien Download bereit steht. Eigentlich ist es ja nicht meine Spielwiese, aber ich wollte mal wissen, ob Microsoft Lehren aus der Vista-Verweigerung der Microsoft-Kundschaft gezogen hat…

So lud ich mir binnen ~45min das 2.3GB-Image herunter und warf VirtualBox an. Und nach weiteren ~45min lief ein “Windows 7 Ultimate” auf meinem betagten Notebook. War insgesamt nicht schwer. Schwer ist es allerdings, nun neben einer laufenden Windows7-Sitzung noch was anderes zu machen. Mal sehen wie sich “das Neue Windows” anfühlt und ob ich einen Schalter finde, Eye candy abzuschalten und einen “netbook-taugliche” Version zustande zu bekommen.

Später mehr …

Mittlerweile habe ich ein volles Laufwerk C: (Allein für einen Lotus Domino Administrator gehen inkl. Mail-Datenbank ~1GB “verloren”). Nun war Handeln angesagt. Leider ist es m.E. nicht möglich, eine virtuelle Festplattendatei (VDI) mit VirtualBox-Bordmitteln zu vergrößern. Aber das war kein Problem.

Ich legt ein neues VDI-File mit 10GB Platz an (dynamisch wachsend), holte mir die [GRML-Live CD (medium)](http://grml.org/download/) und legte eine neue virtuelle Maschine an. Diese bootet von dem LiveCD-Image und bindet das bisherige Windows-VDI-File (als /dev/sda) sowie das neu angelegte VDI-File (als /dev/sdb) als Festplatten ein. Diese virtuelle Maschine wird gestartet und dann im GRML-Linux der Inhalt der bisherigen “Platte” au die neue “Platte” kopiert:

dd if=/dev/sda of=/dev/sdb bs=512

Nach ~15min war das erledigt. Nun kann der virtuelle GRML-Rechner wieder heruntergefahren werden.
Nun muss die Partition in der neuen virtuellen Festplatte noch vergrößert werden.

Als nächstes habe ich also die neue Platte zu dem bestehenden virtuellen Windows-PC als “Primary Slave” hinzugefügt und die virtuelle Maschine gestartet. Nun eine DOS-Box im virtuellen Rechner öffnen und mit diskpart die Partition vergrößern:


c:>diskpart
diskpart> select disk 1
diskpart> select volume 2
diskpart> extend
...
diskpart> exit


Nun kann der virtuelle Windows-Rechner herunter gefahren werden. Das bisherige VDI-File wird ausgehängt und statt dessen das Neue als “Primary Master” angemeldet.
Fertig.

PS: Ich hätte statt der GRML-LiveCD natürlich auch eine [GParted-LiveCD](http://gparted.sourceforge.net/livecd.php) nehmen können und mir damit die Basteleien mit diskpart erspart. Allerdings hinterlässt GParted ein modifiziertes NTFS-Image mit dem Dirty-Flag und beim nächsten Windows-Start spring checkdisk an. Und ob ich das Ganze dann in 30min geschafft hätte…

Abhilfe schaffte das Einsetzen des Schalters -dontusemixedcaseclassnames in der Proguard-Konfiguration, und schon macht Proguard bei der 27. Klasse eines Packages mit "aa.class" weiter. Das sollte m.E. Voreinstellung sein!

Einen interessanten Workaround fand ich bei http://osdir.com/ml/java.sun.kvm/2003-09/msg00083.html :

If you have more than 26 files,create another package and place the rest 26 files and so on.

Klasse!

Heute kam eine interessante – und gleichzeitig gefährliche – Mail mit dem Betreff "Important update from Microsoft Windows XP/2003 Professional Service Pack 2 (KB946026)" rein. Absender war angeblich der Microsoft Update-Service.

Da ich kein E-Mail-Abo dort angemeldet habe und die E-Mail irgendwie anders als übliche Micorsoft-Mails aussah, habe ich sie mir genauer angeschaut…

• Den Knowledgebase-Artikel KB946026 gibt es wirklich, er hat aber nichst mit dem Betreff der E-Mail zu tun, sondern ist ein Sicherheitsupdate für Windows Vista, nicht für Windows XP/2003.
• Die Download-Datei im KB946026 heißt Windows6.0-KB946026-x86.msu statt WINDOWS-KB946026-X86-ENU.exe
• Der Download wird bei Mircosoft nie von der Seite http://hadco.net/ bereitgestellt (wie in der Mail geschehen)
• Der Absender nennt sich Micrisoft Corporation 2008 © – sieht nur so ähnlich aus wie der große Konzern

Unterm Strich ist es ein geschickter – und für Laien gefährlicher – Versuch Krimineller, den Anwender seinen Virus, Trojaner oder sonstige Schadsoftware selbst installieren zu lassen und den Rechner unter fremde Kontrolle zu bringen.  Hände weg von dem Update!

Gerade habe ich ein wenig mit Launch4j (http://launch4j.sourceforge.net/) experimentiert. Es ist ein (sehr leichtgewichtiger) Wrapper für Jar-Aufrufe, d.h. es verpackt ein Jar in einer ausführbaren Windows-Datei (exe), wobei man einige sinnvolle Einstellungen vornehmen kann, z.B.:

• Programm-Icon und Splash,
• Programmname, der auch im Taskmanager auftaucht (statt "java"),
• Verweis auf eine JRE, die automatisch zur Ausführung genommen wird,
• Main-Class, Classpath-Einträge und Kommandozeilenargumente des Jars,
• Registry-Einträge,
• ...

Alle notwendigen Ressourcen werden in eine Exe gepackt, man muss dann nur noch eine JRE hinzupacken und alles zippen – fertig ist die Dist. Und der Overhead ist gering (in dem Zip-Archiv ist noch die 1.4er JRE enthalten):

# l myapp*<br />-rw-r--r-- 1 drue users 13983944 2008-03-18 16:42 myapp-1.0.zip<br />-rwxr-xr-x 1 drue users&nbsp; 1892105 2008-03-18 16:41 myapp.exe*<br />-rw-r--r-- 1 drue users&nbsp; 1858825 2008-03-18 16:41 myapp.jar

Hier ein Beispiel für die Konfiguration, alles XML (ich habe die Launch4J-Dateien im Untervereichnis lib/launch4j abgelegt):

&lt;launch4jConfig&gt;<br />&nbsp; &lt;dontWrapJar&gt;false&lt;/dontWrapJar&gt;<br />&nbsp; &lt;headerType&gt;gui&lt;/headerType&gt;<br />&nbsp; &lt;jar&gt;myapp.jar&lt;/jar&gt;<br />&nbsp; &lt;outfile&gt;myapp.exe&lt;/outfile&gt;<br />&nbsp; &lt;errTitle&gt;My launch4J app&lt;/errTitle&gt;<br />&nbsp; &lt;cmdLine&gt;&lt;/cmdLine&gt;<br />&nbsp; &lt;chdir&gt;.&lt;/chdir&gt;<br />&nbsp; &lt;priority&gt;normal&lt;/priority&gt;<br />&nbsp; &lt;downloadUrl&gt;http://java.com/download&lt;/downloadUrl&gt;<br />&nbsp; &lt;supportUrl&gt;&lt;/supportUrl&gt;<br />&nbsp; &lt;customProcName&gt;true&lt;/customProcName&gt;<br />&nbsp; &lt;stayAlive&gt;false&lt;/stayAlive&gt;<br />&nbsp; &lt;manifest&gt;lib/launch4j/manifest/xp-themes.exe.manifest&lt;/manifest&gt;<br />&nbsp; &lt;icon&gt;resources/myapp.ico&lt;/icon&gt;<br />&nbsp; &lt;jre&gt;<br />&nbsp;&nbsp;&nbsp; &lt;path&gt;jre&lt;/path&gt;<br />&nbsp;&nbsp;&nbsp; &lt;minVersion&gt;1.4.0&lt;/minVersion&gt;<br />&nbsp;&nbsp;&nbsp; &lt;maxVersion&gt;&lt;/maxVersion&gt;<br />&nbsp;&nbsp;&nbsp; &lt;jdkPreference&gt;preferJre&lt;/jdkPreference&gt;<br />&nbsp; &lt;/jre&gt;<br />&nbsp; &lt;splash&gt;<br />&nbsp;&nbsp;&nbsp; &lt;file&gt;resources/splash.bmp&lt;/file&gt;<br />&nbsp;&nbsp;&nbsp; &lt;waitForWindow&gt;true&lt;/waitForWindow&gt;<br />&nbsp;&nbsp;&nbsp; &lt;timeout&gt;60&lt;/timeout&gt;<br />&nbsp;&nbsp;&nbsp; &lt;timeoutErr&gt;true&lt;/timeoutErr&gt;<br />&nbsp; &lt;/splash&gt;<br />&lt;/launch4jConfig&gt;

Für die Konfiguration wird auch eine GUI mitgeliefert. Der Screenshot ist unten angehängt. Die JRE wird im Unterverzeichnis JRE erwartet.

Die Integration von Launch4J in ein Java-Projekt mit Ant und build.xml ist auch ganz einfach. Launch4J bringt einen Ant-Task mit, der im Build-Skript angemeldet werden muss:

&lt;target name=&quot;exe&quot; depends=&quot;jar&quot; description=&quot;Create a selfcontaining executable&quot;&gt;<br />&nbsp;&nbsp; &lt;taskdef name=&quot;launch4j&quot; classname=&quot;net.sf.launch4j.ant.Launch4jTask&quot;<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; classpath=&quot;${launch4j.dir}/launch4j.jar:${launch4j.dir}/lib/xstream.jar&quot; /&gt;<br />&nbsp;&nbsp; &lt;launch4j configFile=&quot;${basedir}/myapp.xml&quot; /&gt;<br />&lt;/target&gt;

Nun gibt es ja noch das EclipseNSIS-Projekt zum Erstellen eines Installers für Eclipse-Anwendungen. Der Launch4J-Ansatz kann gewählt werden, wenn für das Projekt kein Installer benötigt wird und der Aufwand für Entwicklung und Testen der Installation so minimal bleibt. Mit Launch4J liefert man ein Zip-Archiv. Und das war in einer Stunde erstellt.

I’m running a (single) Windows 2003 server. Recently I logged into this machine to see how it works and was greeted by the Update dialog box and it’s message that I could upgrade to Internet Explorer 7 on this machine.

I felt it was a good idea, because a I did hope that upgrade would remove some security annoyances of IE under Windows Server 2003.

But after the upgrade of the web browser I got the message that the server has to be rebooted! I wonder if there is a Windows server out there with an uptime of more then four weeks. :-/

So I found PortableApps – an very promissing suite of portable applications (I wanted firefox with some extensions, a ssh client and an useful editor). Installation was as easy and simple as downloading a 30MB file from their website (the project is hosted on sourceforge.net) and runing the application. It asks for the destination directory – the stick – and copies all neccessary files there. Ready! Additional applications can be installed the same way.

After starting the launcher (an autorun.inf file on the stick starts the launcher if enabled) it resides in the systray. Cool!

As my personal security feature I backed up the stick and can reset it after every usage in an insecure environment (as the class room of a training center is). PortableApps comes with a facility to backup your personal data from a stick or restore them again.

And a last remark: There are plenty of other application suites available. And you can install a lot of portable applications directly (without an application suite as PortableApps) as well.

• It is not possible to store the individual backup files next to each other. All backups are stored in one single file (don’t think about the consequences of a single read error when opening the file) or one backup replaces the previous backup with the same file name.
• It’s not possible to define any measures to manage the space on the backup media an remove older backups depending on their age or the used space on the backup media.
• It is not  possible to define a sophisticated backup policy: only full OR incremental OR differential backups are possible.
• ...

So I decided to install Perl (because Perl is my scripting language of choice) on the server and write a small script that does exactly that. It renames the backup file (originally named backup.bkf) and appends the timestamp to the file name. It also observes the free space on the backup media and deletes the oldest backups so that a certain amount of disk space is assured for the next backup run. To keep the script simple the path to the backup folder, the available disk space and the required free disk space (depending on the size of one backup file). I run this script as a "planned task" one hour before the ntbackup task will run. Its working without problems on a server for about 6 months.