OTHER INFORMATION
This page deals with aspects that are not so obvious, but still quite important to know.
MISCELLANEOUS DETAILS
- glUAE determines the form of an application by first looking at the extension of the file passed as input. The recognized extensions and the associated application forms are:
- .slave ↔ WHDLoad-installed;
- .adf, .dms, .fdi, .ipf ↔ floppy-based;
- .hdf ↔ hardfile-based.
If the extension is not recognized or no file has been specified at all, the application directory is examined to find a file with a known extension (with the extensions being checked in the aforesaid order), which the application form is derived from. If no file is found, the application is considered AmigaDOS-based.
As a consequence, passing a recognizable file makes the application launch faster, as the application directory needs not to be examined.
- As regards floppy images:
- they are detected by their file name extensions;
- image types can be freely mixed also for the same application;
- if no specific image is passed as argument, the first 4 alphabetically-sorted images are mounted to DF0:-DF3:;
- if a specific image is passed as argument, it is mounted to DF0: and the next 3 alphabetically-sorted images are mounted to DF1:-DF3:;
- to avoid the mounting of an image, a quick trick is changing the file name extension to an unrecognized type;
- the assign glUAE_application-<number>: (where <number> is the application instance ID) points to the images directory so that it is easy to locate them (UAE is also instructed to look directly in that directory).
- The directory where the application files reside in must be writable.
- The directory of an application residing in files is always mounted as the device DH0:.
- If no specific UAE configuration is found when an application is alunched, glUAE gives the possibility of choosing one (the requester uses as default path the generic configurations directory, if specified during the installation); upon quitting, it is also possible to associate that configuration permanently (for single-file applications, this works only if glUAE_ULASD is used).
- If a S/startup-sequence file is created automatically, glUAE asks whether to make it permanent upon quitting (for single-file applications, this works only if glUAE_ULASD is used).
- If an alternative version of UAE is preferred/needed for a specific application, it is possible to specify it by storing the full path of the executable in the file .UAE in the application directory.
- Single-file applications are unpacked to a temporary location (freely chooseable during installation) before execution, causing a certain overhead.
- When a single-file application modifies/deletes/adds any file and the user wants to preserve the changes, the source archive must be updated, causing some more overhead and filesystem activity. Obviously, the machine must not be switched off while such activity is going on.
- Due to performance reasons related to what explained at the previous points, large applications should not be made single-file.
- Although glUAE can handle any number of classic applications running at once, it is likely that even running a couple of them leads to major slowdowns, because the current (as of the time of writing) machines are not powerful enough to cope with the demanding emulation UAE has to perform.
- While instances of the same application run in separate disk spaces when started from floppy images, instances of the same hard disk-installed application share all the files.
- The host system directories to expose to an application must be defined with the
filesystem2
option in the .rc file.
- glUAE creates in various places temporary softlinks, files and directories (most of them begin with either glUAE or .glUAE). They are automatically removed when applications quit and must not be deleted manually. When the post-execution cleanup process does not start or complete (e.g. due to the host machine having crashed / rebooted / been turned off), those entries must be removed by means of the script glUAE_WA ("Wipe All") as soon as possible.
- Parentheses in file names should be avoided, as they might cause troubles.
- glUAE does interfere with RunInUAE, as it runs UAE directly.
NOTES ABOUT THE CENTRALIZED SYSTEM
To make the most of the centralized system and safely use it, it is important to learn how the underlying mechanisms work.
The core concept is that everything is based on softlinks. Before an application is started, its directory/partition is mounted as the SYS: volume and all of the centralized system files and directories are mirrored to SYS: via softlinks (of course, entries already present in SYS: are not touched, although the contents of directories is processed recursively anyway; all softlinks are automatically removed when the last instance of the application quits). This implies that:
- the native filesystem(s) involved must support softlinks;
- the softlinked entries should never be deleted, as they actually belong to the centralized system;
- changes in the centralized system performed by an application may affect the behaviour of the other applications;
- when an entry of the centralized system already exist in the application directory, glUAE is forced to scan deeper, thus slowing startup down - this is indeed very noticeable when many/most of the directories are duplicated and/or contain a lot of entries.
Finally, here are some important things to be aware of as regards the mounting/unmouting of the centralized system:
- when the centralized system resides in a partition of its own, it must not necessarily be mounted at the time of the launch of the first application that uses it: glUAE automatically mounts it on the fly (provided that the corresponding entry is present in DEVS:mountlist or in DEVS:DOSDrivers/) and unmount it when the last application quits;
- unmounting is not always possible, as that depends on the device being unmounted;
- unmounting is done preferably by means of the command Dismount; should it not be available,
Assign DISMOUNT
is used instead: be warned that, unfortunately, this may cause problems with non-unmountable devices.
LIMITATIONS
Since UAE is (rightfully) based on an isolated-box model, there are some limitations that just cannot be overcome from the outside; here is a couple of problematic issues:
- drag 'n' drop from AmigaOS to an application window/screen is impossible;
- applications that access only specific floppy drives will not care about the images that glUAE optimistically mounts in the other drives (e.g., if a multi-disk game uses only DF0:, disk images will have to be swapped manually).