0,0 → 1,73 |
|
|
=== 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 ==== |