Memory management on Windows NT

[Gunnar Vestergaard]

The \masm32\examples\dialogs\calender example uses a macro from include\dialogs.inc

In this this Dialog macro there is a call to GlobalAlloc. The Platform API doc says that GlobalAlloc was introduced in Windows 2000. So I suspect that this small calender application will not run on Windows NT. How does one allocate memory so it works on Windows NT also? I mean, I want to use conditional code that is different for different versions of Windows.

I strive to be backwards compatible.

Gunnar

[jj2007]

I strive to be backwards compatible.

How far?
:wink

The Microsoft guide to writing applications for Windows 3.1
by Charles Petzold
3rd Edition
PUBLISHED BY
Microsoft Press
A Division of Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052-6399
Copyright© 1992 by Charles Petzold

This is the general syntax of the GlobalAlloc call:
 
hGlobalMemory = GlobalAlloc (wFlags, dwSize) ;
 
The dwSize parameter is a double word (unsigned long). This value can be greater than 65,536; however, there are special considerations in using global memory blocks greater than 64 KB. (These will be discussed later.)
The wFlags parameter can be a combination of several identifiers that are combined with the C bitwise OR operator. You first have a choice of three identifiers to define the attribute of the allocated memory block:
·   GMEM_FIXED—Memory is fixed. (This is the default if wFlags is 0.)
·   GMEM_MOVEABLE—Memory is moveable.
·   GMEM_DISCARDABLE—Memory is discardable. This option should be used only with GMEM_MOVEABLE. I'll discuss later how you can manage discardable global memory in your programs.
 
With any of the above-mentioned three flags, you can use the GMEM_ZEROINIT flag for convenience; this flag tells Windows to initialize memory contents to 0.

[Gunnar Vestergaard]

jj2007 wrote:

How far?

32 bit Windows. Windows NT.

[hutch--]

Gunnar,

GlobalAlloc() is an oldie so you should not have problems with backwards compatibility with it. Unless you are using it for legacy type operation like the clipboard and a few others, ensure you use the GMEM_FIXED flag as the movable style of memory is technically out of date.

Just to add as we cross posted, NT in 32 bit is the earliest compatible version, the 32 bit add ons for the old 16 bit windows won't run true 32 bit code.

[Gunnar Vestergaard]

GlobalAlloc() is an oldie so you should not have problems with backwards compatibility with it. Unless you are using it for legacy type operation like the clipboard and a few others, ensure you use the GMEM_FIXED flag as the movable style of memory is technically out of date.

Just to add as we cross posted, NT in 32 bit is the earliest compatible version, the 32 bit add ons for the old 16 bit windows won't run true 32 bit code.

But I am still curious. The Platform API for Windows says that the oldest system that GlobalAlloc can be used on is Windows 2000. Is this only because Microsoft does not support and document Windows NT anymore?

Gunnar

[MichaelW]

Per my 2003 PSDK GlobalAlloc, HeapAlloc, and VirtualAlloc are supported back to Windows 95.

[donkey]

Is this only because Microsoft does not support and document Windows NT anymore?

Gunnar

Exactly, any pages that are updated will now reflect back as far as Win2K. GlobalAlloc was introduced in Windows 1.0, actually the way GlobalAlloc works is kind of funny since it still supports lock counts to keep it compatible with Windows 1.0 (since there's no memory compaction in Win32 you don't need a lock count).

[redskull]

Strange that some pages reflect this, and other don't.  In my version (SDK 6.1), the user32 functions (MessageBox, CreateWindow) are detailed as being supported all the way to 95/NT 3.1.  The kernel32 functions are split into "client" and "server" requirements, and only go as far back as 2K.  Or, considering the MS track record, perhaps it's not that strange after all...

-r

[donkey]

Strange that some pages reflect this, and other don't.  In my version (SDK 6.1), the user32 functions (MessageBox, CreateWindow) are detailed as being supported all the way to 95/NT 3.1.  The kernel32 functions are split into "client" and "server" requirements, and only go as far back as 2K.  Or, considering the MS track record, perhaps it's not that strange after all...

-r

Pages that have been updated have a build date at the bottom, those that were ported "as is" have none. Pages with build dates specify support back to Win2K, others have the original entries.