447 |
mateuszvis |
1 |
|
521 |
mateuszvis |
2 |
|
447 |
mateuszvis |
3 |
=== SvarCOM implementation notes ===
|
|
|
4 |
|
|
|
5 |
|
473 |
mateuszvis |
6 |
=== SWAPPING =================================================================
|
|
|
7 |
|
|
|
8 |
While conventional RAM is scarce, a command line interpreter must make effort
|
|
|
9 |
to reduce its memory footprint when launching applications. SvarCOM does that
|
|
|
10 |
by installing a small executable module in memory, called RMOD (for Resident
|
|
|
11 |
MODule). SvarCOM pre-sets RMOD so knows how to execute the external program
|
|
|
12 |
and removes itself from memory, letting RMOD do the job. RMOD executes the
|
|
|
13 |
application, waits for it to finish and then calls back SvarCOM.
|
|
|
14 |
|
|
|
15 |
|
474 |
mateuszvis |
16 |
=== NLS STRINGS ==============================================================
|
467 |
mateuszvis |
17 |
|
|
|
18 |
SvarCOM can output information in many languages. To do so, it relies on a
|
|
|
19 |
precompiled resource file named SVARCOM.LNG. When SvarCOM starts, it looks
|
|
|
20 |
for this file in the %NLSPATH% directory and loads from it the part that
|
|
|
21 |
contains the %LANG% language. All this is done by nls_langreload().
|
|
|
22 |
|
|
|
23 |
The SVARCOM.LNG file is compiled by a separate tool: TLUMACZ. It takes
|
|
|
24 |
CATS-style language files as input and compiles them into a single SVARCOM.LNG
|
|
|
25 |
resource file. It also produces a DEFAULT.LNG with english strings only, this
|
|
|
26 |
one is embedded into the SvarCOM executable to display english text in case
|
|
|
27 |
SVARCOM.LNG is unavailable.
|
|
|
28 |
|
|
|
29 |
|
474 |
mateuszvis |
30 |
=== BATCH FILES SUPPORT ======================================================
|
447 |
mateuszvis |
31 |
|
|
|
32 |
When SvarCOM executes a command, it checks first if it has a *.BAT extension.
|
469 |
mateuszvis |
33 |
If so, it switches into 'batch-processing' mode:
|
447 |
mateuszvis |
34 |
|
469 |
mateuszvis |
35 |
- Writes the batch filename into its persistent (rmod-owned) buffer, along
|
474 |
mateuszvis |
36 |
with a counter that holds the offset of the next line to be executed.
|
469 |
mateuszvis |
37 |
|
481 |
mateuszvis |
38 |
When the batch filename buffer is non-empty, SvarCOM does not ask the user for
|
|
|
39 |
a command. Instead, it opens the batch file, jumps to the "next line to be
|
|
|
40 |
executed" and loads the command from there, incrementing the line counter in
|
|
|
41 |
the process.
|
447 |
mateuszvis |
42 |
|
|
|
43 |
|
576 |
mateuszvis |
44 |
=== PIPING COMMANDS ==========================================================
|
|
|
45 |
|
|
|
46 |
Piping a command means redirecting its standard output (stdout) to the
|
|
|
47 |
standard input (stdin) of another command. While redirection of file handles
|
|
|
48 |
is a concept well supported by the DOS kernels, piping is not, in part due to
|
|
|
49 |
the mono-task nature of DOS. SvarCOM provides piping support through following
|
|
|
50 |
logic:
|
|
|
51 |
1. user-entered (or batch-acquired) command line is analyzed for any kind of
|
|
|
52 |
redirections (incl. pipes) by redir_parsecmd(). If the command appears to
|
|
|
53 |
be piped, then redir_parsecmd() enforces a stdout redirection to a
|
|
|
54 |
temporary file and moves all the pipe chain to an RMOD-owned buffer named
|
|
|
55 |
"awaitingcmd", appending an stdin redirection so the next command's stdin
|
|
|
56 |
is fed from the temporary file. The command is then executed.
|
|
|
57 |
2. before further execution, SvarCOM looks into its "awaitingcmd" buffer, and
|
|
|
58 |
if it is non-empty, it runs its content.
|
|
|
59 |
3. when loading commands from the awaitingcmd, SvarCOM sets a special
|
|
|
60 |
"delete_stdin_file" flag and passes it to command-executing functions so
|
|
|
61 |
these remember to delete the stdin-redirected file.
|
|
|
62 |
|
|
|
63 |
|
573 |
mateuszvis |
64 |
=== GLOBAL EXECUTABLE LINKS ==================================================
|
571 |
mateuszvis |
65 |
|
573 |
mateuszvis |
66 |
SvarCOM features special support for "global executable links". This allows to
|
|
|
67 |
run selected programs from any directory, without the need to copy these
|
571 |
mateuszvis |
68 |
programs to a directory in %PATH%. Executable links are flat files written in
|
573 |
mateuszvis |
69 |
%DOSDIR%\LINKS\. Each file there contains the directory where the matching
|
571 |
mateuszvis |
70 |
program should be looked for.
|
|
|
71 |
|
|
|
72 |
|
521 |
mateuszvis |
73 |
===================================================================== EOF ====
|