Before doing a shell escape or executing any action command, rmenu always calls the push_path function.Under UNIX based systems, this function is a no-op, because there is no way for any child process to alter the parent's current directory.

Under DOS there is no such security. While shelled out to a command processor like COMMAND.COM, a user may select a different disk drive or path. Upon return from the shell session that drive and path will remain selected, potentially confusing the parent program's idea of where the current directory is. To guard against that possibility, the push_path function saves the current drive and path in an internal path stack before any system call that might potentially change them. The pop_path function restores the drive and path saved in the last call to push_path.

Each time push_path is called, the currently logged drive and current working directory are pushed on the stack represented by the static structure array named path_stack, and stack pointer path_stackp. The current drive and directory are obtained via calls to the DOS standard library functions getdisk and getcwd.

pop_path pops the last pushed drive and directory off the path stack, and calls the DOS standard library functions setdisk and chdir to restore the current drive and path.

If incr_path begins with anything other than a slash or drive designator, then it is treated as a relative path to be appended onto old_path to yield the new incremental path. This happens in lines 237-247.

First, old_path is copied into newpath (the buffer to hold the result). If both the relative path incr_path and the old path (now stored in newpath) are non-null, a path delimiter character is appended onto newpath. Finally, the new relative path is appended onto newpath and the incremental path is complete.

The next two Curses functions set the terminal mode for either Curses or non-Curses operation. tty_shell sets the mode for interactive, non-Curses use by calling the Curses library function reset_tty. tty_curses sets the mode for use with Curses by calling several Curses library functions to set things up as necessary. Since I've only been able to test this program under XENIX and DOS, I suspect that tty_shell and tty_curses will be the first functions to require some modifications when porting rmenu to other systems.

A few of those game programs, like Willy Beamish and Chessmaster 3000, wouldn't run when invoked from CMENU. Evidently, CMENU took up too much base RAM space when resident. Not having diddled very much with C's memory allocation faclilities under DOS, my first approach to this problem was to try to reduce rmenu's memory requirements by tweaking some of the parameters in cmenu.h. I decreased the values of MAX_MENUS, MAX_NEXT, and MAX_ITEMS, and ran a make. To gauge the effect, I shelled out to DOS (using the ! command) while running under both the old and new versions of rmenu, and ran DOS's mem command to check free memory. No difference! While shelled out to DOS, I got 530KB of free memory under both the old and new configurations. Hmmmmm... reducing MAX_NEXT alone should have had some impact. Clearly, there was something going on that I didn't understand.

Next, I analyzed my memory usage. With nothing except my startup TSR's resident, running mem told me I have 627KB of free RAM (that's with QEMM386 and all its optional gizmos fully deployed on my VGA-based system.) The size of the RMENU.EXE executable module is about 33KB. If I was only getting 530KB free when running rmenu, then rmenu's code plus its data were taking up a total of 97KB, and the data portion of that was therefore (97KB-33KB) = 64KB. Interesting number! Hunting through the Borland manuals, I located a reference to an external variable named _heaplen. This variable controls the allocation of the near heap, the default memory pool for small- and medium-model programs. If the initialized value of _heaplen is zero, then the system automatically allocates 64KB of memory for the near heap! I had never heard of _heaplen before, so of course my program never initialized it.

I added the code in lines 18-20 and 29-31 of rmenu4.c to support the initialization of _heaplen to some arbitrary value. If HEAPSIZ is left undefined (as in the listing, where the definition line is commented out), then 64KB of heap space will be allocated. If HEAPSIZ is defined, either by removing the opening /* sequence from line 19 or by including an option such as

    --DHEAPSIZ=20000

For memory-critical applications, the best value can be found by trial-and-error. I discovered that my memory-hogging games have just enough room to run when _heaplen is initialized to 20000. Sure enough, when shelled out from rmenu, the mem command now reports 574KB free.

Another way to get the code is to download the appropriate code disk file from the UUNET CUJ code disk archives.Elsewhere in this issue of CUJ is a box explaining how to obtain CUJ code from UUNET using standard uucp software.

2) A bit tougher: extend the scope of the default specifications created in 1) above, as well as the escape/noescape permission status, to any and all submenus that may be invoked. Hint: you'll need to add parameters specifying the current state of all the affected options to the sub_menu function's parameter list.

3) Extend the rmenu memory-allocation strategy to include COORDS structure information as part of the dynamic ITEM allocation scheme (i.e., make it so that storage for the COORDS data is only allocated when necessary). After doing that, calculate how much memory is saved, and contrast the value of saving that memory with the price of the added complexity necessary to support the savings. Was it worth it? The answer probably will depend on how neatly the mechanism has been incorporated into the existing framework.

4) Remove the hardwired aspect of the screen characteristic definitions, so that rmenu does not have to be recompiled to support different terminal sizes. There are at least two ways to accomplish this: a) extend the CMENU language to allow screen dimensions to be written into menu specification files (this approach will most likely require major changes to all portions of the system); b) allow some or all of the screen characteristics to be specified at rmenu run time. This may be implemented in terms of individual command line options to rmenu, or perhaps just one option that gives the name of a special ASCII initialization file that rmenu can read at the beginning of a session to determine what screen characteristics to use.

5) Under DOS, any semicolon characters found in action strings are treated as delimiters between multiple commands. Thus, the semicolon character is precluded from being part of any actual system command. Extend the system0 function to support a method for "escaping" semicolons.