Quote:

I agree with the sentiment about taking over the machine. It's not needed anymore.

However, forbid()/permit() and disable()/enable() are vaild alternatives to placing semaphore locking around all critical functions. The AmigaOS was designed to be lean and fast. Given the choice of locking a semaphore before allocating memory or altering system structures (for example), or just turning off the task switching or interrupts for a brief few microseconds, the OS coders chose the latter.

Either method can work. The problem with forbid/permit/enable/disable was not the functions, but the macro versions that were made available to speed up programs even more. They should have NEVER made macros for it available. Programs should have ALWAYS been made to use the exec functions for those.

Quote:

I would never, never allow one program to take over the machine.

We must move away from that mind set... I'm even unhappy with the forbid() (and disable()) functions... :-/

Okay, that's part of the solution.

we already have SDL

Hello. After reading some other topics here, something's come to mind. What about SDL compability? Is anyone porting SDL to AROS? I think it would be a good idea to "make a declaration" of some kind, standardizing on one "take over the machine for games, emulators, and other special cases" API for AROS. Either our own home-grown thing or a standard, off the shelf thing. I know that AROS has the .hidd's and you can communicate with them directly, this is probably a better approach, but is there a standard way of "turning off" the rest of AROS for full-machine use? Like, full CPU, full screen, take over audio, and this sort of thing? I think we should have a clean way of doing this, any ideas?