Tag Archives: Windows

Git unter Windows

Ganz ehrlich, ich hab die Schnauze voll von Windows. Es begann damit, dass ich mehrere Tage gebraucht habe, um Qt 4.8.x selbst zu kompilieren, weil die pre-built Binaries mit einem alten MinGW mit GCC 4.4.x gebaut wurden, dieses aber nicht mit Qt mitgeliefert wird. MinGW selbst stellt aber keine älteren Releases bereit und wegen ABI-Änderungen bei GCC lässt sich Qt (GCC 4.4) nicht mit aktuellem MinGW (GCC 4.8) zusammen nutzen. Das allein schon war frustrierend genug, aber es tauchen dann ja noch so Schwierigkeiten auf, wie dass der Snakeoil Virenscanner selbst kompilierte Software hart löscht. Jetzt habe ich endlich ein Qt und dann beschwert sich CMake noch lange vor dem Build der Anwendung, dass es ein “sh” im PATH gefunden hat. Git für Windows bringt das mit, wozu auch immer. Dachte ich, schauste mal, ob das unbedingt nötig ist, aber die Git-GUIs für Windows brauchen das und auch sonst ist das mit den GUIs für Git unter Windows höchst schmerzhaft. Eine Liste gibt es zwar, aber das ist alles unbrauchbar:

GitHub for Windows
Verbirgt große Teile der Komplexität von Git, ist damit für gewisse Workflows unbrauchbar und arbeitet, oh Wunder, nur mit GitHub.
Git Extensions
Ist nicht plattformunabhängig und installiert mir Dinge mit, die ich schon habe.
git-cola
Braucht erstmal noch Python und PyQt und letzteres wiederum bringt im Binary-Installer gleich wieder ein ganzes Qt mit. Was hatte ich noch gleich selbst kompiliert?
GitEye
Ist ein komplettes Eclipse, für Git, also riesengroß, nur für ein Versionsverwaltungssystem. Irre.
SmartGit
Nicht frei.
SourceTree
Braucht mindestens Windows 7.

Dann wäre da noch TortoiseGit, aber das ist nur ein Fork von dem für Subversion super geeigneten TortoiseSVN und dementsprechend ungeeignet für einen Git-Workflow. Git ist halt kein zentralisiertes Versionsverwaltungssystem wie CVS, wie soll ich dafür dann das selbe Interface gebrauchen können?

Bei Mercurial hat man wenigstens ein schönes plattformunabhängiges GUI in Qt geschrieben. Das heißt zwar auch TortoiseHg, hat aber von der Bedienung her kaum was mit den zuvor genannten gemein und spült mir auch keine zusätzliche kaputte Shell auf meinen Rechner.

Hölle, ist das alles broken. Ich will mein Linux zurück. :-/

Ach so ja, das Problem mit CMake lässt sich übrigens lösen, indem man das CMake-GUI mit einem sauberen PATH startet, bspw. mit einer Batch-Datei cmake-gui.bat:

cd "C:\Programme\CMake 2.8"
PATH=C:\MinGW\bin;C:\Qt\Qt4.8.5-x86\bin
"C:\Programme\CMake 2.8\bin\cmake-gui.exe"

Nicht mehr mein Betriebssystem

Gerade eben, Büro: Build-Umgebung für Mikrocontroller auf Embedded Device angeworfen. Dort holt ein selbst geschriebenes Perl-Skript die Versionsinformationen aus dem Mercurial und erzeugt daraus eine Datei version.h, die beim Build eingebunden ist, so dass eine Versionsnummer im fertigen Binary landet. Automatisch. Ging immer. Eben nicht.

Es hat mich eine halbe Stunde gekostet rauszufinden, dass nicht mehr wie üblich das von mir installierte Strawberry Perl aufgerufen wird, sondern ein von MinGW mitgeliefertes, dem (mindestens) ein Modul fehlt, welches in meinem Skript genutzt wird.

Abhilfe schaffte die Umsortierung der Einträge in einer der Variablen %PATH% in den Umgebungsvariablen, damit mein Perl vor dem von MinGW gefunden wird. Dass das zusätzliche Perl übrigens bei MinGW dabei war und nicht in einem der anderen Pfade versteckt war, war übrigens nur gut geraten. Vermutlich gibt es noch mehr Perl-Instanzen, die irgendwelche Software hier mitgebracht hat. Unter Windows muss ja jeder immer wieder extra seinen eigenen Scheiß mitbringen.

Mal sehen, an wieviel anderen Stellen das später knallt. Wer den entsprechenden Dialog in Windows XP sofort findet und bei der (unter Entwicklern) üblichen Anzahl von zweistelligen Einträgen auch noch ohne Copy’n’Paste in externen Editor bearbeitet, werfe den ersten Stein.

Bei Linux gibt es ein Perl und in $PATH stehen maximal 5 Ordner.

Microsoft Visual C++ 6 und CMake

Warum man eine steinalte Entwicklungsumgebung mit einem modernen Build-System zusammen benutzen will, lässt sich nicht nur mit »Weil es geht!« begründen, es gibt sogar handfeste Argumente dafür, doch der Reihe nach.

Aus Gründen hab ich hier einige MFC-Projekte vorliegen, die in Visual Studio 6 entwickelt wurden, für das hier auch eine gültige Enterprise-Lizenz existiert. Bekommen habe ich Quellcode eines älteren Projekts ohne die Projektdateien. Neu zu entwickeln ist ein vergleichbares Programm und da Entwicklungsumgebung und KnowHow verfügbar sind, wird das neue Projekt eben auch in Visual Studio 6 entwickelt, die Programme laufen ja trotzdem.

Mit CMake füge ich dem Quellcode jetzt einfach die passenden Dateien mit dem Namen “CMakeList.txt” hinzu und lasse mir von CMake ein Projekt für VS6 erzeugen. Vorteil: ich brauche keine Projektdateien im Versionsverwaltungssystem ablegen, kann mir das auschecken wohin ich will und mein Quellcodebaum enthält nur das nötigste. De facto war ich so sogar in der Lage, das alte Projekt, wo mir die Projektdateien fehlten, mit CMake zu bauen und dem auf die Finger zu gucken. Soviel zum »warum«, es folgt jetzt das »wie« …

Zunächst mal sei gesagt, wenn schon Visual Studio 6, dann auch das letzte Service Pack installieren. Ist ein FAQ1 und das Service Pack gibt’s bei Microsoft.

Da ich hier eine MFC-Anwendung entwickeln will, also ein Tool mit GUI, reicht mir der reine Code nicht aus, sondern ist sind noch ressource files nötig. Bevor ich also später die Projektdateien mit CMake generieren lasse, erzeuge ich mit dem Assistenten von Visual Studio ein neues MFC-Projekt, in meinem Fall »Dialogfeldbasierend«:

MFC-Anwendungs-Assistent Dialogfeldbasierend

Den Rest des Assistenten klickt man nach eigenen Vorstellungen durch und dann kann man Visual Studio erstmal wieder schließen. Man hat jetzt einen Ordner vorliegen, in dem folgende Dateien liegen:

von VS6 erzeugte Dateien für ein neues MFC-Projekt

Davon kopieren wir jetzt den Ordner res und folgende Dateien an einen neuen Ort:

  • foo.aps
  • foo.clw
  • foo.cpp
  • foo.h
  • foo.rc
  • fooDlg.cpp
  • fooDlg.h
  • Resource.h
  • StdAfx.cpp
  • StdAfx.h

Das ist jetzt unser neuer Source-Ordner und dort wird nun eine Datei namens CMakeLists.txt angelegt. Fortgeschrittene CMake-Nutzer können das auch auf getrennte Unterordner für Programmcode, Header und externe Ressourcen aufteilen, spar ich mir hier mal und zeige nur wie das mit einer einzigen CMakeLists.txt aussehen kann:

project(foo)
cmake_minimum_required(VERSION 2.8)

find_package(MFC)

set(FOO-H
    foo.h
    fooDlg.h
    Resource.h
    StdAfx.h
)

set(FOO-RC
    foo.rc
)

set(FOO-SRC
    foo.cpp
    fooDlg.cpp
    StdAfx.cpp
)

add_definitions(-D_AFXDLL)
set(CMAKE_MFC_FLAG 2)
add_executable(${PROJECT_NAME} WIN32
    ${FOO-H}
    ${FOO-RC}
    ${FOO-SRC}
)

install(TARGETS ${PROJECT_NAME} DESTINATION ${CMAKE_INSTALL_PREFIX})

Zu set(CMAKE_MFC_FLAG 2) bitte nochmal selbständig die Doku lesen und nicht verwirren lassen, die dort gezeigten Code-Abschnitte sind aus älteren Versionen vom Installer von CMake selbst kopiert. Wie eingangs angedeutet, machen wir jetzt einen Build außerhalb des Source-Verzeichnisses und rufen dazu das CMake-GUI auf:

CMake GUI für unser Mini-Projekt

Nach einem Klick auf Configure wird man nach dem Generator gefragt. Dort wählt man Visual Studio 6 aus der Liste und bestätigt. Ein weiterer Klick auf Generate erzeugt dann die Projektdateien im zuvor eingestellten Build-Ordner, alles oben im Screenshot zu sehen. Mit einem Doppelklick auf die Datei foo.dsw öffnet sich dann Visual Studio und man kann sein Projekt bauen. Schick auch, dass es gleich ein Unterprojekt gibt, was einem die Anwendung installiert. Theoretisch gibt’s auch noch CPack, womit man sich dann noch gleich einen Installer backen kann, aber das würde jetzt hier zu weit führen. ;-)

das von CMake erzeugte VC6-Projekt

Wenn das alles soweit schön kompiliert, kann man den Source-Ordner so nehmen wie er ist und in das Versionsverwaltungssystem seiner Wahl packen. Projektdateien für Visual Studio generiert sich dann jeder Entwickler selbst mit CMake. Bisschen umständlich ist das später beim Hinzufügen von neuen Dateien ins Projekt, weil man die CMakeLists.txt parallel pflegen muss, aber das ist es meiner Meinung nach wert.

  1. Visual Studio 6 Compiler : Freezing CMake Configuration []

Text vs. Binary

Einer der täglichen Stolpersteine auf dem Weg zum C-Guru, hat mich gerade eine Stunde Lebenszeit gekostet. Vergleiche:

fopen( "header.bin", "wb" )

mit

fopen( "header.bin", "w" )

und dann noch den Auszug aus C in a Nutshell

The mode string may also include b as the second or third letter (that is, "ab+" for example is the same as "a+b"), which indicates a binary file, as opposed to a text file. The exact significance of this distinction depends on the given system.

»The given system« in diesem Fall Microsoft Visual C++® 6.0 unter Windows XP. Und was macht das, wenn man das b weg lässt? Es fügt vor jedes 0x0A, das man mit fwrite() in eine Datei schreibt, selbständig ein 0x0D ein, damit aus dem LF auch brav ein CRLF wird. Und ich wunder mich, warum meine Dateien größer sind, als sie sein sollten …

HowTo: Syntaxhighlighting für Graphviz in Notepad++

Für die 8 Stunden am Tag, wo ich gezwungen bin, Windows zu benutzen, ist Notepad++ der Editor meiner Wahl. Eingebaut ist Syntaxhighlighting für eine ganze Reihe von Programmiersprachen, zum Teil auch recht exotische Sachen, aber natürlich nicht alles, was irgendwie möglich ist. Ein derartiger Fall ist Graphviz, die bekannte Software zur Visualisierung von Graphen. Ich benutze das hier um Zustandsmaschinen zu visualisieren. Die Dateien schreibe ich manuell, was zwar bisschen Arbeit macht, aber Änderungen sind doch deutlich schneller einzupflegen als wenn ich das beispielsweise in Inkscape zeichnen würde.

Vor ein paar Wochen hatte ich mal unmotiviert im Netz recherchiert, wie es mit Syntaxhighlighting für Graphviz in Notepad++ aussieht, kurz und gut: schlecht. Allerdings hat der Editor eine interessante Funktion, mit der man sich schnell selbst ein rudimentäres Syntaxhighlighting zusammenklicken kann. Einfach im Menü auf Ansicht und dann Benutzerdefinierte Sprache …1 klicken. Da öffnet sich ein Fenster, wo man dann erstmal auf »Neue erstellen« klickt. Für die Einstellungen, die ich jetzt für Graphviz gemacht habe, hab ich mal ein paar Screenshots angelegt:

Auf dem vierten Screenshot sieht man bereits das Endergebnis. So ganz perfekt ist es nicht. Folding funktioniert nicht und die Marker für Kommentarblöcke müssen zwingend von Leerzeichen umschlossen sein, damit der Block erkannt wird. Ansonsten bin ich ganz zufrieden, besser als völlig ohne ist es allemal.

Wer sich das nicht selbst zusammenklicken will, kann auch die Datei userDefineLang.xml von hier laden. In dieser speichert Notepad++ diese Einstellungen nämlich und zwar unter Windows XP im Pfad C:\Dokumente und Einstellungen\adahl\Anwendungsdaten\Notepad++2

Achtung: Wenn Ihr selbst schon eigene Einstellungen für andere Sprachen definiert habt, nicht einfach überschreiben, damit die alten Sachen nicht verloren geben! Aber die Datei ist XML, da sollte man sich leicht den passenden Teil rausziehen können.

  1. bzw. View und dann User Define Dialog… []
  2. Pfad natürlich an lokale Gegebenheiten anpassen! []

Resistente Virenschleuder

Als die Europäer das amerikanische Festland eroberten und die fälschlicherweise als Indianer bezeichneten Ureinwohner verdrängten, brachten sie neben Waffen und billigen Geschenken unbeabsichtigt noch etwas anderes mit: Krankheiten, gegen die sie selbst resistent waren, die den Indianern aber schwer zusetzten.

Warum erzähle ich das?

Als Linux in verschiedenen Distributionen begann, den Desktop zu erobern und mit der Ausbreitung des Internets auch Viren, Würmer und andere Malware populär wurden, stellte sich eines heraus: So richtig betroffen waren nur die Windows-Nutzer. Einen Virus für Linux zu schreiben, war ungleich schwerer und die Zahl der Nutzer war doch nicht hoch genug, als dass es sich lohnte. Folglich ist der Linux-Nutzer (und jeder Nutzer anderer Betriebssysteme) gegen die Windows-Viren resistent. Was besagten Nutzer jedoch nicht davor bewahrt, unwissend Überträger zu sein. Denn niemand verhindert, dass er auf seiner Festplatte, seinem USB-Stick und in seinen E-Mails Dateien hat, die eine Form von Schädling enthalten. Ein Windows-Nutzer, der eine Datei eines Linux-Nutzers weniger argwöhnisch öffnet, weil er ihm vertraut, wird so doch das Opfer einer Attacke gegen sein System. Ein Vertrauensbruch, der so nicht beabsichtigt war.

Jeder Windows-Nutzer lernt beizeiten, einen Virenscanner zu installieren, um sich gegen Schädlinge zu schützen. Linux-Nutzer fühlen sich sicher und brauchen solche Software nicht. Damit werden sie zum idealen Überträger, da sie nicht einmal wissen, was sich auf ihrer Platte tummelt.

Aufgefallen ist mir das, als mir jemand schrieb, in einer von mir hochgeladenen Datei (die ich auch von anderer Stelle per USB-Stick empfangen habe) einen Virus entdeckt zu haben. Zwar handelte es sich um einen Fehlalarm, trotzdem macht dies eines klar: Selbst wer nicht betroffen ist, sollte seinen Datenbestand hin und wieder nach Viren untersuchen!

Freie Virenscanner gibt es zum Beispiel mit ClamAV, die man per Cron-Job regelmäßig über seine Daten jagen kann. USB-Sticks lassen sich bei Bedarf automatisch überprüfen, wenn man auf die Daten zugreift, und schon ist das Netz ein wenig dichter und die Gefahr, selbst zur Virenschleuder zu werden, ein Stück geringer.

HowTo: Windows booten mit Debian und GRUB 2

Bei Debian wurde vor einigen Wochen das neue GRUB 2 in Debian Testing (Squeeze) gespült, das alte GRUB, welches das jetzt offiziell »GRUB Legacy« heißen soll, ablöst. Bei Ubuntu ist das übrigens auch für das nächste Release (Karmic) geplant, das in wenigen Tagen rauskommen wird. Wer diese Systeme als einzige auf einem 08/15-PC einsetzt, wird von dem Wechsel vermutlich kaum etwas mitbekommen.

Auf meinem neuen Netbook ist nun Windows XP Home vorinstalliert gewesen. Ich hab das mitbezahlen müssen und ich gebe zu, dass ich es draufgelassen habe, einfach um ab und zu nochmal Diablo II spielen zu können, ohne da im Linux große Verrenkungen anstellen zu müssen mit Installation, Spiele-3D-Grafik oder gar Wine. Nun ist es drauf und ich will es auch booten können. Der Installer von Debian Stable (Lenny) hatte das seinerzeit korrekt erkannt und in der Konfiguration von GRUB Legacy eingetragen.

Beim Upgrade auf GRUB 2 hat Debian diesen Eintrag nun schlichtweg ignoriert. Es hat auch keine neue Suche nach alternativen Betriebssystemen angestrengt, obwohl man vermutlich nur ein bisschen Code aus dem Installer hätte nutzen müssen. In der Liste der zum Boot möglichen Systeme tauchte Windows jedenfalls nicht auf.

Wie das nun bei dicken Rewrites so ist, die noch während des Beta-Stadiums ohne richtige Dokumentation auf die Nutzer losgelassen werden: man steht erstmal im Regen. Dazu kommt, dass der Distributor sich dann noch was ausdenkt, um das sauber in sein System zu integrieren. Bei der Suche, wo ich das nun eintragen müsste, hab ich dann folgendes herausgefunden:

Die neue Config-Datei von GRUB 2 ist /boot/grub/grub.cfg. Das erste was bei Debian drin steht:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

Soviel Hilfe hätte ich gar nicht erwartet. In /etc/default/grub kann man zunächst mal ein paar Optionen für den Kernel zum Laden setzen. Sowas wie quiet oder vga=789 oder ähnliches. Die Syntax ist selbsterklärend.

In /etc/grub.d liegen dann verschiedene Skripte:

-rwxr-xr-x 1 root root 3223 12. Sep 18:08 00_header
-rwxr-xr-x 1 root root 1152 12. Sep 17:56 05_debian_theme
-rwxr-xr-x 1 root root 3221 10. Aug 19:49 10_linux
-rwxr-xr-x 1 root root 4418 12. Sep 18:08 30_os-prober
-rwxr-xr-x 1 root root  281  7. Okt 23:07 40_custom
-rw-r--r-- 1 root root  483 10. Aug 19:49 README

Die sollte man auch alle brav in Ruhe lassen, wenn man sich nicht wirklich gut mit Shell-Scripting auskennt. Allerdings ist 40_custom genau der richtige Ort für unseren Eintrag um Windows zu booten. Dieser Eintrag sieht dann ungefähr so aus, bzw. gleich mal die ganze Datei, damit das klar wird:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows XP" {
    set root=(hd0,2)
    chainloader +1
}

Auch dies ist nur ein Shell-Script, das irgendwann im Update-Prozess für die Konfigurationsdatei von GRUB 2 ausgeführt wird. Bei der Angabe der Partitionsnummer aufpassen, da gab es eine Verschiebung um +1 gegenüber GRUB Legacy. Jetzt also noch den abschließenden Debian-spezifischen Befehl ausführen, um die neue grub.cfg zu schreiben und schon kann man wieder Windows booten:

update-grub

Update: Seit dem Update von heute, 24.01.2010, erkennt Debian Squeeze die Windows-Installation wieder automatisch. D.h. man kann den Inhalt aus /etc/grub.d/40_custom wieder rausnehmen. Einmal update-grub aufrufen sollte danach genügen, um Einträge für Windows in die Liste zu zaubern.

Update: Die Option vga=789 ist übrigens keine gute Wahl mehr. Spätestens seit Kernel 2.6.32-3 ist KMS, also Kernel Based Mode Setting, aktiv und funktioniert auch und wenn man dann vga setzt, kommt man aus dem X nicht mehr per Strg+Alt+F2 auf die »normale« Konsole.

Speicherlimits von MiKTeX erhöhen

Vor einiger Zeit hatte ich im Beitrag Schicke Grafiken in LaTeX mit pgfplots (1) eine elegante Möglichkeit vorgestellt, größere externe Datenmengen in schicke LaTeX-Plots zu verwandeln. Ich mache das immer noch sehr ähnlich, bin aber heute auf ein Problem gestoßen, das auch in der Dokumentation zu pgfplots Erwähnung findet. Im Kapitel »7 Memory and Speed considerations« heißt es dort:

The default settings of most TEX-distributions are quite restrictive, so it may be necessary to adjust them.

Dieses Limit hatte ich nun offenbar auf meinem Notebook erreicht. Die Doku zu pgfplots schlägt vor, die Limits mit Kommandozeilenparametern beim Aufruf von pdflatex zu erhöhen. Das funktionierte in meinem Fall leider nicht, da ich gleichzeitig auch noch die Funktionalität von pgf/pgfplots zum Wiederverwenden bereits kompilierter Grafiken einsetze, Stichwort externalize. Dort wird aus pdflatex heraus noch ein weiterer Lauf von pdflatex gestartet. Jetzt hätte ich diesen Aufruf anpassen und mit dem entsprechenden Parameter versehen können, aber dann wäre ich unter Linux auf die Nase gefallen, wo ich das Dokument ebenfalls kompilieren will.

Im Hinterkopf aus meinen ersten Experimenten mit pgfplots hatte ich aber, dass man diese Memory Limits auch irgendwo global setzen kann. In einem alten Thread in de.comp.text.tex hatte ich schon fast die richtige Lösung gefunden, aber der Tipp initexmf --edit-config-file=latex auf der Kommandozeile und dann im Editor den Wert anpassen funktionierte nicht.

Auf die richtige Spur kam ich dann als ich in C:\Programme\MiKTeX 2.7 eine Suche in den Dateien nach dem alten Limit ausführte. Ich erwartete eigentlich eine Konfigurationsdatei zu finden, aber ich wurde mit der Nase auf die Dokumentation von MiKTeX selbst gestoßen: C:\Programme\MiKTeX\2.7\doc\miktex\miktex.pdf. Da steht in Abschnitt »5.4 Changing TEXMF run-time parameters« nämlich genau, was zu tun ist:

initexmf --edit-config-file=pdflatex

Man beachte den kleinen Unterschied zu oben. ;-)
In der Datei hab ich dann jedenfalls folgendes eingetragen:

main_memory=3000000

Jetzt kompiliert mein Dokument wieder, ich kann fröhlich weiter arbeiten und schreibe mir selbst nochmal ein dreifaches RTFM hinter die Ohren.

Es gibt (k)eine perfekte Schrift für die Konsole

Ursprünglich hatte ich vor einen Beitrag darüber zu schreiben, dass ich es nicht geschafft habe, für Windows eine Schriftart zu finden, die ich zum Programmieren und als Konsolenschrift nutzen kann, also primär in PuTTY. Nun hat sich das etwas anders gegeben, aber der Reihe nach. Die Anforderungen waren folgende:

  • Festbreitenschriftart, monospace quasi
  • saubere Darstellung in Schriftgröße 9 auf dem Notebook, sprich auf TFT-Bildschirmen
  • gute Unterscheidung von den kritischen Zeichen beim Programmieren: l vs. I und 1, 0 vs. O usw.
  • »Line drawing characters« für Pseudofensteranwendungen auf der Konsole (mc, ncurses-basierte…)
  • als Bonus eine breite Auswahl an Unicode-Zeichen

Courier New

Los geht’s erstmal mit Courier New. Die ist ziemlich ausgelutscht, ist aber schon da und hat neben den Strichzeichen auch eine recht breite Unicode-Unterstützung. Die Unterscheidung zwischen kleinem l und der 1 ist nicht so schön. Die zwischen dem großen O und der 0 könnte auch besser sein, ansonsten aber ganz brauchbar.

Schriftprobe Courier New

Lucida Console

Nächster Kandidat ist die Lucida Console, ebenfalls bei Windows dabei. Die sieht sehr klar aus. Die Unterscheidung zwischen O und 0 gelingt nicht so gut. Mir persönlich ist sie in der gewünschten Schriftgröße zu breit und die Zeilenabstände sind recht eng. Das geht noch besser.

Schriftprobe Lucida Console

Consolas

Bei Windows Vista dabei, aber auch separat von Microsoft zu bekommen ist die Consolas. Die sieht unter den richtigen Voraussetzung rein optisch am besten aus. Die Schrift wurde speziell für TFT-Bildschirme und das dort verwendete Sub-Pixel-Hinting und ClearType optimiert, sieht auf alten Monitoren daher leider grauselig aus. Zum Programmieren eignet sie sich super. Leider gibt es einen ganz großen Haken: sie hat nur einen sehr kleinen Zeichenvorrat und die Strichzeichen sind nicht dabei, was sie für die Konsole komplett disqualifiziert, so bleibt sie leider nur etwas zum reinen Programmieren unter Windows.

Schriftprobe Consolas

Andale Mono

Danach habe ich lange mit der Andale Mono gearbeitet, die früher bei Windows dabei war und auch noch im Netz zu finden ist. Diese Schrift lässt recht viel Raum und wirkt recht klein, was zunächst mal ungewohnt ist, aber dann im täglichen Gebrauch nicht weiter stört. Leider hat diese Schrift einen Pferdefuß, der mich dann doch wieder auf die Suche nach einer besseren Alternative geführt hat. Bei 9pt sind ; und : kaum zu unterscheiden. Für einen Chat im irssi ist das doof, weil man ;-) und :-) kaum noch unterscheiden kann.

Schriftprobe Andale Mono

DejaVu Sans Mono

Gestern dann telefonierte ich mit meinem Bruder, einem studierten Experten auf dem Gebiet der Typographie. Von ihm bekam ich den Tipp es mal mit der DejaVu Sans Mono zu versuchen. Diese ist mir unter Linux natürlich schon das eine oder andere Mal begegnet. Die Schrift selbst wird als offenes Projekt auf dejavu-fonts.org entwickelt und man kann sie als OpenType TTF auch unter Windows nutzen. Sie enthält eine sehr breite Auswahl an Unicode-Zeichen und natürlich auch die gewünschten line drawing characters. Die beim Programmieren relevanten Zeichen sind ausreichend gut zu unterscheiden. Im Terminal wirkt sie sehr hoch und lässt wenig Raum zwischen den Zeilen, wirkt aber ausgewogener als die Lucida Console und ist insgesamt gut lesbar. Das macht sie nicht ganz perfekt aber sie ist frei und daher ab sofort meine erste Wahl als Konsolenschrift.

Schriftprobe DejaVu Sans Mono

Songbird: Music Player für Windows

Meine Suche nach einem Amarok-Äquivalent für Windows hat ein Ende gefunden!

Ich bin heute zufällig über einen Mozilla-basierten Music-Player für Windows gestolpert: Songbird.

Die Playlist sieht ähnlich aus wie beim Amarok (oder iTunes, das sich auf meinem Rechner aber nicht gut benimmt), ich bekomme die für mich interessanten Meta-Informationen angezeigt und es gibt – wie man es von Mozilla gewohnt ist – eine Menge addons. Zum Beispiel, um bei last.fm zu scrobbeln.

Einziges Manko: Das Programm lässt sich nicht in die Traybar minimieren – aber da finde ich sicherlich auch noch etwas.