 zurück zum News-Archiv |
25.10.2000
Interview mit Norbert Hanz
Von Thomas Kerkloh
Thomas Kerkloh führte ein Interview mit Norbert Hanz, dem Autor der UDO-Shell.| ATOS: | Stelle dich bitte kurz unseren Lesern vor! |
| Norbert Hanz: | Ich bin 1961 geboren und von Beruf Chemie-Ingenieur. Heute arbeite ich bei einem Chemieunternehmen im Bereich des Qualitäts- und Umweltmanagement, und bin da unter anderem für die Betreuung von Handbuch und Verfahrensanweisungen im Intranet zuständig sowie viele andere Dinge, die noch mit EDV zu tun haben. |
| ATOS: | Kannst du kurz etwas zu Deiner "Computerlaufbahn "sagen? |
| Norbert Hanz: | Meinen ersten Rechner (1040 STF, später mit zweiter Floppy) habe ich Ende 1986 gekauft und bin dazu wie die Jungfrau zum Kinde gekommen (ein angehender Ingenieur muss sich doch mit Computern auskennen). 1991 habe ich mir dann einen TT mit Großbildschirm gekauft und eine 50 MB Festplatte (Wow!). Ein Jahr später habe ich die gegen eine 240 MB Platte ausgetauscht und später eine 1 GB Platte und CD-ROM dazugenommen. Auch einen Mustek-Scanner und einen HP LaserJet 4P (als Nachfolger des NEC P6) nenne ich mein Eigen. Letztes Jahr (April 1999) habe ich mir dann einen Milan zugelegt (man gönnt sich ja sonst nichts) und endlich einen Farbmonitor. Da stehe ich nun und warte auf die weitere Entwicklung (Milan II, wo bist du?). Nun ja, das ist ja jetzt überholt. Früh habe ich angefangen, ein Geographie- und Politiklexikon zu programmieren, erst in GFA-Basic, später dann mit Pure C. Leider fehlten mir die notwendigen Daten, um es mit Leben zu füllen. Von der Aufmachung war es nach meiner Meinung sicherlich besser als Infopedia. |
| ATOS: | Was hat Dich bewogen, die UDO-Shell zu programmieren? |
| Norbert Hanz: | Die Idee zur UDO-Shell kam mir, als ich die Windows-Shell von Dirk gesehen hatte (ich benutze UDO natürlich auch auf der Arbeit :-)), die es ermöglichte, für die Zielformate einen Extra-Ordner anzulegen. Das bot die GEM-Version von UDO nicht. Damit war die UDO-Shell geboren. Natürlich lehnt sich das Aussehen an die Ursprungsversion an, aber inzwischen sind einige Ideen mehr eingeflossen und ich habe noch was in petto. |
| ATOS: | Dass Neues relativ schnell in die UDO-Shell einfliesst, hat man ja beim Artikel in der ATOS (Ausgabe 4/2000 UDO-Shell 0.39ß) gesehen. Wie sieht denn nun heute (13.10.2000) der aktuelle Stand der Dinge in Bezug auf die Entwicklung der UDO-Shell aus? |
| Norbert Hanz: | Zur Zeit ist die 0.39 als Komplett-Paket aktuell, eine Debug-Version ist bei der Version 0.42 angekommen. Diese spezielle Version gibt diverse Debugmeldungen aus, da bei einigen Usern die Shell beim Programmstart abstürzte. Diese sind inzwischen beseitigt. Außerdem wird die Shell ausgeblendet, wenn Grafikkarten eingesetzt werden, die ein eigenes VDI nutzen. Das Problem hat seine Ursache eventuell bei einer Betriebssystemroutine, die nach Aufruf die Ausmaße des Bildschirms zurückliefern sollte. In diesem Fall sind nach einigen Debug-Logs die zurückgelieferten Werte astronomisch hoch, so das die UDO-Shell beim Zentrieren der Dialog/Fenster auf dem Schirm diese ausserhalb des Bildschirms öffnen will. Ich warte jetzt noch auf weitere Informationen/Debug-Logs, um dann evtl. mit einem Workaround das abzufangen. |
| ATOS: | Du hast gerade davon gesprochen, dass da noch etwas in petto wäre. Was kann man denn in Zukunft noch von der Shell erwarten? |
| Norbert Hanz: | GEMScript wird unterstützt werden. Damit ist es dann möglich, die UDO-Shell auch "fernzusteuern ". Zur Zeit suche ich noch nach einem Konzept, um das, was da passiert, für den Usern transparent zu machen. Durch die Steuerung ist es möglich, die Optionen in der UDO-Shell zu ändern. Nach dem Ende des Scripts wird ja dann die UDO-Shell terminiert und sie schreibt dann gegebenenfalls die geänderte Werte als Default in ihre INF-Datei. Beim nächsten manuellen Starten der Shell durch den User würde er sich dann evtl. wundern, was da denn nun auf einmal für Optionen gesetzt wären. Quelltexte drucken ist in der Shell nur indirekt möglich (V. 0.42ß), ich habe es ähnlich wie z.B. bei CAT gelöst. Der User gibt ein externes Druckprogramm an (z.B. Idealist oder LPR) und dieses übernimmt den eigentlichen Ausdruck. Derzeit ist allerdings IdeaList fest eingestellt. Eine eigene Druckoption ist nicht geplant, da man dort das Rad wieder neu erfinden müsste. Zukünftige Features von UDO unterstützen, ist auch geplant. Wie man eventuell mitbekommen hat, wird UDO zum Ende des Jahres von Dirk Hagedorn als OPEN SOURCE freigegeben und schon jetzt haben sich einige Programmierer gefunden, die dort an dem Source gemeinsam weiterentwickeln wollen. Künftige Features werden dann von der UDO-Shell natürlich soweit wie möglich unterstützt. Schon jetzt sind ja einige Möglichkeiten in der Shell, die UDO zur Zeit noch nicht bietet (z.B. direktes Anspringen einzelner Nodes etc. aus der Shell bei Editoren, die das SE-Protokoll beherrschen). Und natürlich ist das Bugfixing eine Sache, die ich weitermachen werde. ;-) |
| ATOS: | Welche weitere Software gibt es von Dir? |
| Norbert Hanz: | Seit ich einen ISDN-Adapter habe (ACER T50), habe ich auch noch ein Global Communications Office für das Teil verbrochen, welches aber noch im Beta-Stadium ist. Vom äußeren Aufbau lehnt es sich an die Windows- bzw. Mac-Version an und ermöglicht die Steuerung des T40/50, vor allem die Möglichkeiten der Telefonanlage. Die Steuerung des ISDN-Adapters wird ja meistenteils über einen Init-String der Modemsoftware gemacht. Leider habe ich noch Schwierigkeiten mit den Rückgabewerten der seriellen Schnittstellen, u. a. bei beliebigen Geschwindigkeiten. |
| ATOS: | Wie man im Artikel über die UDO-Shell in der ATOS 4/00 lesen konnte (und wie Du auch schon gesagt hast) wird UDO zum Ende des Jahres Open Source. Zur Zeit laufen ja Diskussionen in der Mailingliste und im MausNet, was die weitere Entwicklung angeht. Wie schaut es bei Dir aus, entwickelst Du dort mit? |
| Norbert Hanz: | Ja, soweit es mir zeitlich möglich ist. Bedingt durch meine berufliche Tätigkeit habe ich an den Bereichen HTML, RTF und PostScript/PDF ein besonderes Interesse.
Da ich schon eine Erweiterung des Postscript-Codes an Dirk Hagedorn geschickt hatte und er zum Ende des Jahres eigentlich erst noch eine neue Version veröffentlichen will, muss man dann schauen wo man weiter macht, bzw. was dann dort eingebaut wurde. Zur Zeit erfolgt in der Mailingliste von UDO und in der UDO-MausNet-Gruppe ein Austausch von Vorschlägen zur weiteren Entwicklung von UDO. Neben der Organisation, Dokumentierung bekannter Fehler in UDO und Sammlung weiterer Features, die implementierbar wären, geht es auch um den Status OpenSource. |
| ATOS: | Es gibt auch ein Angebot eines Softwarehauses (invers Software) an Dirk Hagedorn, UDO komplett zu übernehmen und es kommerziell zu vermarkten. Welche Position nimmst Du dazu ein? |
| Norbert Hanz: | Losgelöst von UDO (der Autor bestimmt nun einmal, welchen Status seine Software hat) meine ich, dass es nicht immer nur von Vorteil ist, wenn Programme als Freeware bzw. OpenSource zur Verfügung gestellt werden. Einnahmen, die ein Softwareautor z.B. bei Shareware hätte, kann er wieder in den Markt investieren. Ein weiterer Autor oder Hersteller von Hardware könnte davon profitieren.
Natürlich hat auch Open Source seine Vorteile. Jeder kann an der Entwicklung teilnehmen und seine Wünsche einbauen. Nicht zuletzt durch Dirk's Freizügigkeit hinsichtlich fremder Wünsche ist UDO eigentlich schon länger sowas ähnliches wie OpenSource. Im Falle der kommerziellen Übernahme von UDO gibt es sowohl einige stichhaltige Vorteile als auch Nachteile. Aber wie schon gesagt, bestimmt der Autor, was mit seiner Arbeit geschieht. |
| ATOS: | Ist der Bereich TOS (und Kompatibler Systeme) für Dich das Betriebssystem für die nächsten Jahre? |
| Norbert Hanz: | Ja, soweit ich bedingt durch meinen Beruf/meine Arbeit das machen kann. Ich laufe aber nicht betriebsblind durch die Gegend, ich sehe schon, dass es für den Bereich Spiele, Anwendungen und Programmierungssystemen auf anderen Systemen besser aussieht. Gerade für unsere Tochter gibt es sicherlich die eine oder andere CD (z.B. Löwenzahn), die leider nicht unter TOS läuft. Auf dem Atari ist aber eine Programmierung von Hand recht gut zu machen, das sehe ich auch als Vorteil. Ein Umstieg auf ein anderes System steht zur Zeit bei mir aber nicht an. |
| ATOS: | Hattest du auch schon Kontakt mit AXRO bzw. Milan Computersystems und wenn ja: wie klappt es mit der Zusammenarbeit mit AXRO bzw. Milan Computersystems? |
| Norbert Hanz: | Von AXRO/Herrn Martens bin ich wegen der UDO-Shell angesprochen worden, das war im ersten Halbjahr 1999 (an das genaue Datum kann ich mich nicht mehr erinnern und leider finde ich die Mail nicht mehr). Der angesprochene Lizenzverträge ist mir aber trotz Zusage zur Atari-Messe im Juni bisher nicht zugegangen. |
| ATOS: | Den angekündigten Milan II wird es nun ja nicht mehr in der Form geben, geplant ist aber ein 060er-Update, das dem 040er Milan Beinen machen soll. Wird das 060er-Update auch Einzug in Deinen Milan I finden? |
| Norbert Hanz: | Das richtet sich nach dem Preis für dieses Update. Der 68060er ist ja leider etwas teuer. Eventuell hätte ich mir einen Milan II gekauft. Das 'Eventuell' bezieht sich dabei allerdings eher auf meine allgemeine finanzielle Situation, als auf das Gerät.
Die zusätzliche Geschwindigkeit durch ein 060er Update würde sich z.B. in dem Bereich MP3-Decodierung und andere rechenintensiven Anwendungen bemerkbar machen. Wie gesagt, hängt es auch von Preis für dieses Update ab, zur Zeit habe ich da noch keine Entscheidung getroffen. Eventuell wird mein Rechner auch nur auf die aktuelle Stufe des Milan 040/33 MHz aufgerüstet und geflashed. Zur Zeit ist er noch auf 25 MHz getaktet und arbeitet nicht mit dem aktuellen ROM. |
| ATOS: | Was sagst du zum Milan-Aus? |
| Norbert Hanz: | Der Abschied vom Milan II, so wie er geplant war, ist meiner Meinung nach sinnvoll und richtig. Selbst wenn man jetzt noch die Lieferung dieser nun fehlenden Chips irgendwie sichergestellt hätte, könnte das gleiche bei einem anderen Bauteil des Milan II passieren, es würde sich also nur verschieben auf ein anderes Element oder auf einen späteren Zeitpunkt. Die Produktionszyklen einzelnen Bauelemente ist einfach zu kurz.
Nichtsdestotrotz war die Konzentrierung auf den Milan II und die Rückstellung andere Projekte seitens der Milan GmbH sicherlich richtig. Dafür ist Milan Computer personell einfach zu klein. |
| ATOS: | Wie siehst Du die Chancen für eine termingerechte Fertigstellung eines Milan III, so wie sie von Ali G. im Statement vom 10.10.2000 auf der Homepage der Milan Computersystems angekündigt wurde? |
| Norbert Hanz: | Das kann ich nicht beurteilen. Ich kann nur sagen, dass sich die Sache interessant anhört und Potential hat. Ich wünsche dem Projekt auf jedem Fall Erfolg, da dann ein System existiert, das ausreichend Speed hat und somit konkurrenzfähiger ist. Der Aufbau von nicht spezialisierter Hardware ist für ein kleines Unternehmen nach meiner Meinung einfach zu schwierig. |
| ATOS: | Ein Statement zum Stand der Dinge der Atari-Software? |
| Norbert Hanz: | Für das Windows-System gibt es, wie schon angesprochen, vieles an Software, was auf dem Atari nicht existiert. Aber wenn man einmal sieht, dass es z.B. Microsoft trotz der immensen Man-Power, die dort dahintersteht, nicht geschafft hat, manche elementaren Fehler und Sicherheitslücken in ihrer Software zu eliminieren, versteht man dieses nicht.
Auf dem Atari-Sektor verstehe ich allerdings auch nicht, warum man die geringe Man-Power nicht besser einsetzt. Koordination und gemeinsames Entwickeln z.B. eines Browser gibt es dort nicht.
Gerade wird ja wieder einmal das Rad neu erfunden; HireWire heisst ein Browser der in der Planung/Entwicklung ist und der neben Draconis bzw. Light of Adamas, WenSuite und CAB dann wieder mühselig alleine programmiert wird. Dafür ist der Umfang einfach zu groß und da rede ich von Standards wie HTML 4, CSS, JavaScript bis 1.2, von Ähnliches gilt für den Bereich der Texteditoren. So gut wie die einzelnen Produkte in ihren Bereichen auch sind, so fehlt doch bei jedem auch wieder ein Teil. Zum Beispiel das SE-Protokoll, in Zusammenhang mit der UDO-Shell zum Anspringen bestimmter Zeilen, beherrscht meines Wissens in dieser Stufe (Protokoll-Version 1.05) nur QED. Dafür fehlt hier z.B. das Syntax-Highlighting. Neben Applikationen, die fehlen, ist es auch eine Erweiterung und Modernisierung des Betriebssystem notwendig. Ein Beispiel: Die Möglichkeit, in RSC Karteireiter zu benutzen. Die Erstellung geht zwar mit dem Resource Master, aber die Verwaltung im Programm muss durch eigene Routinen durchgeführt werden. Hier könnten einige Sachen, die jetzt zum Teil durch zusätzliche Tools ermöglicht werden, in die Betriebssysteme einfließen. Hiermit möchte ich aber jetzt nicht MS das Wort reden. Man muss halt die richtige Grenze kennen. Was sich hier wie Meckerei anhört, möchte ich gerne als Motivation für die (potentiellen) Programmierer verstanden wissen, sich um neue Software zu bemühen. Ich weiß aus eigener Erfahrung, dass es schwierig wird, wenn man erstmal Arbeiten geht und Familie hat, noch regelmäßig an den Rechner zu kommen. Hier ist aber vor allem Axro gefragt. Wenn ein Milan III erfolgreich sein soll, ist die Software das A+O. Und da kann man sich nicht auf ein paar Feierabend-Programmierer wie mich, der sich alles nur durch Lesen und Ausprobieren erarbeitet hat, verlassen. |
| ATOS: | Wir danken für dieses Interview. |
| Norbert Hanz: | Ich danke ebenso und hoffe für uns alle, dass wir noch lange für und mit unserem Lieblings-Betriebssystem arbeiten können. |