smithy wrote:
Your analysis is interesting, however it's fatally flawed:
Thank you for taking the time to address the technical issues. I'll write a brief reply to each of them, and then all we can do is wait to see what the Amizilla team comes up with. Therefore this will be my last contribution to this thread.
It uses POSIX-compliant threads, which do not exist as yet on the Amiga, and are hard to implement too.
(1) The Mozilla code doesn't directly use POSIX threads. All thread-activity is contained within the NSPR (Netscape portable runtime). The Amizilla team has already ported the NSPR, so this is a non-issue.
No, they have not yet ported the NSPR. They have ported
parts, and if you look at the specification of the NSPR---which is decidely POSIXy---I am seriously wondering whether the solutions the Amizilla team (must) have come up with meet the general intent of the NSPR. AmigaOS 3.1 does not have a concept of threads, since tasks (the obvious candidates) are not able to access any dos.library function. Instead one distorts processes into behaving like threads, but this introduces subtleties which may or may not cause serious havoc, as the NSPR assumes that threads are
anything but processes. Without an in-depth evaluation of the Mozilla code I cannot say whether it will cause problems or not. Time will tell---so the issue is not quite yet a non-issue.
As a side note, AmigaOS 4 is considerably smarter in this regard as it knows about proper threads. In addition, all BCPL remnants have been removed, turning dos.library into a proper library. My guess is that porting the NSPR to AmigaOS 4 will be much easier.
It uses the Boehm garbage collector, for which a sort-of-port exists for the Amiga, but operates under severe restrictions.
(3) I've got no knowledge of that, or how easy a complete port/re-implementation might be.
Not easy. Not easy at all. The collector relies on dark magic involving automatic stack resizing and scanning of all data areas, including the stack. It is doable for sure, but you need to have a very good idea of what it is the collector is doing and how to coax the host system into cooperating without turning it into guacamole. Let's just say that you won't do this in a few hours. Once again, things are much better under AmigaOS 4 than under 3.
(4) It uses fork() at some places, the absolute Unix-to-Amiga porting nightmare.
It shouldn't use fork() either. All concurrency-related things are in the NSPR, which is already ported.
Sorry. fork() is
not overloaded by the NSPR, meaning that it is up to the underlying system libraries to provide support for it. The NSPR reference only mentions how fork() should be used in a portable way with respect to when to call which function, and that is something completely different altogether. Since the function is called in several places in the Mozilla code, you have a mighty big problem on your hands. Pray very hard that these parts are not critical to the operation of Mozilla, or can be rewritten so that fork() is no longer required.
I do not know whether fork() can be ported to AmigaOS 4, but since it has much better support for virtual memory addressing, I'm giving it a proverbial yes here. Once again, a clear advantage over 3.1.
The dynamic library interface is completely different to what is common on the Amiga.
(5) One of the Amizilla developers already has compiled the entire application on the WinUAE - this is a huge achievement, I wonder why they haven't publicised this milestone. And it runs too, so I assume any problems with the library interface have already been overcome.
Err... I don't think you understood what I meant. Yes, they did compile Mozilla, but that doesn't mean it is a working and fully-functioning program. Playing the devil's advocate for a second, if I were to write stubs for every function not supported by the Amiga system or libc libraries, I'd be able to compile and run the program too. This is of course exxagerating, since not all functions are stubs.
What I meant was the following: the NSPR abstracts a far more intelligent library interface than the Amiga provides under 3.1. In other words, porting the relevant parts of the NSPR involves far more work than just writing glue code. It can be done, of course, but that brings me back to my original point of view: you need to write so many extensions to the core OS that you are probably better off offering your services to Hyperion (or Genesi).
In fact, while writing down the above, I realised that what the Amizilla team in fact is doing is writing another ixemul.library. Only not one based on glibc2, but on NSPR. The original ixemul suffered from limitations due to the structure of AmigaOS's 2 and 3, and I see little reason to believe that the NSPR port will fare any better. (Currently, the coders have assumed a minimal code approach: if it supports only what is needed by Mozilla, then it is okay. That's a good approach until a Mozilla coder decides to change some code and introduces a function not present in the Amiga-NSPR, or worse, one which cannot be supported at all.)
That, plus the facts that the NSPR-port still needs to prove its worth, that GTK+ is still unaddressed, that the development environment is not exactly pleasant, plus that I can count the number of developers on the fingers of one hand, is why I believe that for practical intents and purposes, the Mozilla port will fail, especially under 3.1. If they were coding under 4.0, I'd say their chances of success would be considerably improved, but alas, that goes against the minimum requirements for Amizilla.
