The obvious issue with using the SharedCLibrary approach is that you can't just load a new version, as all the current applications that are running that are linked to it expect it to be in a certian place. Killing the old one and loading a new one results in programs pointing to something random in the RMA. You at least to be able to see the explosion happen if you tried to replace the SharedCLibrary if it had already been softloaded. (Programs bound the the one in ROM don't care of course, because it's in ROM and can't be removed.)
mdw has done shared libraries for RISC OS before. The problem with his original linker is that it needed the application to start the show off - it wasn't automatic when the program was loaded. Perhaps it's time for an ELF loader module that handles this for us, and start building ELF executables instead of AOF ones?
One of the other interesting issues is *where* to put the shared code. You want to try to avoid putting them in the RMA because of its size limitation on many machines, and to try to prevent fragmentation. Suggestions have been raised about putting it in a dynamic area, although there can be problems executing code in such areas because of their location (there are of course ways around this...)
Shared libraries are one of the things that RISC OS is missing that it should be possible to implement without breaking everything, like PMT and further memory protection would. I hope it's a success.
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
The new apple of my eye Would you swap your dusty Acorn for a polished Apple computer? Martin Hansen has been checking out the world of Steve Jobs and his range of shiny kit. 15 comments, latest by adh1003 on 6/1/09 1:06PM. Published: 17 Nov 2008