Keine Verzeichnisfarben in Midnight commander nach Upgrade auf Ubuntu 10.04.1 LTS

By dose | October 31, 2010
Under: Uncategorized
Comments: No Comments »

Nach dem Upgrade von Ubuntu Systemen auf 10.04.1 LTS fiel mir auf, dass der Midnight-commander nun die Verzeichnisse nicht mehr richtig highlightet und genauso darstellt wie Dateien, was etwas irritierend ist.

Der Bug ist hier beschrieben und kann wie folgt gefixt werden:

apt-get source mc; sudo cp mc-4.7.0/misc/filehighlight.ini /etc/mc

Doch das ist leider noch nicht Alles. Noch schlimmer hat es die Übersetzungen erwischt, der Midnight Commander erscheint in einem Kauderwelsch aus Englisch und Deutsch.
Der Grund dafür scheint zu sein, dass einige Übersetzungen im Sprachfile der Source als “fuzzy” gekennzeichnet sind und somit bei der normalen .mo Erstellung nicht berücksichtigt werden.
Nachdem wir im vorhergehenden Schritt ohnehin schon die Sourcen geholt haben, können wir auch das beheben:

sudo msgfmt -f -o /usr/share/locale/de/LC_MESSAGES/mc.mo mc-4.7.0/po/de.po

Alles in Allem ist es doch erstaunlich, dass scheinbar niemand das Paket ordentlich getestet hat, bevor es in die Release eingebunden wurde.

Windows Vista/7 und DbgPrint

By dose | January 24, 2010
Under: Uncategorized
Comments: No Comments »

Unter Windows 7 werden Debugmeldungen von Treibern standardmäßig nicht mehr ausgegeben.

Um Debugmeldungen temporär für die aktuelle Sitzung einzuschalten, kann in WinDbg folgendes Kommando verwendet werden:

ed nt!Kd_DEFAULT_Mask 0xffffffff

gdb und SIGTTOU

By dose | January 17, 2010
Under: Uncategorized
Comments: No Comments »

Vornehmlich beim Debuggen von Multithreaded Programmen (kA warum gerade da) erhält man von gdb oft die Meldung

Program received signal SIGTTOU, Stopped (tty output).

und der Debugger vertschüsst sich in den Hintergrund. Dagegen hilft einfach, die Terminalflags mit stty umzustellen:

stty -tostop

Reparaturinstallation mit Unattended XP CD

By dose | December 12, 2009
Under: Uncategorized
Comments: 2 Comments »

Unattended XP Installations-CDs, wie sie sich z.B. mit nLite erstellen lassen, sind sehr praktisch, da man auf ihnen alles gleich vorkonfigurieren und entsprechende Treiber hineinslipstreamen kann. Sie haben allerdings auch einen entscheidenden Nachteil: Man kann mit derartigen CDs weder die Reparaturkonsole aufrufen, noch kann man eine Reparaturinstallation machen, da die Datei winnt.sif ja den Installationsverlauf mehr oder minder bereits vorgibt.

Nun könnte man sich natürlich eine eigene CD ohne diese Datei brennen, aber nur deswegen einen extra Datenträger erstellen scheint auch nicht sehr zielführend. Wie ich heute herausgefunden habe geht es auch einfacher:
Man erstellt einfach eine Datei winnt.sif ohne Inhalt und platziert diese auf einer Diskette. Diese lässt man dann bei der XP-Installation im Laufwerk. Die XP-installation durchsucht automatisch die eingelegte Diskette nach allfälligen RAID-Treibern und eben auch Installationsanweisungen wie winnt.sif, welche die winnt.sif auf der CD “overrulen”.

HP Ink Cartridge Expiration Patch

By dose | October 7, 2009
Under: Uncategorized
Comments: 53 Comments »

English-speaking users: Patch instructions are found at the end of the blog post.

Wir haben hier im Büro einen HP Businessjet Farbtintenstrahldrucker, welcher sich vor einigen Tagen plötzlich weigerte zu drucken. Als Statusinformation am Display des Druckers kam: “Tintenpatrone abgelaufen”.
Nach einigen Recherchen in Google fand ich dann eine Beschreibung der Problematik auf dieser Seite von HP.

HP versieht also scheinbar bei einigen seiner Druckermodelle die Tintenpatronen mit einem Chip, auf welchem das Ablaufdatum der Patrone gespeichert wird und wenn man die Patrone länger benutzt als 2 Jahre, dann verweigert der Drucker den Dienst und besteht auf den Tausch der entsprechenden Patrone.
Nachdem es für mich inakzeptabel ist, dass HP mir vorschreiben will, wie lang ich die Patrone benutzen darf, habe ich versucht, das Problem zu analysieren.

Im Internet finden sich etliche Seiten, welche diese Problematik beschreiben, beispielsweise dieser mit reichlichen Kommentaren versehene Blog Eintrag. Viele Leute lösen das Problem auf mechanische Weise, indem sie die Druckerbatterie entfernen und somit den Drucker resetten, was dazu zu führen scheint, dass dieser “vergisst”, dass die PAtrone abgelaufen ist. Auch das Abdecken des Chips der Patrone soll zum Erfolg führen. Der Tip eines Kommentarschreibers, dass man nach dem Einschalten des Druckers einmal mit zurückgestelltem Datum drucken muss und anschließend während der aktuellen Sitzung normal weiterdrucken kann, hat mich auf die Idee gebracht, dass das Ganze wohl auch einfach Softwaretechnisch zu lösen sein muss. Scheinbar bekommt also der Drucker das aktuelle Datum vom Treiber zugesendet und verwendet dies dann für seine Ablaufdatumsberechnung.

Folglich habe ich mir einmal angesehen, was der Druckertreiber dem Drucker so an Informationen sendet, indem ich den Anschlussport des Druckers in den Druckeroptionen auf FILE: umgestellt und mir die Rohdaten angesehen habe. Dabei sticht folgendes PJL Kommando heraus:

@PJL SET TIMESTAMP="20091005153634"

Hier wird also der aktuelle Zeitstempel an den Drucker übertragen und aufgrund von entsprechenden Versuchen mit modifizierten Dumpfiles konnte ich herausfinden, dass der Drucker auch ohne diesem PJL Kommando funktioniert und folglich keinen Fehler beim Drucken mehr anzeigt.
Kleiner Tip am Rande: Man kann dem Drucker Rohdaten senden, indem man den Drucker freigibt, ihn anschließend mittels

net use lpt1 \hostprinter

einem Port zuordnet und anschließend die Rohdaten mit

copy /b rawdump lpt1

sendet. Damit ist einfaches Testen möglich.

Folglich kann man das Problem also am Einfachsten lösen, indem man den Druckertreiber derart modifiziert, dass er den Zeitstempel nicht an den Drucker sendet. Leider ist jeder Druckertreiber anders aufgebaut, sodass dies keine universelle Lösung ist, auch wenn das einfache Überspringen der Kommandoausgabe sicher die “sauberste” Lösung darstellt. Durch weitere Versuche stellte sich jedoch auch heraus, dass der Drucker ungültige PJL-Kommandos stillschweigend ignoriert. Daher kann man also einen universellen Patch bauen, indem man einfach im Druckertreiber nach dem oben genannten PJL-String sucht und diesen leicht modifiziert (z.B. indem man das Schlüsselwort TIMESTAMP in TIMESTAMX ändert – schon erkennt es der Drucker nicht mehr).

Ich habe einen kleinen Patcher gebaut, welcher einige Druckertreiber “kennt” und dort das Senden des TIMESTAMPs einfach überspringt. Für alle HP Druckertreiber, die er nicht kennt, benutzt er die eben erwähnte universelle Methode, indem er einfach den TIMESTAMP-String ändert. Der Patcher kann die von ihm getätigten Änderungen auch wieder rückgängig machen, falls diese zu Problemen führen sollten. Ich hoffe, dass man das Problem damit umgehen kann und jemand den Patcher brauchen kann. 

Instructions for patching:

I have been notified that this patch may not work on other printer models (I can only confirm that it works on my HP Business Inkjet 2300). so I recommend that you first verify if your printer can be tricked by the following procedure:

1) Turn off your printer
2) Set back system date to prior to the printer cartridge expiration date
3) Turn your printer on again
4) Try to print
5) Reset system date to current date

If printing works with these steps then the driver patch should work too. If it doesn’t, there may be some extra safeguards in your printer model. Sorry.
I don’t own other HP printers with expiring cartridges that I can try out, so I can only hope that the trick works for your printer as well.

>> DOWNLOAD PATCH <<

1) Turn off your printer so that the internal date gets reset. At least this works for HP Businessjet.
2) Apply patch and check if at least one printer driver file gets patched.
3) Either restart the spooling service or restart your computer just to be sure that the patched driver DLL gets loaded.
4) Turn on your printer again and see if you can print with the expired cartridge.

Update 07.04.2010: Incorporated deden’s patch into the patcher, maybe this helps for some printer models…

Feedback via Comments is welcome.

Windows XP auf HP pavillon 1200eg

By dose | September 29, 2009
Under: Uncategorized
Comments: 1 Comment »

Heute hat mir mein lieber Cousin einen HP Pavillon 1200eg vorbeigebracht, welcher mit Microsot Windows Vista vorinstalliert ausgeliefert wird. Nachdem Vista ein langsames, ressourcenfressendes  System ist und er gern etwas mehr vom Gerät hätte, wollte er Microsoft Windows XP installieren. Das war aber gar nicht so einfach, da es auf der HP Seite keine XP Treiber zum Download gibt (einzig und allein das Programm zur Tastensteuerung gab es im Downloadbereich für Windows XP). Ich habe mir daher mühsam alle Treiber zusammensuchen und herausfinden müssen, wie man diese zum Laufen bringt (im Falle des Grafikkartentreibers braucht man sogar ein eigenes Patchprogramm, um die Treiber unter XP zum Laufen zu bringen). Und auch bei der Reihenfolge der Soundtreiberinstallation muss man aufpassen.
Lange Rede, kurzer Sinn: Wenn jemand auch so ein Gerät auf Windows XP umrüsten will, hier die notwendigen Schritte und das Treiberpaket zum Download:

 – Treiber aus SATA\ Unterverzeichnis in Windows XP Installationsmedium
   integrieren (z.B. mit nLite o.ä. Tools).
 – Windows XP wie gewohnt installieren
 – Chipsatztreiber aus 9-5_xp32-64_sb.exe installieren.
 – .NET Framework von Microsoft herunterladen und installieren
   (Wird leider von MobilityModder benötigt 🙁 )
 – 8-12_xp32_dd_ccc_wdm_enu_72271.exe installieren und dabei entpacken
   lassen. Sobald es entpackt ist kann man den Setup schließen, eventuelle
   Fehlermeldung vorerst ignorieren.
 – MobilityModder installieren (MMDotNETSetup.eXE),starten und auf
   Pfad zeigen, in welchen der Treiber entpackt wurde (meistens ein Unter-
   verzeichnis unterhalb von C:\ATI\SUPPORT, sofern C das Systemlaufwerk
   ist. Beispiel: C:\ATI\SUPPORT\8-12_xp32_dd_ccc_wdm_enu_72271),
   anschließend Modifikation starten.
 – Im besagten Verzeichnis nun die SETUP.EXE erneut ausführen, diesmal
   lässt sich der Treiber installieren.
 – Audiotreiber 9-9_xp32-64_hdmiaudio.exe installieren.
 – Audio Codec sp41593.exe installieren.
 – Netzwerkkartentreiber aus RTL8111-NonVista\ installieren.
 – WLAN-Treiber sp42654.exe installieren.
 – HP Quicklaunch-Buttons sp43616.exe installieren.
 – SD-Kartenlesertreiber aus JMB38X_WinDrv_R1.00.29_WHQL\ installieren.
 – Fernbedienungstreiber aus enecir_release_v2_5_1\ installieren.

Das vollständige Treiberpaket gibts hier direkt zum Download.

Debian auf RAID installieren

By dose | September 13, 2009
Under: Uncategorized
Comments: No Comments »

In einem vorherigen Artikel habe ich ja bereits beschrieben, wie man ein bestehendes Debian-System auf RAID1 migriert. Unlängst hatte ich wieder einen neuen Server aufzusetzen, und diesmal wollte ich natürlich gleich bei der Installation ein RAID einrichten. Interessanterweise ist das nichteinmal so trivial, wenn man nicht weiß, was der Installer erwartet, um die Option zum Anlegen eines RAIDs anzubieten. Folgender Blog-Eintrag hat das Ganze zum Glück recht gut beschrieben bzw. auf einen anderen Artikel verlinkt, welcher die einzelnen Schritte beschreibt:

http://lars-schenk.com/installation_debian_etch_auf_einem_software-raid_1_mit_sata_disks/92

Windows Ressourcenproblem

By dose | September 4, 2009
Under: Uncategorized
Comments: No Comments »

Schon seit Jahren ärgere ich mich über folgendes Problem unter Microsoft Windows:

Ich bin ein Benutzer, der viele Anwendungen gleichzeitig offen hat, meine Taskleiste ist oft 3 Zeilen lang. Da ich oft an verschiedenen Sachen arbeite ist es mir angenehm, wenn alle Fenster offen bleiben, sodass ich schnell wechseln kann. Dieser Arbeitsstil scheint Windows aber nicht unbedingt zu gefallen. Mit zunehmender Uptime hat Windows dann scheinbar langsam Probleme bei der Allozierung von GDI-Speicher. Menüzeilen können plötzlich nicht mehr erzeugt werden, Anwendungen stürzen ab, weil nicht geügend Speicher für GDI-Objekte zur Verfügung steht, etc. Besonders markant ist die beim Internet Explorer, wo sich dann keine neuen Fenster mehr öffnen lassen.
Was in diesem Fall meistens hilft ist das Schließen von Anwendungen. Aber leider bringt dies auch nur kurzfristige Abhilfe, weil bald sind die Ressourcen wieder verbraucht und dann gehen die Probleme wieder von vorn los. Im Endeffekt half in so einem Fall längerfristig gesehen nur ein Reboot. Ich habe mich dann immer gewundert, weil ansich noch genügend Hauptspeicher da war (es war garnicht viel ausgelagert) und auch die Anzahl der allozierten GDI-Handles lag durchaus im grünen Bereich.

Nun habe ich heute den Knowledge-Base Artikel KB126962 gelesen, hier steht, wie man die Größe des Desktop-Heaps in der Registry erhöht, um solche Probleme umgehen zu können.  Das löst zwar die Ursache nicht (warum wird scheinbar nicht genug vom Desktop heap freigegeben, obwohl man eh schon etliche Anwendungen geschlossen hat?), aber ist zumindest eine Symptombekämpfung. Ich hoffe mal, dass es was hilft.

Win32 Applikationen mit Bordmitteln debuggen

By dose | September 2, 2009
Under: Uncategorized
Comments: No Comments »

Kürzlich fragte mich jemand, wie man unter Windows mit Bordmitteln einen Memory dump von einem aktiven Prozess erstellen kann. Ich hatte da etwas im Hinterkopf, hab es aber auch nicht mehr genau gewusst. Ich wusste nur, dass es sowas die den guten, alten debug.com von DOS auch für Windows gab. Bin dann schließlich über diesen Blog-Eintrag gestolpert, und nun erinnere ich mich wieder: NTSD heißt der Windows-interne debugger.

Soda, jetzt ist das endlich ein für allemal im Blog festgeschrieben und notiert ; -)

Crack für Monkey Island 1 / Deutsch

By dose | August 22, 2009
Under: Uncategorized
Comments: 9 Comments »

Weil ich gerade so im SCUMM-Debugging drin bin, gibt’s hier auch als Bonus auch gleich einen Patch für Monkey Island 1 / Deutsch. Das Analyseschema ist dasselbe, was schon im vorherigen Post verwendet wurde, allerdings sind hier die Daten in einem LEC-File untergebracht und nicht in den separaten LFL-Files. Ich habe der Einfachheit halber einfach die Bytesequenz gesucht, da ich mir die Analyse der LEC-Files ersparen wollte. Ich habe wieder die Branches bei Erfolg und Fehler untersucht, diesmal sieht das Ergebnis so aus:

Falscher Code eingegeben:
(90:152:0x1BC): Script 152, offset 0x1bc: [3F] o5_drawBox()
(90:152:0x1C8): Script 152, offset 0x1c8: [9A] o5_move()
(90:152:0x1CD): Script 152, offset 0x1cd: [88] o5_isNotEqual()
(90:152:0x1D4): Script 152, offset 0x1d4: [14] o5_print()
(90:152:0x1D9): Script 152, offset 0x1d9: [14] o5_print()
(90:152:0x1E5): Script 152, offset 0x1e5: [AE] o5_wait()

Richtiger Code eingegeben:
(90:152:0x1BC): Script 152, offset 0x1bc: [3F] o5_drawBox()
(90:152:0x1C8): Script 152, offset 0x1c8: [9A] o5_move()
(90:152:0x1CD): Script 152, offset 0x1cd: [88] o5_isNotEqual()
(90:152:0x1F5): Script 152, offset 0x1f5: [14] o5_print()
(90:152:0x1FA): Script 152, offset 0x1fa: [27] o5_stringOps()

Die SCUMM V5-Files von Monkey Island sind nicht mit 0xFF werXORt, wie bei Loom, sondern mit 0x69. Der entsprechende Code befindet sich bei der EGA-Version auf Offset 3EA92 in DISK01.LCK:

3EA90: 6D 29 E1 63 68 DA 69 48 69 7D 96 66 49 69 7D 96

Das Ganze also nun wieder mit 0x69 verXORt ergibt:

3EA90:  04 40 88 0A 01 B3 00 21-00 14 FF 0F 20 00 14 FF

Man hat hier also ein o5_isNotEqual() und ersetzt es wieder durch einen Sprung an den richtigen Offset mittels o5_jumpRelative, welchen man vorher ja aus den 2 Branches berechnen konnte.
Fertig ergibt das dann flgende Modifikationen.

3EA90:  04 40 18 28 00 B3 00 21 00 14 FF 0F-20 00 14 FF

Wieder mit 0x69 verXORn und man hat einen fertigen Patch.
Bei der VGA-Version befinden sich die Bytes übrigens auf Offset 10959A. Noch Fragen?