[GEM Development] GEM/XM VDI source

Shane M. Coughlan shane at shaneland.co.uk
Mon May 8 14:03:30 PDT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

John Elliott wrote:
>   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;
>         }
[snip]
>   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().

Hi John

Thanks for digging through this. :)

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.  At least it
means we can have a way to access the DESKTOP.INI file, and restore the
desktop to expected functionality.

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.  This is additionally complicated by the way that FreeDOS is having
trouble with SUBSTing drives correctly.  Therefore it looks like people
using GEM/XM will end up with an ungainly cluster of GEM folders in the
C:\ root.  Having the nice FreeGEM desktop working with GEM/XM would at
least meant the visual interface would be familiar to people who have
been using OpenGEM 5 etc.

GEM/XM did quite well with multi-tasking existing GEM applications.
Some problems occurred with the GEM games, mainly due to buggy code on
the part of the games I guess.  Occasionally when switching from a game
a certain amount of graphics would remain on the screen when the new
application tried to load.  Psychedelic.

Shane

- --
Shane Martin Coughlan
e: shane at shaneland.co.uk
m: +447773180107
w: www.shaneland.co.uk
- ---
Projects:
http://mobility.opendawn.com	http://gem.opendawn.com
http://enigmail.mozdev.org	http://www.winpt.org
- ---
Organisations:
http://www.fsfeurope.org	http://www.fsf.org
http://www.labour.org.uk	http://www.opensourceacademy.gov.uk
- ---
OpenPGP: http://www.shaneland.co.uk/personalpages/shane/files/publickey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4-svn4127: (MingW32)

iQCVAwUBRF8zktwG3M95JPpzAQivuQP8ChMS4iGjy7nrjRuC3WSAqVo+a7CYK1tS
svFduwY6070XtM1k0v0pn40wri6Zku9MFckjkjqKEtRLNqR3+9yMZiCxjde/XM+l
bLd6njUyTiKit35+5AYIIcixSWGWizLfTtYa8A5kX+pnAI/Jy2DuRKRODm/v6Uem
f/9dGUhIbCo=
=abt0
-----END PGP SIGNATURE-----




More information about the gem-dev mailing list