| Line 3... |
Line 3... |
| 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.
|
| Line 74... |
Line 75... |
| 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 |
|
| 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 |
|
| - |
|
102 |
|
| 79 |
===================================================================== EOF ====
|
103 |
===================================================================== EOF ====
|