Vista restricts GNU GCC apps to 32mb of memory?

[Syngin]

Came across this while Stumbling and thought I'd share with all of the programmers here before the mods banish it to the anals of the 'Hating MS" thread.

http://www.trnicely.net/misc/vista.html

[blackbelt_jones]

Wow!:rolleyes:

[bwkaz]

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 (http://www.awprofessional.com/content/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf) (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.

[blackbelt_jones]

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 (http://www.awprofessional.com/content/images/9780321440303/samplechapter/Chen_bonus_ch02.pdf) (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.

Wow! Thanks for explaining that, I would hate to be caught going around repeating inaccurate info.

[Syngin]

Doh. My bad. :o

[bwkaz]

And I should probably add: This person's requirements do mean that he doesn't have any other choice. But that doesn't mean Microsoft is conspiring against him (or gcc), either; it just means his requirements are broken. ;) Specifically, his "I need to use DPMI" is not a good idea nowadays; DOS has been dead ever since XP. (And yes, I said "a decade" earlier. That's not quite right.)

(Of course, my diagnosis could still be way out in left field. The one data point on that page that doesn't support the "it'd DPMI's fault" diagnosis is dosbox -- if dosbox can't use more than 32mb either, then there may be something wrong. AFAIK, dosbox doesn't use DPMI itself, although it does provide DPMI support on its virtual machine for your DOS programs to use; dosbox's Windows port uses Win32 as far as I know. That doesn't rule out a bug in the dosbox code, either, though.)

[Andrew Wade]

The one data point on that page that doesn't support the "it'd DPMI's fault" diagnosis is dosbox -- if dosbox can't use more than 32mb either, then there may be something wrong. AFAIK, dosbox doesn't use DPMI itself, ...
Actually he said that dosbox can use more than 32mb--if so configured. I guess DPMI is probably the culprit then. Looking through the DPMI spec I don't see why Vista would limit memory accessible through DPMI to 32MiB; it should be possible to demand-page it so pinning excessive amounts of ram isn't a concern. 32 MiB is suspiciously like the limitations of EMS, XMS, and VCPI, but I don't see how they could be involved with 32-bit code--I can't see Vista allowing DOS extenders to run in ring 0.

I doubt this problem will be fixed: other developers may require "very large amount of memory", but they're unlikely to target DOS as a platform.

[bwkaz]

Actually he said that dosbox can use more than 32mb--if so configured. Oh, I must have missed that part then.

Makes sense. :)

32 MiB is suspiciously like the limitations of EMS, XMS, and VCPI, but I don't see how they could be involved with 32-bit code--I can't see Vista allowing DOS extenders to run in ring 0. Yeah, hopefully not. But note that VCPI wasn't supported way back in Win95 (according to the PDF I linked to earlier), because it gives too much control to the client program. (That's probably the "running in ring 0" stuff you're talking about, although I have no experience with the VCPI spec so I don't know for sure if that's what it allows or not.)

IIRC, EMS is paged into low memory one 64K segment at a time (and the machine still runs in either real or v86 mode), so I doubt that has much to do with it, unless there are 32MB limits on the total amount of available EMS memory. XMS I never really figured out how to use (but that's probably because I was using 16-bit DOS programs at the time), so I don't know.

I doubt this problem will be fixed: other developers may require "very large amount of memory", but they're unlikely to target DOS as a platform. Exactly. The targeting of DOS (due to a seemingly irrational hatred of the Win32 API) is the problem here, not any conspiracy against either gcc or the FSF. :)