Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Pyromania on September 06, 2004, 07:30:45 PM
-
AmiZilla has a new home on the web www.amizilla.net
Please update your bookmarks. Of course you can also access it at its original link.
http://www.discreetfx.com/AmiZilla.html
-
Yawn.
-
What is the current status of this project anyway?
-
The status is that about three people are contributing code. Messages on the mailing list average out at about 60 a month, with peaks in the summer months, when there are twice as much. I didn't really study the messages themselves: most of them seem to be CVS-related activity to provide simple AmigaOS<->Mozilla glue code. I think someone managed to get a binary (of 400 MB) running the other day which just printed a few messages on screen.
Project status? It is dead, as it was from day one. Some people just refuse to realise they are kicking a dead horse: AmigaOS (especially 3.1, the minimum requirement) cannot support a program as complex as Mozilla. Perhaps AmigaOS 4 makes things a little easier, but I'm not holding my breath. I find it foolish and naive at the very least to even continue the project. I would have closed it down and returned the bounty money (plus the accumulated interest) to its owners eons ago.
-
But it's fun, and that's the whole point. Just using an Amiga could be considered kicking a dead horse. And if nothing else, it's a good exercise in getting platform-independent code to talk to platform-dependent code in a modular fashion.
Trev
-
-
Atleast they are trying, which is more than i can say about you whiners.. If everyone believed like you, then there would be no software..
-
Tomas wrote:
Atleast they are trying, which is more than i can say about you whiners.. If everyone believed like you, then there would be no software..
Of course, shoot the messenger. Always a good tactic when you are lacking proper arguments. So let's keep the dicsussion which will now ensue polite and to the technical point, okay?
Look guys, even though I do not own an Amiga anymore, and do not intend to buy one either, I am not against it in any way. I'm sure there are still many people who enjoy the little computer and would love to have decent software for it. It is just that Mozilla is a bridge too far. Why? Because it uses software technology (hate that damn word, but okay) which is quite alien to the Amiga, especially OS 3.1. It uses POSIX-compliant threads, which do not exist as yet on the Amiga, and are hard to implement too. It relies on the GTK+-toolkit, which does not exist at all on the Amiga. It uses the Boehm garbage collector, for which a sort-of-port exists for the Amiga, but operates under severe restrictions. I do not know how that will affect the Amizilla. It uses fork() at some places, the absolute Unix-to-Amiga porting nightmare. The dynamic library interface is completely different to what is common on the Amiga. You cannot even compile the sources on an Amiga because of their insane size running into hundreds of MBs. And so forth.
Writing decent implementations of each of the above parts are formidable and very difficult tasks in their own right, and now people are striving to do all of them at once! With AmigaOS 4, POSIX threads and fork() may be properly implementable at last, but despite my asking on several occasions on these forums, the Frieden brothers have not yet confirmed this. In any case, the impression I got while studying the sources was that you need to create so many extensions to the AmigaOS to get Mozilla going, that you might as well offer your services to Hyperion (or Genesi) to aid them in coding their next generation operating system. And at a salary equivalent to the bounty money.
PeroxideChicken, you hit the nail on the head. The problem is exactly that Mozilla did not start out on the Amiga, but was created and designed on a more modern platform. It makes perfect sense to use code that is already available for that platform. If such code does not exist on a much older platform, you're out of luck. On the other hand, Scala and Lightware originated on the older platform, and thus can be much more easily ported to modern ones. The software can even be adapted to take advantage of the newer infrastructure in ways which would be very difficult if not impossible on the old one.
Bottom line: I am not negative, but I am brutally realistic. There's a difference. Unless people can convince me that the above subprojects are easily resolved, I will maintain my opinion that Amizilla is dead in the water. Please keep in mind that I am not saying that people should not do anything at all: there is indeed a lot you can learn from the process of porting a beast like Mozilla. Let them thinker to their heart's content: perhaps it will aid them in porting other programs. However, if you are contributing code with the bounty in mind, your efforts are much, much better spent elsewhere. The same goes for people who donate money in the hope that it will result in a working program: the technical issues are such that the bounty needs to gain at least another two digits before the effort becomes worthwhile. I am very sorry, but that's the way it is.
-
I have to agree with Cymric in most points (however semi-working libpthreads does exist at least). fork() will never work on AmigaOS or compatibles.
The sheer size of the project always made it almost close to impossible to get anything sensible out of it. I'm sorry if this shatters dreams of anyone, but with current work commited to AmiZilla, it will never see the day of light.
-
Would rather like to see that the new AWEB project get as many coders as possible to speed up its progress, the possibilities for this browser is endless:
AWEB Opensource Project (http://aweb.sunsite.dk)
-
I've heard of quite a few things that "would never happen" on the Amiga platform. It is a shame I never hear the people who come out with such statements ever apologising when they've been proven wrong, and I don't see that it helps anyone in any way to be so negative about such projects.
-
I agree with you mikeymike.
But, I for one would love to see AmiZilla. I'm unable to comment on some of the technical issues earlier in the thread, however, we can't all model ourselves on Candide. Amiga users have had their hopes raised and then dashed so many times.
I'm sure there are those who are still waiting for the SharkPPC to come out. Last year I was one of the optimists awaiting its arrival, but now I've given up the idea that its anything but vapourware...
-
mikeymike wrote:
I've heard of quite a few things that "would never happen" on the Amiga platform. It is a shame I never hear the people who come out with such statements ever apologising when they've been proven wrong, and I don't see that it helps anyone in any way to be so negative about such projects.
Please be so kind as to reread my answer and understand why I am not being negative. Then also be so kind as to indicate where I am wrong with my analysis: just saying that I and Piru are 'negative' is not helping the discussion either.
You also have to understand that Mozilla is different from many other ill-fated projects because people donate money so it can be completed. That puts it into an entirely different category altogether. I am very willing to be corrected on the issue, because it would mean that OpenOffice is a mere stone throw away. I do not need to explain the impact the availability of both of these program suites would have on sales of AmigaOnes. In other words, I am already holding the door open for you to score and force me to apologize, and since there have been numerous occasions on these forums where I admitted I was wrong, you know I will.
-
[
Cymric wrote:
mikeymike wrote:
I've heard of quite a few things that "would never happen" on the Amiga platform. It is a shame I never hear the people who come out with such statements ever apologising when they've been proven wrong, and I don't see that it helps anyone in any way to be so negative about such projects.
Please be so kind as to reread my answer and understand why I am not being negative.
Project status? It is dead, as it was from day one. Some people just refuse to realise they are kicking a dead horse
Much.
I'd very much like to see Mozilla/derivative running on AmigaOS. It may or may not happen. Despite what has happened to the Amiga industry, it is still going, and products released that people said would never happen (PCI in an Amiga, an example of a claim I remember). That tells me to not underestimate what is possible.
If another perfectly capable, up-to-date web browser is released, I'd probably be just as happy using that. Amiga/compatibles *need* an up-to-date web browser, badly. And it is perfectly possible that the Mozilla port might not happen, but the experience gained from the attempt makes it possible for another browser to be developed. Who is to say what will happen.
-
Hello Cymric,
Your analysis is interesting, however it's fatally flawed:
You've idenitified 6 reasons for why a Mozilla port is almost impossible:
1. POSIX threads
2. GTK+ toolkit
3. Boehm garbage collector
4. fork()
5. Dynamic library interface
6. Size of sources
Comments about each below:
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.
It relies on the GTK+-toolkit, which does not exist at all on the Amiga.
(2) Good point. Someone is going to have to re-implement part of the GTK+ API. This is going to be a not-insignificant task.
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.
(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.
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.
You cannot even compile the sources on an Amiga because of their insane size running into hundreds of MBs. And so forth.
(6) See (5).
The insurmountable sub-projects are now actually 1 lengthy sub-project (GTK+ re-implementation) and an unknown (Boehm).
I think this makes an Amizilla port quite possible. It just means the developers will spend much of their time porting GTK+ rather than Mozilla...
-
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.
-
@cymric
when its finished and released ill bet my bottom dollar youl d/load it and use it ow thats right you dont have an amiga anymore ow well we will use it !!!
never say cant do
youll be eating your words i garentee you
-
Piru wrote:
I have to agree with Cymric in most points (however semi-working libpthreads does exist at least). fork() will never work on AmigaOS or compatibles.
I still don't get the point of fork(), is it just a quick and simple way to get a small part of your code executing as a separate thread which can do a function and die...?hmmm... putting it like that it seems really usefull :-D
-
I still don't get the point of fork(), is it just a quick and simple way to get a small part of your code executing as a separate thread which can do a function and die...?
No. It splits the current process in two, the only difference being the return code of fork() call. Everything else is 100% the same, addressing, fhs, etc.
AmigaOS or compatibles will never be able to implement fork().
-
For $8772.20 one could get Moz ported "overnight" for AOS/MOS @ India/China...
Well, not quite, but almost. ;-)
-
Piru wrote:
I still don't get the point of fork(), is it just a quick and simple way to get a small part of your code executing as a separate thread which can do a function and die...?
No. It splits the current process in two, the only difference being the return code of fork() call. Everything else is 100% the same, addressing, fhs, etc.
AmigaOS or compatibles will never be able to implement fork().
Yup, I know what it does, but I find it hard to see the point :-)
-
I find it hard to see the point :-)
It's for lazy coders so that they don't need to write proper asynchronous I/O in their apps. :-)
-
Surprisingly when a *nix machine creates a new process it uses fork().
BTW Win32 doesn't have fork().
srg
-
I e-mailed Tom and Jeff back in July asking for an interview for AmiWest 04. They told me the project was like 2%-5% complete. That they were still working on the underpinnings and had a long way to go (about a year or more).
That is not verbatim, but close (I erased the e-mail because their response was way too short for an article).
-
Piru wrote:
I find it hard to see the point :-)
It's for lazy coders so that they don't need to write proper asynchronous I/O in their apps. :-)
Ha! That's what it looked like (which is what I was hinting at earlier) :-D
But there must be some feature of using it that is not "doable" in a formal way, otherwise it would not have been included in the POSIX spec... would it?
-
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.
Acording to the dev list "Let's just say some people are misinformed and haven't looked at the source. I have at least 90% of the NSPR testcases passing and most of the XPCOM ones as well." and, from ym own, admitedly limited knowledge, I wold like to point out two things, OS/2 and Windows are both radically idfferent from POSIX but ports exist for both. GK+ is NOT used in several of teh mozilla prtos either, BeOS, OS/2 and Win32 spring to mind instantly, not to metion the support for QT and motif.
-
Mozilla is NOT gtk based. In fact there is an abstraction layer for the gui and windows/Be/MacOS/etc ports do not even contain a single line of gtk related stuff. I also think that porting gtk will be a lot more pain than just using regular (cyber)graphics.library calls and/or BOOPSI based gui(MUI/Reactor or custom one).
I am currently looking at the widgets and gfx sources to see if I can help... Not sure I'll have the time/skills, but who knows ?