@EntilZha

So, when are you going to release this?

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@Rogue
Quote:

That is true. In all considerations backwards compatibility was always the secondary goal. Compatibility IMO is important, but only to a certain degree. Well-Behaved programs do work; everything else would go through UAE. It was obvious that this would create some shortages in software where old software would cease to function, and it is the hope that developers will fill these holes with new software. In the end, you can only keep to backwards compatibility for a certain time without moving forward; at one point you have to let go. Our idea was that in all the years so much was neglected that it would make sense to make a BIG step forward, even if that meant loosing some programs. Also, I like the AmigaOS as it is. We could have chosen to go a different route and box it in, to be replaced later by something else, but we chose not to do that. Instead, our idea is to develope it further, keep it as Amiga as it is, and thus make it the logical follow-up to the classic OS.

So MOS is doing it the OS X way, you're doing it the BeOS way.

Be changed their executable format at one point and it killed everything in one go.
The thing was at the time (around R4) there was an active development community and all they had to do is recompile, it was fixed so quickly you don't even hear it mentioned these days. In the early days I believe it happened quite a few times.

So it has been done before but I suspect in this case will require more than just a recompile.
As long as developers are kept well informed well ahead of changes it shouldn't be too difficult.

I'm curious though, why didn't you do this from the very beginning - or would that have taken too long?

Last edited by minator on 11-Dec-2004 at 02:04 AM.

_________________
Whyzzat?

@olegil

Quote:

So, when are you going to release this?

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@minator

Quote:

I'm curious though, why didn't you do this from the very beginning - or would that have taken too long?

No, it would have taken less time (speaking of backward compatibility through a boxed approach, assuming you mean that).

However, the reasons against this have been brought to the point by DaveP elsewhere in this thread. What he describes there are the exact reasons why we did it in the first place.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@EntilZha

Quote:

it would have taken less time (speaking of backward compatibility through a boxed approach, assuming you mean that).

No, I meant having a clean break from 68K, adding memory protection from the beginning and not assuming any compatibility on PPC. Leave UAE to handle all backwards compatibility.

_________________
Whyzzat?

@EntilZha

Quote:


You're kidding, right?

_________________
Site admins are people too..pooff!

@minator

Quote:

No, I meant having a clean break from 68K

But they have done a clean break. ExecSG is a totally new PPC Exec kernel with many improvements while taking into account important future functionality.

It would have been *much* easier to host the old 68k Exec on top of for instance a LinuxPPC kernel by usage of an emulation box (a la Amithlon) or to use a PPC re-implementation of Exec in a box, without adding new functionality (a la ABox/MOS).

ExecSG has taken a lot of effort to be done right!

@MikeB

He's talking about the burden of compatibility, not leaving 68k stuff in the kernel.
About the kernels now, I think that apart from the AROS exec, all PPC exec implementations would be difficult to host (including ExecSG/OS4 and ExecPPC/MOS) for different reasons.

_________________

@AMiGR

Quote:

He's talking about the burden of compatibility, not leaving 68k stuff in the kernel.

IMO so far neither has the MorphOS team, AFAIK most of the work has been spent on the ABox.

Quote:

About the kernels now, I think that apart from the AROS exec, all PPC exec implementations would be difficult to host (including ExecSG/OS4 and ExecPPC/MOS) for different reasons.

Why?

And MorphOS already uses this approach. I believe the naming has confused a lot of people. IMO a better name for the QBox would have been QuarkOS or something like that.

Let's take Linux as an example. Linux is a far more complex kernel than Exec is, but MkLinux hosts Linux on top of a Mach microkernel just fine.

@minator

Quote:

No, I meant having a clean break from 68K, adding memory protection from the beginning and not assuming any compatibility on PPC. Leave UAE to handle all backwards compatibility.

This approach would probably have been similar in scope to what we have now, i.e. you wouldn't have some of the problems we have now, but you would have a bunch of stuff (intuition, dos, etc) that wouldn't work any longer and have to be rewritten...

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@MikeB

Quote:

Linux is a far more complex kernel than Exec is, but MkLinux hosts Linux on top of a Mach microkernel just fine.

Correct.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment