Subversion Repositories SvarDOS

Rev

Rev 988 | Details | Compare with Previous | Last modification | View Log | RSS feed

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