|
|
|
Users of Windows 98, 95, 3.1 or NT 4 should consider using ANSIPLUS as well. The ANSIPLUS driver works well under Windows, and because ANSIPLUS is a CON device driver, local copies of it are included in each Windows virtual DOS machine. This means that all the ANSIPLUS internal state variables, and those of its integrated console features, will be local to each virtual machine, so there is no way they can interfere with each other. This section discusses how to work around the specific limitations imposed on ANSIPLUS DOS sessions by Windows or by Windows in combination with other software.
The following topics are covered here: Loading options, Full screen vs. windowed DOS sessions, Copy and paste, Scroll-back, Color palettes, Beep tone, International usage, and Windows NT.
All ANSIPLUS memory loading options are compatible with Windows, with the following exceptions:
Under Windows 9x, ANSIPLUS’s code cannot be loaded into EMS memory unless an EMS memory manager is loaded explicitly in CONFIG.sys by a DEVICE= command in CONFIG.sys before ANSIPLUS. If EMM386 is loaded automatically as Windows 9x initializes, it will be loaded after ANSIPLUS, so EMS memory will not exist when ANSIPLUS is installed by MS-DOS 7. This means you should have a DEVICE=EMM386.exe command in your CONFIG.sys file.
ANSIPLUS's code cannot be loaded to the HMA under MS-DOS 7 (Windows 9x only) because there apparently is not enough unused HMA memory available.
When the ANSIPLUS code has been loaded into expanded memory, Version 6 of 386MAX (and possibly other versions) will refuse to let Windows start in 386 Enhanced mode. The 386MAX memory manager complains that expanded memory cache software is running. This limitation does not exist for the EMM386 or QEMM386 memory managers. To get Windows to run with ANSIPLUS and 386MAX, load the ANSIPLUS driver into XMS upper memory, HMA, or low memory instead.
If Windows 3.0 (not 3.1 or 9x or NT!) will be run in 386 Enhanced mode, it is strongly recommended that the entire ANSIPLUS driver (or any other ANSI driver) not be loaded into high memory by DEVICEHIGH or equivalent, and that ANSIPLUS load itself high instead. This is because Windows 3.0 does not localize the XMS upper memory block area above 640K for its virtual 8086’s, and so only one global copy of ANSIPLUS would be shared among all virtual machines. This can cause trouble: if, for example, a program in one window selects colors, then those colors would also be in force for all DOS programs in other windows!
The VWFD.386 Windows Virtual Device Driver for Windows 3.x or 9x, which is supplied with ANSIPLUS, is required to test whether a DOS virtual machine is running full screen or in a window. If the VWFD.386 driver is not installed, ANSIPLUS will have no way of knowing whether it is running full screen under Windows, so it must assume that a DOS session is in a window and disable three features:
Screen saver:
The screen should be blanked by ANSIPLUS only when a DOS session is full screen; the Windows screen saver should have control when the DOS session is in a window.
Smooth scrolling:
This should operate correctly for full screen DOS programs under Windows. However, when a DOS session is run in a window, the direct access to video controller I/O ports required for smooth scrolling may interfere with some Windows 3.x video display drivers. For example, the 256-color drivers for the Tseng ET4000 may leave undrawn black areas on the screen when scrolling occurs in a window while smooth scrolling is active. Because of this, smooth scrolling must be prevented when a DOS session is in a window, and allowed only when it is full screen.
Mouse copy/paste when Scroll Lock is off:
When a DOS session is running in a window, the user can move the mouse all over the screen, sometimes crossing over the DOS session window. Because of this, ANSIPLUS will not "wake up" the mouse when running in a window unless the
Scroll Lock
key has been pressed to freeze the screen.
DEVICE=VWFD.386
VWFD.386 can be installed to Windows 98, 95 or 3.x. It will not work with Windows NT.
When key input is pasted from the Windows clipboard, it is made available to programs by ANSIPLUS via the Int 16h key input interrupt. But Microsoft, in their wisdom, has disabled Int 2Fh/AH=17h access to the Windows clipboard by a virtual DOS machine while it is executing an Int 16h key input interrupt. To get around this limitation, ANSIPLUS copies data to and from the Windows clipboard in the background during hooked Int 28h DOS Idle, Int 1Ch User Timer Tick and Int 21h DOS call interrupts. However:
Under Windows 9x, it appears that the Int 28h DOS Idle call is never executed by each virtual DOS machine. Under Windows 3.1, it is.
In Windows 3.1, some networks (eg., NetWare) add a " TimerCriticalSection= " line to SYSTEM.ini. Windows 9x does not support this line in SYSTEM.ini, but on a Novell network behaves as though it did. According to Novell, the reason for the TimerCriticalSection line is to avoid a deadlock in its LAN IRQ Virtualization code. Unfortunately, this keeps the ANSIPLUS Int 1Ch hook from executing properly in each virtual DOS machine, and because of this, text might not be pasted to those MS-DOS programs that use Int 16h for key input instead of standard DOS key input if they don't also make Int 21h DOS calls while waiting for key input. Removing the TimerCriticalSection line from SYSTEM.ini may fix the problem, but you should do this only if you have trouble pasting data, and you should test your system carefully to be sure this doesn't introduce problems with network access.
The recommended storage location for scroll-back data under Windows is expanded memory (EMS). Use of EMS for scroll-back instead of video RAM (as was done by ANSIPLUS drivers before Release 3.10) eliminates compatibility problems with Windows video drivers apparently caused by memory accesses to video RAM not on the visible part of the virtual screen.
The standard Windows 3.x DOSPRMPT.pif and _DEFAULT.pif files both allow programs to access EMS memory. A sample PIF file with suggested PIF settings (for the MS-DOS command prompt) is included with the ANSIPLUS package in the file APLUS.pif. These settings are recommended, but not necessary, for all DOS applications that depend on scroll-back under Windows.
Under Windows, when a 386 Enhanced Mode DOS session starts, ANSIPLUS will try to allocate 64K of private expanded memory (EMS) for scroll-back (48K if ANSIPLUS code was loaded into EMS). If the EMS is not available (for example, if the Windows PIF file for the application does not provide expanded memory), then the driver will attempt to use video RAM for scroll-back instead, if that option has been specifically enabled. ANSIPLUS provides a configurable feature that can prevent Windows EMS from being allocated for scroll-back and force any Windows DOS session scroll-back to reside in video RAM. This is not advised, however, because scroll-back in video RAM under Windows is not reliable when used with many Windows video drivers.
Using video RAM for scroll-back under Windows 3.x has problems, particularly for DOS applications run in a window. One difficulty is that when a DOS application is run in 386 Enhanced Mode, Windows will not maintain a full 32K of text mode RAM unless the Windows PIF file specifies High Graphics and Retain Video Memory. If these PIF settings are not used, then the first time that ANSIPLUS needs to access the scroll-back storage area, Windows may present a message claiming that there is not enough memory for the application to correctly display information. If this happens, just click on OK, then hit Alt+Enter to switch to a full screen display and proceed. Scroll-back data will also likely be lost when the focus is switched from task to task, as with the Alt+Tab key, or when changing display modes. Even with these PIF settings, some Windows 3.1 video drivers (eg., 256-color ET-4000) will not work correctly when video RAM outside the visible screen is accessed, resulting in loss of scroll-back text or incomplete updating of the screen. You therefore should exercise caution before relying on video RAM for scroll-back.
Starting with ANSIPLUS Release 3.1, scroll-back lines are captured under Windows as they are completed, rather than as they scroll off the top of the screen. This change was necessary because some Windows 3.1 video drivers (eg., Microsoft VGA) trap BIOS scrolling requests completely and do not pass them through to the DOS virtual 8086 when running a DOS session in a window. This makes it impossible for ANSIPLUS to know when the screen has scrolled if a BIOS call was used to do it. Some important DOS programs now mix DOS output and BIOS calls for scrolling (eg., 4DOS 5.0 and NDOS 8.0 when displaying multi-colored directories).
Full screen DOS programs in Windows will use the same colors that they do when run under DOS. When the same program is run in a window, its 16-color palette will be determined entirely by Windows and the Windows video driver. ANSIPLUS will have no control over the palette when running in a window.
Under Windows, when a DOS session is run in a window using Microsoft's VGA video driver (and possibly others), ANSIPLUS's pink color may appear as white. This can be corrected by converting pink to light magenta with the WINVGA16.com program provided with ANSIPLUS. Including WINVGA16.com in AUTOEXEC.bat will change pink to light magenta for all DOS applications in and out of Windows. Running it within a Windows DOS session will change the color for only that DOS session. However, WINVGA16.com will not work if run in WINSTART.bat because it is not a TSR.
Some 256-color drivers for Windows apparently assume that the OEM 256-color palette has been loaded when the 256-color mode was selected, and never define the colors that Windows will use. Because of this, ANSIPLUS normally does not load its default colors when a 256-color mode is selected under Windows. This can be overridden by a configurable feature.
When Windows is running in 386 Enhanced mode, and a DOS program running in the background outputs a Ctrl+G, the background program’s virtual 8086 may not be running fast enough to accurately time the tone. Because of this, the tone can drag out and sound strange. Disabling ANSIPLUS tone generation under Windows restores the original Windows sound driver, but makes the tone frequency and duration non-changeable.
When the DISPLAY.sys driver is used with Windows 3.x, the colors and other variables of either ANSIPLUS or the DOS ANSI.sys driver are not localized to each virtual 8086. This appears to be because DISPLAY.sys is a CON device driver that calls the previous CON driver (i.e., ANSIPLUS) to control the console, so DOS actually has two CON drivers active at the same time. Windows only localizes the first CON driver it finds on the DOS device chain, and this will be the most recent CON device installed, which is DISPLAY.sys, not ANSIPLUS. Two system setup changes are required to circumvent the problem:
Enter the following command to change the name of the ANSIPLUS driver in memory from "CON" to "CONAPLUS":
SETAPLUS LOCALCON
This command is automatically inserted into AUTOEXEC.bat by the ANSIPLUS INSTALL program when DISPLAY.sys is detected.
LOCAL=CONAPLUS
This causes Windows to localize the renamed ANSIPLUS driver to each virtual 8086. The ANSIPLUS INSTALL program automatically adds this line to SYSTEM.ini.
These system setup changes are totally unnecessary if the DISPLAY.sys driver is not being used.
Support for DOS applications under Windows NT 4.0 is limited by what that operating system allows a virtual DOS machine to do. Therefore, some ANSIPLUS features cannot be made to work as well as desired:
ANSIPLUS cannot control the keyboard state and lights:
Under Windows NT 4.0, the keyboard state is controllable only by user keystrokes. Because of this, Scroll Lock, Caps Lock, Num Lock or Shift status changes initiated by the ANSIPLUS driver will have no effect. Sticky shift keys, unlocking Caps Lock with shift/letter, and relocking Caps on a carriage return will not work. When Scroll Lock has been on, if the Scroll Lock condition is canceled by the mouse or another key, the Scroll Lock light will remain on, and the Scroll Lock key will have to be struck more than once to lock the screen again.
Smooth scrolling does not work:
ANSIPLUS's smooth scrolling has no effect, either full screen or in a window.
EMS memory should not be used by the ANSIPLUS driver:
There seems to be a bug in Windows NT 4.0's handling of EMS calls made from a DOS device driver. If EMS memory is used for scroll-back or for driver code, then after the first EMS call, ANSIPLUS sound generation no longer works. Under Windows NT, the ANSIPLUS driver automatically configures itself to disable EMS scroll-back and use video display memory for scroll-back instead.
Color palettes cannot be controlled by the driver:
Windows NT uses its own color palette for DOS applications. You can set this palette by selecting Properties for the DOS window and then choosing the "Colors" tab. You will need to enter the red, green and blue values for each color and save the properties so the palette will apply in the future.
Unlike MS-DOS, the Windows NT CLS command remembers the background color and does not use the current ANSI driver screen colors. The user must therefore select the background color in the Properties/Colors dialog.
Text height can be controlled:
To use more than 25 lines on the screen, select Properties for the DOS window and then choose the "Layout" tab. Set the "Window Size" to the desired number of lines (eg., 50), and save the properties for future use. Under the Windows NT COMMAND.com command shell, the window size may not adjust automatically each time you adjust the text height with SETAPLUS. Under 4DOS.com, the window size appears to adjust as it should.
|
|
|
© Copyright 2000-2007, Kristofer Sweger. All rights reserved. |
Rev. 10/16/07 |