Diese Artikelserie zeigt auf, wie man unter Windows eine Entwicklungsumgebung mit Open Source basierten Programmen erstelllt und darin Programme und deren Abhängigkeiten kompiliert. Die daraus entstehenden Dateien können unter Windows wie normale Programme verwendet werden.

In diesem Teil wird die erste Abhängigkeit von DOSBox kompiliert. DOSBox bietet z.B. die Möglichkeit CD’s mit Audio Tracks so einzubinden, dass statt der originalen, unkomprimierten WAV Dateien komprimierte MP3 oder OGG Dateien verwendet werden können. Um nun die Unterstützung hierzu nicht komplett neu programmieren zu müssen, haben sich die Programmierer an bestehenden Projekten bedient. Hierdurch ist die Arbeit der Programmierer zwar weniger geworden, derjenige welcher den Quelltext kompiliert, muss aber auch die benötigten Abhängigkeiten zuerst herunterladen und kompilieren.

Eine solche Abhängigkeit ist z.B. Simple DirectMedia Layer (SDL). Simple DirectMedia Layer ist eine plattformübergreifende Multimedia Bibliothek welche low level Zugriff auf Audio, Keyboard, Maus, Joystick, 3D hardware via OpenGL, und 2D Video Framebuffer zur Verfügung stellt.

Zuerst wird das SDL-1.2.13.tar.gz Paket in das Homeverzeichnis der MSYS Umgebung heruntergeladen.

Um SDL unter Windows zusammen mit DOSBox nutzen zu könenn, müssen einige Quelltextdateien angepasst werden. Da sich hierzu im DOSBox Quellcode bereits ein Patch File findet, wir zusätzlich das Archiv dosbox-0.72.tar.gz heruntergeladen.

Beide Archive werden nun entpackt und SDL wird gepatcht.

tar xvzf dosbox-*.gz
tar xvzf SDL-1.*.tar.gz
sed -e "s/VERSION 1,2,12,0/VERSION 1,2,13,0/g" \
-e "s/@@ -13,7 +13,7 @@/@@ -12,7 +12,7 @@/g" dosbox-0.72/src/platform/sdl-win32.diff >sdl-win32.diff
rm -fr dosbox-0.72
cd SDL-1.2.13
patch -p1<../sdl-win32.diff
cd ..

Achtung, patch wird eine Fehlermeldung bringen.

Aus irgend einem Grund kann die Datei src/main/win32/version.rc nicht gepatcht werden. Da in dieser Datei lediglich ein Zeichen verändert werden muss, öffnet man diese Datei am besten mit einem Texteditor (nicht Word!!) der UNIX Zeilenumbrüche versteht (z.B. Notepad++). In der Datei src/main/win32/version.rc sucht man nach FILEFLAGS 0x0L und ersetzt dies durch FILEFLAGS 0x4L

Als nächstes werden die DirectX Header Dateien heruntergeladen und entpackt, damit SDL diese nutzen kann.

Zum Schluss wird alles entpackt, SDL kompiliert und die erzeugten Dateien installiert.

cd
tar xvzf directx-devel.tar.gz -C /mingw include
mkdir SDL-build
cd SDL-build
../SDL-1.2.13/configure --prefix=/mingw && make && make install
cd ..


Nach dem kompilieren findet man in /mingw/bin die Datei SDL.dll vor. Auf diese wird später DOSBox referenzieren.

Im sechsten Teil dieser Artikelserie wird die libpng kompiliert, welche unter anderem für die Erzeugung von Screenshots in DOSBox benötigt wird.

Diese Artikelserie zeigt auf, wie man unter Windows eine Entwicklungsumgebung mit Open Source basierten Programmen erstelllt und darin Programme und deren Abhängigkeiten kompiliert. Die daraus entstehenden Dateien können unter Windows wie normale Programme verwendet werden.

In den vorangegangenen Artikeln wurde die Entwicklungsumgebung erstellt. In diesem Teil wird zum ersten mal etwas in dieser Umgebung kompiliert. Um genau zu sein, handelt es sich dabei um die Autotools. Prinzipiell sind diese Programme in der MinGW/MSYS Umgebung bereits vorhanden. Jedoch handelt es sich um ältere Versionen, welche – gerade bei neueren Paketen – immer mal wieder zu Problemen führen können. Aus diesem Grund werden die aktuellsten Autotools aus dem Quelltext erstellt.

Die Autotools sind mehrere Programme, welche vor dem eigentlichen kompilieren diverse Informationen des Systems sammeln. Dadurch ist schon vor dem kompilieren klar, welche Header Dateien oder welche Libraries verwendet werden sollen. Auch können die Autotools ermitteln ob benötigte Abhängigkeiten vorhanden sind.

Anstatt wie bisher die herunter zu ladenden Dateien im Basis-Installationsverzeichnis (D:\Entwicklung\MinGW-MSYS) zu platzieren, sollten diese ab sofort im Home-Verzeichnis der MinGW/MSYS Umgebung gespeichert werden. Die hat zwei Gründe:

1. Man befindet sich nach dem ausführen von msys.bat direkt in diesem Verzeichnis.
2. Das Basis-Installationsverzeichnis befindet sich prinzipiell ausserhalb der MinGW/MSYS Umgebung.

Unter Windows befindet sich dieses Verzeichnis im Pfad (D:\Entwicklung\MinGW-MSYS\MSYS\home\<ANMELDENAME>\). In dieses Verzeichnis lädt man nun alle Pakete der nachfolgenden Tabelle herunter:

Die Pakete werden entpackt und pro Paket wird ein Build Verzeichnis erstellt in welchem die Pakete kompiliert werden. Hierdurch wird im Original Sourcenpfad nichts verändert.

for a in autoconf- automake- libtool-;do tar xvzf ${a}*;mkdir ${a}build;done
cd autoconf-build
../autoconf-2.63/configure --prefix=/mingw && make && make install
cd ../automake-build
../automake-1.10.2/configure --prefix=/mingw && csmake && csmake install
cd ../libtool-build
../libtool-2.2.6/configure --prefix=/mingw && make && make install
cd ..

Auf der MinGW Webseite wird empfohlen, selbstkompilierte Bibliotheken in /mingw zu installieren. Damit zukünftig erstellte Pakete wissen, dass die Bibliotheken hier zu suchen sind, müssen noch einige Einstellungen an der Entwicklungsumgebung vorgenommen werden.

sed -e 's#export HOME LOGNAME MSYSTEM HISTFILE#PKG_CONFIG_PATH="/mingw/lib/pkgconfig"\
CFLAGS="-pipe -O2 -mms-bitfields -march=i686"\
export HOME LOGNAME MSYSTEM HISTFILE PKG_CONFIG_PATH CFLAGS#g' /etc/profile>/tmp/profile
cat /tmp/profile > /etc/profile
rm /tmp/profile

Wenn man nun die MSYS Umgebung mittels exit verlässt und danach nochmals die msys.bat aufruft, ist alles so eingestellt, dass zukünftige Kompilationen die Bibliotheken ebenfalls in der /mingw Struktur suchen.

Im fünften Teil dieser Artikelserie wird die erste Abhängigkeit von DOSBox kompiliert.

Diese Artikelserie zeigt auf, wie man unter Windows eine Entwicklungsumgebung mit Open Source basierten Programmen erstelllt und darin Programme und deren Abhängigkeiten kompiliert. Die daraus entstehenden Dateien können unter Windows wie normale Programme verwendet werden.

Während im zweiten Teil dieser Artikelserie beschrieben wurde wie man die MinGW Entwicklungsumgebung erstellt, wird in diesem dritten Teil beschrieben, wie man die MSYS Umgebung einrichtet.

Wikipedia schreibt zu MSYS

MSYS (Minimal SYStem) ist eine Softwareportierung der Unix-Shell auf die Windows-Plattform. Es dient MinGW-Entwicklern als ein minimales System, welches unter anderem configure-Skripte ausführen kann.

MSYS installiert zum Beispiel eine bash Shell, Komprimiertools wie bzip2 oder lzma und verschiedene andere Programme, welche für eine Entwicklungsumgebung benötigt werden.

Die Pakete der nachfolgenden Tabelle können alle in das Basis-Installationsverzeichnis (D:\Entwicklung\MinGW-MSYS) heruntergeladen werden.

Danach wird MSYS soweit vorbereitet, dass man später die restlichen Tools installieren kann. Zuerst muss hierzu ein MSYS Unterverzeichnis erstellt werden, dann werden die MSYS Kernkomponenten entpackt und zum Schluss ein Installationsscript gestartet. Hierzu gibt man folgende Befehle in der Eingabeaufforderung von Windows ein:

cd /D D:\Entwicklung\MinGW-MSYS\
mkdir MSYS
tar -xvzf msysCORE* -C ./MSYS/
tar -xvzf MSYS-* -C ./MSYS/
cd MSYS\postinstall\
pi
### Nachfolgend die Fragen und Antworten ###
Do you wish to continue with the post install? [yn ] y
Do you have MinGW installed? [yn ] y
Where is your MinGW installation? d:/Entwicklung/MinGW-MSYS/MinGW
cd ..\..\

Wenn alles funktioniert hat, sollte man nun im MSYS Verzeichnis msys.bat starten können und eine Shell erhalten. Ein gcc -v (welches von /mingw/bin geholt wird) sollte genau so funktionieren wie ein mount. Hat alles geklappt kann man die Shell mit exit wieder beenden.

Jetzt kann man die MSYS Umgebung mit den heruntergeladenen Tools Erweitern, bzw. updaten.

cd /D D:\Entwicklung\MinGW-MSYS\
tar -xvzf bash-* -C ./MSYS/
tar -xvzf bzip2-* -C ./MSYS/
tar -xvzf coreutils-* -C ./MSYS/
tar -xvzf cpmake-* -C ./MSYS/
tar -xvzf csmake-* -C ./MSYS/
tar -xvzf diffutils-* -C ./MSYS/
tar -xvzf findutils-* -C ./MSYS/
tar -xvzf gawk-* -C ./MSYS/
tar -xvzf lzma-* -C ./MSYS/
tar -xvzf make-* -C ./MSYS/
tar -xvzf tar-* -C ./MSYS/
tar -xvzf texinfo-* -C ./MSYS/
tar -xvzf crypt-* -C ./MSYS/
tar -xvzf perl-* -C ./MSYS/

Leider wurden die Coreutils in der Version 5.97 falsch gepackt, so dass im MSYS Verzeichnis ein coreutils-5.97 Verzeichnis erzeugt wurde. Darin befinden sich die bin, lib und anderen Verzeichnisse welche eigentlich in das MSYS Verzeichnis installiert werden sollten. Diesen Umstand kann man mit den folgenden Befehlen (welche innerhalb der ausgeführten msys.bat eingegeben werden) beheben:

cd /D D:\Entwicklung\MinGW-MSYS\MSYS\
msys.bat
### Alle folgenden Befehle in der msys Shell eingeben!!! ###
cd /
mv coreutils-5.97/bin/* bin/
### da wir mit mv mv.exe nicht verschieben können, muss
### es kopiert und separat gelöscht werden.
cp coreutils-5.97/bin/mv.exe bin/
mv coreutils-5.97/info/* info/
mv coreutils-5.97/lib/* lib/
mv coreutils-5.97/man/man1/* man/man1/
rm -r coreutils-5.97

Im vierten Teil dieser Artikelserie werden die Autotools installiert. Da diese direkt aus dem Quelltext erstellt werden, wird zum ersten mal die Entwicklungsumgebung ‹live› eingesetzt.

Diese Artikelserie zeigt auf, wie man unter Windows eine Entwicklungsumgebung mit Open Source basierten Programmen erstelllt und darin Programme und deren Abhängigkeiten kompiliert. Die daraus entstehenden Dateien können unter Windows wie normale Programme verwendet werden.

Im zweiten Teil dieser Artikelserie beschreibe ich die Installation einer Entwicklungsumgebung basierend auf dem MinGW Projekt. Eine Entwicklungsumgebung besteht aus einer Zusammenstellung von Programmen und Werkzeugen, welche zur Erstellung beliebiger Software verwendet werden kann. In solch einer Zusammenstellung können z.B. ein Texteditor zum bearbeiten der Quelltexte, ein Dateiverwaltungssystem, ein Kompiler und ein Linker vorhanden sein.

Wikipedia schreibt zu MinGW

MinGW oder Mingw32 (Minimalist GNU for Windows) ist eine Softwareportierung der GNU-Entwicklerwerkzeuge (GCC, GDB) auf die Windows-Plattform, mit der man Programme für Windows entwickeln kann. MinGW entstand aus dem Cygwin Projekt heraus. Es wird, anders als bei Cygwin, keine Kompatibilitätsschicht in Form einer DLL benötigt. Auch kann hiermit entwickelte Software unter Lizenzen veröffentlicht werden, die nicht mit der GNU GPL kompatibel sind.

Prinzipiell kann man einfach den Installer von der MinGW Webseite herunterladen, anklicken und abwarten. Es hat sich jedoch bei mir gezeigt, dass diese Installationsart im späteren Verlauf zu Problemen führt. So wird z.B. MinGW wie auch MSYS in ein und das selbe Verzeichnis installiert. Das sollte bei neueren Versionen eigentlich kein Problem sein. Sollte… Meine Erfahrungen haben gezeigt, dass es besser ist alles von Hand zu installieren.

Vorinformationen

• Da eine Entwicklungsumgebung naturgemäss relativ viel Platz belegt, sollte man sich für die Installation eine Disk aussuchen, welche mindestens noch 4-5GB übrig hat.
• Für alle Installationen in dieser Artikelserie wird von folgendem Basis-Installationspfad ausgegangen:
  D:\Entwicklung\MinGW-MSYS
• Wer sich bereits ein wenig mit der Thematik des kompilierens auseinander gesetzt hat, kann getrost die neusten Versionen aller in dieser Artikelserie beschriebenen Pakete herunterladen. Man muss aber damit rechnen, dass unerwartete Fehler auftreten können. Wer auf Nummer sicher gehen will, sollte genau die in diesem Artikel angegebenen Versionen herunterladen.

Installation und Konfiguration

1. In dem oben angegebenen Basis-Installationspfad werden als erstes alle Pakete aus der unten stehenden Tabelle heruntergeladen.
2. Im Basis-Installationspfad wird vom gzip Archiv bin/gzip entpackt, vom libarchiv die Dateien bin/{bsdtar,libarchive2.dll} und vom Dependencie Paket die beide Bibliotheken bin/{bzip2,zlib1}.dll.
3. bsdtar.exe in tar.exe umbenennen.
4. Innerhalb des Basis-Installationspfades muss ein MinGW Verzeichnis angelegt werden in welchem alle heruntergeladenen Pakete entpackt werden. Hierzu öffnet mein eine Eingabeaufforderung (Start/Ausführen/cmd [Enter]) und gibt darin die folgenden Befehle ein.
   
cd /D D:\Entwicklung\MinGW-MSYS\
mkdir MinGW
tar -xvzf binutils-* -C ./MinGW/
tar -xvzf gcc-core-* -C ./MinGW/
tar -xvzf gcc-g++-* -C ./MinGW/
tar -xvzf gcc-ada-* -C ./MinGW/
tar -xvzf gcc-g77-* -C ./MinGW/
tar -xvzf gcc-java-* -C ./MinGW/
tar -xvzf gcc-objc-* -C ./MinGW/
tar -xvzf mingwrt-*-mingw32-dev* -C ./MinGW/
tar -xvzf mingwrt-*-mingw32-dll* -C ./MinGW/
tar -xvzf w32api-* -C ./MinGW/

Im dritten Teil dieser Artikelserie wird die MSYS Umgebung installiert, welche erst den sinnvollen Umgang mit den Entwicklungswerkzeugen ermöglicht.

1987 habe ich als 10 Jähriger Knirps mit meinem C64 herumgespielt. Eigentlich war zu der Zeit der 386er gerade aktuell, doch von solch einem Rechner konnte ich nicht einmal träumen 😉 Jedenfalls erschien im Jahre 1987 das Spiel Police Quest: In Pursuit of the Death Angel. Ich weiss noch, wie ich damals bei uns im Ort an die Herbstschau ging und da zum ersten mal dieses Spiel erblickt hatte. Das Spiel hatte mich sofort gefesselt. Man durfte selber steuern wohin man den Protagonisten schicken wollte und wenn man z.B. eine Tür aufmachen wollte, stellte man die Figur vor selbige und gab open door ein. Ich war sofort Feuer und Flamme und gab mein ganzes Taschengeld dafür aus, jeden Tag einen Messeeintritt zu erwerben um mich bei diesem Stand aufhalten zu können. Irgendwann liessen mich die Leute da sogar selber spielen! Und hätte es nicht so etwas wie Hunger, Durst, Schlaf oder Hausaufgaben gegeben, ich würde wohl heute noch dort sitzen 🙂

Jedenfalls sind es solche Erinnerungen, welche mich persönlich immer wieder die alten Spiele hervorkramen lassen. Doch leider wird es immer schwieriger solche Spiele unter einem heutigen System überhaupt zum laufen zu bekommen. Die Spiele welche sehr Hardwarenah programmiert wurden, rasen bei den heutigen Gigahertzen nur so über den Bildschirm. Die ISA Soundkarten gibt es schon lange nicht mehr und von onboard PCI Karten wussten die damaligen Spiele noch nichts. Und von heutigen Monitorauflösungen jenseits von 640×480 will ich gar nicht erst anfangen zu sprechen.

Um also all diese Hürden überwinden zu können, bietet sich die Verwendung eines Emulators an. Und genau für diesen Zweck gibt es einen Emulator mit Namen DOSBox.

Zitat Wikipedia:

DOSBox ist ein freier x86-Emulator, der das Betriebssystem DOS und die in dessen Ära gebräuchliche Hardware nachbildet. Ziel ist das Ausführen älterer, DOS-basierter Software, die mit modernen Computersystemen nur eingeschränkt oder gar nicht kompatibel ist.

Da der Emulator auf den unterschiedlichsten Systemen wie etwa Linux, BSD, Mac OS X und vielen anderen läuft, ist er natürlich sehr beliebt und verbreitet. Mit Hilfe dieses Emulators habe ich schon so manches Kleinod aus früheren Kindertagen wieder in altem Glanz erstrahlen lassen.

Doch wie das nunmal im Leben so ist, irgendwann gelangt man an einen Punkt wo selbst die tollsten Tricks das alte Spiel nicht mehr zum laufen bringen. Bei mir war dieser Punkt beim Spiel Bazooka Sue erreicht.

Das Problem bei diesem Spiel ist die Verwendung von Umlauten in den Dateinamen. So gibt es z.B. eine Datei GLÜCK.WAV oder LÖWE.WAV welche in der entsprechenden Situation abgespielt wird.

Da DOSBox ein internationales Projekt ist und die Programmierer englischsprachig sind, gibt es für Umlaute zuerst einmal keine Unterstützung. Das merkt man auch daran, dass das Spiel an den jeweiligen Stellen mit einer Fehlermeldung abstürzt.

Doch Open Source wäre nicht Open Source, wenn man nicht einfach selber Hand am Code anlegen könnte. Also habe ich mir den Quellcode heruntergeladen und die besagte Stelle relativ schnell identifiziert und gepatch.

Viel schwieriger war dann jedoch die Frage zu beantworten, wie man denn dieses Paket – inklusive all seiner Abhängigkeiten – unter Windows XP zum kompilieren bringt. Nach einer Woche intensiven ausprobierens, Foren scannens, Bugreports lesen und Anwendung von Vodoo Praktiken habe ich es tatsächlich geschafft eine DOSBox Version auf meinen Rechner zu zaubern, welche Umlaute in Dateinamen versteht.

Da dieses Unterfangen doch einige Stolperfallen beherbergen kann, habe ich mich entschieden eine Artikelserie zu veröffentlichen, welche aufzeigt, wie man das kompilieren einer derart komplexen Software mit Hilfe von Open Source Tools unter Windows bewerkstelligen kann. Obwohl es in diesem Artikel explizit um DOSBox geht, kann diese Artikelserie für jedermann interessant sein, der selber das eine oder andere Projekt unter Windows kompilieren möchte.

Im zweiten Teil der Serie werde ich mich der Erstellung und Installaiton der MinGW/MSYS Entwicklungsumgebung widmen.

Eine Zone, welche sich im Status mounted befindet? Das kann eigentlich nicht sein.  Zumal es diesen Status in den offiziellen Dokumentationen von SUN auch nicht zu geben scheint.

# zoneadm list -cv
  ID NAME          STATUS     PATH                     BRAND    IP
   0 global        running    /                        native   shared
   1 zone1         running    /opt/local/zones/zone1   native   shared
   2 zone2         running    /opt/local/zones/zone2   native   shared
  10 zone3         mounted    /opt/local/zones/zone3   native   shared

Durchkämmt man den OpenSolaris Code nach den verschiedenen Statussen findet man jedoch auch die Definition für den mounted Status

#define ZONE_STATE_MOUNTED

Und wie kommt dieser Status zustande? Hauptsächlich durch die Installation eines neuen Patches/Paketes. Hierdurch wird mit den Befehlen die Zone (sofern diese nicht lief) in den Status mounted gebootet um dann das Pake/den Patch installieren zu können. Im Normalfall wird das entsprechende Tool dann auch den Ursprünglichen Zustand wieder herstellen. Aber manchmal funktioniert das halt nicht.

Das Problem ist, dass man mit der Zone solange nichts machen kann (kein reboot, kein halt) bis man den Status auf installed gebracht hat. Hierzu verwendet man einen ebenfalls eine nicht angegebene Option von zoneadm: unmount

Mit dem Befehl:

zoneadm -z zone3 unmount

Wird die Zone sauber unmounted und wieder in den Status installed gebracht.

Wo sind bloss die 50GB Speicherplatz geblieben?

Diese Frage musste ich mir heute Morgen auf einem unserer Solaris 8 Systeme stellen. Nach einigen Aufräumarbeiten war der Übeltäter gefunden. Eines unserer Projektverzeichnisse hatte Logdateien enthalten, welche 38GB gefressen hatten.

Das Problem: Mir konnte natürlich wiedermal niemand sagen ob die Daten noch gebraucht werden.

Also wollte ich all die Dateien mit gtar/bzip2 Archivieren. Doch da hatte ich die Rechnung ohne den Wirt gemacht. Ein gtar cvjpf Archivdatei.tar.bz2 logfiles* scheiterte an der Menge der übergebenen Dateien und beendete sich mit der Fehlermeldung:

/bin/tar: Argument list too long

Was? Wieviele Datein waren denn da auf dem Server? Ein ls -1|wc -l brachte mir die Gewissheit.

372’378 Dateien!

Das ist natürlich eine Menge. Und wie sichere ich die nun? Ganz einfach. Zuerst wird mittels find eine Liste aller Dateien erstellt und danach wird das tar File anhand dieser Datei erzeugt.

find . -name '*.log' -print >/tmp/archivliste
tar cvjpf logfiles.tar.bz2 --files-from /tmp/archivliste

So einfach kann es sein… 🙂

Nachtrag:

Will man die Dateien löschen, hat man mit rm natürlich wieder das selbe Problem. Aus diesem Grund hier der Befehl, wie die Dateien löschen kann.

find . -name '*.log' | xargs rm

Uebrigens:

Der Grund, warum es über die Argumente nicht geht ist die beschränkte Puffergrösse für Argumente. Denn ein logfiles* wird in logfiles1 logfiles2 logfiles3 etc. aufgeschlüsselt. Und bei knapp 380’000 Daeien ist dieser Pufferplatz schnell einmal voll. Zumal der Puffer wohl nur zwischen 32Kb und 64Kb gross sein wird.

Gerade eben wollte ich auf einem unserer Solaris 10 Systeme den Parameter nfs_portmon des nfssrv Modules von 1 auf 0 setzen, damit er die unprivilegierten Ports nicht prüft.

Nun wird überall im Netz geraten, in /etc/system den Eintrag vorzunehmen und dann einen reboot durchzuführen. Warum aber sollte ich ein ganzes System mit unzähligen Zonen neu starten, wenn ich doch nur einen Parameter ändern möchte?

Es muss doch bei Solaris 10 möglich sein, wie unter Linux (mit dem sysctl Befehl) die Kernelkonfiguration zu manipulieren. Nach ein wenig suchen fand ich denn auch die Lösung. mdb

# mdb -kw
Loading modules: [ unix krtld genunix specfs dtrace cpu.generic ...etc...
> nfs_portmon/D
nfs_portmon:
nfs_portmon:    1
> nfs_portmon/W 0
nfs_portmon:    0x1             =       0x0
> nfs_portmon/D
nfs_portmon:
nfs_portmon:    0
> $q

Mdb ist der modulare debugger von Sun. Man startet ihn mit den Parametern -kw, welche auf die Objektdatei /dev/ksyms und das Core File /dev/kmem schreibend zugreifen.

Nun kann man im Debugger einfach den Parameter (ohne Angabe des Modules, da dies automatisch aufgeschlüsselt wird) gefolgt von einem /D für dump oder einem /W <wert> für write angegeben werden.

Um den Debugger zu beenden, gibt man $q ein.

So einfach geht das 🙂 (und erst noch ohne rebooot!).

Es ist kurz vor Mitternacht und ich werde eines kratzens gewahr. Es ist das Kratzen einer unserer Katzen auf dem Katzenklo. Nun mag das Katzenklo die Katze vermeintlich froh machen, uns jedenfall hat selbiges einen Schock verpasst.

Denn als es plötzlich abartig zu stinken begann, habe ich mich aufgemacht um das «Korpus Vähkali» fachgerecht zu entsorgen. Doch als ich das Licht eingeschaltet und das Klo erblickt hatte, traf mich fast der Schlag.

Eine riesen Blutlache liegt neben dem, auf dem und im Katzenklo. Da eine derartige Blutkonzentration im Stuhl eines Menschen den sofortigen Gang zum Notarzt einläuten würde, haben wir sofort unsere Teirärztin angerufen.

Die beruhigte uns jedoch und meinte, dass bei dem restlichen Verhalten unserer Katze (sonst scheint Sie putzmunter zu sein) wohl nur ein Fall von «sieht schlimmer aus als es ist» vorliegen muss.

Und tatsächlich. Als wir die «Katzastrophe» aufwischen, erkennen wir, dass sich «das Blut» an gewissen Stellen Pink verfärbt.

Moment…. Pink? Da haben wir des Rätsels Lösung! Nina hat heute wohl «heimlich» immer und immer wieder diese «Rolling Snacks» von Vitakraft geklaut und diese unserer Baghira gegeben. Die hat sich natürlich über diese Aufmerksamkeit gefreut und fleissig die Hefe-Joghurt Bällchen gefressen.

Da Sie dummerweise (oder vielleicht gerade deshalb) durchfall hatte, hat sich der Farbstoff mit dem Kot vermischt.

Naja, solange es nichts schlimmeres ist…

Zum darstellen von Videos (wie etwa im Jack Keane Artikel) ist das WordPress Plugin FLV Embed ideal geeignet. Schade daran ist nur, dass dieses Plugin die Multimedia Schaltfläche nicht aktiv unterstützt. Will heissen, wenn man via Multimedia Button einen Flash Film einbinden will, dann kann man den Film zwar aus der Galerie auswählen, die nötigen Tags wie [flv :<Dateiname> breite hoehe] muss man jedoch immer noch selber darum herum schreiben.

Das was mir persönlich etwas lästig. Aus diesem Grund habe ich das Plugin so erweitert, dass bei einem Flash Film ein Button erscheint, welcher zum einen automatisch ein [flv : etc. darum herum packt, und zum anderen einfach einen Standard Wert von 320×240 Pixeln wählt.

Nachfolgend die Beschreibung, was man selber verändern muss.

1. Im Adminbereich klickt man auf Plugins / Plugins bearbeiten.
2. Unter Plugin-Dateien wählt man FLV Embed an.
3. Im nun erscheinenden Source Code Fenster sucht man die Zeile //////////////////// parse content functions, und fügt darunter folgenden Code ein (alternativ ab WP 2.7.1 FLV_EMBED 1.2.1 folgenden Code und ab WP 2.9.x FLV_EMBED 1.2.1 folgenden Code) ein.
4. Wählt man nun ein Flash Video aus, wird ein Button Namens FLV Player dargestellt. Klickt man darauf, wird das flv darum gebaut und bei Einfügen in den Artiekl sogleich der gesamte String in den Artikel übertragen. Je nach Gusto kann man dann noch die default Grösse verändern.

So einfach kann das sein 😉