| 1 |
|
1 |
|
| 2 |
|
2 |
|
| 3 |
=== SvarCOM implementation notes ===
|
3 |
=== SvarCOM implementation notes ===
|
| 4 |
|
4 |
|
| 5 |
|
5 |
|
| 6 |
=== SWAPPING =================================================================
|
6 |
=== SWAPPING =================================================================
|
| 7 |
|
7 |
|
| 8 |
While conventional RAM is scarce, a command line interpreter must make effort
|
8 |
Conventional RAM is scarce, that is why a command line interpreter must make
|
| 9 |
to reduce its memory footprint when launching applications. SvarCOM does that
|
9 |
efforts to reduce its memory footprint when launching applications. SvarCOM
|
| 10 |
by installing a small executable module in memory, called RMOD (for Resident
|
10 |
does that by installing a small executable module in memory, called RMOD (for
|
| 11 |
MODule). SvarCOM pre-sets RMOD so knows how to execute the external program
|
11 |
Resident MODule). SvarCOM pre-sets RMOD so it knows how to execute the external
|
| 12 |
and removes itself from memory, letting RMOD do the job. RMOD executes the
|
12 |
program and removes itself from memory, letting RMOD do the job. RMOD executes
|
| 13 |
application, waits for it to finish and then calls back SvarCOM.
|
13 |
the application, waits for it to finish and then calls back SvarCOM. All
|
| - |
|
14 |
necessary contextual data is kept in a resident, RMOD-owned memory structure.
|
| 14 |
|
15 |
|
| 15 |
|
16 |
|
| 16 |
=== NLS STRINGS ==============================================================
|
17 |
=== NLS STRINGS ==============================================================
|
| 17 |
|
18 |
|
| 18 |
SvarCOM can output information in many languages. To do so, it relies on a
|
19 |
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 |
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 |
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 |
contains the %LANG% language. All this is done by nls_langreload().
|
| 22 |
|
23 |
|
| 23 |
The SVARCOM.LNG file is compiled by a separate tool: TLUMACZ. It takes
|
24 |
The SVARCOM.LNG file is compiled by TLUMACZ (from the SvarLANG.lib suite). It
|
| 24 |
CATS-style language files as input and compiles them into a single SVARCOM.LNG
|
25 |
takes CATS-style language files as input and compiles them into a single
|
| 25 |
resource file. It also produces a DEFAULT.LNG with english strings only, this
|
26 |
SVARCOM.LNG resource file. It also produces a DEFLANG.C file with english
|
| 26 |
one is embedded into the SvarCOM executable to display english text in case
|
27 |
strings only, this one is embedded into the SvarCOM executable to display
|
| 27 |
SVARCOM.LNG is unavailable.
|
28 |
English text in case SVARCOM.LNG is unavailable.
|
| 28 |
|
29 |
|
| 29 |
|
30 |
|
| 30 |
=== BATCH FILES SUPPORT ======================================================
|
31 |
=== BATCH FILES SUPPORT ======================================================
|
| 31 |
|
32 |
|
| 32 |
When SvarCOM executes a command, it checks first if it has a *.BAT extension.
|
33 |
When SvarCOM executes a command, it checks first if it has a *.BAT extension.
|
| 33 |
If so, it switches into 'batch-processing' mode:
|
34 |
If so, it switches into 'batch-processing' mode:
|
| 34 |
|
35 |
|
| 35 |
- allocates a "batch context" structure and attach it to rmod
|
36 |
- allocates a "batch context" structure and attach it to rmod
|
| 36 |
- writes the batch filename into the batch context (rmod-owned) memory, along
|
37 |
- writes the batch filename into the batch context (rmod-owned) memory, along
|
| 37 |
with a counter that holds the offset of the next line to be executed.
|
38 |
with a counter that holds the offset of the next line to be executed.
|
| 38 |
- a batch context has a "parent" pointer that may point to another batch
|
39 |
- a batch context has a "parent" pointer that may point to another batch
|
| 39 |
context (owned by a different batch instance), it is, in essence, a linked
|
40 |
context (owned by a different batch instance), it is, in essence, a linked
|
| 40 |
list that allows batch files to call one another (typicall through the CALL
|
41 |
list that allows batch files to call one another (typicall through the CALL
|
| 41 |
command) allowing SvarCOM to get back to the parent batch once the child
|
42 |
command) allowing SvarCOM to get back to the parent batch once the child
|
| 42 |
terminates.
|
43 |
terminates.
|
| 43 |
|
44 |
|
| 44 |
When the rmod batch context pointer non-NULL, SvarCOM does not ask the user for
|
45 |
When the rmod batch context pointer non-NULL, SvarCOM does not ask the user for
|
| 45 |
a command. Instead, it opens the batch file, jumps to the "next line to be
|
46 |
a command. Instead, it opens the batch file, jumps to the "next line to be
|
| 46 |
executed" and loads the command from there, incrementing the line counter in
|
47 |
executed" and loads the command from there, incrementing the line counter in
|
| 47 |
the process.
|
48 |
the process.
|
| 48 |
|
49 |
|
| 49 |
|
50 |
|
| 50 |
=== PIPING COMMANDS ==========================================================
|
51 |
=== PIPING COMMANDS ==========================================================
|
| 51 |
|
52 |
|
| 52 |
Piping a command means redirecting its standard output (stdout) to the
|
53 |
Piping a command means redirecting its standard output (stdout) to the
|
| 53 |
standard input (stdin) of another command. While redirection of file handles
|
54 |
standard input (stdin) of another command. While redirection of file handles
|
| 54 |
is a concept well supported by the DOS kernels, piping is not, in part due to
|
55 |
is a concept well supported by the DOS kernels, piping is not, in part due to
|
| 55 |
the mono-task nature of DOS. SvarCOM provides piping support through following
|
56 |
the mono-task nature of DOS. SvarCOM provides piping support through following
|
| 56 |
logic:
|
57 |
logic:
|
| 57 |
1. user-entered (or batch-acquired) command line is analyzed for any kind of
|
58 |
1. user-entered (or batch-acquired) command line is analyzed for any kind of
|
| 58 |
redirections (incl. pipes) by redir_parsecmd(). If the command appears to
|
59 |
redirections (incl. pipes) by redir_parsecmd(). If the command appears to
|
| 59 |
be piped, then redir_parsecmd() enforces a stdout redirection to a
|
60 |
be piped, then redir_parsecmd() enforces a stdout redirection to a
|
| 60 |
temporary file and moves all the pipe chain to an RMOD-owned buffer named
|
61 |
temporary file and moves all the pipe chain to an RMOD-owned buffer named
|
| 61 |
"awaitingcmd", appending an stdin redirection so the next command's stdin
|
62 |
"awaitingcmd", appending an stdin redirection so the next command's stdin
|
| 62 |
is fed from the temporary file. The command is then executed.
|
63 |
is fed from the temporary file. The command is then executed.
|
| 63 |
2. before further execution, SvarCOM looks into its "awaitingcmd" buffer, and
|
64 |
2. before further execution, SvarCOM looks into its "awaitingcmd" buffer, and
|
| 64 |
if it is non-empty, it runs its content.
|
65 |
if it is non-empty, it runs its content.
|
| 65 |
3. when loading commands from the awaitingcmd, SvarCOM sets a special
|
66 |
3. when loading commands from the awaitingcmd, SvarCOM sets a special
|
| 66 |
"delete_stdin_file" flag and passes it to command-executing functions so
|
67 |
"delete_stdin_file" flag and passes it to command-executing functions so
|
| 67 |
these remember to delete the stdin-redirected file.
|
68 |
these remember to delete the stdin-redirected file.
|
| 68 |
|
69 |
|
| 69 |
|
70 |
|
| 70 |
=== GLOBAL EXECUTABLE LINKS ==================================================
|
71 |
=== GLOBAL EXECUTABLE LINKS ==================================================
|
| 71 |
|
72 |
|
| 72 |
SvarCOM features special support for "global executable links". This allows to
|
73 |
SvarCOM features special support for "global executable links". This allows to
|
| 73 |
run selected programs from any directory, without the need to copy these
|
74 |
run selected programs from any directory, without the need to copy these
|
| 74 |
programs to a directory in %PATH%. Executable links are flat files written in
|
75 |
programs to a directory in %PATH%. Executable links are flat files written in
|
| 75 |
%DOSDIR%\LINKS\. Each file there contains the directory where the matching
|
76 |
%DOSDIR%\LINKS\. Each file there contains the directory where the matching
|
| 76 |
program should be looked for.
|
77 |
program should be looked for.
|
| 77 |
|
78 |
|
| - |
|
79 |
|
| - |
|
80 |
=== STACK-OVERFLOW PROTECTION =================================================
|
| - |
|
81 |
|
| - |
|
82 |
RMOD reserves a 64-bytes memory buffer for its private stack. This is more than
|
| - |
|
83 |
enough for RMOD itself, as well as for the DOS exec function INT 21h,AX=4B00h.
|
| - |
|
84 |
|
| - |
|
85 |
There may be, however, exotic configurations where this stack is not enough,
|
| - |
|
86 |
typically if some stack-hungry TSR kicks in while RMOD is being active, or some
|
| - |
|
87 |
large interrupt handlers are used, etc. In such situation the 64-bytes stack
|
| - |
|
88 |
could be overflowed. RMOD copes with this by placing the stack right on top of
|
| - |
|
89 |
its command history buffer, and terminates the history string with a specific
|
| - |
|
90 |
signature. This way, if a stack overflow occurs and damages the command history
|
| - |
|
91 |
buffer, SvarCOM is able to easily detect it and invalidates the history buffer,
|
| - |
|
92 |
causing no risk of system instability. The user is notified about it, and the
|
| - |
|
93 |
only inconvenience is that he cannot recall the previous command.
|
| - |
|
94 |
|
| - |
|
95 |
Below the input buffer is RMOD's own memory signature, followed by its PSP.
|
| - |
|
96 |
This means that should the stack overflow become truly severe (more than 192
|
| - |
|
97 |
bytes and less than 326 bytes), RMOD signature will be overwritten and SvarCOM
|
| - |
|
98 |
won't be able to locate it, so a new copy of RMOD will be recreated. In case of
|
| - |
|
99 |
of a stack overflow that tries to use more than 326 bytes of memory, all hope
|
| - |
|
100 |
is lost and everything becomes possible.
|
| - |
|
101 |
|
| 78 |
|
102 |
|
| 79 |
===================================================================== EOF ====
|
103 |
===================================================================== EOF ====
|
| 80 |
|
104 |
|