First post, by DosFreak
- Rank
- l33t++
http://www.trnicely.net/misc/vista.html
xecutable images created for the DOS/Wintel environment (but not employing the Win32 API), using the GNU GCC compilers and langu […]
xecutable images created for the DOS/Wintel environment (but not employing the Win32 API), using the GNU GCC compilers and language standards, are subject to failure (or performance degradation) when executed in Microsoft Windows Vista, because Vista arbitrarily restricts the memory space for the GCC executable to 32 MB (33,554,432 bytes). Attempts to allocate more memory than this using the malloc(...) function (or related functions, such as calloc(...)) will fail. This limitation applies whether the application is executed with the "Run" command, within a Command Prompt box (DOS box), or with the Start command. This limitation does not appear in Windows XP, Windows 98, or previous versions of Windows and DOS; the exact same executable, running under Windows XP SP2 or Win98SE, is capable of allocating several hundred megabytes of physical memory (if present on the machine). The limitation appears to apply to any compiler and linker not employing Microsoft's proprietary Win32 API.
The operating environment exhibiting this incompatibility in Vista includes GNU GCC "C" 3.04, DJ Delorie's DJGPP 2.03, and Vista Home Basic 6.0.6000 running on a Dell E520 with a Pentium D 915 2.8GHz dual core processor, 1 GB of 533 MHz DDR memory, 800 MHz front side bus, and SATA drives. The limitation appears with or without the use of executable compression, and with or without the use of the DJGPP DPMI servers CWSDPMI (Charles W. Sandmann), CWSDPR0, CWSDSTUB, and PMODE/DJ. Since the problem does not appear when the same executable image is run under Windows XP or Win98SE, the problem clearly lies in Vista, and is not due to the vintage of DJGPP, GCC, their libraries, or their DPMI servers. The system is operated as a standalone, single-user machine, logged on as Administrator (Command Prompt run as Administrator), with no Internet connection. Nearly all security features are disabled, including User Account Controls, Windows Firewall, Windows Defender, and Security Center (except for a warning message).
A simple test code is provided in the file vista1.zip (46K), which includes the source code vista1.c and a DOS/Wintel executable vista1.exe compiled with GCC "C" 3.04, DJGPP 2.03, and CWSDSTUB.EXE. The test code attempts to allocate a large chunk of memory (40,000,000 bytes), using malloc(...); if it fails, it repeats the attempt, decreasing the amount by 1,000,000 bytes each time. Results are reported to the console. Run it from a Vista Command Prompt (DOS box), with the "Run" command, or with the "Start" command; the results will be the same---failure until the request is decreased to 33,000,000 bytes (or possibly less). However, if the same code is run in a Command Prompt session in Windows XP, Win98SE, or Win98, or in a standalone DOS session under Win98 or Win98SE, the allocation will be limited only by the available physical memory. The code can also be run with a command-line parameter, e.g., "vista1 100", which will start the allocation attempts at 100 million bytes.
I have spent several days looking for workarounds to the 32MB memory limitation, without success. I have investigated property sheets and system settings, combed through the Windows registry, searched through Microsoft's forums, searched through the GNU/Linux forums, and looked through numerous other forums with information on Vista. Not only does no one offer a fix, they don't even seem to be aware of the problem. Out of desperation, I even e-mailed Microsoft Support with the problem. As expected, I received a boilerplate reply offering to discuss the matter for a nominal fee ($120 per hour or more).
Thus far I have found no workaround for this problem. For many applications, it may not be a serious matter, but much of my work requires very large amounts of memory (arrays of several hundred megabytes in some cases), and I feel sure this is true for other users as well. Even if all your work is normally done on non-Windows platforms, it would still be unfortunate to lose as a distribution base all of the Windows-based systems on the planet (currently about 90 % of all systems, and if Microsoft gets its way, nearly all of those systems will eventually be forced to "upgrade" to Vista).
Essentially the same limitation applies to source compiled with the g77 Fortran compiler; one difference is that the code will usually fail immediately with the error message "Load error: no DPMI memory" if total memory requests exceed 32MB. I do not know if the problem appears in other environments (e.g., other editions of Vista or codes cross-compiled for DOS/Wintel with other versions of GCC). Proprietary compilers which inherently convert code to the Win32 API (such as Visual C++ or even Borland C++ 4.52 with PowerPak) do not exhibit this limitation; they convert calls to the standard "C" malloc(...) to calls to Win32 API functions such as GlobalAllocate(...) or VirtualAllocate(...), which are then linked in at run time from Microsoft system DLLs. I suspect the real problem may be that Vista is treating any application that does not call the proprietary Win32 API (either directly, or through compiler or linker translation) as a "16-bit" application, and is then applying the 32MB limitation for "security" reasons.
I would appreciate being informed of a fix for this problem, if one exists. However, I am not interested in wild guesses, vague suggestions, or discussions of Microsoft. My definition of a "fix" does not include installing and booting to a different operating system (e.g., GNU/Linux, XP, or Win98SE), migrating code to the Win32 API, or migrating from the DJGPP environment to the CygWin, MinGW, Microsoft Visual C++, Borland/Inprise, or Watcom development environments.
http://www.justlinux.com/forum/showthread.php?p=866761
No, it doesn't limit gcc programs to 32mb of memory. […]
No, it doesn't limit gcc programs to 32mb of memory.
What it does do (according to my psychic powers, given the information on that page -- i.e. this is just a guess, but I bet it's right), is restrict the maximum amount of memory available to any DPMI server (or perhaps an incorrectly-coded DPMI server?). The fact that the program works under 98 and XP (and likely 2000) does NOT mean the program is correct! It just means that 98 and XP either (a) contained a workaround for this known-broken program, which was removed in Vista, or (b) never used the extra memory, so they didn't care about allocating it using DPMI (this is generally the cause of issues with a program putting a non-zero value into a reserved parameter, for instance, but I don't think that's happening here), or (c) didn't care about DOS programs eating up all available physical memory. I'd guess the problem is (c) -- Vista probably started to care about old DOS programs eating up physical memory.
For various major known issues (at the time Win95 was released) with various DPMI-using programs, see bonus chapter 2 of Raymond Chen's book (PDF), entitled "How to Ensure That Your Program Does Not Run Under Windows 95". This issue is just more of the same.
The problem is DPMI ("DOS protected mode interface"), not gcc. The problem for this person is that they refuse to move out of the DOS world. So this person doesn't like win32; too bad. If you want to run on Windows, you'll have to use either the win32 API (which is documented) or the NT API (which is not). Just like if you want to run on Linux, you'll have to use either glibc or one of the other C libraries, or code syscalls directly (although on Linux, both are documented). There is no POSIX layer for Vista. (Well... there might be, but if it exists, it's only barely POSIX compliant, and it runs in parallel with win32, as a separate layer on top of the undocumented NT API.)
In short: DPMI is dead, and has been for about a decade now. And programs compiled with mingw or Cygwin gcc will work without this limit; it only exists if you use a (certain?) DOS extender.
I can confirm that this is likely the case since I have run into situations in NT4/2000/XP where various programs run in NTVDM would eat memory like there's no tommorow.
Now the question is what file controls this....I've already tried swapping with XP's DOSX.exe but that did nothing. Switched out NTVDM with XP's and 2003 NTVDM but that did nothing. (XP NTVDM didn't work at all, 2003's works but doesn't fix the issue).
I tried his utility out in XP and it does work with any memory value all the way up to 1+gb. In Vista it maxes out to 32mb....
