|
|
|
The ANSIPLUS INSTALL program can recognize and alter the OS/2 CONFIG.sys file just as it can for MS-DOS. Once ANSIPLUS is installed, it will be available to all OS/2 full screen and windowed DOS sessions. ANSIPLUS features will not be available to OS/2 sessions, however, because ANSIPLUS is currently a DOS, not an OS/2 device driver. Only a few other issues affect ANSIPLUS under OS/2:
Screen scroll-back data will exist only as long as the virtual DOS machine that created it exists, so scroll-back will not be available from one command to another under the OS/2 command shell, but it will be available when you are using a DOS command shell in a virtual DOS machine.
The $i PROMPT, which is part of the default DOS prompt inserted by the OS/2 installation program, interferes with ANSIPLUS scroll-back because at every DOS command shell prompt the top line on the screen is replaced by an OS/2 help message. When the screen scrolls, this message is then added to scroll-back instead of the original content of the top line. It is best to remove the $i from your DOS prompt, but if you want to keep on using it, you should replace the $i with the prompt sequence $e[s$e[H$e[K$i$e[u, which will save the top line to scroll-back before the OS/2 help message is put there.
You must disable VIDEO_RETRACE_EMULATION if you want to use smooth scrolling in full screen DOS sessions. Otherwise, OS/2 will ignore ANSIPLUS’s smooth scrolling control. Rough scrolling always applies in DOS windows.
Because virtual DOS machines are created and initialized so often by OS/2, the ANSIPLUS signon message is suppressed when ANSIPLUS is loaded as a device driver by CONFIG.sys. When ANSIPLUS.exe is loaded as a TSR, the signon message will always be displayed. The unregistered Shareware driver will display the ANSIPLUS signon (with the 9 second delay) about one percent of the time when it initializes.
Because of DESQview’s handling of drivers loaded before it starts, and because it takes over an interrupt vector used by ANSI drivers, DESQview presents a challenge for an attached console driver like ANSIPLUS:
If a device driver, such as ANSIPLUS, is loaded before DESQview is started, a single copy of the driver will be shared by all DESQview windows (i.e., virtual 8086’s), because DESQview does not create local copies for each window. This means, for example, that changing colors by ANSI escape sequence in one window would affect the colors used in other windows.
As each DESQview window is created, the Int 29h fast console output interrupt, which ANSIPLUS and other ANSI drivers depend on to receive much of their character output, is taken over by DESQview. This means that DOS output, including ANSI control sequences, will never be processed by the driver, because DESQview will get it first.
Because of these problems, to use the ANSIPLUS console driver in a DESQview window, it must be loaded as a TSR after the window has started. The best way to do this is to create a batch file that loads ANSIPLUS and does anything else needed to set up the window, and then executes the command associated with the window.
And there are a few more complications:
It is desirable to use ANSIPLUS both inside and outside of DESQview. This means that if an ANSIPLUS driver is already loaded when DESQview is started, it must detect this event so that the driver can disable itself. When DESQview terminates, the driver must then reactivate itself.
To save memory, any TSR copies of ANSIPLUS loaded in a window should be able to execute using the sharable code from the first ANSIPLUS driver loaded, so that the TSR copy for each DESQview window will require only about 6K.
Expanded memory, which is used by ANSIPLUS to hold its scroll-back data and sometimes its code, is managed globally under DESQview, so the ANSIPLUS driver must allocate separate EMM handles for scroll-back and assign them different names in each DESQview window.
The Freeware ANSIPLUS.exe device driver satisfies all these requirements. The old Shareware ANSIPLUS.sys driver, however, cannot be loaded as a TSR except by another program, such as Quarterdeck’s DEVICE.com. And because loading the CON device driver ANSIPLUS.sys will change the system console, DEVICE.com does not appear to completely install the driver, at least as far as COMMAND.com, the MS-DOS command shell, is concerned. This must be corrected by entering a CTTY CON command in each window after ANSIPLUS.sys has been loaded.
The ANSIPLUS driver is DESQview aware: after it is loaded in a DESQview window, it uses alternative video buffers for video output if the screen is not "virtualized", calls the BIOS for cursor positioning instead of writing directly to the video controller, releases time slices when waiting for key input, disables the ANSIPLUS screen saver, and prevents the video RAM from being used to store scroll-back (EMS scroll-back is still allowed).
When a task switcher, such as MS-DOS DOSSHELL, is running, the user should have independent ANSIPLUS consoles for each task. To provide this functionality, ANSIPLUS supports the Microsoft Int 2Fh functions 4B01h-4B05h task switcher interface, which is used by both DOSSHELL and Windows 3.1 Standard Mode. Via the interface, ANSIPLUS reports its instance data to the task switcher and monitors switcher activity to control allocation and destruction of EMS handles for session scroll-back, if the task switcher allows this. ANSIPLUS should also work with other task switchers that support this interface.
|
|
|
© Copyright 2000-2007, Kristofer Sweger. All rights reserved. |
Rev. 11/01/07 |