ID: Q194924
The information in this article applies to:
******************************************************************** BETA INFORMATION BETA INFORMATION BETA INFORMATION BETA This article discusses a Beta release of a Microsoft product. The information in this article is provided as-is and is subject to change without notice. No formal product support is available from Microsoft for this Beta product. For information about obtaining support for a Beta release, please see the documentation included with the Beta product files, or check the Web location from which you downloaded the release. BETA INFORMATION BETA INFORMATION BETA INFORMATION BETA ********************************************************************
Under Windows 3.1x, GetFreeSystemResources() returned the free percentage of a specified type of Windows resource. The available types of resources were System, GDI, and User. Each type of resource was allocated from its own 64K heap.
Because of a drastic architectural change in the way resources are allocated between Windows 3.1x and Windows NT or Windows 2000, it does not really make sense to call GetFreeSystemResources() on Windows NT or Windows 2000. Therefore, GetFreeSystemResources() always returns 90% for 16-bit programs running on Windows NT or Windows 2000.
The GetFreeSystemResources() function is not part of the 32-bit Windows API. However, Windows NT and Windows 2000 provide backward compatibility for 16-bit programs through a Virtual DOS Machine (VDM) and a subsystem called Windows on Windows (WOW). A VDM is a 32-bit process that is subject to the same resource limitations as any other 32-bit process. With help from the WOW, it emulates Windows 3.1x on Windows NT and Windows 2000. All 16-bit Windows applications run as tasks under a VDM. The WOW runs as a task alongside these applications and provides support for the 16-bit API. Using this method, 16-bit applications can call outdated APIs such as GetSystemFreeResources().
Windows NT and Windows 2000 handle resources in a completely different manner from 16-bit Windows. On Windows NT and Windows 2000, each process has 4 GB of virtual address space. This address space is divided into user application space and system space. The system space is further divided for different types of system resources. It is possible to use every address allotted for a certain type of resource. If you do this, then no more allocations of that type of resource can be made. Because of this change in architecture between Windows 3.1x and Windows NT or Windows 2000, it does not really make sense to call GetFreeSystemResources() on Windows NT and Windows 2000.
It is unlikely that a single 16-bit program will exhaust any one particular type of resource within Windows NT or Windows 2000. However, if enough 16- bit applications are running in a single VDM, it is possible that they will collectively exhaust the resources available to the VDM. For this reason, Windows NT and Windows 2000 support launching 16-bit applications in separate VDMs. For more information on how to do this, see the references below.
For additional information, please see the following article in the Microsoft Knowledge Base:
ARTICLE-ID: Q115235
TITLE : INFO: Running a Windows-Based Application in its Own VDM
ARTICLE-ID: Q128460
TITLE : How to Run All 16-bit Windows Applications in Separate
Memory
Keywords : kbAPI kbKernBase kbNTOS350 kbNTOS351 kbNTOS400 kbWinOS2000 kbResource kbGrpUser
Issue type : kbinfoLast Reviewed: January 8, 1999