Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Windows Server 2008 Server Core : Starting the Command Interpreter (part 2) - Modifying Config.NT

3/20/2012 5:34:02 PM

2. Modifying Config.NT

The Config.NT file contains a number of entries that affect how the system works at the command prompt. At one time, the configuration file contained a wealth of device drivers and statements that defined how the command prompt used files and buffers. However, the Config.NT file rarely contains device drivers and these driver entries are normally defined by third-party software for you. Given that Server Core lacks the functionality required for an application server (which means providing complex server-based applications such as a database-based application), you may never see a driver entry in Config.NT. The following sections describe common additions you can make to the Config.NT file.

NOTE

Some people may remember Config.SYS, the file that DOS uses to perform the same configuration that Windows performs with Config.NT. In fact, some people try to move Config.SYS to the Windows environment. Fortunately, the 32-bit version of Windows accepts many older DOS commands even when it doesn't use them. For example, the FastOpen utility provides a caching feature in DOS to make directory searches faster. Even though Windows provides this file, too, it doesn't actually use the functionality and FastOpen doesn't actually perform any task. Once you move to the 64-bit versions of Windows, much of this functionality is missing completely. For example, you can't create a Config.NT file that contains a reference to the FastOpen utility.

2.1. Using ANSI.SYS to Control the Environment

The ANSI.SYS device driver provides added functionality for applications at the command prompt. By using special escape codes, you can create a character-based user interface for your batch files. You can find a good listing of ANSI escape codes at http://www.evergreen.edu/biophysics/technotes/program/ansi_esc.htm and on the Microsoft Web site at http://www.microsoft.com/technet/archive/msdos/comm1.mspx?mfr=true. This utility uses the following syntax:

device=[Drive:][Path]ANSI.SYS [/X] [/K] [/R]

As with all device drivers that you add to the Config.NT file, you begin the ANSI.SYS entry using device= entry, followed by the drive and path to the ANSI.SYS file. The following list describes each of the command line arguments.


/X

Remaps the extended keys on 101-key keyboards independently. Actually, this feature works no matter how many extra keys your keyboard has.


/K

Forces ANSI.SYS to treat a 101-key (or more) keyboard like an 84-key keyboard by ignoring the extended keys.


/R

Changes the line scrolling functionality to improve readability when working with screen reader programs. A screen reader program interprets the screen content and presents it using some other form of output. Normally, screen reader applications say what's on screen to help those with special sight needs understand the content.

2.2. Setting the DOS Location

This utility uses the following syntax:

DOS=[{HIGH | LOW}] [{,UMB | ,NOUMB}]

The following list describes each of the command line arguments.


HIGH | LOW

Determines whether the command environment attempts to load part of itself into the High Memory Area (HMA) (HIGH) or keep all of the code in conventional memory (LOW). The default setting is LOW. Generally, you want to load the command environment into high memory to preserve more conventional memory for applications.


UMB | NOUMB

Determines whether the command environment should manage the Upper Memory Blocks (UMBs) created by a UMB provider. Windows provides a UMB provider as a default. DOS users used to rely on a special program named EMM386.EXE to perform this task. The UMB argument tells the command environment to manage the UMBs, which frees additional memory for loading applications in areas other than conventional memory. The default setting is NOUMB.

2.3. Running DOS Applications Only

You can execute any kind of application you want from the command prompt. If you want to start Notepad, simply type Notepad and press Enter. However, mixing Windows and older DOS applications can sometimes cause problems. Developers wrote DOS applications with the expectation that these applications controlled the entire machine, which can cause myriad problems with Windows applications. If you have one of these older applications (and they're quite rare), you can help the DOS application execute properly by adding the NTCMDPROMPT entry to Config.NT. This entry tells the operating system to disallow Windows application execution at the command prompt, which means that the DOS application continues to feel that it owns the machine. Of course, you can start your Windows applications from another command prompt or by using any of the usual techniques, such as the Start menu.

2.4. Displaying the Config.NT Commands

Normally, you won't see any information about the commands that execute before the command window opens; all you see is a command prompt. Adding an ECHOCONFIG to the Config.NT file displays each of the commands as they execute. Using this feature can help you diagnose problems with the Config.NT file contents.

2.5. Controlling the Expanded Memory EMM Entry

Older applications, especially character mode (DOS) games, rely on the Expanded Memory Specification (EMS) memory to overcome command prompt memory limitations. It's important to remember that the command line effectively limits the amount of memory available to DOS applications to 640 KB minus any memory that the operating system uses. Normally, you set the amount of this memory as part of the application's PIF. However, the PIF doesn't let you control the Expanded Memory Manager (EMM), which is the application that actually makes the memory accessible. The EMM entry lets you change how the EMM works. This option uses the following syntax:

EMM = [A=AltRegSets] [B=BaseSegment] [RAM]

The following list describes each of the command line arguments.


A=AltRegSets

Defines how many alternative mapping register sets the EMM has available for mapping memory between extended memory and conventional memory. You can provide any value between 1 and 255. The default setting of 8 works fine in most cases. Check your application documentation for additional requirements.


B=BaseSegment

Defines the base segment, the location where the EMM places code within the DOS conventional memory area from extended memory as needed. Generally, any setting you choose works fine. However, some applications use specific segments for their use. Using the same memory segment for two purposes causes memory corruption and can cause the application to fail. The application documentation should tell you about any requirements. You can set the base segment to any hexadecimal value between 0x1000 and 0x4000. The default setting is 0x4000.


RAM

Specifies that the EMM should only use 64 KB of address space from the UMB area for the EMM page. Normally, the EMM uses the entire UMB for the EMM page to improve EMM performance. However, your application may require more conventional memory than this practice allows. Using the RAM option reduces the EMM page size, which makes it easier for the command environment to load more applications in upper memory—freeing conventional memory for application use.

2.6. Setting the Number of Accessible Files

The Files setting may not seem very important, but every file handle you provide to the command environment uses conventional memory. Remember that conventional memory is already quite small and many older applications barely load in the space provided. The default Files=40 setting usually provides a good compromise. This setting means that the command environment can open 40 files, which is more than sufficient for most older applications. You can increase the number to as many as 255 when your application complains that it's out of file handles or decrease the number to as little as 8 when the application complains about a lack of memory.

2.7. Controlling Extended Memory with HIMEM.SYS

The HIMEM.SYS driver provides extended memory support at the command prompt. The eXtended Memory Specification (XMS) is a method that applications use to overcome the DOS memory limitations. You set the amount of available XMS using the PIF for the application. However, you can further refine XMS functionality by relying on the command line switches described in this section. As with all device drivers that you add to the Config.NT file, you begin the HIMEM.SYS entry using the device= entry, followed by the drive and path to the HIMEM.SYS file. This driver uses the following syntax:

DEVICE=[drive:][path]HIMEM.SYS [/HMAMIN=m] [/INT15=xxxx]
   [/NUMHANDLES=n] [/TESTMEM:{ON|OFF}] [/VERBOSE]

The following list describes each of the command line arguments.

NOTE

HIMEM.SYS includes a number of command line switches, many of which are archaic. For example, even though HIMEM.SYS still supports the /A20CONTROL command line switch, you'd have to have a very old computer (over 10 years old) to need it. In short, unless you have a very old system, you'll never have a use for these older command line switches. In addition to the /A20CONTROL command line switch, I haven't discussed the /CPUCLOCK, /EISA, /MACHINE, and /SHADOWRAM command line switches. This section contains descriptions of the command line switches that are still useful.


/HMAMIN=
m

Specifies how many kilobytes of HMA memory an application must request in order for HIMEM.SYS to fulfill the request. Some applications ask for small pieces of the HMA area, which fragments an already small memory area and makes it unavailable for other applications. It becomes a question of efficient memory use. An application that can use a larger piece of the HMA will likely free more conventional memory for use by other applications. You can specify any value between 0 and 63. The default value is 0. Setting this command line switch to 0 or omitting it from the command line lets HIMEM.SYS allocate the HMA memory to the first application that requests it, regardless of how much HMA memory that application will use.


/INT15=
xxxx

Specifies the amount of extended memory in kilobytes that HIMEM.SYS should reserve for the Interrupt 15h interface. You may wonder what the Interrupt 15h interface is all about; it's the method that applications use to interact with XMS. The only time you need to use this command line switch is if you have an older DOS application, very likely a game or graphics application, that relies on XMS memory. The application will very likely display a nebulous error message that specifically mentions the Interrupt 15h interface. Make sure you set the amount of XMS memory to 64 KB larger than the amount required by the application. You can specify any value from 64 KB to 65,535 KB. However, you can't specify more memory than your system has installed. When you specify a value less than 64, HIMEM.SYS sets the value to 0. The default value is 0.


/NUMHANDLES=
n

Specifies the maximum number of Extended Memory Block (EMB) handles that the system can use simultaneously. Every time an application requests more memory, it needs a handle to access that memory. Generally, you don't need to provide this command line switch unless you have an older graphics-intensive application. You can specify a value from 1 to 128. The default setting is 32, which is more than enough for most applications. Changing the number of handles uses more memory for housekeeping chores, so you'll want to use this command line switch with care.


/TESTMEM:{ON|OFF}

Determines whether HIMEM.SYS performs a memory check when you open the command prompt. Most people don't actually know whether the memory they're using is good, so checking it from time to time is a way to reduce unwelcome surprises. However, running the test takes time. You'll see a noticeable delay in displaying the command prompt when you use this command line switch. In most cases, it's far better to test your memory using a third-party diagnostic program that works outside of Window's influence. Otherwise, you can't be sure that you're testing all of the memory and won't know which surprises Windows has hidden from view. The HIMEM.SYS test is more thorough than the test that runs when you start your computer, so you can use it when you don't have any other means of testing available.


/VERBOSE

Displays additional status and error messages while HIMEM.SYS is loading. The system normally doesn't display any messages unless it encounters a problem loading or initializing HIMEM.SYS. Adding this command line switch can point out potential problems in your system setup and aid in diagnosing application problems that you wouldn't normally detect. You can abbreviate this command line switch as /V. Unfortunately, despite the documentation for HIMEM.SYS online, you can't display the verbose messages by pressing the Alt key as the system loads HIMEM.SYS into memory; you must use the /VERBOSE command line switch to see the extended messages.

Other -----------------
- Windows Server 2008 Server Core : Essential Registry Hacks - Modifying the Software Setup
- Sharepoint 2007 : Customizing a SharePoint Site - Create a Content Type
- Sharepoint 2007 : Modify the Top or Left Navigation Bar & Create a Site Column
- Microsoft Systems Management Server 2003 : Configuring Site Server Properties and Site Systems - Monitoring Status and Flow
- Microsoft Systems Management Server 2003 : Configuring Site Server Properties and Site Systems - The Site Configuration Process Flow
- Windows Server 2003 : Windows Security and Patch Management - Using Auditing and the Event Log
- Windows Server 2003 : Windows Security and Patch Management - Locking Down Windows
- Recovering from a Disaster in an Exchange Server 2007 Environment : Recovering from a Site Failure & Recovering from a Disk Failure
- Recovering from a Disaster in an Exchange Server 2007 Environment : Identifying the Extent of the Problem & Preparing for a More Easily Recoverable Environment
- Windows Server 2008 Server Core : Setting the Environment & Modifying the Hardware Setup
- Windows Server 2008 Server Core : Performing Console Configuration
- Windows Server 2008 : Using Basic ds Commands - Understanding Distinguished Names & Adding Objects with dsadd
- Windows Server 2008 : Manipulating IIS with appcmd
- Microsoft Lync Server 2010 Edge : Edge Server Administration (part 2)
- Microsoft Lync Server 2010 Edge : Edge Server Administration (part 1)
- Sharepoint 2010 : Setting Up the Crawler - Crawling Other Document Types with iFilters
- Sharepoint 2010 : Setting Up the Crawler - Defining Scopes
- Microsoft Dynamics CRM 4.0 Accelerators : Extended Sales Forecasting Accelerator (part 1) - CRM Reports
- Microsoft Dynamics CRM 4.0 Accelerators : Extended Sales Forecasting Accelerator (part 1) - CRM Customizations
- Microsoft Dynamics AX 2009 : Processing Business Tasks - Building a Display dimensions dialog
 
 
Most view of day
- Windows Server 2012 : Enabling and disabling the graphical interface in Hyper-V
- Microsoft Project 2010 : Defining Project Resources - Defining Resource Costs
- Microsoft Project 2010 : Fine-Tuning Task Details (part 10) - Scheduling Summary Tasks Manually
- Sharepoint 2013 : Integrating Apps for Office with SharePoint (part 1) - Standalone Apps for Office
- Microsoft SharePoint 2013 : Working with Visio Services - Designing dashboards - Data linking (part 2) - Refreshing external data
- Sharepoint 2013 : Managing Security - See What Permissions Are Set (part 1) - Check Permissions on Files and List Items
- Sharepoint 2013 : Backup and Restore (part 2) - Export and Import - Using PowerShell, STSADM, Central Administration
- BizTalk 2006 : Getting Started with Pipeline Development (part 3) - Configuring Recoverable Interchanges, Using the Default Pipelines
- Extending Dynamics AX 2009 (part 1)
- Microsoft Excel 2010 : Using Formulas - Table References in Formulas, Using Array Formulas
Top 10
- Sharepoint 2013 : Working with the CSOM (part 6) - Working with the JavaScript client object model - Creating, reading, updating, and deleting in the JavaScript client object model
- Sharepoint 2013 : Working with the CSOM (part 5) - Working with the JavaScript client object model - Handling errors
- Sharepoint 2013 : Working with the CSOM (part 4) - Working with the JavaScript client object model - Returning collections
- Sharepoint 2013 : Working with the CSOM (part 3) - Working with the managed client object model - Creating, reading, updating, and deleting
- Sharepoint 2013 : Working with the CSOM (part 2) - Working with the managed client object model - Handling errors
- Sharepoint 2013 : Working with the CSOM (part 1) - Understanding client object model fundamentals
- Windows Phone 8 : Configuring Mailbox Settings (part 5) - Configuring Automatic Replies
- Windows Phone 8 : Configuring Mailbox Settings (part 4) - Lightening the Display,Changing the Mailbox Sync Settings
- Windows Phone 8 : Configuring Mailbox Settings (part 3) - Message Signatures, Blind CCing Yourself
- Windows Phone 8 : Configuring Mailbox Settings (part 2) - Unlinking Mailboxes, Conversation View
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro