Vincent Rivière, 27.02.2013 14:16:32:
Did you try my suggestion to leave out appl_init in XaAES?I didn't try, but that's a good solution, since the whole point is to not call the AES from supervisor mode.XaAES runs from EmuTOS but then EmuTOS crashes when XaaES exits. It's not the appl_exit later I think.EmuTOS may have additional bugs when closing the VDI workstation, etc. Anyway, calling appl_exit() from supervisor mode is forbidden, too.
That's why I asked you to run this XaAES - maybe there's a bug in EmuTOS that can easily be fixed. It says:
pid 12 (GEM): BUS ERROR: User PC=E03362, Address: F1C00008 (basepage=254000, text=E03488, data=0, bss=0) pid 1 (GEM): BUS ERROR: User PC=E030B6, Address: F1C00008 (basepage=1076000, text=E02F10, data=0, bss=0)
Maybe it helps. If you can't compile yourself I can upload an xaaes040.km.
Your patch was actually detecting the presence of FreeMiNT, thenNo. It avoided to set the clipboard to u:/clipbrd which is nonsense anyway.I fixed the u:/clipbrd nonsense by fixing FreeMiNT to run GEM= using the boot drive as default drive. It prevented the AES to find the accessories, anyway (both TOS and EmuTOS).In EmuTOS, it crashes when calling scrp_write() from appl_init() in supervisor mode, whatever the path exists or not. It is not supposed to
Ok, then that's what my patch actually did. I remember it did not work anymore with the current trunk-kernel.
I'm in the mood of adding an explicit panic message in EmuTOS if someone tries to call the AES from supervisor mode (after the 0.9.0 release).
You could test for super and if so not call scrp_write. But again just a hack.
BTW: The whole point is to determine if the VDI physical workstation must be opened or not at XaAES startup, we should focus on that.
It could check if it's run from a process (i.e.ppid) called GEM but if it works at all it will again have to be tested on all relevant platforms.
-- Helmut Karlowski