Windows Vista restricts GNU GCC apps to 32 MB

[Andrej Marjan]

On May 1, 2007 03:37:33 pm Lennart Sorensen wrote:
> On Sat, Apr 28, 2007 at 07:41:28PM -0400, Sy Ali wrote:
> > I read it differently.. as it seems to read that it is a problem for
> > anyone who writes with one codebase which is to be deployed broadly
> > without any special vista-specific tweaks.
> >
> > Yes, old software may not generally require more than 32MB of memory..
> > but some of it sure does.
>
> I read it as: Anything using the standard C interfaces like malloc()
> is limited to 32MB, while anything using the Win32 API calls can have
> as much as it wants.

Not quite. Since you've revived the thread and several people have been misled 
by the article, allow me to expound needlessly.

I don't know to what extent he's confused and to what extent he's being 
intentionally inflammatory, but in a nutshell, he's complaining that a 
change/regression of the NT DOS emulator in Vista prevents DOS binaries from 
allocating more than 32 MB, and that the Windows C runtime library and 
compilers don't do what he wants them to do.

First, DJGPP is a variant of GCC that produces DOS binaries. The guy uses 
DJGPP to produce DOS binaries that use extended memory managers to allocate 
hundreds of MB of memory. This works under DOS and DOS-derived OS's like 
Win98. 

NT has always had a limited DOS emulator. It's never worked with all DOS 
binaries, especially games. Apparently prior to Vista (and possibly WIn2k3), 
the NT DOS emulator allowed his DOS binaries to allocate all the memory they 
wanted. As of Vista, however, there's a cap of 32 MB.

So much for the DOS part.

On to the Windows part: Windows has a perfectly good C89 runtime built in, but 
this guy says the MS compiler doesn't support long long (for a long time a 
GCC extension and now I think part of C99), and better compilers don't 
support the GMP library.

Your interpretation doesn't make much sense since the "standard C interfaces" 
have to be implemented in terms of the host OS's system calls. On Unix, 
malloc(3) is implemented in terms of brk(2). The Windows C runtime has a 
working malloc() implementation, that happens to be implemented in terms of 
the Win32 API (of which I'm blissfully ignorant so I can't name the relevant 
functions). Keep in mind that Win32 is *the* system API of Vista (the NT 
kernel has its own API that Win32 sits on top of, but it's hidden entirely 
behind Win32).

A *Win32* binary that links against the Windows C runtime and uses only C89 
functions, can have as much RAM as it wants. This problem is strictly related 
to *DOS* binaries running in the DOS *emulator* on Vista.

So, this is a really long-winded way to say that, in the grand scheme of 
things, he's making a mountain out of a molehill. 
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists