[GEM Development] GEM/XM VDI source

[John Elliott]

: I have been using an INI file that works with your desktop 3.2.3.
: However, for some reason it's not working with the new desktop.  Two
: windows should automatically open, but they don't.  The desktop also
: does not appear to be automatically detecting drives anymore.

  I've just got round to finding out why this should be. It's an AES bug, at
least in my opinion.

  When the GEM/3 desktop is launched, it calls shel_get() to retrieve the
current memory version of DESKTOP.INF. If the first byte is not '#', then it
draws the conclusion that this is the first time it has been launched and
displays the splash screen. The FreeGEM version uses the same test when
probing for drives.

  The problem is that on XM, the first call to shel_get() does return a '#'
character. The reason for this is in the sh_rdinf() function within the AES
(which initialises the AES drive list by parsing DESKTOP.INF). In GEM/3, it
has the following lines at the end:

                                        /* clean up tmp buffer          */
        pcurr = ad_ssave;
        for(tmp = 0; tmp < (INF_SIZE / 2); tmp++)
        {
          LWSET(pcurr, 0x0);
          pcurr += 2;
        }

  which are not present in XM. So in GEM/3, the first call to shel_get()
will return all zeroes, but in GEM/XM it will return the copy of DESKTOP.INF
that the AES was using.

  The problem doesn't appear to manifest itself on single-tasking GEM/1 and
GEM/2, even though they don't zero the buffer. This seems to be a happy
accident caused by the order in which things are done. In single-tasking
GEM, sh_addpath() gets called after sh_rdinf(), and that changes the address
of the buffer slightly; so the odds are that the first character is no
longer '#'. In multi-tasking GEM, sh_addpath() is called before sh_rdinf(),
so once the buffer has been populated it remains undisturbed.

  This really wants fixing in the XM AES (and, ideally, the single-tasking
1.x and 2.x AESes, for which we don't have source) rather than the Desktop.
I'm not completely happy with DR's fix, because sh_rdinf() resets the buffer
to zeroes and then sh_addpath() comes along and starts playing games with
where the buffer is. I think, instead, DR's fix should be made into a
separate function that's called from the end of sh_rdinf() and sh_init().

-- 
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott           |BLOODNOK: "But why have you got such a long face?"
                       |SEAGOON: "Heavy dentures, Sir!"    - The Goon Show 
:-------------------------------------------------------------------------)