Topic : Das ATOS-Magazin 5/00
Author : Das ATOS-Team
Version : 31.12.2000
Subject : ATOS Diskettenmagazine
Nodes : 209
Index Size : 8868
HCP-Version : 5
Compiled on : Atari
@charset : atarist
@lang :
@default :
@help : ATOS Hilfe
@options : -i -s -h+zz -t2
@width : 70
View Ref-FileATOS ReportagenInterview mit Norbert Hanz Das ATOS-Magazin 5/00ATOS: Stelle dich bitte kurz unseren Lesern vor!
Norbert H.: 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 H.: 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
muß 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 eine 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 H.: 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 im petto.
ATOS: Das 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 H.: 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 Ausmasse 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 H.: 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 User 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üßte.
Zukünftige Features von UDO zu 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 H.: 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, 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 H.: 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 H.: 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 OpenSource 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 H.: 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 H.: 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
Lizenzvertrag 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 Beine machen soll. Wird das 060er-Update
auch Einzug in Deinen Milan I finden?
Norbert H.: 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 060-er 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 H.: 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.
Nichts desto trotz 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 H.: 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 H.: 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 heißt 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 "neueren" Sachen wie XML und dem
ganzen Rattenschwanz wie SVG oder ähnlichem ganz zu
schweigen.
Ä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.
Den Punkt mit der Freeware habe ich ja schon dargelegt.
Software ist fast wichtiger als Hardware. Auf dem
Atari-System fehlt halt einfach einiges: z.B. wie schon
oben erwähnt ein Browser mit CSS & HTML 4 & JavaScript
1.2, einen richtigen PDF-Reader (und Writer), ein
aktuelles Programmierpaket, das auch entsprechend (mit
aktuellen Bibliotheken, Dokumentation etc.) vermarktet
wird. Das sind einfach notwendige Applikationen für ein
Betriebssystem von heute. Auf anderen Betriebssystemen
geht die Entwicklung z.B. von HTML zu XHTML,
Texteditoren gibt es so einige auf dem Atari-System aber
anderes z.B. fehlt einfach.
Neben Applikationen, die fehlen, ist auch eine
Erweiterung und Modernisierung des Betriebssystems
notwendig. Ein Beispiel: Die Möglichkeit in RSC
Karteireiter zu benutzen. Die Erstellung geht zwar mit
dem Resource Master, aber die Verwaltung im Programm muß
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 muß 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 H.: Ich danke ebenso und hoffe für uns alle, dass wir noch
lange für und mit unserem Lieblings-Betriebssystem
arbeiten können.
Thomas KerklohInterview mit Thomas Raukamp