Rev 573 | Rev 988 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | RSS feed
=== SvarCOM implementation notes ===
=== SWAPPING =================================================================
While conventional RAM is scarce, a command line interpreter must make effort
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 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.
=== 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 a separate tool: TLUMACZ. It takes
CATS-style language files as input and compiles them into a single SVARCOM.LNG
resource file. It also produces a DEFAULT.LNG 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:
- Writes the batch filename into its persistent (rmod-owned) buffer, along
with a counter that holds the offset of the next line to be executed.
When the batch filename buffer is non-empty, 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.
===================================================================== EOF ====