@Chip

Quote:

What about patching the MOS binary during load?

It could work. Pass ExecBase as a third parameter and patch startup code.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

What you are talking about is just a minor issue. There are several possible hacks to retarget the ExecBase address, either via MMU (protect 0x4 address and retarget it on catch) or simply patching the 0x4 address on task launch and remove it at suspend. If everything goes bad then even the ELF loader could be tweaked to relocate the 0x4 address accesses to different memory position.

There is nothing what would prevent any MOS programs to run on OS4 with the same approach what OS4emu implements. (Filling the gaps of missing functions by implementing them.) Probably it would be even easier, because MOS implements only a 3.1 environment with some new functionality, no need for reinvent the changes since then.

Possible, but I see this 100% pointless. (There is no any app what I would need from MOS.) Anyway, who have plenty of time to waste: be my guest and go ahead.

About Sputnik: it will be nice once, when it will be ready, but I would rather go for a "native" OS4 application, which makes use of OS4 functionality instead of hacking an alien app to somewhat running on it. I can wait...

_________________
Álmos Rajnai

@Chip
@Chain-Q

Please stop arguing in this thread, take it via PM instead, thank you

_________________
Site admins are people too..pooff!

@Rachy

Exactly my point.

We won't see any Sputnik on OS4 for a long long time anyway. It depends alot on MUI4
and until we get that first we won't see Sputnik at all.

Btw how's the MUI4 porting going? Jens? Stefan?

_________________
/Harry

[SOLD] µA1-C - 750GX 800MHz - 512MB - Antec Aria case

Avatar by HNL_DK!

@Rachy

Quote:

There are several possible hacks to retarget the ExecBase address, either via MMU (protect 0x4 address and retarget it on catch) or simply patching the 0x4 address on task launch and remove it at suspend.

Latter would beed MMU management anyway because 0x4 is write protected. The first one requires that you install a handler but at least public docs are not offerint this option.

Quote:

If everything goes bad then even the ELF loader could be tweaked to relocate the 0x4 address accesses to different memory position.

How? Access from absolute address doesnt require relocating information and ELF loader cant figure out where 0x4 address is accessed. But it could maybe analyse startup code and detect where 0x4 address is referenced.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Chip
Quote:

Why would OS4 developers should care how MorphOS was made?

Well, IMO it's always clever to look at how other people solved things before you, especially if it's your competition... But nevermind...

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@Samwel

Quote:

It depends alot on MUI4 and until we get that first we won't see Sputnik at all. Btw how's the MUI4 porting going? Jens? Stefan?

from MUI4 (MOS beta-version), file "changes" (Stefan Stuntz):

Quote:

only a MOS version is available at the moment since that's the system I use for developing. no keyfile needed, no timeouts. there was supposed to be something for OS4 too, but folks over there were (and still are) unable to supply a machine for porting.

@Chain-Q

Quote:

Well, IMO it's always clever to look at how other people solved things before you, especially if it's your competition..

In this particular case I don't think it would have been a clever choice to copy MorphOS...

@hatschi

The OS4 port of MUI4 is being done by Jens Langner...

@COBRA

Quote:

In this particular case I don't think it would have been a clever choice to copy MorphOS...

The QBox idea is quite good (even if it hasn't evolved much).

If OS4 team wants to have full memory protection and other goodies while keeping the system compatible with old apps they'll have to implement a similar "sandbox" idea.

MacOSX also did that for Classic < = 9.2 apps.

IMHO opinion it's a good idea but the sad thing is that Ralph didn't make the QBox grow as much as people would like.

But (clever or not) OS4 team will have to do the same (keeping the current API compatible apps in a sandbox) in the future if they want OS4 to have modern features, so you'll have to repeat what MorphOS team did 4 years ago.

Last edited by Crumb on 29-Sep-2006 at 01:18 PM.
Last edited by Crumb on 29-Sep-2006 at 01:17 PM.

_________________
The only spanish amiga news web page/club: CUAZ

@COBRA

Quote:

Quote: Well, IMO it's always clever to look at how other people solved things before you, especially if it's your competition.. In this particular case I don't think it would have been a clever choice to copy MorphOS...

These little differences in the Exec base predate to 3.5/3.9 days in 2000 when MorphOS was already going on its own route.

ChainQ wrote: "but simply without caring about what other people did before, and why they did that." OS4 being based on 3.9 makes it incompatible (from 68k side) in this regard unless they threw AVL functions away. MorphOS has PPC cache control functions on these slots mostly. It is not white and black really...

edit someone did copy MorphOS because OS4 is no longer using MMU as a mandatory 68k->PPC transition scheme

Last edited by itix on 29-Sep-2006 at 01:36 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Crumb

Quote:

The QBox idea is quite good (even if it hasn't evolved much).

You're talking about something completely different now, we were discussing the differences between how OS4 and MorphOS library function calling works from native PPC code.

The idea of sandboxing is very old and I also see it as something which must be done at some point. You would need a whole new API if you wanted seperated address spaces, etc. In that case you'd pretty much be writing a whole new OS from scratch, which will have nothing to do with the original AmigaOS, except that if it is done well, it could inherit some of the qualities of the original AmigaOS (compact, efficent, etc.). Under MorphOS it's quite easy for a badly behaving app to bring down the whole OS and freeze everything, so there is nothing like this implemented there. So MorphOS is not implementing a sandbox, infact it is itself the system which would have to be sandboxed in the future, just like AmigaOS 3.x, 4.x.

@tomazkid

What about post #166 ?

@Chip

If there's an insult on #166, I can't see it.

_________________

@Chip
Quote:

Chip wrote: @tomazkid What about post #166 ?

What about taking this to PM?

@Chip

There is absolutely nothing wrong with post #166.

Mark

_________________
IceStar Media Ltd.

@COBRA

Actually it is allready sandboxed. Problem is there is nothing running outside of it that could been seen by us mortals (I somehow doubt that I ever managed to crash Quark).

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

@AMiGR

Who told there are any insult?

Tomazkid asked us to continue the arguing in PM:
Quote:

Please stop arguing in this thread,

I think it was very clear request.

@hatschi:

Thanks, but why just me?
Anyway, you also didn't PM me...

Last edited by Chip on 29-Sep-2006 at 02:58 PM.

@Kronos

My understanding is that every thing is running in ABOX, so there is not a lot you can crash out side ABOX really? Well if every thing is in side ABOX then that include drivers as well, if a drivers crashes some hardware registers, some how locks up the hardware then quark comes full stop right.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Crumb

I do not agree that you need have safe environment (Box), for example forbid() and permit(), can be replaced by queuing or locking whit out removing forbid() and permit(), forbid() and permit(), will just en up being bad programming practice, it is theoretically possible whit the interface system, it possible to send out warnings to developers compiles for newer OS when they do some thing that they should not do.

A normal program for example does not change or patch any thing in side the kernel, or try to hack some program memory of different task, so they should run quite safe even if heavier memory protection is added, and even if the old message passing system is abandoned, there is possible to keep it for backswords compatibility, and having a more secure way for newer programs.

But clearly there are a few bad programming examples in OS3.9 NDK that should not be done, for example assume that you have access to signals value whit in message port structure, that might end up being protected in the future, as result IExec -> Wait() becomes restricted to kernel (or maybe drivers that allocate memory/signals for the message port, and basically builds the structure from stretch.)

It is theoretically possible to build memory protected message structure now, if you do not share that message port whit external task, a task that do that can execute external function from libraries as long as the library do not create a new task or forewords that message port to a external task.

Last edited by NutsAboutAmiga on 29-Sep-2006 at 04:13 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS