
OS/2 Subsystem handling of C:\CONFIG.SYS
----------------------------------------

OS/2 1.x uses at boot time the information in the C:\CONFIG.SYS file to
configure itself and set global parameters relevant for its operation.

The OS/2 SS holds a private copy of CONFIG.SYS in the registry which it
uses for setting initial values when the OS/2 Subsystem starts. File I/O
operations which access the file C:\CONFIG.SYS are mapped to the
registry entry of CONFIG.SYS.

This mapping allows OS/2 setup programs to work properly in the NT
environment and allows special initialization of the OS/2 SS.

Users can modify these parameters by editing the file C:\CONFIG.SYS with
an OS/2 editor (and exiting from the editor with the Save option).
This ensures that the modified information be spread to the proper locations
in the registry (these locations are described later).

Another alternative is to use REGEDIT, but this is not recommended
since the changes are kept locally within the CONFIG.SYS registry node.

The NT OS/2 subsystem recognizes the following subset of parameters
that can be found in CONFIG.SYS:

PROTSHELL
LIBPATH
SET
DEVICENAME
COUNTRY=xxx[, ...]
CODEPAGE=xxx[,yyy]
DEVINFO=kbd,xx[, ...]

Other parameters are ignored.

The OS/2 Subsystem, when started, looks for a registry entry of CONFIG.SYS.
If the entry already exists, then the Subsystem leaves it as is. If there 
is no such entry in the regsitry, the Subsystem looks for an original OS/2
config.sys file. This file is processed and the relevant information is 
extracted and placed in the registry. If no OS/2 config.sys file exists, the
Subsystem creates a default registry entry for the CONFIG.SYS information.

The entry name is config.sys, its type is REG_MULTI_SZ and it is created in
the registry node:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OS/2 Subsystem for NT\1.0\config.sys

The entry contains initial important values for CONFIG.SYS that setup programs
look for.

The default config.sys in the registry contains:

/--------------------------------------------------/
PROTSHELL=c:\os2\pmshell.exe c:\os2\os2.ini c:\os2\os2sys.ini
%SytemRoot%\system\cmd.exe
SET COMSPEC=%SytemRoot%\system\cmd.exe
LIBPATH=%Os2LibPath%
SET PATH=.
/--------------------------------------------------/

%SystemRoot% is replaced with the SystemRoot value.
%Os2LibPath% is replaced with the Os2LibPath environment variable at the
             time the NT OS/2 Subsystem started.

When the first file operation within an application is activated on
C:\CONFIG.SYS (in DosOpen(), DosMove(), etc...) The registry information
of CONFIG.SYS is copied to a disk file called C:\OS2CONF.NT
All following accesses to C:\CONFIG.SYS will be mapped to the C:\OS2CONF.NT
file. (Note that the file C:\OS2CONF.NT contains the same strings as in
the registry, but each string is terminated with CR-LF making the file
an ordinary text file).

When the application terminates, The file C:\OS2CONF.NT is copied back
to the registry where it is posted as REG_MULTI_SZ entity.

The copy process scans this file for the special string:

LIBPATH=

The value of the LIBPATH string is copied to the registry

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Session Manager\Environment\Os2LibPath

so that on the next boot it will set the correct new value for Os2LibPath.

The value of PATH, if changed, is appended to the end of:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Session Manager\Environment\PATH

so that any new value added to the PATH will be in effect on the next boot.

The environment values which are defined by SET are added to the registry
node:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Session Manager\Environment

The user needs to reboot his system after any changes are made to
C:\CONFIG.SYS
so that the changes become effective.

The DEVICENAME parameter is described later in the 'OS/2 CUSTOM
DEVICE DRIVERS' section of this document.

The OS/2 Subsystem uses the NT defaults for NLS processing to set the environment
for OS/2 1.x apps running under the OS/2 SS unless it encounters
specific directives in the CONFIG.SYS registry node. These directives
which are COUNTRY, CODEPAGE, DEVINFO, will override (if present) the defaults.


OS/2 SS CUSTOM DEVICE DRIVERS
-----------------------------

General:
-------

The NT device driver model is different from OS/2, and access to HW is
not given to user-mode programs, therefore the body of the OS/2 custom
device driver itself has to be ported to the NT model and join the \nt\driver
directory, to be loaded by NT at init time.

Naming:
------

In OS/2 the OS reads the .SYS file to add the name "SECDEV" to the
device driver list. On DosOpen, this list is searched first.

The command in the os2ss config.sys file (which is in the registry),
that makes the connection between OS/2 apps and a custom device driver
which is ported to NT is:

DEVICENAME=<logical-name-of-OS/2-device> [<name-of-NT-device>]

<logical-name-of-OS/2-device> is the name used by OS/2 apps to open the
device.

<name-of-NT-device> is an optional parameter which specifies the full
pathname of the NT device to which the OS/2 logical device name is mapped.
If this parameter is not specifid then the NT device name will be defaulted
to:

\Device\<logical-name-of-OS/2-device>

The OS/2 SS, at initialization time, processes config.sys. It
creates symbolic links for all the devices to be used by
OS/2 programs, including custome devices as defined above.

For Example:

DEVICENAME=SECDEV

will map the OS/2 logical name SECDEV to \Device\SECDEV

DEVICENAME=SECDEV \Device\SECURITY

will map the OS/2 logical name SECDEV to the NT device \Device\SECURITY

APP interface:
--------------

The app code (as opposed to the DD code) will load and run binary compatible.
This is because the device-specific parameters passed by NtFsFileControl, and
by DosDevIoctl(2), are just PVOID buffers. Of course, the new NT-ported
DD has to be compatible with the original, i.e. accept the same set
of parameters within the buffers.

Other OS/2 apis e.g. DosOpen are supported compatibly, identical to
the support for 'system' DDs like COM device, KBD, SCREEN etc.

The OS/2 SS DosDevIOCtl and DosDevIOCtl2 will accept only Categories 0x80-0xff
when accessing custom device drivers. Other codes are reserved by OS/2 for
predefined categories.

A sample pseudo code will be:
//
// if \Device\SECDEV is the name of the security card DD
//
APIRET RetCode;
HFILE Handle;
 ...
RetCode = DosOpen("SECDEV", &handle, ...);
// check error
RetCode = DosWrite(handle, ...);
// check error
RetCode = DosDevIoctl2(handle, ...).
// check error


NT Device driver interface
--------------------------

The OS/2 DosDevIOCtl[2] API is translated by the OS/2 SS to the
NtDeviceIoControlFile() API. The NtDeviceIoControlFile() API has an
IoControlCode parameter. The value of this parameter is calculated by
the OS/2 SS according to the following formula:

CTL_CODE(Category|0x8000,Function|0x800,METHOD_BUFFERED,FILE_ANY_ACCESS)

The | operations on the Category and Function parameters are done in order
to map the Category and Function values to the range which is not reserved
by Microsoft.

The DosDevIOCtl[2] pvData parameter is passed to NtDeviceIoControlFile()
as the OutputBuffer parameter.

The DosDevIOCtl[2] pvParm parameter is passed to NtDeviceIoControlFile()
as the InputBuffer parameter.

If the OS/2 application is using DosDevIOCtl() APIs, the NT device
driver can trust the values passed by NtDeviceIoControlFile() as the input
and output data buffers.

If the application is using DosDevIOCtl then the input and output buffer
sizes which are passed to NT by NtDeviceIoControlFile() are 0. The NT
device driver should check for the validity of the buffers.





