We've decided that it's about time we release Timberwolf's source code to the public.

To that end, I've set up a project on github here:

https://github.com/tfrieden/timberwolf

If you want to become a contributor, let me know and tell me your github user name so I can add you.

The code is licensed under MPL, naturally, but we kindly ask that changes or additions should be returned to the project, in a true open source spirit.

Build instructions will be added later.

Well, to put up a bit of an update, I've started updating the current version to the latest baseline source, so wit ha bit of luck, the next version will be Timberwolf 19.0. No ETA yet, though, as this is a bit of work still (60 MB packed source for 4.0.1, 90 MB packed source for 19.0, i.e. lots of differences).

I opted to update first to the latest version on the off chance that the 100 % cpu was due to the 4.0.1 version. I had some problems with the Windows version back in the days, so it might resolve itself automatically. If not, I'll have to look at it again.

We'll see... just thought I owe everyone an update on the situation. Thanks for the good wishes, it seems they helped.

I need to apologize for the lack or progress in the recent weeks.

The reasons is that I'm still suffering from complications due to a rather harmless operation in August which makes working painful for me (literally). Since the whole thing is taking so long to heal, my doctor is now sending me from expert to expert on a quest to find out if there is a more serious cause behind my current condition.

I currently have to limit my working hours to the absolute minimum (i.e. the amount of work I need to do to get by financially), which sadly means Timberwolf is not getting it's share of attention.

If all goes well, and nothing bad happens, I should be back on it before the end of the year.

Again, apologies for this, but it's currently beyond my power.

Great, someone announces LibreOffice, people complain about it. If they would have announced an Abiword port, you would have complained about "Why not OpenOffice/LibreOffice/SomeOtherOffice" or "Why not port Doom 3 instead".

Elwood, no offense, but this sort of destructive comment is uncalled for. If they want LibreOffice, let them do LibreOffice... you don't have to use it when it's out, you know

Quote:

As has been said, MEMF_PRIVATE means private to the process. If it is not accessed outside of the process, it's OK.

@ AmigaBlitter

The included cairo is a straight recompile of the original, with no Amiga specific changes. The 4.1 version has Amiga-specific addition (like hardware surfaces). We use the other one with Timberwolf because Timberwolf requires a newer version than the one that comes with the SDK and does not use hardware surfaces, anyway.

@ all

thanks for the good wishes

Quote:

Actually, that's not quite true. The scheduler just restored the task context, it does not bother about the tasks code. It does not access the actual task's code. So, assuming that a task is rescheduled and the task's current code is paged out, the scheduler would just load the context, and restart the task. Of course, the newly launched task would then not find the code in memory, would page fault, which would cause it to be suspended again and cause a page-in operation on the page that was to be executed. Only then would it launch successfully.

The same is basically true for any task that is launched by the scheduler that was interrupted on a page fault that has not been served up to then, data or code doesn't matter.

Quote:

This is a bit misleading in it's wording. It does not have anything to do with 68k code, but rather the fact that no program (especially not programs that are basically ports from OS3) has the ability to flag parts of it's code as interrupt executable. Therefore, any ode has to be assume interrupt executable (the other way around would be problematic).

So it's not 68k compatibility, but rather backward compatibility in general.

Quote:

I think that is an area that is prone to misunderstanding, that's true. Most people associate shared memory with locked memory, and private memory with unlocked (page-able) memory.

However, there is no connection between shared/private and locked/unlocked memory, only the fact that shared memory is by default allocated as locked. This is simply because most of the time, shared memory is assumed to be used for things like system structures, messages etc, everything that has to be accessed by multiple processes.

Private memory, on the other hand, is supposed to be accessed only by the application allocating it. As such, it is allocated in an unlocked state by default since the MEMF_PRIVATE has to be explicitly given, and the application is supposed to "know what it's doing".

Currently, these two types of memory are also only semantically different, they are, however, not really different in the sense that even now, MEMF_PRIVATE could be accessed from other processes as well (although it would be considered a programming error), simply because the system does not yet offer real per-task memory contexts. This will change in the future though.

Quote:

The pager favors old data for page-out operations, so memory that is frequently accessed, or (in theory) code that is run often wold be relatively "hot" and thus would be unlikely to be paged out.

The problem with memory paging in AmigaOS is that nobody can really tell what the memory is used for, and when it will be accessed. So backward compatibility dictates a rather "conservative" memory locking, basically, everything that is not implicitly marked as available for paging has to be locked in memory.

Code is sadly one of those, since you can never know what code can be executed in what context. If code is run in a task context other than the disk devices and the pager itself, it could be paged out, but as soon as code is executed in a environment that does not allow waiting, it can not be paged out.

Having said that, we are working on "fixing" this situation. For example, we have plans for running interrupts like tasks, i.e. an interrupt from a hardware would basically just signal a task that such an interrupt occurred and the interrupt handler code would run in a high priority task. That way, it *can* wait and thus would be able to wait for paging operations.

This is just an example, of course, there are other problem areas, but rest assured that we are working on those.

Subject says it all, RC3 is currently in the os4depot upload queue. It should fix the slowdown bug of the last version, the crashes with cairo on non-AltiVec machines, and a few smaller issues.

As usual, feedback to the bugtracker please.

Apologies again for the long delay of RC3. As I mentioned earlier, I spent a few days in hospital and even though the operation itself wasn't a problem, I had some complications that lead to a very painful phlebitis in my right arm. Still not fully recovered, but fit to continue working now.

Now that I'm back I can give a more detailed explanation. I couldn't work on RC3 yet because I spent a few days in hospital. Nothing serious, but it was urgent and had to be done, otherwise, it could have become serious.

I'm still a bit groggy from the operation and won't be able to work much for the next few days. Expect rc3 end of next week.

Apologies for the delay, it was inevitable.

Thanks for the feedback. Seems I need to work on sqlite and most likely keep cairo at the original version.

Please also review your bug reports on the bugtracker, and if you think that a bug needs to be fixed, change it to "Medium" or even "High" priority, depending on the severity. Crash bugs, especially reproduceable ones should be marked as High priority, and preferrably with a way to reproduce it.

What I don't understand, though, is why the browser works find on my machine, with the new .so's installed. I'm using FFS on my test partition, IIRC, so I'd like to hear whether you are using something else ?

Trevor, the old libsqlite will not work on JXFS

Can someone please try with the old cairo but the new libsqlite ? I would like to see whether it is working or not.

Thanks.

Regarding replacing cairo: If you do replace it with the old version, also take libpixman from the older archive.

Can someone also please summarize what the situation is if you replace libcairo, libpixman and libsqlite with the old versions ? Speed acceptable again ? Or still too slow... ?

Sigh...

Let me check what's wrong there. For the record, it worked of course flawlessly on my machine....

Subject says it all, it's currently uploading to OS4depot and should be in the upload queue shortly.

There's a bunch of changes in this version, please consult the bugtracker for information on bugs fixed.

Highlights of this release are as follows:

- The UI font size now adapts correctly to the system#s default font
- Downloaded files can now be directly opened with user-selectable programs, for example, you can use UnArc to open a newly downloaded archive.
- Should now work without RANDOM mounted, it will fall back to using pseudo-random numbers (i.e. rand in newlib). RANDOM is an entropy collector, and thus generates much more reliable random numbers. If you can, use RANDOM:
- Should be slightly faster now (html5 benchmark said between 0 and 20 % faster) due to new Cairo build (latest version). Don't expect miracles, though.
- The bookmark database is now using a new scheme that should make concurrent access possible. This was necessary to make sure that the user interface is correctly enabled when the browser is launched with a web page (home page/command line). The upside is that it might now work on JXFS (please try). The downside is that this has to be tested and might make it necessary to have an rc3

Future course:
As already hinted, the next thing we want to achieve is getting updated to the latest Firefox build (14.0, I think). It wasn't possible to do that during the bounty as that would have been a fast moving target. Now that the bounty is paid off, we'll tackle that.
Once OS4.2 is out, we'll add the OpenGL and WebGL support, making it fully hardware accelerated. I'll evaluate the amount of work it would be to implement a non-OpenGL layer manager, but it looks like a lot of work... we'll see...


As usual, feedback to the bugtracker, please.

@ samo79

I didn't fix it yet, it's been a cosmetic issue for me, so I didn't prioritize it.

Currently building rc2, and since there has been massive changes in the database handling (necessary for fixing a bug with the user interface not becoming active all the time), there might be the need for an rc3, anyway. I'll see that I can fix it then.

@ fingus

Thanks.


Firefox is pretty modular, so it's easy to work on different parts in parallel. GFX (the graphics parts) and Widget (the User Interface Parts) are the biggest chunks when it comes to porting, and they are pretty much separate.

The rest, bugfixing in general, can always easily be divided...