Layers.library V45 on the aminet

[OlafS3]

Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm not specifically not talking about other old software.

What classic hardware do you use? 68020? 68030?

If people would at least help testing and send logs to Toni Wilen there would be a higher chance that Aros 68k (and expecially the Roms) would be improved. If only Wawa does something it is hardly motivating Toni Wilen to do something on it. If something is missing report it or set up a bounty for it, if there is enough interest there is a chance that somebody cares for it. Complaining about the situation is not enough...

Ok I understood you wrong, you do not want anything amiga-related. I think you are on the wrong forum now :-)

[OlafS3]

Not what I meant. The owners of said software obviously decide what they do and don't do with their property, and I'm not complaining about that. What I am complaining about is that we're stuck with AOS on our 68k Amigas, while something much better is possible, where we're also not tied to AOS anymore (including Aros). I'm specifically not talking about other old software.


Yes, Aros is an AOS derivative after all, and it would be nice to be able to get rid of that completely, because 68k can do better than AOS and Aros.

Get rid of anything amiga-related?

I think I read there was Unix on 68k revived, use that. But for me personally it would not make sense, I can use it on X86 already.

You "could" modernize AmigaOS (or any other related OS) but then you risk that no software runs on it anymore. Then you have a kind of BeOS with zero software, what sense would it make? A "proof of concept"?

[OlafS3]

Olsen , Thomas,

I have to ask a stupid question here.

When you would such a possible buyout of AMIGA OS - with the existing free AROS.
Where are the advantages?

Is AROS so far from this?
Or would AROS have already some areas where its ahead - like a MUI clone etc?

What is AROS really missing today?

First what do you mean when you say AROS? Here it seems you use it for AROS X86. AROS 68k is very different to the others (even though it inherits most of the advantages and disadvantages) because you can directly mix 68k with AROS 68k. From the view of a application there is no difference. AROS 68k when you download the nightly build is more or less a very basic 3.1. installation with Roms, small editor, more or less good-looking icons, MUI in form of Zune (still missing parts) and Wanderer as desktop. Basic problems with it are that Zune is still not 100% MUI38 resulting that not all MUI programs work or at least only partly work. The desktop Wanderer is based on Zune and slow, has bugs and is limited. That is what people look at and make (misleading) judgements on AROS. Then there are typical basic libs and devices from 3.1. that implement gadtools, intuition, AHI, CybergraphX 3 and so on.

The nice thing about Aros is you can replace almost everything, you can add installer by copying it in C, you can replace Wanderer with another desktop (I use Magellan), you can easily replace Zune with MUI (what I did in my distribution) and you can add almost everything by just copying files. That is how I created my distribution.

I have f.e. added almost any compiler from 68k to my distribution and they all work (including all examples). In newest version I just upload I have included working Modula 2 and Oberon compiler and the newest port of Freepascal (from this weekend). All were not created for Aros 68k because it did not exist at that time but all work on it.

I cannot say much about Aros 68k on real hardware, Toni optimized it recently and Wawa wrote that it becomes usable (on 68060).

[OlafS3]

Hi Olaf,

From what you say AROS 68K is already or can already be a very good AMIGA OS replacement?


If there are areas where performance could be improved like e.g EXEC, or LAYERS.
Would these be areas where some geeks ould help?

I would assume Cosmos would be talented for tuning Exec?

And I would think that Thomas would be the perfect guy to do layer super fast?

Thomas (as Olsen and others) "would" be perfect but he has already explained that he is not allowed to do so because of contracts he signed in the past. Everyone who was involved in AmigaOS development in the past has signed such contracts it seems, almost like a weapon to hinder competition. But nevertheless they cannot directly contribute because it could used against Aros then

[OlafS3]

Maybe these NDAs are time-limited (I wish they are) ?

it seems not

[OlafS3]

Then you will never be able to work in professional (as in: for money) software development. Such NDAs are quite common, and of course, the they forbid you to take the developed software and re-sell that to a competitor. Or would you pay for a software just to see that your competitor would get access to it, too?

It's a bit different for software that was licensed.

take the software and resell it yes of course, but in this case you have said it forbids you any source contributions to Aros even if there is no original line of code included just because you had access to the old sources. That is completely different...

good to take a lot of devs out of game

[OlafS3]

Well, look, first of all, I don't think we're "pulling in opposide directions", or that we aren't moving. This thread is about a move, after all, and I hope it's a move in the right direction.

Second, whether a processor is 7Mhz or not does not matter: If a given function (say AndRectRegion()) takes 1% of overall calling time to move a window, it does not matter whether you speed this up by a factor of two (realistic, if AllocMem is bypassed) or a factor of 1000 (unrealistic, unless you replace it by a NOP), the net effect will be NIL. It's really a very elementary truth that is independent of the processor speed. To get a speedup of two, *every single* function in the call path would have to be speed up by the very same factor, and that's not going to happen.

The problem really is that Cosmos has apparently never worked in a larger software project with exploding complexity, and thus has no feeling in what type of modifications one would want to make, and in which step of the project. Yes, of course it makes sense to optimize a bottleneck of a program, and there to use processor-specific code. But it does not make sense if you have additional constraints that are harder to characterize, such as maintainability, or portability. If the code can work on an old machine, and the speed impact by not using the latest processor instructions is below measurable, it makes no sense to use such optimizations. Basically you compromize compatibility and get nothing in return. In the same way, it does not make sense to replace an AllocMem() by a copy on the stack (all provided this is valid) if you don't receive a measurable effect. Again, you would compromize maintainability (as in: There is a single constructor call for a certain object) and would not gain anything measurable in return.

As always, you have to find compromizes in development, especially when it comes to larger and complex problems, and "running time" is not the one and only goal. You not only want to deploy your software on a wide variety of hardware, you also want compatibility to existing software, and you also want to be able to read your code from ten years from now. You also want that customers can install and use the software easily, and are not confused by compatibility issues that version C of a library can only work with programs P and Q, but program R requires version B, and program S may work with C, but only if specific settings are made...

The overall problem cannot be reduced to a simple count of cycles.

one question... I understand you are not allowed to contribute any changes to Aros because of the contracts. Would you be allowed to look at the Aros sources and give tips what to improve and how (in abstract form) or would that be problematic too? And someone else does the real changes? I think even the Aros devs would be grateful for tips.

[OlafS3]

I understand

it is a pity that the few experienced devs left cannot contribute because of silly contracts from long ago

[OlafS3]

They can contribute to Aros if a bounty making OS3.1 open source succeeded. This would effectively end the NDA, or did I miss something (again)?

Also, Thomas Richter and olsen have effectively convinced me that binary patching is bad in the current situation, only took like ten posts of explaining to do it (hehe). Still, I can't help liking Cosmos and respect what he does, it goes beyond logical reasoning, so no need to convince me further.

To be honest I do not believe that such a bounty has any chance because of both the money it would need and the parties involved. You read the discussions here, people will say why donating for such a bounty when you can get everything in amigaforever or for free (illegal). Most NG supporter will say for what do we need the old sources (in case of AmigaOS they already have access). It would be of big benefit for AROS and MorphOS to remove unknown compatibility issues and similar but that brings me to the third party I do not need to name who has no interest to support AROS or MorphOS. And a common spirit between the camp is not there (expecially regarding parts of the core developers). AROS certainly is the exception because of the openness. Short: Someone can try it out like I did with Magellan. Ask the known parties and if they really say yes make a bounty.

[OlafS3]

We may not agree with the situation, but the fact is that money changed hands to acquire the Amiga operating system, and as such represents a significant investment for the buyer.

The owner of the technology is naturally interested in preserving the value of the investment, which is why programmers who were involved in AmigaOS development work signed contracts governing what we may or may not do with the knowledge we gained. Unless these contracts are canceled, we are bound by them.

How much of a risk there would be in violating the terms of these contracts is difficult to say. Speaking for myself, I don't really want to find out because it is not something which I consider *that* important.

We understand that, nobody can expect someone else taking legal risk, even if they would be theoretical (and I do not think that they are totally theoretical even today). Nobody is forced to sign such a contract.

[OlafS3]

I'm not sure what will become of this work, but here's a sample. I'm having trouble getting a table to format right in here, so read if you can, sizes are in bytes.

These aren't cherrypicked, they're just the ones I've done and tested enough to feel confident in them working like the originals.

Code: [Select]


Command OS3.1 Mine AROS (Vision 2.7)
AddBuffers 444 356 2168
Break 432 504 3732
ChangeTaskPri 460 476 3096
DiskChange 312 248 2052
Lock 536 628 2788
MakeDir 464 364 2732
MakeLink 700 556 2528
Relabel 584 580 3312
SetClock 668 636 4840
SetDate 688 724 3212

Total 5,288 5,072 30,460



My first reaction was "who cares today for disk capacity" but then I thought a little and must admit that this is indeed important when you want to run it on classic hardware. Aros devs use PCs for development so stripping software down from 3 KB to 500 Byte has not a very high priority but if people want it in that direction it would be good if more people become involved. Of course you can replace most components so if you have reprogrammed something it could be used. But this is certainly a basic problem, many components certainly could be optimized.

[OlafS3]

You are not *forced to* by the language to do that. C and even more so C++ or Java requires(!) you to use language constructs to organize your code that are quite expressive and rich, and allows the compiler to check for the correctness of these constructs. In Assembler, you have nothing. Pretty much every Java code looks the same - same style. In C++, you have more freedoms and several programming styles are possible, but one way or another, the language offers you constructs how to address specific problems, and the compiler is there to check for the correctness of such constructs.

Anyhow, we're arguing in circles. Given that you never worked on a major project in assembler, I see that you can hardly judge why all that is beneficial for a project, and why it helps so much. Don't you think that it's rather ignorant to make such arguments without ever having gone through all this at least once?

Try it, then we do the talking. Probably in five years if you start now.

I think you and Thorham (and Cosmos) are looking at it from a completely different perspective. You look at it as a professional developer, they look at it as hobbyists doing it just for fun and are happy if they squeeze out some bytes or make it a little faster on their own system and environment. This discussion about sense or nonsense of using assembler or if it makes sense that everyone does his own patches can last for another 1000 postings and will not come to a end. It is the same as discussing if it makes sense to use a exotic OS instead of mainstream. As long as they offer only patches (and do not spread the changed original) nobody can do anything about it. There are countless patches on aminet and everybody knows that using it is risky so people are responsible themselves if they use it or not.

Better would be AmigaOS 68k would still be in development but we cannot bake reality..

[OlafS3]

Apparently they have technical issues with vbcc and a very gcc specific codebase.

http://en.wikibooks.org/wiki/Aros/Platforms/68k_support/Developer/Compiler#VBCC

I still think this is the right path for native 68k though, which is the one platform I want and that I think is underdeveloped.



I haven't discussed it with them because I'm still not sure I'm on the right track. I may realize exactly why they haven't done it themselves and I don't see a point in distracting them or making it look like a fork. It's just my little playground ATM.

The discussions lately (especially from you and OlafS3) convinced me to do something  instead of just complaining about how they handled it, lol.

That is great :-)

I have reached the end of line regarding Aros 68k now. When you look at functionality I think the difference is not far but it still misses needed optimizations to reduce size and adapt it to the classic hardware. AmigaOS is still unbeatable there (its biggest strength and weakness at the same time). If some skilled developers would help there and help to remove incompatiblility issues everyone would benefit. And for the Aros developers compatibility to 3.1. is the main goal. Thomas has said he will answer questions so perhaps if we all work together something good can come out.

@Wawa

On aros-exec there is someone wanting to help testing on real hardware:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8851&forum=4&post_id=90173#forumpost90173

perhaps you can get in contact. We need more people being active then the progress will be much faster.

[OlafS3]

who? magorium? i doubt he needs my help, anyway he didnt asked for any so..

no

ntromans