Wer wie ich immer noch Fan der älteren Micrografx Draw Version 5.0 ist, hat vielleicht festgestellt, dass sich diese Version unter Windows XP nicht mehr installieren lassen will. Das Setup bricht mit der Fehlermeldung “Setup konnte entweder Windows 95 oder Windows NT 3.51 oder höher nicht erkennen.” ab.

So geht es trotzdem:

1. Micrografx Draw 5.0 CD einlegen. Falls Windows das Setup per Autostart automatisch startet, das Setup abbrechen.
2. Im Explorer auf die Datei “setup.exe” rechtsklicken und im Kontextmenü “Eigenschaften” auswählen.
3. Den Reiter “Kompatibilität” wählen.
4. Unter “Kompatibilitätsmodus” Windows 95 auswählen, siehe Bild unten.
5. Mit “OK” bestätigen und die setup.exe per Doppelklick starten.
6. Das Setup läuft nun fehlerlos durch und Micrografx Draw kann ohne weitere Einstellungen gestartet werden.

Bei dieser Gelegenheit kann man auch gleich prüfen, ob man die “aktuellste” Version hat. Bei Sierra gibt es einige Patches. “wd5p1.exe” für Version 5, “wd6updat.exe” für Version 6 und “wdrawdll.exe”, die neue Librarys enthält.

Stand August 2009: Die Sierra-Domain existiert nicht mehr und die o.g. Dateien auch nicht auf anderen Seiten zu finden. Updates sind damit nicht mehr möglich.

Windows 98 lässt sich nicht neu installieren. Es erscheinen CAB-Dateifehler, VXD-Datei fehlen oder nach dem Start gibt es eine allgemeine Schutzverletzung.

Zwei verschiedene Fälle und die Lösung.
Fall 1:

Ein Windows 98-Rechner meldet kurze Zeit nach dem Booten eine allgemeine Schutzverletzung. Ein Grund ist nicht zu erkennen. In der letzten Zeit wurde definitv nichts am System verändert. Eine Neuinstallation von Windows 98 brauchte keinen Erfolg, der Fehler bleibt bestehen.
Unter Linux läuft das System einwandfrei, ein Hardwaredefekt ist also auszuschließen.
Fall 2:
Ein anderer Windows 98-Rechner kann den Teil der Registry nicht mehr öffnen, der in der Datei user.dat gespeichert ist. Das führt zu allerlei merkwürdigen Effekten: die Tastaturbelegung ist amerikanisch, man kommt nicht mehr in die Systemsteuerung, etc.

Auch hier brachte eine Windows 98-Neuinstallation keine Besserung. Je nach Installations-CD brach das Setup während des Kopierens mit einem CAB-Dateifehler ab oder beim ersten Starten fehlte ein VXD-Gerätetreiber. Auch dieses System lief unter Linux einwandfrei.

Die Lösung:

Die Installation von Windows 98 SE brachte in beiden Fällen die Lösung. Laut C’t (Heft 09/05) soll das Win98-Setup Probleme haben Dateien zu erkennen, die aufgrund von Kopierfehlern fehlerhaft sind.
Da meine Installations-CDs unzerkratzt und sauber waren, schließe ich ich einen solchen Fehler aber so gut wie aus.

Hat Microsoft ein “Ablaufdatum” in Windows 98 integriert?

eXtplorer ist ein in PHP geschriebener Dateimanager mit einer komfortablen AJAX-Oberfläche. Er kann als Plugin im CMS Joomla oder “standalone” verwendet werden. Besonders praktisch kann dieses Tool sein um das “wwwrun-Problem” zu beheben. In diesem Artikel soll beschrieben werden, wie sich eXtplorer über den SSL-Proxy von all-inkl.comnutzen lässt. Zusätzlich werden Änderungen gezeigt, die es ermöglichen, das das Skript im “standalone”-Modus ohne den skripteigenen Loginmechanismus genutzt werden kann.

Die Nutzung via SSL

Um eXtplorer über eine SSL-verschlüsselte Verbindung benutzen zu können, ist normalerweise kein zustätzlicher Aufwand nötig – vorausgesetzt für diese Verbindung wird der Serverport 443 benutzt. In den üblichen Webhostingpaketen ist das aber in der Regel nicht der Fall. Bei meinem Webhoster all-inkl.com wird z.B. ab dem Tarif Privat Plus ein SSL-Proxy (www.ssl-account.com) zur Verfügung gestellt. Das Skript eXtplorer benötigt für seine Arbeit die URL unter der das Skript aus dem Internet zu erreichen ist. Eine automatische Bestimmung ist durch die Verwendung des Proxy-Servers nicht möglich. Daher muss in der Datei /includes/init.php die if-Abfrage, die mit folgender Zeile beginnt komplett (d.h. auch der else-Zweig) auskommentiert

if($_SERVER['SERVER_PORT'] == 443 )

und direkt dahinter diese Zeilen eingefügt werden:

$GLOBALS["home_url"] = "https://ssl-account.com/pfad/zu/extplorer/";
$GLOBALS["script_name"] = "https://ssl-account.com/pfad/zu/extplorer/index.php";

Login abschalten

Wenn eXtplorer “standalone” benutzt wird, ist das Interface durch den skripteigenen Loginmechanismus geschützt. Wenn man stattdessen lieber den Zugang über eine .htaccess-Datei absichern möchte und dafür auf die Benutzerverwaltung verzichten kann, kann in der Datei /include/init.php die Zeilen

if( !<a href="http://www.php.net/is_callable" target="_blank">is_callable</a>( <a href="http://www.php.net/array" target="_blank">array</a>( $GLOBALS['mainframe'], 'getuser') )) {´
// login to use eXtplorer: (true/false)
$GLOBALS["require_login"] = true;     }
else {  $GLOBALS["require_login"] = false;     }

auskommentieren und

//immer ohne Login
$GLOBALS["require_login"] = false;

einfügen. Da der Pfad zum Homeverzeichnis nun nicht mehr in den Benutzereinstellung gesetzt werden kann, muss er in /includes/init.php eingetragen werden. Die Zeile

$GLOBALS['home_dir'] = !<a href="http://www.php.net/empty" target="_blank">empty</a>( $_SERVER['DOCUMENT_ROOT'] ) ?
$_SERVER['DOCUMENT_ROOT']: '.';

habe ich in meinem Fall durch

$GLOBALS['home_dir'] = !<a href="http://www.php.net/empty" target="_blank">empty</a>( $_SERVER['DOCUMENT_ROOT'] ) ?
$_SERVER['DOCUMENT_ROOT']."/../../" : '.';

ersetzt. Das bedeutet, dass das Homeverzeichnis zwei Ebenen höher als das Skript liegt. Wenn eine solche relative Pfadangabe nicht möglich oder zu umständlich ist, kann man den Pfad auch absolut angeben.

$GLOBALS['home_dir'] = "/pfad/zum/homeverzeichnis";