[GEM Development] GEM/XM VDI source

[John Elliott]

: The DR fix at the end of sh_rdinf() in GEM/3 works, so I guess it's an
: option for future inclusion on versions of the GEM/XM AES. 

  If anyone's got that building. Ben? 

: I'm a tad worried about the directory structure of GEM/XM.  It's very
: different from GEM/3, and is likely to throw some of the existing users
: off. 

  I've taken a quick look at this. It should be possible to get at least
some of the GEM/3 directory structure just by resource editing (I haven't
tried this so you're on your own here).

  The two strings in GEM.RSC that would want changing are:

- STINPATH. In XM this reads "C:\GEMDESK;C:\GEMAPPS;C:\GEMSYS;C:\". 
 Change it to the GEM/3 value of "C:\GEMAPPS\GEMSYS;C:\GEMAPPS;C:\". 
- STINFPAT. In XM this reads "C:\GEMDESK\DESKTOP.INF".
 Change it to the GEM/3 value of "C:\GEMAPPS\GEMSYS\DESKTOP.INF".

  Then move the contents of \GEMDESK, \GEMBOOT and \GEMSYS to
\GEMAPPS\GEMSYS, cross your fingers, and launch GEM.

  To make things a bit tidier, we'd also need to backport a few other things
from GEM/3:

* The GEM/XM VDI has a built-in AES search path of \GEMBOOT and \GEMAPPS. 
 GEM/3 searches "..\GEMBOOT" instead.

* The GEM/3 AES gets the clipboard path from its resource file using a few
 lines at the end of ap_init():

        rs_gaddr(ad_sysglo, R_STRING, STSCDIR, &scdir);
        LBSET(scdir, gl_logdrv);                /* set drive letter     */
        sc_write(scdir);
 
  but those lines aren't present in the XM AES, so I don't know where (if 
anyhere) it sets up the path to \GEMSCRAP.

-- 
John Elliott