[GEM Development] Batch File Programming for GEM.BAT

[Peter Green]

I think that the batchfile method is rather patchy at least. Now that 
the muesli (and the feta, mushroom and sprouts sandwich for lunch, and 
the sate beef and fried rice dinner) are all digested, I am more able to 
think about batchfiles.

I had a few questions at the time about how messy it might turn out to 
be, trying to write a batchfile to automate the process; but Ben is 
right about the further ramifications. You could use IF EXIST and really 
get a slew of "Invalid drive..." commands; IF NOT EXIST merely staves 
off the problem by one or two steps.

A CHOICE-like option would make it much more workable, allowing the user 
to select a drive name to SUBST. The old Norton's BE.EXE (which I think 
was written in BASIC and compiled into an executable) wouldn't be a bad 
solution if it could be liberated from its current owners, probably 
Symantec. I think I still have a copy of DOS World magazine somewhere 
which has a method for taking input by using the TIME or DATE command, 
so you can do it without actually using CHOICE. I'll see what I can find.

Or, as I suggested, a short .COM or .EXE file...

Peter
Ben A L Jemmett wrote:

>You might be able to get away with something like this:
>
>IF NOT EXIST Z:\NUL: SET LASTDRV=Z
>IF NOT EXIST Y:\NUL: SET LASTDRV=Y
>...
>IF NOT EXIST C:\NUL: SET LASTDRV=C
>SUBST %LASTDRV%: %SWAPDIR%
>
>However, you'd want to check a few things first: 
>
>* how do various DOSes handle this for drives that don't exist (I'd expect a
>slew of "Invalid drive specified" messages, perhaps)
>
>* how does the LASTDRIVE setting in CONFIG.SYS affect SUBSTed drives
>(perhaps you'll find drive Z: is free but LASTDRIVE=E so SUBSTing it won't
>work)
>
>* what happens when (like on my old machine) the CD-ROM drives are on Y: and
>Z: and don't have media in them (I'd expect to see "Device not ready error
>reading drive Z:   Abort, Retry, Fail?" messages for each one)
>
>* what happens when a network mapping exists to a server that isn't
>available (sometimes this can cause a delay of many seconds)
>
>Some of these issues are why I had the ability to put a limit on how many
>drives my Desktop would auto-detect -- I got well and truly fed up with
>waiting two minutes for it to time out on an unavailable server and then the
>Zip drive.
>
>You might find the most reliable option is to settle for the old-style
>C:\GEM* directories and then configure the GDOS to use C:\GEMSYS for swap,
>as John detailed on Wednesday.  The minimal set, from memory, is GEMBOOT,
>GEMSYS, GEMAPPS, GEMDESK, and GEMSCRAP (although the last one might be
>SCRAP?  The GDOS has a hardcoded location for it at any rate!).  You can
>always provide "this is what you have to do but up to you if you want to
>fiddle with your drive letters like this" instructions for users who don't
>like the clutter.
>
>Another alternative would be to prompt the user -- yay for CHOICE, but find
>a free version you can stick in the download because not all DOSes have it
>-- patching the GDOS can be done by piping commands into DEBUG as a very
>last resort.
>
>Regards,
>Ben A L Jemmett.
>(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)  
>
>_______________________________________________
>gem-dev mailing list
>gem-dev at simpits.org
>http://www.simpits.org/mailman/listinfo/gem-dev
>
>  
>