THE APPLOCATIONS SYSTEM


Overview and key features

The Applocations System ("AS", in short) is a set of mechanisms that allows extremely easy access to executables, regardless of where they are located. For example, one could type "browser" in a shell and get an Internet browser launched, or set the default tool of an icon to "viewer" and get the viewer application run, regardless of the actual location of the executables. With the AS, in short, the access to any executable is totally transparent and immediate.
Another key feature is that executables can be freely renamed or moved, remaining transparently accessible as they were before the operation.
Finally, the removal of executables is automatically and quickly handled, so that the system is never littered with leftovers.
The AS, in practice, extends and makes more powerful the commands path concept.


Requirements

The AS strictly requires the following:
* that the filesystem(s) executables reside on support Bidirectional Links (BLs from now on; BLs are links that can be accessed by the filesystem also starting from the file they link to);
* the presence of a directory called ".applocations" in the root of each volume containing executables that the user wishes to access through the AS;
* that the OS component that handles the commands path and launches executables ("executable launcher", from now on) considers the set of the .applocations directories in all the mounted volumes (part of) the default commands path.

The following would be highly desirable:
* BLs support in the command MakeLink;
* further extension of the "executable launcher" (more about this below).
* a GUI for a comfortable manual management of the AS (more about this below).


Basics of how it works

For each executable that is managed by the AS, a BL is present in the .applocations directory on the same volume.
When a path-less name of a file that is not in the current directory is passed to the system, the executables launcher searches for a match in the commands path and, if a BL is found, launches the linked executable.
If an executable is renamed/moved, the BL remains valid because, contextually to the operation, the filesystem updates also the reference to the linked file. Similarly, if an executable is removed, the corresponding BL gets removed automatically.


Including executables in the AS

The AS only handles those executables which have a BL in an .applocations directory, so there must be some way to create the BLs.
The first and lowest-level solution is adding support of BLs to the command MakeLink, so that it is possible to create the BLs manually.
The second is providing a GUI where the user can comfortably specify the executables.
The third is extending the executables launcher so that it automatically creates a BL whenever a "new" executable is run (after the user has given the authorization by means of either a global configuration setting or a choice in a requester presented on the fly by the executables launcher itself).
More automated solutions could be implemented with hooks at various levels (WB, DOS, etc.), but those choices should be taken carefully.
It would be desirable to offer the user also the possibility of specifying which executables not to include in the AS (he might want to minimize the number of BLs).


Miscellaenous notes and issues

BLs

BLs themselves would be a nice feature, as they could have other uses as well. The system strictly needs only BLs that can be linked only to a single file and viceversa, but more powerful BLs would of course be welcome.

The commands path

The commands path, other than the addition of all the .applocations directories, remains the same, so it may well include C:, S: and any other location (so that excluded executables can still be accessed transparently).
BLs are the key of the system, so if they are not feasible the system becomes totally useless.

Caching

Since executables accessed by means of BLs involve filesystem work, the executables launcher might use a cache (of user-defineable size) of the most recently accessed BLs.

Hiding of .applocations

If would desirable to offer the option of hiding the .applocations directories. Possible solutions:
* not to associate real icons to them, so that they never show in "show only icons" WB mode (this is warmly suggested anyway);
* instruct the WB to ignore them like .backdrop;
* hide them at a lower level (DOS, maybe?);
* extend the filesystem to support hidden directories (this would be a useful general-purpose feature).

Corrispondence of link and executable names

BLs, like other kinds of links, can be named indipendently from the name of the linked file. However, relatively to the AS, this power has also a downside, as shown by the following example. Let's assume that the executable "viewer", associated to the BL "viewer" gets renamed as "HyperViewer": the viewer remains accessible with "viewer" (which would seem a good thing, as references to "viewer" would remain valid), but the corrispondence between the BL and the executable, from a user/human point of view, has become weaker.
Ideally, when a executable is renamed, the user should be given the possibility of choosing also whether the corresponding BL has to be renamed or not. Which level to solve the problem at? It would be easy to extend the WB and shell command Rename so that they ask also the name for the link, but the problem would still show up in other applications. The only solution would be handling the problem at a lower level.
A clean solution is having (as a filesystem option) BLs that are renamed automatically like the linked file whenever the latter is renamed (please note that this does not mean that the user cannot rename at will just the link later). Such solution preserves the corrispondence, although it breaks previous references (f.ex. default tools - but, after all, it is pretty normal that references to a command are broken if the command name is changed).

Multiple executables

One might wonder what happens if there are multiple executables with the same name. Let's see what can be done with an example.
There are 3 executables named "convert" (say, in the directories "graphics/", "sound/" and "text/") and all of them should be included in the AS. A simple and good solution would be creating more meaningful BLs - f.ex., "graphics.convert", "sound.convert" and "text.convert" (the automated tools for creation of BLs should propose solutions of this kind and it would be good to have official guidelines about how to handle these cases).
Particular care has to be taken when executables are on different volumes, since the duplication does not appear when (re)naming BLs, but when executing commands: the problem can be solved by means of a request to the user from the executables launcher as soon as it detects a name duplication in the commands path.
A careful naming scheme for the BLs also helps a lot with handling different versions of the same executable (f.ex. "convert.old", "conver.new", "convert.1.2", etc.).

Other advantages

Besides its ease and flexibility of use, the AS has other advantages:
* it requires no sever/daemon;
* it is intrinsically robust as the coherency of the .applocations directories is guaranteed at the lowest level possible (i.e. the filesystem) in a synchronous manner;
* since BLs are local to the volumes, executables are transparently accessible from any machine which has the AS running on it; moreover, if executables are moved/renamed/deleted, even from a machine that does not have the AS, the .applocations directory stays coherent (f.ex., let's say that a certain editor, residing on a shared volume, is normally accessed from a machine using the command "editor" and that then somebody else changes the location of the editor from another machine: the editor will still be perfectly accessible by means of "editor");
* it is conceptually simple (the amount of issues above are due mostly to the nature of the matter it tackles, rather than to its design);
* it requires very little resources.

Drawbacks

The AS is not perfect. Here is a list of its drawbacks.

Drawback #1: it does not work with legacy filesystems like FFS, PFS, etc.
Food for thought: for how long will people use obsolete filesystems? Is it unreasonable to ask them to switch to the modern and officially supported ones, to benefit of the new features (of the filesystems themselves and of AS)?

Drawback #2: it does not work with non-Amiga filesystems like FAT, EXT3, etc.; it does not work on read-only media; it doesn't work on volumes that do not allow the creation of the .applocations directory.
Food for thought: is running executables from there common? Commonly used applications probably are not located in places that might be unreachable (which often is the case when it comes to removable media), or provide low performance, or are not formatted in an AmigaOS official filesystem. Moreover, since the purpose of the AS is reaching easily executables that are reliably reachable (and commonly used) within the whole system what would be the point of having any kind of shortcut at all? In general, what is the point of storing references to items whose presence in uncertain/unlikely? Is it really wise allowing incoherencies?

Last edited by saimo on 22-Jan-2010 at 09:24 AM.
Last edited by saimo on 22-Jan-2010 at 09:21 AM.
Last edited by saimo on 22-Jan-2010 at 08:47 AM.
Last edited by saimo on 21-Jan-2010 at 10:44 PM.
Last edited by saimo on 21-Jan-2010 at 06:31 PM.
Last edited by saimo on 21-Jan-2010 at 05:50 PM.
Last edited by saimo on 21-Jan-2010 at 04:32 PM.
Last edited by saimo on 21-Jan-2010 at 04:27 PM.
Last edited by saimo on 21-Jan-2010 at 04:20 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@all

I hope the length of the post above won't discourage anybody from evaluating my proposal (by the way, pondering on the matter will help greatly improving APPDIR:, since it shares many issues with the applocations system - f.ex., how to create the references to the executables). Also, I hope the description is clear enough.
I'll update it whenever necessary, accordingly to the comments that will follow.

@Ball000

Quote:

IMHO, the only point I could argue against such a feature as APPDIR: would indeed stand in not being possible to turn it off. And here, I do mean what you just said about the system not working properly anymore when APPDIR: feature is turned off. But it seems easy to have "APPDIR:NotePad" mean "NotePad" for the system when the feature is turned off, as in APPDIR: would mean "Path" in such a case.

No, that's not what happens: if APPDIR: is turned off, to the system "APPDIR:" is simply a device name, so all the user gets, provided that Assign-Mount is enabled, is a requester saying "Hey, APPDIR: is not mounted: what should I do?".

Last edited by saimo on 21-Jan-2010 at 04:30 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Drawbacks

* It requires rewritting/modification in the filesystem itself as such it is "getting in the way" of users who don't want to use the filesystem you wrote (because of no evidence of reliablity) or modified (because you won't be able to modify every filesystem out there and every one has it's preference be it FFS2, SFS, SFS2, JXFS just to name the one natively available but I heard some braves are using PFS too for example).
* your solution does not work on network drive (because they are using Samba for example, and Samba does not support BL and never will),
* it does not work on read only medium (for example it can't cache executables from a CD-Rom),
* it does not work on USB drives/keys that are not reformatted using an Amiga BL aware filesystem (which is not so common on my part I only use FAT formatted USB devices for purpose of being able to do crossplatform exchanges)

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

* It requires rewritting/modification in the filesystem itself as such it is "getting in the way" of users who don't want to use the filesystem you wrote (because of no evidence of reliablity) or modified (because you won't be able to modify every filesystem out there and every one has it's preference be it FFS2, SFS, SFS2, JXFS just to name the one natively available but I heard some braves are using PFS too for example).

As for writing to the filesystem: true, but then also APPDIR: requires writes. If you can think of a system that doesn't, it'd be just cool
As for reliabily: of course I'm not suggesting to introduce the AS before the modified filesystems are deeply tested and proven to be reliable.
As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems.
Finally, in general, should we always be so scared of innovating only because somebody is afraid of innovation and/or wants to stick to legacy without a real reason?

Quote:

* your solution does not work on network drive (because they are using Samba for example, and Samba does not support BL and never will), * it does not work on read only medium (for example it can't cache executables from a CD-Rom), * it does not work on USB drives/keys that are not reformatted using an Amiga BL aware filesystem (which is not so common on my part I only use FAT formatted USB devices for purpose of being able to do crossplatform exchanges)

This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)? It is indeed not recommendable to cache paths for applications stored in the places you suggest.
Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.?

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

As for writing to the filesystem: true, but then also APPDIR: requires writes. If you can think of a system that doesn't, it'd be just cool

unless I misunderstood your solution but you are suggesting to have a .applocation on each supported medias don't you ? So you requires write access to all of them while AppDir: only requires write access to one location (ENVARC:)

Quote:

As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems.

This is simply unrealistic see how you react to an unvital optionnal small utility feature think to how people will react when you'll announcethem you will touch to their filesystem and you will enforce them to switch to the filesystem you choosed...

Quote:

This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)?

After all we are on AmigaOS wouldn't it good to have a requester asking you to insert volume "MySuperdDuperCD:" when you try to run the installed part of your favorite game ?

Quote:

Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.?

Just because you don't do it, does mean noone needs it...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

unless I misunderstood your solution but you are suggesting to have a .applocation on each supported medias don't you ?

Just for clarity: The AS strictly requires [...] the presence of a directory called ".applocations" in the root of each volume containing executables that the user wishes to access through the AS;

Quote:

So you requires write access to all of them while AppDir: only requires write access to one location (ENVARC:)

Sorry, but you originally objected that the AS requires writes to disk and that the writes might not be reliable, so I answered to that. Now the fact that the writes happen in multiple directories is a different story. And my simple answer is: so what? Since the writes are reliable (they must be, otherwise it would be foolish to make the filesystem public in first place), what's problem?

Quote:

Quote: As for filesystem preferences: mine is a suggestion for the future and restricted to just the "official" filesystems, which will naturally take the place of the old ones more and more as time goes by; I can hardly see anybody sticking to some old/esotic filesystem forever when, instead, the OS comes with its own advanced and maintained filesystems. This is simply unrealistic see how you react to an unvital optionnal small utility feature think to how people will react when you'll announcethem you will touch to their filesystem and you will enforce them to switch to the filesystem you choosed...

You make it seem like my reaction to APPDIR: is exaggerated and unjustified, but it's not: the feature, as of now, is not officially optional, suffers from some problems (there are a few threads that talk about them, so I won't repeat them here) and is not useful to me. I'm pointing this out only because that's much different from refusing to update a system with modern and fully working components, with a large variety of benefits. Asking people to replace unsupported stuff with modern and official components is just reasonable in general (regardless of the AS, I mean). Legacy can't stop evolution forever.
Please also keep in mind that I'm not asking for things to happen tomorrow: mine is a proposal for the future. And, above all, at the moment of its introduction I wouldn't want it to be enforced on users.

Quote:

Quote: This is all true, but, on the other hand, any system with the same purpose of AS (like APPDIR:) is based on the assumption that such executables are present in the system: what's the point of having a shortcut to an application whose presence is uncertain (if not unlikely)? After all we are on AmigaOS wouldn't it good to have a requester asking you to insert volume "MySuperdDuperCD:" when you try to run the installed part of your favorite game ?

Yes, sure, but the main point still stands: what's the point of caching references to executables whose presence is uncertain? Moreover, also consider that the fact alone that an application is not "permanently installed" is a sign that the user does not need it often: it certainly isn't the kind of application that the user needs to access from several places like shell, WB, menus, other applications and so on, thus needing the transparent access that AS (or any other similar mechanism) offers - for that application, most likely an icon in AmiDock, an entry in a menu, an alias or maybe just a simple direct access (open volume and click icon) is more than enough.
Finally, please note that APPDIR: removes invalid references as well (although periodically).

Quote:

Quote: Moreover, how often does one launch applications over Samba, from USB keys, CDs, etc.? Just because you don't do it, does mean noone needs it...

I didn't say that since I don't have that need and so nobody does. I was just asking, because, you know, we're having a discussion that's how it's supposed to work
(As for the issue itself, it is already covered above.)

Last edited by saimo on 21-Jan-2010 at 10:47 PM.
Last edited by saimo on 21-Jan-2010 at 06:47 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

Sorry, but you originally objected that the AS requires writes to disk and that the writes might not be reliable, so I answered to that. Now the fact that the writes happen in multiple directories is a different story. And my simple answer is: so what? Since the writes are reliable (they must be, otherwise it would be foolish to make the filesystem public in first place), what's problem?

No I was objecting that you require special mechanism in the filesystem for this to work not the fact you are writing to disk (which obviously is needed when one is doing a cache of some sort). Now the problem is you also require to have write access to media in order to cache things that are located on them...

Quote:

You make it seem like my reaction to APPDIR: is exaggerated and unjustified, but it's not: the feature, as of now, is not officially optional, suffers from some problems (there are a few threads that talk about them, so I won't repeat them here) and is not useful to me. I'm pointing this out only because that's much different from refusing to update a system with modern and fully working components, with a large variety of benefits. Asking people to replace unsupported stuff with modern and official components is just reasonable in general (regardless of the AS, I mean). Legacy can't stop evolution forever. Please also keep in mind that I'm not asking for things to happen tomorrow: mine is a proposal for the future. And, above all, at the moment of its introduction I wouldn't want it to be enforced on users.

I personnaly don't see any problem in the current APPDIR: implementation. About your thoughts concerning legacy and evolution I totally agree with you.

Quote:

Yes, sure, but the main point still stands: what's the point of caching references to executables whose presence is uncertain? Moreover, also consider that the fact alone that an application is not "permanently installed" is a sign that the user does not need it often: it certainly isn't the kind of application that the user needs to access from shell, from WB, from menus, from other applications and so on, thus needing the transparent access that AS (or any other simililar mechanism) offers - for that application, most likely an icon in AmiDock, an entry in a menu, an alias or maybe just a simple direct access (open volume and click icon) is probably more than enough. Finally, please note that APPDIR: removes invalid references as well (although periodically).

The point is that because they are "unstable" or not used very often they are *required* to be in the AppDir: because chances are high that commands you are using all the time you know their location while this won't be the case for occasionnally used softwares. In fact I miss one thing in AppDir : a way to configure the retaining delay (and augmenting it from one month to one year)

Quote:

I didn't say that since I don't have that need and so nobody does. I was just asking, because, you know, we're having a discussion that's how it's supposed to work

Yes it wasn't meant to be aggressive sorry if it sounded like that. For example I have a NAS at home and my dev projects are on it, as a consequence I frequently execute programs from a Samba mounted drive (but I generally remember where they are because I juste finished compiled them prior to their execution

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

No I was objecting that you require special mechanism in the filesystem for this to work not the fact you are writing to disk (which obviously is needed when one is doing a cache of some sort). Now the problem is you also require to have write access to media in order to cache things that are located on them...

As I said multiple times, yes, BLs are a requisite: quite simply, if, for whatever reason, they are not feasible, the AS can be put aside; if they are, the AS become doable. Moreover, I have to repeat that BLs are a nice general-purpose feature that could find other interesting uses.

As for having write access to the media: yes, that's another requisite and, yes, sometimes it's a disadvantage. However, again I have to wonder: how often? Moreover, it has also a few nice sides: since BLs are local to the volume, executables are transparently accessible from any machine which has the AS running on it; moreover, if executables are moved/renamed/deleted, even from a machine that does not have the AS, the .applocations stays coherent - f.ex., let's say that you run a certain editor, residing on a removable HD, from your machine using the command "editor" and that then somebody else mounts the same HD on another machine and changes the location of the editor: the next time you attach the HD to your machine, the editor will still be perfectly accessible by means of "editor". Or, even better, think of how handy this could be with network-shared drives...

Quote:

I personnaly don't see any problem in the current APPDIR: implementation.

It might suffice to you, no questioning. But it does have problems (I won't go into details because it would OT and because there are other threads dealing with the matter).

Quote:

The point is that because they are "unstable" or not used very often they are *required* to be in the AppDir: because chances are high that commands you are using all the time you know their location while this won't be the case for occasionnally used softwares. In fact I miss one thing in AppDir : a way to configure the retaining delay (and augmenting it from one month to one year)

Yes, sure, ideally that's one more reason for having always the same shorcut, but practically you are suggesting the introduction of forced cache incoherency to handle just a minority of cases. Cache incoherency is in general something to be avoided, as it might (and usually does) end up firing back in a number of unforeseen ways. For the specific need you're talking about, I'd avoid breaking a mechanism like that of APPDIR:, AS or whatever other system, and I'd just use "classic" shortcuts like an Alias, a link, etc.

Quote:

Yes it wasn't meant to be aggressive sorry if it sounded like that. For example I have a NAS at home and my dev projects are on it, as a consequence I frequently execute programs from a Samba mounted drive (but I generally remember where they are because I juste finished compiled them prior to their execution

Ah, wait, last night I realized an incorrect thing has been said and tacitly accepted: it's not true that the AS does not work with Samba (or over a network) in general. As we just said, the AS requirements are that the filesystem(s) involved must offer BLs and allow writing: whether the volumes are inside the case of one's machines or at the other end of the world doesn't make any difference

Last edited by saimo on 22-Jan-2010 at 09:14 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

No argument to other things, it's clear we don't agree but that's our right

Quote:

Ah, wait, last night I realized an incorrect thing has been said and tacitly accepted: it's not true that the AS does not work with Samba (or over a network) in general. As we just said, the AS requirements are that the filesystem(s) involved must offer BLs and allow writing: whether the volumes are inside the case of one's machines or at the other end of the world doesn't make any difference

Yes of course location does not matter (locale or overseas) but here problem lies in Samba good luck to make your BL concept So BL won't (and never will) work with Samba, NFS, etc.

Oh and concerning the cache incoherency maybe the system (be it AppDir or AS) can detect the device is using removable medias and thus can tolerate incoherency longer than for other type of devices.
Anyway cache incoherecy can be normal for some reason and might not force the cache cleaning think to when I go to parties with my A1 that normal my NAS is unaccessible but just because it is for 48 hours does not mean it would be the case forever... Your AS solution definitively has an advantage here effectively because the cache stays on the media itself (as you pointed in the first part of your answer), so that's another advantage of your solution (see I'm even preaching against myself now

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

No argument to other things, it's clear we don't agree but that's our right

Absolutely

Quote:

Yes of course location does not matter (locale or overseas) but here problem lies in Samba good luck to make your BL concept So BL won't (and never will) work with Samba, NFS, etc.

Maybe it's just me being ignorant (I use Samba, but only thanks to the Guide for Dummies), but Samba or whatever other sharing system sits on top of the local filesystems, right? BLs should be entirely handled locally... or am I missing something?

Quote:

Oh and concerning the cache incoherency maybe the system (be it AppDir or AS) can detect the device is using removable medias and thus can tolerate incoherency longer than for other type of devices. Anyway cache incoherecy can be normal for some reason and might not force the cache cleaning think to when I go to parties with my A1 that normal my NAS is unaccessible but just because it is for 48 hours does not mean it would be the case forever...

Mmm... regarding the AS, the only way to handle that I can think of is having protection bits also for BLs (so probably they'd have to be soft) and allowing the user to uncheck the 'd' bit of the references he wants to preserve.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

Maybe it's just me being ignorant (I use Samba, but only thanks to the Guide for Dummies), but Samba or whatever other sharing system sits on top of the local filesystems, right? BLs should be entirely handled locally... or am I missing something?

I use Samba but in the reverse order : to use folders shared by my NAS from my Amiga (not the reverse as it won't make sense as it's a NAS or to mount my work's laptop when I bring it to home. So gound luck to make Microsoft or Linus Torvald accepting your BL concept so that it's implemented in the local filesystems respectively NTFS and ext3

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Quote:

So gound luck to make Microsoft or Linus Torvald accepting your BL concept so that it's implemented in the local filesystems respectively NTFS and ext3

Well, as vidarh told us, MacOS has (something very similar to) them (Aliases), so the concept is already in use somewhere else. And, again, we're talking about a general-purpose feature that might be useful to just any system. Why shouldn't we hope that if a good technology is introduced in our world it might as well spread outside? Do we have always to follow? Shouldn't we hope to lead (again), should we? Of course it's unrealistic to expect instant success. But still...

Back to the matter: as repeatedly said, yes, the AS works only with filesystems that offer BLs, and I'm proposing to implement them in the AmigaOS own filesystems (SFS and JXFS), so, yes, it goes without saying that the AS doesn't work with FAT/EXT3/whatever. The point is that I'm proposing a system for AmigaOS, for people that run applications on AmigaOS: in such context, is the fact that the AS doesn't work in "exotic" cases a deciding factor? A factor that obscures the advantages of the system? In general, the AS has advantages and disadvantages, just like APPDIR: (but also the directory structure of UNIX/Linux/MacOS and so on): if it's bad or APPDIR: is better, sure, let's put it aside. But let's make sure all the aspects are taken into account

Last edited by saimo on 22-Jan-2010 at 10:22 AM.
Last edited by saimo on 22-Jan-2010 at 10:21 AM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC