0,0 → 1,103 |
|
|
=== SvarCOM implementation notes === |
|
|
=== SWAPPING ================================================================= |
|
Conventional RAM is scarce, that is why a command line interpreter must make |
efforts to reduce its memory footprint when launching applications. SvarCOM |
does that by installing a small executable module in memory, called RMOD (for |
Resident MODule). SvarCOM pre-sets RMOD so it knows how to execute the external |
program and removes itself from memory, letting RMOD do the job. RMOD executes |
the application, waits for it to finish and then calls back SvarCOM. All |
necessary contextual data is kept in a resident, RMOD-owned memory structure. |
|
|
=== NLS STRINGS ============================================================== |
|
SvarCOM can output information in many languages. To do so, it relies on a |
precompiled resource file named SVARCOM.LNG. When SvarCOM starts, it looks |
for this file in the %NLSPATH% directory and loads from it the part that |
contains the %LANG% language. All this is done by nls_langreload(). |
|
The SVARCOM.LNG file is compiled by TLUMACZ (from the SvarLANG.lib suite). It |
takes CATS-style language files as input and compiles them into a single |
SVARCOM.LNG resource file. It also produces a DEFLANG.C file with english |
strings only, this one is embedded into the SvarCOM executable to display |
English text in case SVARCOM.LNG is unavailable. |
|
|
=== BATCH FILES SUPPORT ====================================================== |
|
When SvarCOM executes a command, it checks first if it has a *.BAT extension. |
If so, it switches into 'batch-processing' mode: |
|
- allocates a "batch context" structure and attach it to rmod |
- writes the batch filename into the batch context (rmod-owned) memory, along |
with a counter that holds the offset of the next line to be executed. |
- a batch context has a "parent" pointer that may point to another batch |
context (owned by a different batch instance), it is, in essence, a linked |
list that allows batch files to call one another (typicall through the CALL |
command) allowing SvarCOM to get back to the parent batch once the child |
terminates. |
|
When the rmod batch context pointer non-NULL, SvarCOM does not ask the user for |
a command. Instead, it opens the batch file, jumps to the "next line to be |
executed" and loads the command from there, incrementing the line counter in |
the process. |
|
|
=== PIPING COMMANDS ========================================================== |
|
Piping a command means redirecting its standard output (stdout) to the |
standard input (stdin) of another command. While redirection of file handles |
is a concept well supported by the DOS kernels, piping is not, in part due to |
the mono-task nature of DOS. SvarCOM provides piping support through following |
logic: |
1. user-entered (or batch-acquired) command line is analyzed for any kind of |
redirections (incl. pipes) by redir_parsecmd(). If the command appears to |
be piped, then redir_parsecmd() enforces a stdout redirection to a |
temporary file and moves all the pipe chain to an RMOD-owned buffer named |
"awaitingcmd", appending an stdin redirection so the next command's stdin |
is fed from the temporary file. The command is then executed. |
2. before further execution, SvarCOM looks into its "awaitingcmd" buffer, and |
if it is non-empty, it runs its content. |
3. when loading commands from the awaitingcmd, SvarCOM sets a special |
"delete_stdin_file" flag and passes it to command-executing functions so |
these remember to delete the stdin-redirected file. |
|
|
=== GLOBAL EXECUTABLE LINKS ================================================== |
|
SvarCOM features special support for "global executable links". This allows to |
run selected programs from any directory, without the need to copy these |
programs to a directory in %PATH%. Executable links are flat files written in |
%DOSDIR%\LINKS\. Each file there contains the directory where the matching |
program should be looked for. |
|
|
=== STACK-OVERFLOW PROTECTION ================================================= |
|
RMOD reserves a 64-bytes memory buffer for its private stack. This is more than |
enough for RMOD itself, as well as for the DOS exec function INT 21h,AX=4B00h. |
|
There may be, however, exotic configurations where this stack is not enough, |
typically if some stack-hungry TSR kicks in while RMOD is being active, or some |
large interrupt handlers are used, etc. In such situation the 64-bytes stack |
could be overflowed. RMOD copes with this by placing the stack right on top of |
its command history buffer, and terminates the history string with a specific |
signature. This way, if a stack overflow occurs and damages the command history |
buffer, SvarCOM is able to easily detect it and invalidates the history buffer, |
causing no risk of system instability. The user is notified about it, and the |
only inconvenience is that he cannot recall the previous command. |
|
Below the input buffer is RMOD's own memory signature, followed by its PSP. |
This means that should the stack overflow become truly severe (more than 192 |
bytes and less than 326 bytes), RMOD signature will be overwritten and SvarCOM |
won't be able to locate it, so a new copy of RMOD will be recreated. In case of |
of a stack overflow that tries to use more than 326 bytes of memory, all hope |
is lost and everything becomes possible. |
|
|
===================================================================== EOF ==== |