You are currently offline, waiting for your internet to reconnect

Information on Application Use of 4GT RAM Tuning

This article was previously published under Q171793
This article has been archived. It is offered "as is" and will no longer be updated.
This article describes the 4GT RAM Tuning feature of Windows NT ServerEnterprise Edition (Windows NT Server/E) version 4.0. With standard WindowsNT Server, the per-process address limit is 2 gigabytes (GB) of randomaccess memory (RAM). The 4GT feature of Windows NT Server/E increases thislimit to 3 GB without introducing new APIs. 4GT does this by reducing thepotential RAM allocated to the Windows NT kernel from 2 GB to 1 GB.

Much of the information in this article was extracted from the ReleaseNotes for the product.
Applications developed for the Windows NT Server platform continue to grow,both in terms of size and performance demands. For applications that areI/O intensive, such as database management systems (DBMS), the use of alarger process space can provide considerable performance benefits as time-intensive I/O access to media is reduced. With the current Windows NTServer product, the per-process address limit is 2 GB. 4GT increases thislimit to 3 GB without introducing new APIs. 4GT does this by reducing thepotential RAM allocated to the Windows NT kernel from 2 GB to 1 GB.

This feature benefits applications that run on powerful computers with morethan 2 GB of physical RAM and that can take advantage of a larger addressspace. The impact on developers and applications are summarized below.

Windows NT Server/E supports 4GT on Intel architecture servers only.

NOTE: The 4GT works only on 32-bit processors, so it does not increase theaddressable memory of Windows NT Server beyond its current limit of 4 GB.

Writing Applications for 4GT

User-mode Address Selection:

When 4GT is enabled, the highest bit of a virtual address cannot be used todifferentiate user-mode addresses from kernel-mode addresses.

Memory Allocation Issues:

Some dynamic link library (DLL) files load near the 2 GB boundary;therefore, there is a region of the 2 GB space in which contiguous memorycannot be allocated using VirtualAlloc.

Effects Visible in Kernel Mode:

Kernel-mode code can no longer assume the user/kernel boundary is at0x80000000 or at any other number. Code that uses ProbeForRead orProbeForWrite macros must be rebuilt using new headers that no longercontain assumptions about kernel space starting at 0x80000000.

Enabling 4GT Support in Your Applications

The changes to support 4GT are done at both the system and applicationlevels.

System Changes:

After you have installed Windows NT Server/E, you must modify theBoot.ini file to enable 4GT. To enable 4GT, simply add the /3GB parameterto the startup line.

NOTE: This change is only effective if you are using Windows NT Server/E.On standard Windows NT, this flag will relocate the kernel, butapplications will be unable to access more than 2 GB.

For example:
[boot loader]
[operating systems]multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Server Version 4.00"/3GB
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Server Version 4.00[VGA mode]" /basevideo /sos
NOTE: Some of the lines above have been wrapped for readability.

Application Changes:

No new APIs are required for 4GT support. Instead, memory allocationsremain the same, with the exceptions that are noted below in "Tips forEffective 4GT Support." However, it would be ineffective for everyapplication to automatically be provided with a 3-GB address space. Toprovide a selective use of 4GT, the following mechanism has beenimplemented:
  • Executables that must see the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. This can be done using the Imagecfg tool that is included in the Support folder on the Windows NT Server/E compact disc. For example, to modify the target file DBMSApp.exe, type the following at a command prompt:
    Imagecfg -l DBMSApp.exe
NOTE: The linker also has a new switch (/ LARGEADDRESSAWARE) to linkexecutables with the IMAGE_FILE_LARGE_ADDRESS_AWARE bit. Setting this bitand then running the application on a system that does not have 4GT supportshould not affect the application.

Tips for Effective 4GT Support

The following guidelines are intended as a summary of changes thatdevelopers will want to review when they consider enabling 4GT supportwithin their applications:
  • Use GlobalMemoryStatus to get the amount of total user virtual space. Avoid using hard-wired constant definitions such as "#define HIGHEST_USER_ADDRESS 0xC0000000". Try to detect the real value at runtime.

  • Avoid signed comparisons with pointers. Some applications might crash on a 4GT-enabled system for just this reason. A condition such as "if (pointer > 40000000)" will be false for a pointer that is above 2 GB.

  • Code using the highest bit to tag items (data value versus an address value) will fail. For example, a 32-bit word might be considered a user- mode address if below 0x80000000 and an error code if above. This does not work anymore.

Setting a Paging File Size

If you are using the 4GT option and have a system with greater than 3 GB ofphysical memory, you may want to consider changing the default size of yourpage file. Note that this is changed by using the System tool in ControlPanel. In Windows NT 3.51, the default pagefile size is generally 11 MBlarger than physical memory. In Windows NT 4.0, the default pagefile sizeis equal to the amount of physical memory on the system. On a 4-GBcomputer, this would result in a 4.01-GB paging file. Under suchcircumstances, the effectiveness of this paging file could be minimal,based on the total size, which is 4 GB. Accordingly, a 256-MB page filecould be a more effective use of disk space. However, having a smallerpaging size will affect the total memory commit size for applications. Youshould review these settings with the Independent Software Vendor (ISV) foryour applications that are being run with the 4GT option.

Article ID: 171793 - Last Review: 12/04/2015 17:28:49 - Revision: 1.1

Microsoft Windows NT Server 4.0 Enterprise Edition

  • kbnosurvey kbarchive kbhowto kbinfo KB171793