Von Zeit zu Zeit kommt bei mir die Anfrage, doch einmal mein geekisches Arbeitszimmer abzulichten. Und weil ich heute 'mal aufgeräumt habe, ist dies ein guter Zeitpunkt dazu. So without any further ado, here are the pictures:

Das ist mein Schreibtisch, von links her gesehen. Oben sieht man von links nach rechts meinen betagten HP Laserjet IIID, dann Saavik, Kirk, McCoy und SULU. In der unteren Reihe erkennt man einen Scanner, und hinter dem Keyboard mein TFT-Display mit der Webcam obendrauf. Hinter der Webcam sieht man ein kleines 4-Kanal Mischpult, dessen Eingänge mit einigen Rechnern verbunden sind und dessen Ausgang auf die B&O geht. Rechts vom Monitor ist zuunterst ein 4-Port KVM, den mir mal der RHE aus seinem reichhaltigen Althardwarebestand vercheckt hat und obendrauf das kleine silberne Kästchen ist mein MAC mini. Daneben rechts außen steht chekov. Das glänzende graue Etwas links oberhalb vom Laserjet ist die linke Aktivbox der B&O.

Das ist nochmal dasselbe von der rechten Seite und man könnte es schöner nicht erkennen, wie die Technologien unterschiedlicher Jahrzehnte aufeinanderprallen: Auf dem Regal steht rechts neben der B&O-Edelanlage von 2004 ein echt trashiges "Schneider Power Pack 34" von 1983 (Konfirmation!). Der Ausgang von letzterem geht in einen kleinen RIAA-Entzerrvorverstärker und dann wiederum ins Mischpult. So kann ich meine alten LPs über die B&O anhören. Das graue Dings oberhalb der B&O ist die rechte Aktivbox. Die Tapete stellt übrigens die "Nachtwache" von Rembrandt dar.

Das ist die gegenüberliegende Seite: Ein 8-Port-KVM, erst kürzlich für schlappe 5 € von επτ€σ im Hardwareverkauf des Testteams erworben, drumrum von links nach rechts ein alter Hobel mit NT3.51, ein noname-17-Zoll-Röhrenmonitor, dann SevenOfNine (die Linuxbox, die meine Webcambilder schießt) und Jakobs Spielrechner. Ganz unten rechts steht eine halbgeöffnete Maschine an der ich zur Zeit rumbastele.

Und weil kirk auf der einen Seite mit dem 8-Port KVM auf der anderen Seite gesteuert wird, müssen irgendwie die Signale von der einen Zimmerseite zur anderen kommen. Am einfachsten geht das über die Decke, wie man in diesem Bild sieht. Spätestens diese Konstruktion senkt den WAF ("Womens' Acceptance Factor") dieses Arbeitszimmers auf einen Wert, der ganz nahe bei Null oder drunter liegt.

Ein Klick auf eins der Bilder öffnet selbiges nochmal in einem separaten Browserfenster in hoher Auflösung.

Das wurde ich nun schon einige Male gefragt: Wie zeigt man eigentlich die Version des Windows-Betriebssystems rechts unten über dem "Tray" auf dem Desktop an, also etwa folgendes:

Ganz einfach: Unter dem Key HKEY_CURRENT_USER\Control Panel\Desktop gibt es einen named REG_DWORD value mit dem Namen PaintDesktopVersion. Dessen Wert setzt man von 0 auf 1 und loggt sich erneut ein. Falls der Wert im fraglichen User Profile nicht existiert, muß man ihn halt selbst anlegen.

Link: http://www.brianmadden.com/content/content.asp?id=500

Auf Brian Maddens Website findet man Microsoft's Complete Longhorn Terminal Server Feature List. Wichtig: Es wird hier bewußt der Terminus "Longhorn" und nicht "Vista" verwendet, denn Vista ist das neue Client OS von MS, während der Server dazu immer noch "Longhorn Server" heißt. Das bedeutet auch gleichzeitig, daß die beschriebenen Features nicht unbedingt in dem Umfang oder überhaupt in Vistas "Remote Desktop" auftauchen müssen, zumal ja der Server nach dem Client OS und eventuell sogar sehr viel später shippen wird.
(Edited: Fixed Typos)

Link: http://www.spiegel.de/panorama/0,1518,378168,00.html

Was ich mich schon immer gefragt habe, ist die Frage: Wann wurde eigentlich das Photo des Jungen auf der Kinderschokolade-Packung gemacht. Solange ich mich erinnern kann, ist das dasselbe Bild und es sieht immer ein bisschen nach Kindheit in den Siebzigern aus, als die Welt noch in Ordnung war. Und wie dieser Beitrag auf Spiegel-Online zeigt, war das tatsächlich vor 32 Jahren. Damals war ich 4 Jahre alt und kann mich vermutlich deswegen an kein anderes Gesicht erinnern.

So, jetzt bleiben eigentlich nur noch zwei ewige Fragen von mir übrig, vielleicht kann es irgendjemand für mich auflösen:

• Was macht Calle Del'Haye heute
• Wie hieß nochmal der Joker des FC Bayern in den 80ern, der immer in der 60sten Minute eingewechselt wurde und dann das entscheidende Tor gemacht hatte

Any clues?

So, wir haben jetzt einen großen Teil technischen Zeugs hinter uns - keine Angst, wenn's um Registry Reflection oder Registry und File System Redirection geht, heben wir diesbezüglich nochmal ab. Aber vielleicht sollten wir uns jetzt auch mal die Frage der Beancounters und Suits, die in unserer Firma arbeiten und auch von unserer Software ernährt werden, stellen:

Wann braucht man überhaupt native Binaries für x64?

Gute Frage. Sind native x64 Binaries vielleicht eine Lösung für ein Problem, das sich eigentlich gar nicht stellt? Ja und nein.

Gegenfrage: Sind 16-bit Binaries eigentlich noch lauffähig auf x64 Plattformen? Das ist zwar ein orthogonales Problem, aber passt hier thematisch ganz gut.

MS hat sich bei x64 schwer angestrengt um den Übergang zu der neuen Plattform möglichst schmerzlos zu gestalten, das muß man ihnen lassen. Aber 16-bit Binaries (also MS-DOS Binaries und Win16 Binaries) laufen auf x64 Systemen nicht mehr. Punkt. Damit, ähem, endet eine 23-jährige Ära von Binärkompatibilität mit DOS. Von, naja, einer Reihe von Ausnahmen abgesehen, die zum großen Teil von einer Unart einer den Kollegen bei επτ€σ nicht ganz unbekannten Firma namens InstallShield herrührt. InstallShield hatte nämlich die unangenehme Angewohnheit, lange Zeit (ich glaube für alle 5.xer Produkte) den Bootstrapper ihrer Setups, also den setup.exe, als 16-bit Windows Applikation auszuliefern. Das führte dazu, daß alle Setups, die InstallShield in dieser Version verwendeten, unter NT erstmal zum Start einer ntvdm führten, in der dann der 16-bittige setup-stub lief, der dann wiederum einen reinrassigen Win32-Prozess startete, welcher schließlich die eigentliche Installation vornahm. Ziemlich braindamaged, das Ganze, aber es gab dafür sicher einen Grund. Ganz bestimmt. Drum werden auf x64 Windows auch solche setups ausgeführt - obwohl sie 16-bittig sind - jedoch anders als man denkt: Der Programmlader erkennt ein derartiges setup.exe und führt stattdessen ein 32-bittiges setup aus, das von MS und InstallShield entwickelt wurde und mit dem OS mitshippt.

Aber jetzt zur Gretchenfrage: Wann braucht man unbedingt native x64 Binaries und kann nicht mit 32-bittigen Binaries auskommen, wann muß man also wirklich portieren?

Gretchenantwort: In der Regel laufen x86 binaries für 32-bit Windows unverändert und ohne Probleme auf x64. Sogar der Service Control Manager auf einem x64-System weiß mit 32-bittigen Services umzugehen, was mich während der Beta von XP x64 Edition am allermeisten erstaunt hat. Daher bleiben also für mich jetzt erstmal nur vier Kategorien von Softwareprodukten, die für x64 native übersetzt werden müssen:

• Software, die unmittelbar von den Goodies von x64 profitieren will, beispielsweise dem größeren Adreßraum
• Treiber: Kernel-Mode Code muß native vorliegen, um auf x64 zur Ausführung kommen zu können
• Plugins für System Binaries wie Shell Extensions, ISAPI extensions (?)
• Hook-DLLs für User mode processes

Die letzten drei Kategorien lassen sich auf ein fundamentales Problem zurückführen: Ein nativer x64 Prozeß kann keine 32-bittigen x86-DLLs laden (es sei denn es sind resource-only DLLs) und umgekehrt. All dieser Schmuh mit step-up-thunks von Win16 nach Win32 und die step-down-thunks von Win32 nach Win16, die es früher so gab als WinNT, Windows9x und Windows 3.x nebeneinander her sehr verbreitet waren, gibt es nicht unter x64. Puh, eine Sorge weniger!

Natürlich ist es auch so, daß alle DLLs, die ein portiertes Binary nachlädt, auch entsprechend native übersetzt sein müssen. Das bedeutet: Wen man eine Shell Extension oder eine Hook-DLL portiert hat, muß man natürlich auch all die Binaries noch portieren, die dieses Binary so der Reihe nach nachlädt.

Generell läßt sich aber als Fazit festhalten: Win32 Binaries für x86 Plattformen sollten von Ausnahmen abgesehen allesamt laufen. Muß man für ein Produkt native x64 Binaries erzeugen, so ist ein Mischbetrieb von x86 Binaries und x64 Binaries für *ein komplettes Produkt* durchaus möglich. Das soll heißen: Teile eines Produktes können durchaus x86 Binaries sein und nur diejenigen Teile müssen neu und native übersetzt sein, die wirklich native sein müssen.

(Edited: Fixed Typos)