The MASM Forum Archive 2004 to 2012

if I understand memory alloc is old win98 and only can alloc 256mb memory, so if I want to create a bigger workarea in XP?
what interface should I use?

I have just done some testing and GlobalAlloc seems to work fine for any amount (I tested up to 1 gig).

VirtualAlloc(Ex) is the preferred way to allocate large blocks, actually you should be using it for anything over 4MB. GlobalAlloc is slow and should be avoided.

I keep hearing this but I have never been able to get a time on GlobalAlloc() when it is used as fixed memory. The other strategies are out of date but as fixzed memory its so fast, timing it is not possible.

Hi Hutch,

At MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/globalalloc.asp) they say...

QuoteThe global functions are slower than other memory management functions and do not provide as many features.

Also there are bugs in the global memory functions that have patches from MS that must be installed,

QuoteMicrosoft has released a patch that will prevent programs from hanging when 16-bit DPMI memory management cross-references selectors during memory allocation.16-bit programs that use the GlobalAlloc() API call for multiple large (1.5 to 8 megabyte) memory allocations in succession can cause programs to stop responding (hang).

This was due to a problem with GlobalCompact not being included when upgrading the API from 16bit to 32bit Windows, it will almost always fail when dealing with blocks over 1Gig.

Since he is talking about large memory blocks, GlobalAlloc is certainly not the API to choose.

thanks, I try use virtualalloc instead of globalalloc

I have read that in MSDN as well but GlobalAlloc() tests well with fixed memory, I have never been able to get a timing above zero for its allocation speed of any size block.

The other styles are out of date and are better handled by other strategies. I must say that I have no use for 16 bit DPMI but then with fixed memory you never use GlobalCompact.

I timed repeated allocalation of small blocks (without deallocating in between) and HeapAlloc was much faster than GlobalAlloc.

Try SmallAlloc by Ultrano. :)  http://www.ultrano.com/ilix/SmallAlloc_MJB04.zip

Eóin,

Thanks for the info, just as an aside, where you need a large number of small allocations, have you ever tried the OLE string functions ? I have generally found them to be very fast as the memory is preallocated by the system.

These are the two macros in MASM32 but it has the correct API calls.


      alloc$ MACRO ln
        invoke SysAllocStringByteLen,0,ln
        mov BYTE PTR [eax], 0
        EXITM <eax>
      ENDM

      free$ MACRO strhandle
        invoke SysFreeString,strhandle
      ENDM


VirtualAlloc you say ... I have some maintenance projects here that use "malloc" and allocate some serious amounts of space for use on a 3g RAM server. I'll have to look more into VirtualAlloc as I thought that was used more with threads. Sort of like TLS allocation.

thomas

Quote from: hutch-- on June 15, 2005, 12:46:43 AM
Eóin,

Thanks for the info, just as an aside, where you need a large number of small allocations, have you ever tried the OLE string functions ? I have generally found them to be very fast as the memory is preallocated by the system.

These are the two macros in MASM32 but it has the correct API calls.

Code Select Expand


      alloc$ MACRO ln
        invoke SysAllocStringByteLen,0,ln
        mov BYTE PTR [eax], 0
        EXITM <eax>
      ENDM

      free$ MACRO strhandle
        invoke SysFreeString,strhandle
      ENDM


Can I use it for unicode strings like this:

    invoke GetWindowTextLengthW,edit1
    shl    eax,1 ;I assume this version of unicode uses 2 bytes for each character
    mov    ulen1,eax
    mov    ued1, alloc$(ulen1)
    invoke GetWindowTextW,edit1,ued1,ulen1
    ...
    free$  ued1


ramguru,

In the same OLE library is another allocation API that allocates in 2 byte increments which is designed for unicode string. The byte version is really for legacy code but I imagine that they both call the same internal capacity anyway. If you use the byte version, double the return value from GetWindowTextLengthW to get the correct byte count.

Thanks for reply Hutch. Now I'm facing other problem - double-byte unicode to utf-8 conversion, neither WideCharToMultiByte nor MultiByteToWideChar seems to work. If some-one has any ideas...please please...let me know

...past problem, made my own routine (I can't just sit & wait  ::)).

I'm guilty of worse behaviour... :bg