Release notes for Aemulor for IYONIX pc v2.32
Compatibility improvements and bug fixes
Important changes since version 2.31
First A9home release
- This release and future releases of Aemulor will not automatically treat all programs invoked by a 26-bit program as 26-bit programs, ie. if they must be emulated then they too must be added to the Applications list in Aemulor.
The reason for this change is that it allows 26-bit programs to now use the 32-bit !ARMovie supplied with the IYONIX pc. It also means that double-clicking a URL within a 26-bit application will no longer cause your web browser to start up under Aemulor.
- Previous versions mistakenly treated filetypes in the range &000-&EFF as code and performed a cache synchronisation when loaded with OS_File from a 26-bit program. This was never the intended behaviour, and in fact it would only have worked properly with the ARM610 engine.
The code has been corrected to only synchronise for known types requiring it, including Impression Publisher's 'IModule' filetype that previously gave intermittent startup failures with the StrongARM engine.
This change does, however, have the potential to break compatibility with some applications that worked previously.
- Added a Find window with search-as-you-type for locating programs in the Applications window. (F4)
- Shift-dragging an application into the Applications window adds an entry of the form '*.!' rather than the full pathname.
- Dragging an application into the Applications window now scrolls to the existing entry if there is one.
- Added support for multiply-instantiated modules
- Wimp_SetPointerShape now handles shape pointers in the same way as RO4
- Implemented OS_SetEnv and OS_Control
- Eureka ToolSprites patch modified to cope with absence of Tools3D file.
- Support for 26-bit BASIC passing workspace parameters in R0-R5 to module *command handlers such as Reporter's *Report command.
This is a free upgrade to all existing users
- Improved the checking of valid SWI decoding table/code in modules.
- Corrected matching of command lines against the app config which could cause data aborts with long commands, eg. !Browse invoking !ChangeFSI on a scrapfile.
- Limit the kernel to a 28MB application slot also whilst Aemulor is running because otherwise it will map memory over the emulated RMA and other DAs when the desktop shuts down ('Exit desktop' or 'Shutdown' in TaskManager) potentially causing crashes.
- In order to achieve this safely, Aemulor now creates a number of 'Aemulor DA space' dynamic areas of zero purely to consume address space and thus prevent the kernel allocating DAs within that region whilst Aemulor is running. (Doing so would cause crashes with large applications after Aemulor is terminated.)
- Circumvented the hang when 'resizing RAM disc and Aemulor is set to auto-run 26-bit apps' which appears to be an OS bug.
- 26-bit utilities were inadvertently being emulated in SVC26 mode, causing crashes in Utility files that use OS_EnterOS before then switching back to USR26 mode.
- Under some circumstances Aemulor's post filter could be installed twice on 26-bit tasks in TaskWindows leading to crashes when/after the TaskWindow is closed or Aemulor is stopped.
- Emulated IRQ handlers were being passed an incorrect IO base address in R3.