Even hooks can cause headache. In older OS4 kernel versions you had to use 68k stub to get working PPC dispatcher for MUI (this was fixed later, i dont know what was issue)
The issue where hooks that where called directly, not via Utility/CallHookPkt. If this stayed within the 68k emulator, it wasn't a problem, but if the custom class was PPC native and the call was made by a 68k program then this wouldn't work. It has been fixed in the meantime.
About MUI, I didn't make the rules (in fact Hyperion has nothing to do with the contest), but plainly there are three major complaints I have with MUI (which can all be circumvented but mostly aren't):
- Rendering done on App context means that if the app is busy it will not "visually" react to input, unless the app is multithreaded (OTOH it will not crash input.device on a buggy class).
- Due to MUI's configurability, some apps look crap unless you use the same configuration as the author. Discipline is required on the authors behalf to at least test the app with the default MUI config.
- Due to the myriad of different custom classes and the fact that lots of functionality is duplicated, it is sometimes difficult to keep up-to-date with an application's requirements for custom class versions. MUI could use some sort of automatic update server that keeps all classes available (say, via Aminet) and automatically installs missing classes.
But if I start a program and the first thing I need is to install half a dozend custom classes, I quickly loose interest.
