I have just picked up a new computer that has windows 2k for it OS. I was assured this would run DOS programs. I have installed PFS First Choice but when I click on the exe file or shortcut the screen either returns to Desktop. If I go to Command Prompt (dos) Loading first Choice, then I get an error message run time error 6009...not enough space for environment. My guess is that it's a 16bit vs 32bit problem....any help would be greatly appreciated. info@vicjohnston.ca

here you go: TechNet Home > Products & Technologies > Windows 2000 Professional > Resource Kits > Appendix D - Running Nonnative Applications in Windows 2000 Professional Topics on this Page The Emulation Model Running Windows 32-Bit Applications Running Win16-based Applications Running MS-DOS-based Applications Running OS/2-based Applications Running POSIX-based Applications Troubleshooting Additional Resources You can run applications created for Microsoft® Windows® 95 and Microsoft® Windows® 98, 16-bit Windows, Microsoft® MS-DOS®, OS/2, and the Portable Operating System Interface for UNIX (POSIX) standard under Microsoft® Windows® 2000 Professional. Windows 2000 Professional uses subsystems and processes that emulate the operating systems under which these applications run. The Emulation Model Windows 2000 provides support for nonnative applications by emulating the environments in which they are designed to be processed. This support is provided through environment subsystems and Virtual DOS Machines (VDMs). Each environment runs as a separate user-mode process, protected from errors in the other environments. Failure in one subsystem does not disable another subsystem or the core operating system. Applications are also user-mode processes, so they cannot hinder the other environments or the kernel-mode processes. Except for the Microsoft® Win32® subsystem, which is the native environment of Windows 2000, each environment is optional and is loaded only when a client application needs its services. Emulation Architecture The architecture of Windows 2000 provides a separate address space for each environment subsystem or VDM, thus protecting it from all other environments and preserving the robustness of the operating system. Most applications also run in their own address space. This allows Windows 2000 to run all operating system services and all applications by preemptive multitasking — working on more than one task at a time by periodically interrupting the execution of each. Figure D.1 shows the structure of the Windows 2000 emulation environment subsystems and VDMs. A description of the major emulation environment features follows. Figure D.1 Windows 2000 Emulation Environments Win32 Subsystem Win32 processes 32-bit applications and is the native environment of Windows 2000. It contains the console, which provides text window support, shutdown, and hard-error handling for all subsystems. Applications created for earlier versions of Microsoft® Windows NT® and Windows 95 or Windows 98 — which are also 32-bit operating systems — run on this subsystem. MS-DOS VDM The MS-DOS environment is implemented as a VDM, a 32-bit Windows–based application that emulates an Intel 486 computer running MS-DOS. Each MS-DOS–based application runs in its own separate VDM. Any number of these VDMs can be run at once, limited only by system resources. Each has its own address space, thus protecting the applications from each other and protecting the core operating system from the VDMs. Win16 VDM Extra layers added to the basic MS-DOS VDM emulate the 16-bit functionality of Microsoft® Windows 3.1® (Win16). By default, a single multithreaded VDM is used to run all 16-bit Windows-based applications; each application has its own thread in this VDM. Windows 2000 multitasks the VDM preemptively with respect to other processes but multitasks the applications running within it cooperatively (without interrupting processing) with respect to each other. You can also run a 16-bit Windows-based application in its own separate VDM. The result is that Windows 2000 preemptively multitasks the application because it preemptively multitasks the VDM itself and there is no other application running within the VDM. OS/2 Subsystem The OS/2 subsystem supports 16-bit character-based OS/2-based applications on x86-based computers. It emulates OS/2 version 1.3 and supports version 1.x, but not 2.x or later. POSIX Subsystem The POSIX subsystem supports applications written to the POSIX.1 standard. Applications must conform strictly to POSIX.1, or to the related standards set by the International Standards Organization (ISO) and the International Electrotechnical Commission (IEC) — commonly known as the ISO/IEC standards. Virtual DOS Machine Structure MS-DOS and Win16 (which is built on MS-DOS) are emulated by VDMs, not subsystems. Unlike the subsystems, the VDMs are not server processes. Instead, they run as 32-bit applications on the Win32 subsystem. They emulate the source code of MS-DOS version 5.0, minus the file system support. In addition, the Win16 VDM has two extra layers of memory that are loaded to enable it to use the Windows user interface. These layers are shaded in Figure D.2, a diagram of VDM virtual memory usage. A description of each layer of memory follows. Figure D.2 VDM Memory Map Instruction Execution Unit For Windows 2000 running on a computer other than an x86-based processor, the Instruction Execution Unit emulates the Intel 80486 instruction set, which lets the computer run the binary application. On an x86-based computer, the Instruction Execution Unit acts as a trap handler, which captures instructions that cause hardware traps and then transfers control to the code that handles them. A VDM on an x86-based processor supports enhanced-mode applications. 32-bit MS-DOS Emulation The 32-bit MS-DOS emulation layer emulates the DOS Protected Mode Interface (DPMI) and 32-bit memory access. Calls made to MS-DOS-level functions for extended and expanded memory are replaced in this layer with Windows 2000 memory calls. Windows 2000 then makes conversions so that the 16-bit application sees segmented memory as it normally would. Device Drivers Windows 2000 device drivers are a special type of dynamic load library (DLL) that assists in virtualizing hardware. The VxDs support communication (COM) ports, line printers (LPTs), video cards, the system timer, and other standard hardware. Windows 2000 drivers are dynamically loaded, so that new drivers can be written to support other, nonstandard devices. In addition, a call to a 16-bit MS-DOS driver or terminate-and-stay-resident (TSR) program can be relayed in a VDM through the thunking process (which transforms calls between 16-bit and 32-bit formats) to a Windows 2000 driver to communicate with the Windows 2000 kernel. This arrangement provides the functionality for compatibility with Microsoft® Windows® 3.x–based and MS-DOS-based applications, consistent with the design of Windows 2000. It avoids the unrestricted access to hardware that occurs in MS-DOS and sometimes in Windows 3.x. The 16-bit MS-DOS-based virtual device drivers that are designed as kernel drivers for MS-DOS-based versions of Windows (Windows 3.x, Windows 95, and Windows 98) are not compatible with Windows 2000 drivers and are not supported under Windows 2000. For more information about device compatibility, see "Device Driver Requirements" later in this chapter. 32-bit WOW Translation The WOW (Win16-on-Win32) layer consists of 32-bit window manager code and Graphics Device Interface (GDI) code that translates 16-bit segmented addresses into 32-bit flat addresses. A 16-bit application cannot call a 32-bit application programming interface (API). When an application calls a 16-bit API, the call goes to a stub routine, which in turn calls a 32-bit API. The 32-bit API performs the required action, and the result is transformed into the format expected by the 16-bit API stub, which returns the result to the application. This transformation is an example of thunking. Heap This area of memory holds code and data segments for 16-bit applications and DLLs, temporarily stored while programs are executing. This is a portion of memory whose existence or size cannot be determined until the VDM is running. In a Win16 VDM, this space is controlled by the Win16 kernel (Krnl386.exe) and contains Win16 global memory objects as well as objects allocated with the 16-bit GLOBALALLOC( ) parameter. In an MS-DOS VDM, the space is given to extended memory specification (XMS) memory, managed by the Himem.sys file. Windows 3.1 Kernel The Windows 3.1 emulation layer provides the functionality of the Windows 3.1 kernel and 16-bit API stubs. This is the layer that issues the 16-bit segmented addresses that are translated into 32-bit flat addresses by the WOW layer. Applications The 16-bit application or applications that are being processed in the VDM resides in this layer. 16-bit MS-DOS Emulation The 16-bit MS-DOS emulation layer contains all the information to emulate basic input/output system (BIOS) calls and tables. Device Driver Requirements Windows 2000 allows applications to communicate with computer hardware only by way of the core operating system. This maintains the robustness of the system. This feature can be a problem for applications not designed for Windows 2000 because they sometimes use device drivers that attempt to communicate with computer hardware directly. To protect the integrity of the core operating system, Windows 2000 prevents such drivers from running. Applications that require either Windows 2000–compatible device drivers or an upgrade to a compatible version include those that: Communicate directly with hardware (for example, a fax card, scanner card, or terminal emulation card). Rely on their own disk device drivers (for example, an application that increases hard disk capacity). Communicate directly with disk drives (for example, a disk maintenance application). Use their own graphics device drivers to communicate with the hardware (for example, an application that uses a custom printer driver). Note If your application requires, but does not supply, a Windows 2000–compatible device driver, contact the manufacturer. The manufacturer might have developed a version of the application that is fully compatible with Windows 2000. Suitability of Hardware Platforms Windows 2000 runs on computers with x86-based . Table D.1 shows how the system supports nonnative applications on these hardware platforms. Table D.1 Application Compatibility with Hardware Application Environment x86-based Processors Win32 (Windows NT, Windows 95, and Windows 98) Source-compatible. Win16 (Windows 3.x) Runs in a VDM. MS-DOS Runs in VDMs. POSIX Source-compatible. Interprocess Communication One process communicates with another on Windows 2000 by a local procedure call (LPC). When an application calls an API, the appropriate subsystem receives the LPC and in turn calls System Services (in the core operating system) or another subsystem. When the subsystem gets the requested values back, it sends an LPC passing them to the application. The LPC activity is invisible to the user. The Win32 subsystem handles all screen input and output for the other environments. Windows 2000 supports a common command processor, Cmd.exe, which runs commands from any subsystem. An application running under any subsystem can communicate with applications in other subsystems through object linking and embedding (OLE), Dynamic Data Exchange (DDE), and named pipes. Printing from an emulation environment is identical to printing on the operating system it emulates. To connect to a remote printer, type the net use command on the command line with the local port name and printer share name, as shown: net use lpt1: \\myprinter\pscript You can then use the dialog boxes or commands within an application to set up a printer and print your document. Note The POSIX subsystem does not support printing directly, but you can print its output if you redirect STDOUT (the standard output, which is usually the screen) to a printer and then write the POSIX output to STDOUT. Maintaining Windows 2000 Security The Windows 2000 Security subsystem protects interprocess communications but not processes that run in environments that emulate other operating systems. An application process running in the Win16 emulation environment behaves like an application process running on a Windows 3.1–based computer. It shares information with processes running on other computers in the same way — with the same reduced protection — that an application running on a Windows 3.1–based computer shares information. This can have unintended consequences if you have assumed that all information on the computer is protected by the more advanced security available in Windows 2000. Applications in emulation environments are potential weak points in system security if they are allowed to share critical resources over the network. For this reason, emulation must not be run on computers that store sensitive information. Running Windows 32-Bit Applications Although Windows 95 and Windows 98 are not designed for the same user requirements as Windows 2000, you might want to create applications on one system and run them on another. Windows 2000 does not require a special environment for this purpose. Applications based on Windows 95 and Windows 98, along with those from earlier versions of Windows NT, run on the Win32 subsystem. To run Windows 2000–based applications on Windows 95 and Windows 98, see the documentation for those applications. Application Compatibility Under Win32 Applications based on Windows 95, Windows 98, or Windows NT are fully compatible with Windows 2000, provided they do not depend on hardware that is no longer supported, or on files created in the High Performance File System (HPFS) format, which is intended for OS/2 operating systems. Windows 2000 and Windows 98 both use Win32 Driver Model (WDM) architecture, which provides a common set of input/output (I/O) services. Windows 95 uses an earlier version of WDM, which means that not all of its hardware device drivers work with Windows 2000. Most applications written for Windows 95 and Windows 98 run with no problems on Windows 2000. The exceptions are applications that: Write to different registry locations on Windows 95 and Windows 98 than on Windows 2000. Write different registry values to the same registry locations. Install different run-time files (such as .dll and .exe files). Install different versions of files that are common to Windows 95, Windows 98, and Windows NT. Make operating system–specific calls on Windows 95 and Windows 98 that are not available on Windows 2000. Hardware Restrictions Under Win32 Windows 2000 supports Windows NT 4.0 drivers and the new WDM drivers. It does not support 16-bit virtual device drivers such as those used in Windows 95 and Windows 98 for multimedia programs, games, and memory management applications. However, Windows 2000 supports most applications based on Windows 95 and Windows 98 that do not require a device driver to access hardware directly without going through the core operating system. Note For information about the Hardware Compatibility List (HCL), see the Microsoft Windows Hardware Compatibility List link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Absence from this list does not mean the hardware does not work with Windows 2000, only that it is untested and unsupported. Win32 Interprocess Communication Applications based on Windows NT, Windows 95, and Windows 98 can communicate with other processes using all the communication features and protocols that Windows 2000 offers. Running Win16-based Applications Windows 2000 provides a complete operating environment for 16-bit Windows 3.x–based applications, including those written on Microsoft® Windows® for Workgroups. The environment is comparable to the enhanced-mode environment in Windows 3.x.Applications in 16-bit Windows run in the multithreaded Win16 VDM. Application Compatibility Under the Win16 VDM The Win16 VDM supports nearly all 16-bit Windows-based applications. The few exceptions are as follows: Task-switching APIs. Block-mode device drivers. Microsoft CD-ROM Extensions (mscdex command) functions 2, 3, 4, 5, 8, E, and F. Enhanced-mode applications are supported on an x86 computer. On a non-x86 computer the VDM emulates the Intel 80486 instruction set, which lets the computer run enhanced-mode applications. How the Win16 VDM Works Windows 2000 runs 16-bit Windows-based applications as separate threads in a single VDM with a shared address space. This multithreading feature differs from MS-DOS-based applications, which each run in a separate VDM. The single multithreaded VDM mirrors the processing of native Windows 3.x. This is the default, but you can create other VDMs if you want applications to run in their own separate address spaces. Separating the applications simplifies performance monitoring. See "Configuring the Win16 Environment" later in this chapter. Logical Structure of the Win16 NTVDM The Win16 VDM has two system threads: A Wowexec.exe thread, which performs bookkeeping and other helping functions for Win16-based applications. A heartbeat thread, which simulates timer interrupts to the application. In addition, each Win16-based application has a thread running in the VDM. Several 16-bit applications can run in the VDM at the same time. However, to simulate native Windows 3.x processing, only one processing thread can be active at a time; all other threads of the applications are blocked. The multitasking within the VDM is cooperative rather than preemptive. The current thread is not interrupted; instead, processing of another thread does not begin until the current thread reaches a pausing or stopping point. Interruption might occur only from outside, when VDM processing is preempted by a thread of a Win32-based application that has a higher priority. When the microkernel resumes processing of the VDM, it always resumes with the thread that was preempted. Win32 code is used wherever it improves performance without sacrificing application compatibility; and Win16 code is used where Win32 code would use more memory without improving performance. Files Used by Win16 VDM The principal files used by the Win16 VDM are listed in Table D.2. Files that reside in MS-DOS layers are also found in MS-DOS VDMs. Table D.2 Principal Files Used by the Win16 VDM File Description Logical Location Autoexec.nt, Config.nt System startup configuration files, corresponding to the Autoexec.bat and Config.sys files in Windows 3.x and MS-DOS SystemRoot\System32 Command.com MS-DOS command interpreter 16-bit MS-DOS emulation layer Dosx.exe DPMI interface TSR program 16-bit MS-DOS emulation layer Gdi.exe Win16 Graphics Manager interface Windows 3.1 kernel layer Himem.sys Extended memory specification (XMS) driver 16-bit MS-DOS emulation layer Krnl386.exe Win16 kernel Windows 3.1 kernel layer Mmsystem.dll Win16 multimedia API Windows 3.1 kernel layer Mscdexnt.exe MSCDEX interface TSR program 16-bit MS-DOS emulation layer Ntdos.sys MS-DOS system kernel 16-bit MS-DOS emulation layer Ntio.sys MS-DOS input/output (I/O) kernel 16-bit MS-DOS emulation layer Ntvdm.exe VDM server SystemRoot\System32 Redir.exe NetBIOS interface TSR program 16-bit MS-DOS emulation layer Shell.dll Win16 shell interface Windows 3.1 kernel layer Toolhelp.dll Win16 tool helper API Windows 3.1 kernel layer User.exe Win16 User Manager interface Windows 3.1 kernel layer Autoexec.nt and Config.nt are used to start the files needed to run 16-bit Windows-based applications. The system creates Autoexec.nt from the Autoexec.bat file that belongs to the VDM, and creates Config.nt subsequently. It writes comments to the Autoexec.bat and Config.sys files describing the .nt versions. Win16 Interprocess Communication Windows 3.x–based applications can communicate with each other and with other processes on Windows 2000 using DDE, OLE 1.0, OLE 2.0, network basic input/output system (NetBIOS), WM_COPYDATA, and remote procedure calls (RPC). They can also use Windows Sockets (Winsock) through the Winsock API. Named pipes cannot be created but can be opened. Configuring the Win16 Environment Windows 3.x stores configuration information in the Win.ini and System.ini configuration files. Windows 2000 stores configuration information in the registry. However, Windows 2000 retains the Win.ini and System.ini files for use by Windows 3.x–based applications. If you install Windows 2000 over a Windows 3.x–based system, you can migrate the existing configuration information into the new system. Migrating the Configuration When you begin to install Windows 2000, the Setup program checks to see whether Windows 3.x is already installed. If it is, you need to install Windows 2000 in the same directory. Windows 2000 then configures its environment based on the existing environment, enabling it to support all the features of currently installed Windows 3.x–based applications. The first time you log on to Windows 2000, the settings that configure your desktop, and any program groups that are not predefined for Windows 2000, are migrated from Windows 3.x into Windows 2000. The Windows 3.x program groups appear as folders on the Start menu. Important After installing Windows 2000 in this manner, leave Windows 3.x on the computer. Deleting it might remove files needed by the applications. If you later install a new application while running Windows 3.x, Windows 2000 does not automatically gather file association and OLE information for the new application when you start Windows 2000. You need to reinstall the application on Windows 2000. Creating Multiple VDMs Under Win16 You have the option to run a 16-bit Windows-based application in its own VDM with its own address space. This feature allows applications to be fully preemptible and multitasked. To run a Win16-based application in its own VDM using the command line From the command line, type start /separate processname To reverse this procedure and run the application in the shared VDM process, type shared instead of separate. Processing might be slow if many VDMs are open at the same time. For information about how multiplying VDMs simplifies performance monitoring, see "Overview of Performance Monitoring" in this book. Win16-based Application Processing The Win16 VDM runs 16-bit Windows-based applications, which you can start from My Computer, Windows Explorer, or the command prompt. There are no visible distinctions in the user interface between 16-bit Windows-based and 32-bit Windows-based applications. Starting an Application When you start an application, Windows 2000 checks the binary type of the file to be run. It distinguishes between a 16-bit Windows-based application and an MS-DOS-based application, and starts the VDM with the correct parameters based on binary type. Running Mainframe Connectivity Software Some Windows 3.x–based software for connecting to mainframe computers requires a TSR program in order to operate correctly. When TSR programs run under Windows 3.x, they add a command to the Autoexec.bat file to start, or they need to be started through a batch file that must be run manually before starting Windows 2000. To run mainframe connectivity software that requires a TSR program In the Autoexec.bat file (or batch file if one is required), copy the line that contains the command to start the TSR program. Go to the Autoexec.nt file, find the line containing the file name "Redir.exe," and insert the line you copied as the next line in the file. Restart your computer before starting the connectivity application. Note The Autoexec.nt file usually resides in the SystemRoot\System32 folder with other Windows 2000 program files. Terminating the Win16 Environment If a malfunctioning application causes the Win16 VDM to not respond, you can terminate the VDM. To terminate the Win16 VDM Press CTRL+SHIFT+ESC to get the Windows NT Task Manager dialog box. Click the Applications tab. Click the name of the application you want. Click End Task. If the application does not respond, another dialog box appears, giving you the option to wait or to end the task. Important This procedure terminates all applications running in the VDM at the time. You can avoid this result by having a separate VDM for each application, but that lengthens the processing time. Running MS-DOS-based Applications Each MS-DOS-based application runs on Windows 2000 in a separate VDM. Any number of VDMs can be run within resource limits, each in its own address space. By default, Windows 2000 gives the name Ntvdm.exe to every VDM, but you can change their names; see "MS-DOS Application Processing" later in this chapter. Each VDM has its own system configuration files, named Autoexec.nt and Config.nt by default. To create custom startup files to run in place of these, see the information about customizing startup later in this section. Application Compatibility Under an MS-DOS VDM The MS-DOS environment supports nearly all MS-DOS-based applications. Exceptions are those that make direct hardware calls. It is recommended that you test your applications to ensure that they will work. MS-DOS-based applications that are known not to work on Windows 2000 are: Task-switching APIs. Block-mode device drivers. Interrupt 2F dealing with DOSKEY program callouts (AX = 4800). Microsoft CD-ROM Extensions (mscdex command) functions 2, 3, 4, 5, 8, E, and F. The Clipboard API (int 2k and func 17 commands). 16-bit virtual device drivers that require direct access to a hardware component. How MS-DOS VDMs Work When Windows 2000 runs on a 486-based processor, a processor mode called Virtual-86 mode is available. This mode allows direct execution of most instructions in an MS-DOS-based application. A few instructions (such as I/O instructions) must be emulated to communicate with the hardware. An MS-DOS VDM contains three threads: An application thread on which the MS-DOS-based application runs. A heartbeat thread that simulates the timer interrupts on native MS-DOS. A console thread that handles console I/O for the application. To run MS-DOS-based applications, the VDM acts as a virtual computer that supports: x86-based processor instructions, provided by the Instruction Execution Unit. Read-only memory basic I/O system (ROM BIOS) interrupt services, provided by the MS-DOS emulation module. MS-DOS Interrupt 21 services, provided by the MS-DOS emulation module. Virtual hardware for devices, such as the screen and keyboard, provided by Windows 2000 device drivers. Displaying Under MS-DOS VDM On x86-based computers, character-based applications can run either in a full screen display or in a window. Graphical applications can be displayed only in full screen. If an application in a window changes its video mode, it automatically switches to full screen. Files Used by MS-DOS VDM Table D.3 contains the principal files used by MS-DOS VDMs. Table D.3 Principal Files Used by an MS-DOS VDM File Description Logical Location Autoexec.nt, Config.nt System configuration files SystemRoot\System32 (you can change this location using a program information file) Command.com MS-DOS command interpreter 16-bit MS-DOS emulation layer Dosx.exe DPMI interface TSR program 16-bit MS-DOS emulation layer Himem.sys Extended memory specification (XMS) driver 16-bit MS-DOS emulation layer Mscdexnt.exe MSCDEX interface TSR program 16-bit MS-DOS emulation layer Ntdos.sys MS-DOS system kernel 16-bit MS-DOS emulation layer Ntio.sys MS-DOS I/O kernel 16-bit MS-DOS emulation layer Ntvdm.exe VDM server SystemRoot\System32 Redir.exe NetBIOS interface TSR program 16-bit MS-DOS emulation layer xxx.pif Program information file (PIF) SystemRoot (by default) Autoexec.nt and Config.nt are used to start the files needed to run MS-DOS-based applications. The system creates Autoexec.nt from the VDM's Autoexec.bat file and creates Config.nt subsequently. It writes comments to the Autoexec.bat and Config.sys files describing the .nt versions. PIF files provide information about the best way to run the application. If the application has no PIF file, the system uses a default file, _default.pif. MS-DOS VDM Interprocess Communication MS-DOS-based applications can communicate on Windows 2000 using the mechanisms of network basic I/O system (NetBIOS) and RPC. Named pipes cannot be created, but can be opened. Configuring the MS-DOS Environment You can customize the environment for MS-DOS-based applications using PIF files. Customizing Program Information When you start an MS-DOS-based application, Windows 2000 looks for a PIF file. If you were using a PIF file to run an MS-DOS-based application on Windows 3.x, you can continue to use it. In Windows 2000, however, a PIF file is created only when you create or modify a shortcut for the application. To create, modify, and save a PIF file Right-click the application file name in Windows Explorer. Click Properties. In the application's Properties dialog box, modify any settings you want to be different. Click OK to save the new settings in a shortcut (PIF) file for the application. The file name and extension of the new file are Xxx.pif, where xxx represents the main program file of the application. You can change the file name, but do not change the extension. The extension is not shown on Windows 2000 except in command-line tools like the dir command. However, you can still see a listing of your PIF files if you search for them using that extension. For example, the right pane of the window in Figure D.3 illustrates the results of a search for files in the format "*.pif." If your browser does not support inline frames, click here to view on a separate page. Figure D.3 Results of a Search for Files with a "*.pif" Extension Any changes made to the application's properties are also written to its PIF file's properties. Note The system reads a PIF file whenever you start the application by double-clicking its icon or the PIF file's icon. If you start the application from the command line, PIF file settings are ignored. Using Multiple PIF Files for an Application You can create more than one PIF file for an application, and you can create several PIF files for running an application under different circumstances. For example, on the Memory tab of a PIF file you can specify how much expanded memory specification (EMS) an application has access to. If you have two PIF files, you can allot a large amount of EMS to one of them for working with large data files, and allot only limited EMS to the other for use with small files. For information about how to set up two PIF files for an application, see Windows 2000 Professional Help. Default PIF File Windows 2000 provides a default file, _default.pif, in the SystemRoot folder. It has settings that work with most MS-DOS-based applications. Windows 2000 uses this PIF file if the application does not have one. Changing the settings in this file is not encouraged; leave the default file intact and create a separate PIF file for the application. Manufacturer-Supplied PIF Files Some software manufacturers provide a PIF file for an application. To find out whether your application has one, search the disks for a file with a .pif extension. For more information, see Windows 2000 Professional Help. Customizing Startup in the MS-DOS Environment To create a custom startup file for your application in Windows 2000, first specify this file in the application's PIF file. When you start the application, Windows 2000 reads the custom file rather than the Config.nt and Autoexec.nt files. For example, if your application requires a TSR program when it runs, you can include the name of that program in the application's startup file. Tip When you create startup files, base them on the Autoexec.nt and Config.nt files. That way the basic information to configure the MS-DOS environment is already included. At system startup, Windows 2000 adds path and set commands from the C:\Autoexec.bat file to the Windows 2000 environment variables, then ignores the remainder of both C:\Autoexec.bat and C:\Config.sys. If these files are not present when you install Windows 2000, the Setup program creates them. The startup files in this environment subsystem, and their use by Windows 2000, are listed in Table D.4. Table D.4 Startup Files in the MS-DOS Environment File Use in Windows 2000 C:\Autoexec.bat Adds path and environment variables to the Windows 2000 environment at system startup. The values thus established for these variables are then available to each application you use. C:\Config.sys Is not used by Windows 2000. Autoexec.nt and Config.nt in SystemRoot\System32 Configures the environment when an MS-DOS-based application is started with _default.pif. (You can use custom .nt files if you start from another PIF file.) You can edit the Config.nt and Autoexec.nt files just as you would Config.sys and Autoexec.bat. If you change values in Autoexec.bat, Autoexec.nt, or Config.nt, you must restart to make the changes effective. Available Commands for MS-DOS Configuration When you start an application in a new command window, Windows 2000 reads the Config.nt and Autoexec.nt files to configure the environment. If, for example, you change a driver in the application's Config.nt file, the change goes into effect the next time you start the application. Most commands in these files, but not all, are available for this purpose. Config.nt File Windows 2000 ignores any commands in the Config.nt file except for those listed in Table D.5. Also listed are special uses for these commands, if any. Table D.5 Commands in Config.nt File That are Read by Windows 2000 Command Special Use country/region No special use. device Loads an installable device driver. If necessary, you can load drivers that control memory, such as Himem.sys, or that control character-based display, such as Ansi.sys. dos No special use. dosonly No special use. echoconfig No special use. fcbs No special use. files No special use. install No special use. loadhigh No special use. ntcmdprompt Runs the Windows 2000 command interpreter, Cmd.exe, rather than Command.com after running a TSR program or after starting the command prompt from within an MS-DOS-based application. rem No special use. shell Specifies the command interpreter. Only Cmd.exe is supported. stacks No special use. Autoexec.nt File Windows 2000 supports approximately the same range of commands in the Autoexec.nt file as MS-DOS does in the Autoexec.bat file. For more information about these configuration commands, see Windows 2000 Professional Help. MS-DOS-based Application Processing You can start MS-DOS-based applications from My Computer, or the command prompt in the MS-DOS window. Starting an MS-DOS-based Application When you start an application, Windows 2000 looks at the binary type of the file to be run. It distinguishes between a 16-bit Windows-based application and an MS-DOS-based application, and starts the VDM with the correct parameters based on binary type. The following six settings in the _default.pif file establish the MS-DOS environment: Expanded memory specificaton (EMS) Extended memory specification (XMS) Miscellaneous multitasking options (such as Windows shortcut keys) Application shortcut key Custom MS-DOS initialization files Compatible Timer Hardware Emulation To start an MS-DOS-based application at the command prompt using its PIF file, use the start command. For example, to start Myapp.exe using Myapp.pif, type: start myapp The first MS-DOS-based application that you start at the command prompt establishes the environment for all MS-DOS-based applications running in that window. In a few cases, Windows 2000 might not recognize that an application is MS-DOS based. If an MS-DOS-based application fails to start, try starting it with the forcedos command. For example, to start the program Myprog in the D:\Oldapps directory, type the following at the command prompt: forcedos /d oldapps myprog Renaming VDMs Each MS-DOS-based application runs in its own VDM. All the VDMs are named Ntvdm.exe by default, but you can apply new names to specific VDMs by editing the registry. To rename a VDM Copy the file Ntvdm.exe to a new file and assign a different name. Use a registry editor to find the cmdline registry entry in HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Control \WOW. The default value of cmdline is SystemRoot\System32\Ntvdm.exe. In this value, change "ntvdm.exe" to the name of your copy of Ntvdm.exe. Caution The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible. When you start an MS-DOS-based application, it runs in a process with the name you specified in the registry. The registry change takes effect without rebooting. Thus, you can change the registry before starting different MS-DOS-based applications and have each application start in a uniquely named process. For information about using the registry editor, see the registry information in Windows 2000 Professional Help. Tip To avoid changing the default name permanently, set the value of cmdline back to Ntvdm.exe when you are finished running MS-DOS-based applications. Using TSR Programs Windows 2000 supports MS-DOS-based TSR programs, also called pop-up or memory-resident programs. Like any MS-DOS-based application you run in Windows 2000, TSR programs run in the window where they are started and can be used only within that window. They function reliably only when running alone or with other MS-DOS-based applications. If your application requires a TSR program, start the TSR program, and then start the application in the same command window. You can also create a custom startup file that starts the TSR program, and then specify it in the PIF file. For more information, see "Configuring the MS-DOS Environment" earlier in this chapter. Tip Starting a TSR program from Autoexec.nt or Config.nt is inefficient because the program is recopied each time you start an application that reads Autoexec.nt or Config.nt. Start the program just as you would any other application in Windows 2000. Command Interpreter When you run a TSR program or temporarily suspend an MS-DOS-based application to return to the command prompt, Windows 2000 runs Command.com (the command interpreter for MS-DOS) by default. This preserves the MS-DOS environment and lets you use the TSR program immediately. To return to Cmd.exe, type: exit When you quit an MS-DOS-based application, Windows 2000 returns to the Windows 2000 command interpreter, Cmd.exe. The Dosonly Command You can use the Windows 2000 dosonly command to disable applications other than MS-DOS-based applications. If they are not disabled, these applications can start at the Command.com prompt and disrupt a TSR program or suspend an MS-DOS-based application. You can include the dosonly command in either your Config.nt file or your custom startup file. The Ntcmdprompt Command When Command.com is running, some features of the Windows 2000 command prompt, such as the DOSKEY program's display of command history, are not available. If you prefer to run Cmd.exe after starting a TSR program or after starting the command prompt from within an MS-DOS-based application, you can use the ntcmdprompt command. You can include ntcmdprompt in either your Config.nt file or your custom startup file. Note The TSR program might not be available when Cmd.exe is running. Using an MS-DOS-based Application Mouse Cursor Some MS-DOS-based applications use a mouse cursor that cannot be synchronized with the system mouse pointer used by Windows 2000. If the Windows 2000 system mouse pointer does not work as expected with an MS-DOS-based application, you can hide it, thereby returning control of the mouse cursor to the application. For more information, see Windows 2000 online Help. Terminating the MS-DOS Environment If a malfunctioning application locks up a VDM, use the following procedure to terminate the VDM. To terminate an MS-DOS VDM Press CTRL+SHIFT+ESC to display the Task Manager. Click the Applications tab. Click the name of the application, and then click End Task. If the application does not respond, another dialog box appears giving you the option to wait or to end the task. Running OS/2-based Applications Windows 2000 supports OS/2-based applications through the OS/2 subsystem. A thunking code was developed to translate the 16-bit OS/2 APIs to 32-bit APIs for the 32-bit processor. This section describes the thunking layer as well as other ways in which the OS/2 subsystem differs from native OS/2. Compatibility of OS/2-based Applications and APIs In general, the OS/2 subsystem supports OS/2 1.x–based applications. However OS/2-based applications and APIs that normally gain access to kernel mode (Ring 0 of the Intel protection architecture) generally are not supported because they might interfere with the operating system or hardware devices. There are exceptions, however, and those are discussed in this section. Supported Applications You can run the following types of applications on the OS/2 subsystem: OS/2 1.x–based 16-bit applications on x86-based computers only. Character-based applications. Video input/output (VIO) applications that do not threaten the security of the core operating system or the robustness of Windows 2000. Unsupported Applications The types of applications listed in Table D.6 are unsupported and cannot be run on the OS/2 subsystem. There are exceptions for some of these types, which are noted. Table D.6 Applications Not Supported by OS/2 Type of Unsupported Application Exception or Workaround Applications created on OS/2, 2.x, and later versions of OS/2. Bound applications (those that can also run on MS-DOS) run on the Win16 VDM using the forcedos command. Presentation Manager applications. These applications run if you install the Windows NT Add-on Subsystem for Presentation Manager, available from Microsoft. Advanced video I/O (AVIO) applications. These applications run if you install the Windows NT Add-on Subsystem for Presentation Manager. Applications requiring direct access to hardware memory or I/O ports at Ring 2 or below, such as those that go directly to video memory. You can run an application that performs Ring 2 operations if none of those operations are IN/OUT instructions. For details, see "How the OS/2 Subsystem Works" later in this chapter. Custom device drivers (those not included with OS/2). You must rewrite these to the Windows 2000 device driver interface. See "How the OS/2 Subsystem Works" later in this chapter. If you have the source code for an unsupported application, you might be able to run it by recompiling it without the unsupported APIs. To find out which APIs are unsupported, you can attempt to run the application: the error message that is returned lists the unsupported APIs. Supported and Unsupported APIs Most APIs are supported, some are unsupported, and others are partially supported, as summarized in Table D.7. As with the applications, there are some exceptions. Table D.7 API Support on the OS/2 Subsystem API Prefix Level of Support Exceptions Dev Not supported. Dos Supported. DosDevIOCtl and DosDevIOCtl2 are only partially supported. Gpi Not supported. Kbd Supported. Those that conflict with security or robustness of Windows 2000 are not supported. Mou Supported. Those that require Presentation Manager (PM) or AVIO are not supported unless you install Windows NT Add-on Subsystem for Presentation Manager. Net Selected APIs supported, based on their commercial use. Vio Supported. Those that require PM or AVIO are not supported unless you install Windows NT Add-on Subsystem for Presentation Manager. Those requiring access to a physical video device are partially supported. Win Only WinQueryProfile and WinWriteProfile are supported. Partially-supported APIs threaten the robustness of Windows 2000 but are allowed as long as they do not perform certain operations. For example, Windows 2000 does not allow an API to take direct control of a hardware device but does allow interrupt instructions. The partially-supported APIs are as follows: DosDevIOCtl and DosDevIOCtl2 VioGetConfig VioGetMode and VioSetMode VioGetState and VioSetState How the OS/2 Subsystem Works The OS/2 subsystem is implemented as a protected server; OS/2-based applications communicate with the subsystem by using the LPC message-passing facility. These applications use calls to the DLLs that contain the APIs, the same kind of messages used to communicate with the OS/2 kernel as they use on native OS/2. The subsystem runs in its own protected address space. Each application also runs in its own protected address space. This protects them from other processes running on Windows 2000. Memory Management Figure D.4 shows memory usage on the OS/2 subsystem while an application is running. If your browser does not support inline frames, click here to view on a separate page. Figure D.4 OS/2 Subsystem Memory Map The tiled area is 512 MB of virtual address space, which is reserved up front, then used when 16-bit applications need segments. The OS/2 subsystem maintains a local descriptor table (LDT) for each process, with shared memory segments at the same LDT slot for all OS/2 processes. The OS/2 subsystem removes some of the memory management limitations of OS/2 1.x. The most important of these is the 16-MB limit on physical random access memory (RAM). The high memory capacity of Windows 2000 is available to the OS/2 subsystem, and this capacity translates into increased performance for applications that can use the added memory. Microsoft® SQL Server™, for example, can use the added memory. At setup time SQL Server determines the physical memory available in the system and uses that amount of memory to set the level of caching it will use. In Windows 2000, the caching level can be as high as 32 MB or more — double the caching capability allowed in native OS/2. Protection Model The OS/2 subsystem provides the same protection between OS/2-based applications that exists in the native OS/2 operating system. The OS/2 subsystem constructs protected address spaces (both the flat address space and LDTs) for the applications. Paging Mechanism The OS/2 subsystem uses the Windows 2000 paging mechanism and does not perform segment swapping, which is less efficient. Segment swapping exists in OS/2 only to support the Intel 286 processor, which Windows 2000 does not support. Object Maintenance The OS/2 subsystem uses OS/2 semantics to maintain the various OS/2 objects. Examples include process IDs, the process tree, handles, local and global infoseg, thread-1 semantics, exit list processing, signals, and semaphores. The subsystem uses Windows 2000 objects only when they are relevant; when used, they are embedded in OS/2 objects (for example, file handles). Process Tree The process tree records the descendant processes of a given process. The OS/2 subsystem uses the process tree in all related operations, such as ending a program when you press CTRL+C. Threads and Scheduling Every thread created by an OS/2-based application is implemented with a Windows 2000 thread in the same process. The Windows 2000 thread receives the priority and ID that are relevant in OS/2. The exact OS/2 semantics (such as contents of the register and the stack) are retained when the thread function starts. The Windows 2000 scheduler handles the scheduling of OS/2 threads. OS/2 priorities 0 through 63 are mapped to Windows 2000 variable priorities 0 through 15. (OS/2 priorities are changed only by the application; they are not changed by the scheduler.) OS/2 threads never receive Windows 2000 real-time priorities 16 through 31. VIO User Interface The VIO user interface is partially supported by the OS/2 subsystem. Applications cannot get direct control of the video hardware. For more detail on allowed and disallowed VIO applications, see the lists of APIs in "Compatibility of OS/2-based Applications and APIs" earlier in this chapter. Input/Output Processing The OS/2 subsystem supports all the native device drivers of Windows 2000, such as those for the display, print, disk, communications, keyboard, and mouse devices. It also supports filters. The OS/2 subsystem does not support custom OS/2 device drivers unless the drivers are rewritten, or device monitors unless the monitors are limited to the session. Partial support is also provided for I/O privilege code. Filters The OS/2 subsystem supports filters and integrates them with Win32 and MS-DOS; meaning that you can redirect input and output between applications based on OS/2, MS-DOS, and Win32 in an operation that is transparent to the end user. Custom Device Drivers Some applications have their own custom OS/2 device drivers (also called private drivers), which are not included in the OS/2 subsystem. Examples are drivers that provide custom support for security, fax, Musical Instrument Digital Interface (MIDI), or IBM 3270 Communication Cards. To be usable, a custom driver must be rewritten to the Windows 2000 device driver model. However, no change to the application is required because it can still communicate with the driver using the DosDevIOCtl API. The application code can still load and run in a binary-compatible manner because the device-specific parameters passed by the DosDevIOCtl2 API are only pointer-to-void (PVOID) buffers. To be compatible with the original custom driver, the rewritten version must accept the same set of parameters within the PVOID buffers. Other Dos APIs, such as DosOpen, are compatible with both custom drivers and native Windows 2000 device drivers. This is because the OS/2 subsystem reads its Config.sys file at initialization, finds the internal name of the custom driver, and maps the custom driver to the Windows 2000 driver. You can enter the device driver name in Config.sys by using the devicename command (devicename=os2devicename [[path][ntdevicename]]). See "Configuring the OS/2 Environment" later in this chapter. Device Monitors Device monitors, which enable an application to monitor and filter all events on a physical device, are a feature of OS/2 at the device-driver level. If implemented across the Windows 2000 system, a device monitor would violate security. Therefore, the OS/2 subsystem implements device monitors only within an OS/2 session (an OS/2-based application and all of its descendants). Within the session, device monitors are fully compatible with OS/2. The vast majority of OS/2-based applications already use monitors within sessions. I/O Privilege Mechanism Some OS/2-based applications and APIs have I/O privilege code segments that let them perform I/O operations in Ring 2 of the Intel protection architecture. However, in Windows 2000, Ring 2 corresponds to user mode, where I/O operations are not allowed. Windows 2000 restricts these operations to kernel mode (Ring 0), which is protected to maintain the system's robustness. Thus IN/OUT instructions using the I/O privilege are disabled because they take control of hardware and thereby threaten robustness. However, CLI/STI instructions, which disable and enable hardware interrupts, will work. Unlike native OS/2, the OS/2 subsystem does not require an IOPL=YES statement in the Config.sys file to use the I/O privilege. But before using CLI/STI instructions, consider the following: A CLI instruction suspends all other OS/2-based applications and all other threads in the issuing process until an STI instruction follows. Windows 2000 cannot simply disable external interrupts, as native OS/2 does, because this action would compromise the robustness of the operating system. Semaphore calls use far less run-time overhead and are the preferred alternative for implementing critical sections of an application when it is possible to modify the application. Caution IN/OUT instructions cause your application to fail. When an IN or OUT instruction is issued, Windows 2000 immediately terminates the application with a general protection fault. Files Used by the OS/2 Subsystem Table D.8 lists the main files that make up the OS/2 subsystem. Table D.8 OS/2 Subsystem Files File How Used Os2srv.exe The subsystem server invoked when the first OS/2-based application is run. It remains throughout the session to serve new applications as you run them. Os2.exe The client side of every OS/2-based application. There is an instance of Os2.exe for each OS/2-based application that is running. Doscalls.dll1 Contains the APIs with the "Dos" prefix. The other DLLs used in OS/2, such as Kbdcalls.dll and Viocalls.dll, are loaded with the subsystem and provided when the application calls them. Netapi.dll1 Contains the Microsoft® LAN Manager APIs. 1 These files are located in the System32\Os2\Dll or C:\Os2\Dll folder when the Windows NT Add-on Subsystem for Presentation Manager is running. Note The Windows NT Add-on Subsystem for Presentation Manager supplies and uses many other files not listed here, such as all the 16-bit PM DLLs (Pmwin.dll, Pmgre.dll, and so on) and 16-bit executables (Pmshell.exe, Pmspool.exe, and so on). OS/2 Interprocess Communication The OS/2 subsystem can communicate with Windows 2000 processes through named pipes, mail slots, NetBIOS, files, and COM devices. The OS/2 subsystem implements all OS/2 interprocess communication mechanisms as shown in Table D.9. Table D.9 OS/2 Interprocess Communication Mechanisms Communication Mechanism Implementation Named pipes The OS/2 subsystem implements named pipes on top of the Windows 2000 named-pipe file system. Microsoft LAN Manager 2.x named pipe functionality is fully supported. Anonymous pipes (including inheritance) Fully supported. They are integrated into the OS/2 file handle space. Shared memory The full functionality of OS/2 1.x shared memory, including Get and Give semantics, is implemented using Windows 2000 shared memory. The discardable-segments property is ignored and is invisible to the OS/2-based application. Semaphores The OS/2 subsystem supports the full range of OS/2 1.x semaphore APIs, including RAM semaphores in private and shared memory, system semaphores, and fast-safe RAM semaphores. Association of semaphores with timers and named pipes is fully supported. The subsystem uses a combination of the Windows 2000 semaphore object and the Windows 2000 event object to implement an OS/2 semaphore. Queues OS/2 1.x queues are fully supported, using shared memory between OS/2 processes and OS/2 semaphores as required. Signals OS/2 signals are fully supported, using Windows 2000 APIs to manipulate thread context. The subsystem controls the address space of OS/2 processes and uses it to manipulate the register content and the stack of thread 1 of the process to be signaled. Dynamic Linking The OS/2 subsystem uses a full OS/2 loader, which loads DLLs, executables, and resources the same way as in native OS/2. Static linking, load-time dynamic linking, and run-time dynamic linking all function as they do in native OS/2. Windows 2000 also has a useful feature, called thunking, which allows 16-bit OS/2-based and PM-based applications to load and call any Win32 DLL. A small set of new APIs is provided for thunking. For more information about thunking, see "OS/2 Application Processing" later in this chapter. OS/2 Network Connectivity The OS/2 subsystem uses many LAN Manager APIs. It also uses NetBIOS (both version 2.x and version 3.0 functionality), named pipes, and mail slots. The OS/2 subsystem maintains remote drives the same way native OS/2 does. With these, any OS/2-based application can use redirected drives transparently with the file I/O APIs. Uniform Naming Convention (UNC) naming is supported as well. Redirected drives of various network operating systems can be used if the related Win32 Windows 2000 device drivers (redirectors) have been installed. Configuring the OS/2 Environment The OS/2 subsystem handles initialization compatibly with native OS/2 and is configurable using some OS/2 configuration commands. Windows 2000 provides APIs with the prefix Win for this purpose. Initialization of the Subsystem When the OS/2 subsystem starts for the first time, it proceeds as follows: It checks the registry for OS/2 subsystem configuration information. If it finds none, it checks the original Config.sys file and adds that information to the registry. If the original Config.sys file does not exist or is not an OS/2 configuration file, the subsystem adds the following default information to the registry: PROTSHELL=c:\os2\pmshell.exe c:\os2\os2.ini c:\os2\os2sys.ini %systemroot%\System32\cmd.exe SET COMSPEC=%systemroot%\System32\cmd.exe The subsystem updates the environment variable Os2LibPath with path information found in the original Config.sys file. The updated value of Os2LibPath is SystemRoot\System32\os2\dll, which is concatenated with the list of directories specified in the libpath line of the original Config.sys file. Path information in the original Config.sys file is not entered automatically into the default Windows 2000 path. To enter this path information, use the following procedure. To enter Config.sys path information into the default Windows 2000 path Click Start, and then select Settings. Click Control Panel. Click the System icon to open it. In the dialog box that appears, click the Advanced tab. Click Environment Variables. In the System Variables list, double click Os2LibPath. In the Variable Value window that opens, type SystemRoot\System32\os2\dll. Click OK. The system appends this information each time a user logs on. Changing Registry Information The OS/2 configuration information is stored in the registry, but you can edit it as an OS/2 Config.sys file with an OS/2 text editor. The seven OS/2 configuration commands that are available for editing are discussed in the next subsection. Important To change configuration information, you must be logged on as an administrator. To change configuration information While running Windows 2000, start an OS/2 text editor in a window. Open C:\Config.sys. Edit the configuration information. Save and close the file. Quit the editor. Log off Windows 2000, and then restart your computer. Note Windows 2000 retrieves the configuration information from the registry and stores it in a temporary file that you can edit. The new information is stored in the registry. Available Commands for OS/2 Configuration Windows 2000 supports only the OS/2 configuration commands shown in the following list: codepage country/region devicename devinfo=kbd libpath protshell set Some of the commands in this list are processed in special ways, as shown in Table D.10. Table D.10 Processing of OS/2 Configuration Commands Command Special Processing devicename The device driver specified must be compatible with Windows 2000. The syntax is as follows: devicename=os2devicename [[path][ntdevicename]] where the variables have the following meanings: os2devicename: Is the logical name that OS/2-based applications use to address the device. path and ntdevicename: Specify the Windows 2000 device driver to which the OS/2 device name is to be mapped. If these are omitted, the device is mapped to: \device\os2devicename libpath This command appends path information to the OS/2 library path in the Windows 2000 environment. You can use it to add or change the path information in the Os2LibPath variable. protshell Specifies the command interpreter. However, only the Windows 2000 command interpreter, Cmd.exe, is supported. set This command is ignored if used with any of these parameters: COMSPEC, PATH, PROMPT, VIDEO_DEVICES, VIO_IBMVGA, or VIO_VGA. OS/2-based Application Processing OS/2 16-bit character-based applications run directly on Windows 2000 without modification. Windows 2000 recognizes an OS/2-based application from information in the header of the executable file. It then calls the OS/2 subsystem to load the application. File Systems Supported The OS/2 subsystem supports long file names and extended attributes, but not the High Performance File System (HPFS). The subsystem does not use or expose recoverability and C2 security functions. Starting an Application You can start a character-based or VIO application from the system command prompt, from My Computer, from Windows Explorer, or from within a Win32-based or OS/2-based application. You can create a single batch file that can start any combination of MS-DOS, Windows, or OS/2 programs. If you never run an OS/2-based application, the subsystem uses no Windows 2000 resources. The Os2srv process is loaded when you run an application for the first time and remains loaded after you quit the application. Thunking The thunking mechanism in the OS/2 subsystem allows the 16-bit OS/2 and Presentation Manager applications to load and call any Win32 DLL. Thunking code translates 16-bit calls to 32-bit, so they can be received by the 32-bit processor, and translates the responses back into 16-bit code so the application can process them. You might want to use the thunking mechanism to: Call from your OS/2-based application to some functionality that is available under Windows 2000 only as Win32 code. Split an application available under Windows 2000 only as Win32 code into applications based on OS/2 and Win32, then communicate between them using named pipes. This method, however, is more complicated and can slow performance. Port your OS/2-based application from the OS/2 subsystem to Win32 in stages, starting with only part of the application. To use the thunking feature in the OS/2 subsystem Write a small header file (.h file, as shown in Figure D.5) to act as a thunking layer. The file defines the Win32 APIs that the application calls. This file contains six 16-bit APIs: Dos32LoadModule Dos32GetProcAddr Dos32Dispatch Dos32FreeModule FarPtr2FlatPtr FlatPtr2FarPtr Write a .def file for your 16-bit application, containing calls to the six 16-bit APIs, as follows: IMPORTS DOSCALLS.DOS32LOADMODULE DOSCALLS.DOS32GETPROCADDR DOSCALLS.DOS32DISPATCH DOSCALLS.DOS32FREEMODULE DOSCALLS.FARPTR2FLATPTR DOSCALLS.FLATPTR2FARPTR extern USHORT pascal far Dos32GetProcAddr(ULONG DllHandle, PSZ pszProcName, PULONG pWin32Thunk); extern USHORT pascal far Dos32Dispatch(ULONG Win32Thunk, PVOID pArguments, PULONG pRetCode); extern USHORT pascal far Dos32FreeModule(ULONG DllHandle); extern USHORT pascal far FarPtr2FlatPtr(ULONG FarPtr, PULONG pFlatPtr); extern USHORT pascal far FlatPtr2FarPtr(ULONG FlatPtr, PULONG pFarPtr); Figure D.5 Thunking Layer (.h file) to be Linked with 16-Bit OS/2-based Application The thunking layer actually calls the Win32 APIs, using parameters passed in the 16-bit APIs. This relay is necessary because the OS/2 subsystem has only one generic pointer parameter, EXTERN, and the Win32 APIs need more or different parameter

I just set this up to work great. make sure running command.com works fine (shows prompt), if not, reset your config.nt and autoexec.nt to the default. Next run command.com and write your environment to a batch file...( set > setenv.bat) then edit the batch file adding a set in front of each variable and an = at the end - this kills the env. variable and lets up mem space. The important thing is to add the first executable within the batch file at the end or else the environment will go back to where it was because win 2000 is creating a whole new env. while this batch goes off. You can then create a shortcut to this setenv.bat for the desktop.