@cgutjahr

Quote:

He's not a fanboy, he's Timothy DeGroote, a Hyperion director and shareholder.

How did you get to that result?

_________________

@Yssing

Quote:

Yssing wrote: @ferrels Quote: I'm sorry but there are quite a few talented Amiga programmers still out there. Just look at NetSurf and OWB, and they're getting more robust and feature-rich all the time....and all without any bounty money involved and the code is open to all....and not delayed for years. Well that is very good, and OWB is indeed a very good browser. But you can try and get those developers to port firefox for your favorite OS for 6k euros, maybe you can get them to drop everything and work on it for 2 years for 6000 euros, my bet is you can't but please prove me wrong. Quote: No one wanted to take on the Timberwolf bounty for several reasons, none of which were for a lack of programming skills as you've suggeste You do know that the mozilla bounty was way bigger and was open for a very long time, yet no one did it..

Which brings us back to the start of both Timberwolf and AmiZilla:

Porting it to Amiga with the resources at hand would never have lead to a fully useable browser that could stay maintained over of longer time.

Hence the sad state Timberwolf got delivered without ever being proberly fixed.
Hence noone taking on AmiZilla or the now opensourced TW.

Last edited by Kronos on 18-Sep-2016 at 10:46 AM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@zzd10h

Could you kindly share the instructions so that nobody else has to ask the same thing?

@Yssing

Timothy DeGroote being Hyperion is not really a secret. If you didn't know who "SimplePPC" is, check his profile and the e-mail address you see will confirm his identity.

@mr2

Quote:

According to one MOS betatester onboard network is not ready

BFD - The X1000 was released with several onboard devices not working that had to be replaced with plug in cards.
I think I can afford a network card. That can go in one of the PCI slots or a PCIe X1 slot.
Onboard sound? Don't need it, I and going to use a SoundBlaster Live.

I have a Radeon HD6970, but I'm not using that or the HD4770, I have.
I'm going to use a Radeon X1950XTX 512MB video card. Its the last card that features real 2D acceleration (and its not bad at 3D either), since most Amiga software use the former anyway, this card should have advantages over some more recent cards.

As far as ready, ask anyone who used it a shows where you weren't allowed to sit down and try an X5000 under OS4.

Oh, and its my personal belief that if Aeon was in charge of OS4 development, it would be progressing faster.

Last edited by Beans on 19-Sep-2016 at 01:14 PM.

_________________
Amiga! "Our appeal has become more selective"

@cgutjahr

I apologise. I misread your post.

Last edited by Yssing on 18-Sep-2016 at 08:21 PM.

_________________

Quick search finds this git repository.....

https://github.com/tfrieden/timberwolf

An easy download for any interested.
While the version of the code might be outdated, it might serve as a guide to future porting.
"What work is needed to get from point X to AmigaOS"
A git diff comparison of the original mozilla version and this repository might be valuable as a starting point for other programmers trying to learn.

Plaz

@Mr_Capehill

"Could you kindly share the instructions so that nobody else has to ask the same thing?"

For the moment, I have problem to compile it but I am in touch with Hans-Joerg.
Hopefully, with his help, it will finally work.

_________________
http://apps.amistore.net/zTools

@zzd10h

Quote:

For the moment, I have problem to compile it but I am in touch with Hans-Joerg. Hopefully, with his help, it will finally work.

After that if you want to find something to fix in the code look for timer device related code. This stuff is almost always broken in one way or another in Amiga apps.

In https://github.com/tfrieden/timberwolf/blob/master/nsprpub/pr/src/md/amigaos/amigaos_thread.c in pt_Wait() for example if Wait() returned with waitSig signal set, it may still happen that the time request has already completed (is not pending anymore) too, but the code as it is would not remove the request from the replyport (no GetMsg() or WaitIO()). Using a single "timerUsed" variable for two timer requests isn't probably a good idea either. And not setting it back to FALSE once a timer has finsihed.

@ferrels

Please stop talking. You obviously know embarrassingly close to nothing about software development to comment on any time frames or porting effort regarding such a huge project as Firefox/Timberwolf.

AmigaOS is totally alien to any other platform that porting anything bigger than a simple shell tool is a pain. The dependency tree of Firefox is monumental. I'm not claiming the Friedens are Gods, but it requires experience, talent and some serious dedication to even begin thinking about porting something like Firefox to AmigaOS, especially in the state AmigaOS was at the time. 2 (man-)years seems like a reasonable time to me.

After getting 1.5 month salary for 2 years work they were probably pretty tired of the project, and then spending another month collecting the sources to make it compile in a generic environment (not only their own, most likely very custom build SDK setups) probably came very low on the priority list.

Quote:

...... I'm not assuming anything. It's very simple math used in most industries. Two men, given a task projected to take one year, is 2 man-years in time. How the Friedens managed that time was entirely up to them, but nonetheless, the 2 of them had an entire year to PORT a project, not develop one from the ground up. And once they had decided that the project was complete, they delayed releasing the code and then stated "We have released the source as a gesture towards the Amiga community", as if they were doing us a favor instead of abiding by the terms of the bounty. That doesn't sit well with many people. .....

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Georg

That code is perfectly valid. If waitSig is set it checks md.timerUsed to see if the TimerRequest had ever been presented to the timer.device and then does a CheckIO() on it, if that returns true it does AbortIO() and WaitIO() to clear it.

You *do not* reset timerUsed after its been used as it's purpose it to verify that the timer request has been presented to the timer.device at least once.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

If waitSig is set it checks md.timerUsed to see if the TimerRequest had ever been presented to the timer.device and then does a CheckIO() on it, if that returns true it does AbortIO() and WaitIO() to clear it.

You mean: if that returns false it does AbortIO() and WaitIO().

But what if it CheckIO() returns "request is completed". Who is then calling GetMsg() or WaitIO() to remove the request from the replyport? If sigRecd had waitSig set, it at the same can also have the timersig set! Yes that's a somewhat unlikely scenario, but for an app like Timberwolf probably not if there are multiple busy threads running which can delay each other's execution.

Another thing with timer.device is to be careful with the signal that gets set when the request is replied. If the timer requests were previsouly aborted, the signal alone does not necesserily indicate that the request is really completed, you must make sure that the request has also arrived at the replyport. Check if GetMsg() returned NULL. Some manually clear timer signal after having aborted timer requests or before resending a new timer request to prevent getting a "wrong" signal.

@Georg

Quote:

You mean: if that returns false it does AbortIO() and WaitIO().

If returns the pointer to the TimerRequest ie request in progress it wil do the AbortIO() and WaitIO()

Quote:

But what if it CheckIO() returns "request is completed".

It won't . Once SendIO() has been called, the request is 'in progress' until WaitIO() or GetMsg() has been called on the TimerRequest port.

Quote:

If sigRecd had waitSig set, it at the same can also have the timersig set! Yes that's a somewhat unlikely scenario, but for an app like Timberwolf probably not if there are multiple busy threads running which can delay each other's execution.

That doesn't matter as the CheckIO AbortIO() WaitIO() sequence deals with that. and Wait() already cleared the signal.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

If returns the pointer to the TimerRequest ie request in progress

No, the other way round, if it returns the pointer to the TimerRequest it is completed, not in progress.

Quote:

It won't . Once SendIO() has been called, the request is 'in progress' until WaitIO() or GetMsg() has been called on the TimerRequest port.

No. You can do a test and SendIO() a timerrequest and then in a loop call CheckIO(). At some point CheckIO() will no longer return "in progress", but "done". No WaitIO() or GetMsg() invovled for the change from "in progress" to "done".

Quote:

the CheckIO AbortIO() WaitIO() sequence

Usually the sequence is:

if (!CheckIO(io)) AbortIO(io);
WaitIO(io);

Timberwolf was working great with some of my fav Firefox addons too & this with RC1 back in 2012!

Firefox addons with Timberwolf

it's just a shame it's useless now under OS4.1FE but thank goodness Fab, Kas1e gave us OWB else we'd have no modern browsers at all

Last edited by klx300r on 19-Sep-2016 at 04:54 PM.
Last edited by klx300r on 19-Sep-2016 at 04:28 PM.

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@Georg

Quote:

No, the other way round, if it returns the pointer to the TimerRequest it is completed, not in progress.

Oopps yes sorry misread the autodoc just now when refering to it.

Quote:

Usually the sequence is: if (!CheckIO(io)) AbortIO(io); WaitIO(io);

Which is the sequence in this case.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Actually I think that CheckIO() is probaby redundant as AbortIO() and WaitIO may both be safely called on completed requests as long as the request as been Sent at least once. So whether it works my way or your way it should be taken out.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

Which is the sequence in this case.

The code in the link has the WaitIO() call inside the "if(!CheckIO" block.

Quote:

Wait() already cleared the signal.

AbortIO/WaitIO sequence may not cause timer signal to be cleared, because if request is already completed at that time, no Wait() is called.

The app side Wait() may not have cleared it either, because this can happen:

sig = Wait(timersig | othersig)
--> othersig arrives, task unblocked, othersig cleared
[..]
-> timer request finsihes, timersignal sent and set
[..]
AbortIO/WaitIO -> not clearing timer request signal, because request already completed.

new timer request gets queued
sig = Wait(timersig | othersig)
-> task unblocked, because timersig (still) set
-> app sees timersig, but it must not rely on this alone to confirm that the
-> request is finsihed, because it may be a signal still set from previous request

@Georg

I was wondering this part, Forbid + Permit:

https://github.com/tfrieden/timberwolf/blob/master/nsprpub/pr/src/md/amigaos/amigaos_thread.c#L302

Does it actually immediately give up the CPU or what will happen..?

@Plaz

See also here: https://github.com/sahlberg/timberwolf