Ich habe das noch nicht im Detail untersucht, aber so wie ich das aus den Zeitschriften ersehen kann, gibt es einige Unterschiede darin, was Netscape und Microsoft für JavaScript 1.2 halten. Ich könnte viel Aufwand betreiben, um beide Dialekte zu unterstützen, aber falls schließlich einer von beiden verschwinden sollte, hätte ich viel Entwicklungszeit verschwendet. Ich ziehe es vor, ein bißchen zu warten und dann festzustellen, was sich im Netzalltag durchsetzt und das schließlich zu implementieren.

Angesichts des enormen Zeitaufwandes, der zur Entwicklung einer Java-Portierung erforderlich ist, werde ich das nicht selbst erledigen. Das bedeutet, daß ich (oder jemand anderes), sobald ein Java-Interpreter einer Drittfirma erhältlich ist, ein Plug-In schreiben werde, welches diesen unterstützt.

Falls niemand gute Plug-Ins für diese Grafikformate schreiben sollte, könnte ich das selbst übernehmen. Aber das würde die sonstige Entwicklung von "AWeb" verzögern. Indem ich diese relativ unabhängigen Aufgaben an Plug-In-Programmierer delegiere, stelle ich schließlich doch noch so etwas wie meine eigene Entwicklungsmannschaft auf die Beine...

Ich weiß, daß das GIF-Plug-In verbessert wird und tatsächlich ziemlich preiswert ist. Neulich teilte mir jemand mit, daß er JPEG- und PNG-Plug-Ins schreiben wolle.

Ich weiß auch, daß einige an einem Datatype-Programm arbeiten. Diese neue Generation von Datatypes wird progressive Bildanzeige unterstützen und vielleicht sogar animierte GIFs. Sobald diese neuen Datatypes erhältlich sind, könnte ich Plug-Ins schreiben, die sich ihrer bedienen. Wahrscheinlich werde ich sie nicht intern unterstützen, da manche Leute möglicherweise lieber bei den alten Datatypes bleiben werden.

Bedauerlicherweise gab es nicht viele Anwender, die mit der Entwicklung von Plug-Ins begannen. Zumindest nicht, soweit mir bekannt ist. Mit der Ausnahme einiger Grafik-Plug-Ins (das AnimGIF-Plug-In und jüngst die oben erwähnten JPEG- und PNG-Plug-Ins) befinden sich derzeit keine weiteren in Entwicklung.

Sachen wie "RealAudio" sind aufgrund von Lizenzfragen schwer zu realisieren. Man muß eine gewaltige Summe bezahlen, bevor man den Quellcode portieren kann - wenn er überhaupt zur Verfügung gestellt wird.

Haha, diese Ferien müßten dann aber über zwei Jahre dauern ! Tatsächlich habe ich gerade erst in den letzten Wochen eine kleine "Auszeit" genommen, in der ich nur die letzten Fehler vor der Veröffentlichung entfernt, e-Mail beantwortet, Übersetzungen fertiggestellt, die Demoversion programmiert und ähnliches getan habe. Aber jetzt stehe ich wieder vor dem Beginn einer neuen Entwicklungsperiode. Zuerst werden einige Fehler entfernt, die in Version 3.1 immer noch vorhanden sind, dann ist es an der Zeit, die Style Sheets in Angriff zu nehmen. Falls genug Fehlerbeseitigungen erfolgen, die ein entsprechendes Bugfix rechtfertigen würden, wird es ein solches früher geben - genau wie die 3.0b-Bugfix-Version.

An "AWeb" werde ich solange weiterarbeiten, wie es sich verkauft. Ich investiere meine gesamte Zeit in das Projekt und bekomme gerade genug Geld dafür, um meinen Lebensunterhalt zu bestreiten. Sobald das nicht mehr der Fall ist, wird, auch wenn es traurig ist, die Entwicklung von "AWeb" ebenfalls beendet sein. Zumindest von meiner Seite aus; falls jemand oder ein Team bereit ist, die Entwicklung fortzuführen, würde ich das nicht unmöglich machen.

Jeder, der immer noch OS 2.x verwendet, sollte umgehend aufrüsten. Viele moderne Programme benötigen 3.x, und darüber hinaus dient der Kauf eines solchen Upgrades auch dazu, den Amiga am Leben zu erhalten.

Der Punkt ist, daß es genau das nicht garantiert, da es so viele GUI-Systeme gibt. Es würde ein wirklich gleichbleibendes "Look & Feel" nur dann garantieren, wenn es zu einem Teil des Betriebssystems würde, so daß wirklich jedes Programm es nutzen müßte. Im übrigen würde ich meinen Amiga verkaufen, sollte MUI wirklich zu so etwas werden...

Mir gefällt das Konzept eines verbesserten und vom Anwender konfigurierbaren GUI, aber ich mag die Art und Weise nicht, in der das in MUI implemtiert wurde. Das Betriebssystem ist so entwickelt worden, daß GUI-Elemente unmittelbar reagieren, indem alle sichtbaren Aktionen von einer spezialisierten Routine vorgenommen werden. Wenn man einen Knopf drückt, zeichnet ihn diese spezielle Routine in einem aktivierten Zustand, so daß man weiß, daß man ihn betätigt hat, auch wenn das Programm selbst zu beschäftigt ist um unmittelbar auf die Eingabe zu reagieren. Mit MUI wird diese Rückmeldung der Routine dem Programm selbst auferlegt. Nur wenn das Programm bereit ist und sich sagt "Mal nachsehen, ob irgendetwas passiert ist, während ich diese Berechnung vorgenommen habe.", wird die Rückmeldung gegeben. Das kann erst Sekunden nach der tatsächlichen Betätigung der Maustaste geschehen. In dieser Hinsicht verhält sich MUI wie Windows, und das sollte jedem Amiga-Anwender Grund genug sein.

Ich bevorzuge C, weil es so flexibel ist. Mit C kann man praktisch alles machen, was man will. Besonders wenn man einen mächtigen Compiler benutzt wie den SAS/C (Ich möchte Steve Krueger dafür danken, daß er diesen Compiler nach wie vor unterstützt !) gibt es keinen Grund, Assembler zu verwenden.

Objektorientierte Programmierung ist auch nicht schlecht, aber die Art und Weise, wie sie in C++ verwirklicht wurde, hat zu viele seltsame Kniffe und Ungereimtheiten, als daß ich mich damit anfreunden könnte. Ich habe einen sehr kurzen Blick auf Java geworfen und dem ersten Anschein nach sieht es ganz gut aus.

Für schnelle Wegwerf-Prototypen eines Programmes verwende ich gerne Basic. Nur ein oder zwei Zeilen und man hat ein lauffähiges Programm.

Ich brauche es, um an "AWeb" zu arbeiten... Ja, ich habe auch einen PC, um die neuesten PC-Browser zu sichten, und um alle mögliche interessante Software nutzen zu können (die meisten interessanten CD-ROMs laufen nur unter Windows - keine Chance auf dem Amiga). Ich mag die Arbeitsweise des Amigas nach wie vor, sogar mit der heute veralteten Technologie erledigt er die meisten Aufgaben eleganter als ein aktueller PC unter Windows '95. Aber ich sitze nicht vor meinem Computer um die Effizienz des Betriebssystems zu beobachten. Ich will die Maschine für etwas benutzen. Und hier verliert der Amiga gegenüber dem PC unglücklicherweise mehr und mehr an Boden. Heute verwende ich meinen Amiga dazu, "AWeb" zu programmieren und ein wenig Geld zu verdienen, etwas, was auf einem PC viel härter wäre und weniger Spaß machen würde. Aber um ehrlich zu sein wüßte ich nicht, ob ich meinen Amiga noch hätte, wenn ich nicht an "AWeb" arbeiten würde.

Keine Sorge, ich werde meinen Amiga nicht loswerden, so lange es mir möglich ist, an "AWeb" weiterzuarbeiten. Und wenn "AWeb" sterben sollte... falls ich meinen Amiga verkaufen würde, geschähe dies mit Schmerzen in der Brust.

Was wir definitiv nicht brauchen ist eine weitere Aufsplittung des ohnehin schon kleinen Amiga-Marktes in mehrere noch kleinere Märkte. Deshalb glaube ich, daß es einen (oder mehrere 100% kompatible) Wege geben sollte, auf denen der Amiga in die Zukunft schreiten könnte. Die Entscheidung, welcher Weg dies sein wird, liegt bei AI, natürlich nachdem die bereits laufenden Entwicklungen untersucht wurden. Falls es einen interessanten Ansatz geben sollte, wäre AI gut beraten, mit der entsprechenden Firma zusammenzuarbeiten, um ihn zum Standard für neue Amigas zu machen.

Ich selbst habe keine spezielle Vorliebe, obwohl ich glaube, daß es keine gute Idee ist, wenn man neue Hardware und neue Software kaufen muß, weil die alte Software auf der neuen Hardware nicht mehr läuft.

Das wichtigste dürfte das Vorhandensein von Software sein, die den heutigen Anforderungen gerecht wird. Ohne das wäre der Amiga nach wie vor eine nette Maschine - aber nur für Hobbyisten, die Spaß daran haben, mit dem Amiga zu arbeiten, weil sie gerne mit einem guten Computer arbeiten, und nicht als wirkliche Alternative zum Massen-PC.

Um solche Software zu ermöglichen sollte der Amiga einige Dinge (in keiner besonderen Reihenfolge) mitbringen:

Ein in das Betriebssystem eingebautes gutes, unmittelbar reagierendes, ausbaubares GUI-System. Eine eingebaute 24 Bit-Grafikkarte. Werkmäßig SCSI und eine eingebaute Festplatte. 16 Bit-Sound. Speicherschutz für eine höhere Zuverlässigkeit. Virtueller Speicher.

PPC wäre nett für zusätzliche Geschwindigkeit, die anderen Dinge sind aber bedeutsamer.

I haven't studied it in detail yet, but what I understand from magazines, there are some differences in what NetScape and MicroSoft consider to be JavaScript 1.2. I could put much effort in trying to support both flavours, but if one is going to disappear after all, I've lost much development time. I prefer to wait a bit and see what is going to be the most widely used on the net, and then implement that.

Seeing how much time it takes to create a Java port, I won't do that myself. That means that when a third-party Java interpreter becomes available, I (or someone else) will write a plugin that supports it.

If no-one writes good plugins for these picture formats, I might do it myself. But that would delay other development of AWeb. By delegating these relatively independent things to plugin writers, I sort of build my programming team after all...

I know the GIF plugin is under improvement, and is actually really cheap. Recently someone told me he would start on JPEG en PNG plugins.

I also know that people are working on a datatype rewriting program. These new generation datatypes will support progressive display, and maybe even animated GIFs. If these new datatypes become available, I might write plugins that use them. Probably I won't support them internally, as people might prefer to stick to the old datatypes.

Unfortunately, there hasn't been many users that actually started to write plugins, at least not that I know of. Apart from a few image plugins (the AnimGIF one, and only recently the JPEG and PNG plugins I mentioned above) there are no plugins in development.

Things like RealAudio are difficult to do because of licencing reasons. You need to pay a huge sum befour you can port the source, if the source is available at all.

I can hardly imagine why he wouldn't consider AWeb a serious opponent, or WebCruiser for that matter. Or does he think that a serious browser necessarily needs to use MUI?

And yes, I'm of course very satisfied that AWeb is the first browser that supports JavaScript. But only in the sense that AWeb is now ahead of all its opponents, not to teach Stefan a lesson.

Haha, this holiday would have to last over two years, then! In fact, I've taking some "rest" the last couple of weeks, only fixing the last bugs before the release, answering e-mail, getting translations be done, creating the demo, etc. But I'm about to get started on real development again right now. First fix some bugs that were still left in the 3.1 release, then it's time to start working on style sheets. If there are enough bugs to justify a bugfix release, there will be one earlier, just like the 3.0b bugfix.

I'll stay working on AWeb as long as people are buying it. I put all my time into it, and get just enough money in return to make a living from. When that stops - well, it's sad but then the AWeb development stops. At least by me, if anyone or any team is willing to continue development, then I won't make that impossible.

Anyone still using OS 2.x should upgrade immediately. Many modern programs need OS 3.x, and by actually buying such an upgrade from time to time you help the Amiga staying alive.

AWeb also needs OS 3.x, not only for the datatypes but it uses some other features as well. In fact the internal multitasking needs a feature that is only available in OS 3.0, and is not easily worked around in OS 2.x. Don't forget, OS 3.0 was introduced to be actually used by programmers, not to work around it so everything would still run on prior versions of the OS.

Point is that it doesn't guarantee that, because there are so many GUI systems around. It would only guarantee a real consistent look and feel if it was made part of the OS, so really every program would have to use it. If that should ever happen to MUI I would sell my Amiga, BTW...

I like the concept of an enhanced and user-configurable GUI, but I don't like the way it was implemented in MUI. The OS was designed in a way to make GUI buttons responsive, by doing all visual feedback in a separate, dedicated task. If you click a button, this special high-priority task renders the button in a depressed state, so you know that you have clicked it, even if the program itself is too busy to immediately react to your command. Now in MUI, this feedback is deferred to the application task itself. Only when the application is ready and says: "let's see if anything happened whle I was doing this calculation", the visual feedback is given. This can be seconds after you actually pressed the mouse button. In this respect MUI is behaving like Windows, and that should mean enough to every Amiga user.

I prefer C because of it's flexibility. In C you can do virtually everything you want. Especially when you use a powerful compiler like SAS/C (I like to thank Steve Krueger for still supporting this compiler!) there is no need at all to use assembler.

Object oriented programming is not bad at all, but the way it's done in C++ has too many strange quirks and inconsistencies for me to like it. I've had a very quick look at Java, and at a first glance it looks nice.

For quick throw-away prototype kind of programs, I like to use Basic. Just one or two lines and you've got a running program.

I need it to work on AWeb... Yes, I own a PC too, to check out the latest PC browsers, and to be able to use all kinds of interesting software (most interesting CD-ROMs only run on Windows, no chance on an Amiga). I still like the way the Amiga works, even with nowadays outdated technology it performs most tasks smoother than an up-to- date PC under Windows 95. But I don't sit behind my computer to enjoy the smoothness of the OS, I want to use the machine for something. And that is where the Amiga gets more and more behind of the PC, unfortunately. Today I use my Amiga for programming AWeb and earn a bit of money, something that would be much harder and less fun on a PC. But frankly, if I wasn't working on AWeb, I wouldn't know if I would still own my Amiga today.

Don't worry, I won't get rid of my Amiga as long as I can stay working on AWeb. And after AWeb is dead... if I'd sell my Amiga it would be with pain in the heart.

What we definitely don't need is the already small Amiga market splitting up into several even smaller markets. So I think there should be one way (or several 100% compatible ways) the Amiga is heading the near future. It's up to AI to decide what way this will be, of course after exploring the developments already going on. If there is an interesting development, AI should cooperate with that company to make it the standard for new Amigas.

I have no specific preference for myself, although I think that having to invest in new hardware and new software because old software won't run on the new hardware, is not a good idea.

Most important would be the availability of software that is up to today's standards. Without that, Amiga would still be a very nice machine, but only for hobbyists that like to work with the Amiga for the sake of working with a nice computer, not as a real alternative to the PC for the masses.

To make such software possible, a few things new Amigas should have (in no particular order) are:

A good, responsive, extendable, GUI system standard incorporated in the OS. A 24-bit graphics card built in. Standard SCSI + hard disk built in. 16-bit sound. Memory protection for better reliability. Virtual memory.

PPC would be nice for extra speed, but the other things are more essential.