|
CD Shell is a operating environment for x86 processors. It runs in 16-bit real-address mode, but uses 32-bit instructions from time to time (and so requires a mimimum 386 CPU).
The environment consists of the CD Shell core and a set of modules, which interact with each other to accomplish various tasks such as interfacing with the user or booting the system. The core exposes an API for use by the modules, called the core services. The modules in turn expose a set of routines, called module services, that the core can use for such things as executing commands and expanding variables.
|
|
|
The CD Shell core functions on two different levels. The user level deals with the interepretation of commands, and the developer level is tasked with providing services to the modules.
|
|
The absolute basic function of CD Shell is to receive and dispatch commands. It can either read commands from the console command line or from a script file. Once a command has been retrieved, the core must look to the modules for a handler capable of processing the command. If none is found, then the core will issue an unknown command error. This process is repeated over and over until command is encountered that results in further booting of the system.
While command execution is the driving force behind CD Shell, there are a few other things that can happen. When processing a command, the core may come across a macro (called a variable in userland) which needs expansion. In this case, a call is made to the module that hosts the macro to retrieve it's contents. When solving a mathematical expression, a module may need to be invoked to evaluate a function. Also modules can be defined to accept keystrokes (hotkeys) from the core's command line.
|
|
The CD Shell core provides about one hundred support services that the modules can use for things such as memory allocation, file and console input/output, and string processing. These services simplify the basic tasks most modules need to perform so that the developer can focus on the main functionality provided by their module.
The services are exposed through what is called the Core Services Table. It is a linear vector table (similar to the real-address mode Interrupt Vector Table) containing far pointers to the individual service routines.
|
|
|
The entire operating environment is contained in the first 640kb of system memory. CD Shell divides this area into five segments, appropriated for use as follows:
|
|
00000-0FFFF: BIOS Segment / Stack
|
|
This area is mainly reserved for the BIOS' use. It contains the Interrupt Vector Table (IVT), BIOS Data Area, and Initial Program Loader (IPL) area (0000:7C00). Also, CD Shell bases its system-wide stack at the top of this segment, and grows into it in expand-down fashon.
|
|
10000-1FFFF: CD Shell Core
|
|
This is where the CD Shell core (cdsh.bin) is loaded. All of the core services routines are located here.
|
|
20000-2FFFF: Script Cache Segment
|
|
This is where script files are cached during execution. Caching the scripts greatly increases script execution speed, as optical drive reads are relatively slow.
|
|
30000-7FFFF: Reservable Memory Pool
|
|
This area is where memory is dynamically allocated from. Modules are loaded here, and any memory they request from the core will be provided here, such as that reserved for user-defined macros.
Memory is allocated in very simple incremental style. Therefore, once a chunk of memory has been allocated, it cannot be freed.
|
|
80000-9FFFF: Scratch Area
|
|
This area is available for both the core and modules to use, but is not preserved across service calls. Once a module returns control back to the core, whatever it stored in the scratch area is not guaranteed to be there the next time the module is invoked.
|
|
|
The core employs an abstraction layer over the BIOS boot device access routines, which enables CD Shell to run while all of its files are wrapped up in an iso image. This is done by hooking BIOS interrupt 0x13, and offsetting the Logical Block Address of all disc accesses by the start address of the file cdshell.iso.
What does this mean to developers? If your designing a module, for instance, and you wish to access files that are on the disc but not inside cdshell.iso, you'll have to make a call to the core service disc.get_info to acquire the raw interface to the boot device. If you want to access files inside cdshell.iso after CD Shell shuts down, you'll need to use the same core service to retrieve the LBA offset of the virtual ISO file system.
For most purposes, however, this interface is completely transparent.
|
|
Copyright © 2002-2005 Michael K. Ter Louw. All rights reserved.
|
