Piru wrote:
@Hans_
Why?
Say for example everything in AmigaOS and amiga apps depend on the shared memory model.
To mention few inside the OS itself:
- Libraries in general
Libraries are generally written such that the application holds the data itself. Thus the code could be shared (and protected) whilst the library calls remain within the application's process. Per-application globals can already be handled too, so I don't see the big issue here.
- Devices (timer, audio, trackdisk, scsi.device etc)
Yes, the devices are going to be a pain. But how many of the device APIs actually pass pointers to the driver internals? The input device, timer device and others definitely don't. Their message internals could remain the same. For the trackdisk and scsi.device, the application wouldn't be able to put the read/write buffer just anywhere, but that's the application's problem, not the device driver's. When working on a project involving controlling CD/DVD-R drives, I was anticipating a move toward increased memory protection and ensured that the entire contents of the message were allocated in shared-memory. It's doable.
I'm not too familiar with the other device driver APIs, but I'd expect most of them to have similar issues. Most of the time, it would be the application that has to change.
- Exec Message passing
Well, obviously. But what kind of a change are you thinking of? I'd expect the message passing by reference to continue, but with a requirement that the entire contents of a message must be in shared mem (or temporarily shared mem, if possible), and the message receiver isn't allowed to cache pointers (i.e., after a reply message, it no longer has access).
- Exec IO interface (devices)
Already covered above.
- dos.library <-> filesystem interface
- filesystems (they reply extensively on the message passing)
I don't know enough about these to comment. You're probably right that these would require extensive rewrites. To be honest, I think that DOS is the messiest part of the Amiga API. If anything would need a rewrite from scratch, or simply be replaced with a more modern alternative, it would be DOS (at least get to get rid of all the BCPL stuff).
- Exec interrupt interface
Don't IRQ handlers operate in kernel space? If so, what's the issue?
- Hook interfaces all over the place
How many would involve data crossing over process boundaries? Yes, those would be a real pain.
- ARexx
The impression that I get is that people want ARexx to be retired, and replaced with something more modern anyway. One of the open-source scripting languages (Python?) would be a good candidate.
All of these would need to be rewritten, and since the dependacy on the old legacy APIs would be all over the place, and support for things such as MP, SMP and 64bit sizes would be missing, it would almost be better to write them from scratch anyway.
Exactly what is the difficulty with expanding ints to int64s? We're breaking compatibility anyway, so keeping structure alignment isn't necessary.
I also disagree that sandboxing would somehow help migrate the system gradually. You still need something to run the sandbox on. For the sandboxed environment to actually work you'd still need pretty much the whole host opearating system done already. Even with optimistic guestimates that'd take over half a decade (here assuming everything else such as the highly skilled and well motivated developing team, being paid and doing fulltime work would be provided).
To get things started, you'd need the new exec kernel and a set of device drivers running before the sandbox could be put in place. However, after that, the process could be more gradual.
Hans
BTW, some people enjoy retrofitting and enhancing their old cars/motorcycles. Probably the most interesting of those would be Burt Munro taking a motorcycle designed in 1901 with a max speed of 60 mph, and setting a world speed record of 190.07 mph (unofficially 205.67 mph was reached) in 1967.
