Arachne XAPM

Xapm.apm is the result of creating Arachne ApmTools to be both a standard and a remote APM.

Remote APM's, or APX as the .apx file extension would suggest, are Arachne packages that install outside of the Arachne directory tree.

This creates several advantages to the user.

1. It keeps Arachne slim.

2. The packages themselves are portable, accross different Arachne versions and installations, without the user having to re-install the packages to a new or old version of Arachne to use them.
   • For example, the APX packages which would have been installed for Arachne 1.70 could be used for Arachne version 1.73, 1.75, 1.85, 1.89 and in the future for Arachne 2.00, 2.01, 2.03, 2.05 etcetera without having to re- install them each and every time.

3. The user could have Arachne on one drive while the packages have been installed on a different drive: for example, Arachne is on Ramdrive "R" and is using the Arachne APX packages which have been installed on hard drive "D" or, Arachne has been installed on drive A, or in ramdrive, and is using the packages installed on floppy drive B.

4. If the USER chooses, different (or the same???) Arachne packages can be installed on various drives and in different directories and still be available to ANY Arachne installation on the same computer providing the "apxpath" variable is changed by the user (via xpath.htm) to reflect the (pathname) location to be used.

5. Packages containing changes to mime config that call some helper application which has been installed to a hardrive (or floppy drive for that matter) such as:
   • file/.pdf >HTM|@call c:\\pdf2htm\\pdf2htm5\\pdf2htm.bat $1 $2
   which seem to point to someone else's drive and directory structure, can be re-written to give a more "universal" pointer such as:
   • file/.pdf >HTM|@call %%apxpath%%\\pdf2htm\\pdf2htm5\\pdf2htm.bat $1 $2

   where %%apxpath%% is a DOS variable containing the USER's drive and root directory hosting the Arachne APX packages. The remainder of the path being the directory structure delivered in the APX package that contains the helper application(s).

   • This being the case, it becomes easy enough for an experienced Arachne user to help the less experienced ones since, no matter which drive or directory is used for the APX packages, the directory tree structure is the same for everyone using any given APX Arachne package.

6. One more advantage worth mentioningis that ALL applications can now be packaged. Neopaint is the example that comes to mind...

   The fact that Neopaint.apm has never been created might be related to these 2 very good reasons:

   1. Neopaint takes up much more space than many smaller applications and not many users would like to have this installed (especially more than once!) IN the Arachne directory.

   2. Many unsuccessful attempts have probably already been made to create a Neopaint APM but a "universal" .ook could not be created to make it return from another drive\directory.

   There are other such applications that require being run directly from their own installation directory and which, after having terminated, remain in their own directory instead of returning control to the application directory from which they have been called...

   APX packages have overcome these two drawbacks by:

   1. Allowing the USER to place a package "anywhere" ONCE.
   2. Allowing the creation of "universal" OOK files that make calls to the application package, regardless of it's location, though the "indir %apxpath%" OOK function of the XAPM package.

   ---

   
   
   Any apm can be designed as an external APX-apm.
   How This Works

   xapm-apm.id

   1. declares the .htx file type as a HTM (html) file type and
   2. declares .apx a file type to be auto-installed to the %apxpath% directory with the help of xapm.com

   Xapm contains the following key files:

   1. apm.id
   2. xapm.com
   3. indir.exe
   4. xpath.htm
   5. xpath.ook

   xapm.com
   Is a DOS utility that makes use of indir and unarj (allowing Arachne) to unarj a file to a different drive and/or in a different path.

   indir.exe
   This is the heart of xapm.apm.
   It is a copyrighted freeware push-directory/pop-directory utility by Mike Wiering.

   Calls made by APX's oopx\*.ook 's and mime.cfg are like so:

   indir %apxpath% apps\neopaint\neopaint.exe for OOK's and

   ... |nindir %%apxpath%% apps\\neopaint\\neograb for MIME.cfg

   xpath.htm
   ("Arachne Remote APX-apm Driver" page) is the Arachne graphical interface for this package that allows the user to declare the actual drive and destination path value (apxpath) to auto-install and or use the APX-apms.

   xpath.ook
   is the batch file that Arachne uses to set the value for the DOS variable 'apxpath'.
   -- The echo/pause was purposely left on as a visual check to the path's value before a file is unarj'ed.

   
   .htx files are not needed in THIS (xapm.)apm. The file extention was created to indicate that the file is part of a remote APX-apm's Graphical User Interface and should not be expected to work without the Xapm.apm package having been installed first.

   .htx are the same as the .htm files except for these features:

   1. To be of any use, .htx files need to be declared in mime.cfg.
        (installing xapm.apm will do this: file/.htx        HTM)

   2. The .htx call 'special' OOK's from %apxpath%\oopx directory instead of calling the regular oops\*.ook files.

   3. oopx\*.ook files vary from ordinary oops\*.ook in the following way:
      
      An oops\*.ook files' default directory is "implied" to be the Arachne default directory.
      
      An oopx\*.ook files' default directory is explicitly determined by the user.
      by making reference to "indir %apxpath%" in the oopx\*.ook. This becomes important when
      an OOK calls an executable or other file located on another drive or in a
      directory not included in the Arachne default directory.

   4. The DOS variable %apxpath% must be declared before any of the oopx\*.ook files can be used.

   5. The user declares the DOS variable %apxpath% when submitting the first input box on xpath.htm form.
   I've re-named and re-written the way that the %apxpath DOS variable is used several times...

   Should more remote APM's be created, it would be advantageous to all to keep the same file type '.htx', the xapm.dgi script, the same standard DOS variable '%apxpath' and the same sub-directory structure:(ie: %apxpath%\system\DOS, %apxpath%\oopx, %apxpath%\DOC\someapx\).

   That way all APX-apms could be used with the same %apxpath% DOS variable if they were located on the same drive and in the same initial root directory path.

   Alternatively the user could install different APX-apm's in different directories for a various number of reasons ( multiple users ) and use xapm's xpath.htm (or batch files) to set the 'apxpath' variable in order to determine which APX remote directory will be used.

   Xpath.htm

   One thing is certain, XAPM gives Arachne and her users more .ook batch file programming and .dgi script versatility as well as offering a choice of drive and pathname for auto-install of APX apm type packages.

   License Copyright (C)2005 Bruno Castonguay