@Kronos

Quote:

The point of buying an "Amiga" is to be able to use the SW we know. The point of coding for "Amiga" is the love-affair with small-footprint OSes. And when I can't have the old API anymore, than I want one that is as modern as possible while still keeping it simple. I certainly don't want any compromises just to make it look more "Amiga-like".

Parts of AmigaOS API has changed many times, I don't understand why it should stay 100% similar forever. Even simple things like opening window is quite different now when you compare it to 1.x. AmigaOS API is still AmigaOS API anyway.

I think OS4 way is right. Backward compatibility is important now, but if you don't want to stay in the past forever then you have to change things, even if it means risking backward compatibility. AmigaOS API is quite old now and it's just good that Hyperion is improving it.

Last edited by miksuh on 09-Dec-2004 at 04:57 PM.

@Kronos

Quote:

Or maybe keep those 2 worlds aparte ....

If E-UAE for AmigaOS4 becomes on par with WinUAE and would be extended with some seamless emulation abilities, such a solution would be sufficient for me to run most classic Amiga software.

Of all other software I hope to see PPC native AmigaOS4.x specific versions. I wouldn't want to stick to AmigaOS3.x software for everyday usage (forever) anyhow.

Quote:

oh, wait, boxes are evil

What makes you say that?

@MikeB

Quote:

Quote: oh, wait, boxes are evil What makes you say that?

Did you never watch Terrahawks (sp?) on TV in the 80s? The boxes were most definitely evil!

_________________

@MikeB

Quote:

[...] Quote: oh, wait, boxes are evil What makes you say that?

as many Amiga OS 4.x followers sad things like ... boxes are evil ... some time ago, when "we" had to say why the Amiga OS way is better than the MorphOS way.

_________________
Best regards,
hnl_dk - Henning Nielsen Lund [Denmark]

Please send no PM to me, email me if you want to contact me. See you somewhere else.

@hnl_dk

Quote:

as many Amiga OS 4.x followers sad things like ... boxes are evil ... some time ago

Really? I must have missed all the action.

Although personally I usually prefer a fully native environment I don't think boxes are "evil". In fact I have been a vivid UAE advocate since the late 90s when Amiga emulation was also considered "evil". Back then from my point of view, because UAE was portable it would become useful for future Amigas as well.

@Thread:

As a side note, i would love to ask,as there we have two approaches to the same problem,and as at one point both solutions might need to either break compatibility,or start developing on another box,how many native MOS PPC software will work ok under the new QBox with new API's etc?i mean, what i do like about the OS4 way is that old 68k apps will break at some point, but meanwhile we do have native Compilers,and a native software base that should still work with newer API's, or can easily be recompiled/adapted.
Will Morphos need big changes from A-Box to be able to run on Q-box?, will native software running on the Abox could crash the whole box,while you was working on some program that's not yet ported to native Q-box?

Note, i'm not criticising MOS, i already choosen my path,though i do like to have some sort of clean competition.It's just that some things are not clear enough, or i didn't searched for it enough.Thanks for the answers.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

@hnl_dk

I don't remember anyone saying that the "box" design was "evil".

Why should good or evil come into it?

Difference between MOS & OS4?

We`re nice

_________________
2017 Camaro 2SS

@Rudei

?

I haven't tasted any Os4 or Mos users so I'll have to defer judgement.

_________________
******************************************
I dont suffer from Insanity - I enjoy it

******************************************

@Kronos

Quote:

Problem is that REAL and strict MP would require a completly new message-system, one that breaks 99% of all non-trivial SW. One could offcourse just keep the old API and allow both to be used, but this would mean that an old app could still kill the whole system. Or maybe keep those 2 worlds aparte .... oh, wait, boxes are evil

Amazingly enough, you managed a complete sentence without sarcasm. Congratulation.

There are other possibilities. You can let a task specifiy whether it can run isolated or not. A specific subset of the API deals with strict message-passing. Alternatively, you can divide address space into task-private and global spaces. A box-approach is only one of many different possibilities.

Quote:

For those thinking they could turn of 3.x-support, look at MacOS. How long did it take till every app needed was PPC ? And than, how long did it take till they all were ported to OSX ?

For the record, most well-behaved 3.x software works on OS 4. The problem are those programs that exploit implementation-specific details. Unfortunately there are quite a few of them, but that is not the fault of the OS.

Quote:

The point of buying an "Amiga" is to be able to use the SW we know. The point of coding for "Amiga" is the love-affair with small-footprint OSes.

Amiga for me has a certain set of virtues that I would like to see. It has nothing to do with running old software.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Ami603

ALL current OS4-SW (and all current MOS-SW) use the legacy API, with exec-messages
open system-structure and in case of BOOPSI/Reaction user-code running in a kernel-task.

So they can ALL kill the whole OS atm.
In MOS2.0 (with QBox) they could only kill the ABox.
In OS4.1 (.2/.5) they can either kill the whole OS, or you turn of legacy-support meaning you can't run them at all.

Both solutions will need a complete recompile/rewrite of apps before they can really benefit from MP and such like.

Think of MOS1.4 and OS4.0 as somthing like MacOS-8 or 9, PPC-native, but still not really modernized.

@MikeB
Maybe you should just stop talking about technical issues you don't understand.
"Box" does not mean emulated or non-native, it just means that something is running inside a safe area of the OS, where it can do no harm to the rest of the system.

Running UAE is nice, but how would such a system be really differnt (and more "Amiga") than running UAE on QNX ? In both cases the host OSes would have some sort of Amiga-look&feel, but both would also lack the well-known-Amiga-API (when you turn of legacy-support).

@miksuh
Yes it has changed, and that good
But the usual-suspects have babbled that the QBox couldn't be "Amiga" as it would feature an alien API, ignoring that a new API is absolutly needed when you want MP.
Sofar I have seen nothing that would indicate that this new APi would compromise on the classic Amiga-strongpoints, small footprint/easy to understand, and it will be no less
"Amiga-like" than whatever API Hyperion may come up with. Except for the name, but the Gateway+Amino-desasters have allready shown that the name allone won't make anything "Amiga".

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

@Rogue
Dividing SW in "isolated" or "non-isolated" with both useing differnt APIs and running in seperated address-spaces is pretty much 90% of what "boxed" means. All that is missing is a seperate scheduler, which makes absoltly no differnce for both users and developers.

Sure, OS3.x works under OS4.000000 without any tricks since it pretty much uses the same API as those used in OS4.000000-SW. The tricky part will be to run OS3-4.000000-SW in OS4.2, when real MP is introduced.

Thats why I used the MacOS9-comparision.

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

@The_Editor

Quote:

I haven't tasted any Os4 or Mos users so I'll have to defer judgement.

Silly man

_________________
2017 Camaro 2SS

@Kronos

Quote:

Maybe you should just stop talking about technical issues you don't understand. "Box" does not mean emulated or non-native, it just means that something is running inside a safe area of the OS, where it can do no harm to the rest of the system.

Actually a *sandbox* is a "protected, limited environment where applications are allowed to "play" without risking damage to the rest of the system."

Like I said, I don't agree that boxes would be "evil", how else can I advocate an *emulation box* like UAE? Does an emulated application crash the host system when run through UAE?

(Looking at the definition of a sandbox, I do find the name "QBox" rather strange for a non hosted MorphOS environment.)

Quote:

Running UAE is nice, but how would such a system be really differnt (and more "Amiga") than running UAE on QNX? In both cases the host OSes would have some sort of Amiga-look&feel

I don't agree IMO QNX and AmigaOS are very different in implementation, look and usage.

Quote:

but both would also lack the well-known-Amiga-API (when you turn of legacy-support).

I believe, you don't understand what Rogue tries to tell you.

@Kronos

Maybe you shouldn't be so rude or get so personal so quick?

ABox runs as a single task on what used to be called the "Quark" microkernel ( now Q-box). Much like UAE runs as a single Task/Process on a host operating system. E.g. a "box" - just operating at a lower level of abstraction. Its a fair comparison and a totally fair way of achieving backwards compatibility with 68k applications. As its a box approach that MikeB has advocated he clearly has never said the box approach was evil. Do you follow the logic now?

Whilst UAE can be run in a window and is effectively an entire sub-operating system in-a-task ABox adopts the display device and is the basis for all the drivers that are run. Sure that could be changed later on, but the "box" is not so useful unless there is something outside of that box that (A) is being used and (B) can be used without significant re-engineering.

I recall a MorphOS developer in a similar discussion with me in 2003 saying that the q/box and a/box lables were more or less just to focus the minds of the developers rather than being any kind of amazing design concept - we were discussing at the time the problem of display mastering between boxes without having to resort to a "soft driver" type approach.

Quote:

In OS4.1 (.2/.5) they can either kill the whole OS, or you turn of legacy-support meaning you can't run them at all.

Thats not even true.

With the OS4 design goals and intent if a task does not require access to addresses used in the address space of another task then it can be protected quite nicely. There are other design points that have already been outlined in this thread where address spaces can be shared.

This granular approach offers maximum backward compatibility, encourages the use of by copy ( deep copy ) future usage and yet still allows an improvement in the memory protection of the entire system - and therefore its stability.

The alternative is to be defeated and never even provide the facility to protect address spaces regardless of whether or not it would break an individual task or not then if you want to protect the system say "hey, well the a/box can screw up but we don't care about that, we got the parent q/box that can't be affected and it has its own design".

What on earth is the difference between that design and UAE running on Windows where UAEs main system binaries have x86 versions for performance ( a-la Amithlon)? It doesn't progress the core operating design, it abandons it, it ignores it and it never improves it.

Id rather support an OS progression that has some chance of improving the existing OS design than something that will forever freeze its main stability flaws for posterity and abandon it for a mythical underfined specification.

Thats also why Ive been always convinced of the validity of the OS4 path and skeptical of the OS5 claims.

MOS2.0 turns a/box into an effective UAE.
AOS4.x advances the operating system kernel to provide protection where it is possible and allow tasks to opt out where they would otherwise break and even then they are contained and can only cause limited damage.

I think Ive understood the MP goals for AOS4.x, no doubt Ill be corrected if I havent.

@DaveP

Exactly that was my point.
bah, the language barriers

Last edited by Ami603 on 09-Dec-2004 at 07:44 PM.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.

@Kronos

Quote:

But the usual-suspects have babbled that the QBox couldn't be "Amiga" as it would feature an alien API, ignoring that a new API is absolutly needed when you want MP.

Again something I missed.

I did see various people (inlcuding me) ask what the QBox would be like.

- For instance would it be anything like AmigaOS?
- Would it run ABox software transparently or do you need to start a whole ABox (Exec, Ambient, MUI, etc) environment? (For example an UAE environment would runs far more classic software).
- How exactly would these boxes co-operate? (Boxes were also said to be "planned" and/or being "negotiated" with regard to Atari TOS and other operating systems.)

AFAIK there haven't been proper answers to any of such questions, despite that the QBox was often touted as *the* solution to all limitations and issues surrounding the current ABox. If it's so important to the future of MorphOS and the ABox is considered to be dead end (Exec funtionality would not be expanded), don't you want to know more about the QBox?

@DaveP
Quote:

With the OS4 design goals and intent

Yep, "goals" and "intent", but I was talking about SW compiled for the current OS4 which offers none of those new APIs and will therefore suffer from the same problems on a protected system as as SW written for 3.x.

You can "improve an existing design", or you can make a clean cut, once you have reached the point where real MP can be introduced you will also have a system with a completly differnt API, since the classic APi is not cut out for this.

Now where is the big difference ? In both cases classic-SW can't directly communicate with new SW, but with the OS4-approach it can never be ruled out that a classic crashes the whole OS (unless you turn of legacy support).

Sofar I'm not even conviced that the OS4-approach will ever (bigger guns have allready failed on similar ones), while it is quite clear the the Box-approach does work.

Wether one of these will ever be really implemented is offcourse another question.

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

@Kronos

Quote:

Dividing SW in "isolated" or "non-isolated" with both useing differnt APIs and running in seperated address-spaces is pretty much 90% of what "boxed" means. All that is missing is a seperate scheduler, which makes absoltly no differnce for both users and developers.

No, it isn't. In a boxed environment, you limit the available functionality. The A/Box in MorphOS (correct me if I'm wrong) cannot use anything but the AmigaOS 3.x API plus x; no functionality of the underlying kernel is available. Most of all, no functionality of the fabled Q/Box is available. You can invent some cross-call API for that, but things will always look different depending on what box you are running in.

Making a task isolated, the only difference could be a single tag duing task creation.

Quote:

The tricky part will be to run OS3-4.000000-SW in OS4.2, when real MP is introduced.

Not really. As long as programs use as prerequisite what the autodocs tell them, and the API provides the functionality that is there, nothing will happen.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Kronos (and thread)

Well, isn't the simple point of OS4 to provide an updated APi so that eventually new (and ported) applications will use them so that they are MP 'aware' or 'ready'...eventually old applications would be phased out?

The old software and old APIs continue to work (but are either deprecated or not recommended) and if you run 'old software' you potentially compromise system stability (assuming they use same resources and adresses space)?

Or did I miss something?