Newsgroups: comp.windows.ms.programmer
Path: utzoo!utgpu!watserv1!sunee!gpsteffl
From: gpsteffl@sunee.waterloo.edu (Glenn Steffler)
Subject: Re: How to best represent a list in Windows?
Message-ID: <1991Apr5.205519.29757@sunee.waterloo.edu>
Summary: memory management
Organization: Gold Disk Inc.
References: <e2BXZ1w163w@coyote.datalog.com>
Date: Fri, 5 Apr 1991 20:55:19 GMT
Lines: 65

In article <e2BXZ1w163w@coyote.datalog.com> ferdie@coyote.datalog.com (fred jarvis) writes:
>    I want to use a list structure in a Windows application.
>Typically, something like
>        typedef struct {
>           datatype *data;
>           listnode *next;
>        } listnode;
>would be used, with each node dynamically allocated.

Obviously this is a no-no in Windows, as you must allocate crap loads
of pointers (ie. handles, then locked).  This would eat up the local handle
table to the point where you run out of local heap space.  The same
issue faces you with global memory handles.

>    If listnode contains handles, rather than pointers, each time a
>node is referenced, calls to GlobalLock & ..Unlock (or LocalLock...)
>must be made, which seems inefficient to me.

Can't be done in an independant fashion.  (not portable eh!?)

>    I know LocalAlloc returns a pointer if called with the
>LMEM_FIXED flag, but this is discouraged by the higher powers
>(e.g. Petzold).  So what is the best approach to take (besides
>going back to DOS) ?

As I have said in three or four posts the last four months:

Gold Disks new animation package for M Windows required several
thousand records and has (possibly) hundreds of link lists to keep track of 
the play lists for the animations, and the resource lists of the
bitmaps/sounds/midi etc data.

The only good solution was to write my own custom memory management
stuff which allocates global memory locks it, and then divides said
memory into bite sized (sorry for the pun) chunks for use in
link lists.  Since protect mode allows memory to appear fixed logically
while physically moving around we are totally Windows friendly.
However, we wouldn't run very well in real mode or with expanded (*EMS)
memory as the locked memory segment would impeed normal Windows
memory compaction etc.

Once the block has been fully divided, either re-size it bigger
or if too big (>32k wastes cycles when moving memory in standard mode)
simply allocate another global block and continue the concept.

Thus, my solution is fair, adequate and seems to leave Windows with
plenty of memory management leeway in protect mode.  (Yea, like
what fool would create animations in real mode?? -serious)

Besides allocating blocks with global alloc creates a selector
table entry (descriptor) which must be cached by the processor
every time a new selector is accessed.  Trust me...this can slow
down the processor quite a bit when skipping thru a link list.

>    Fred Jarvis    ferdie@coyote.datalog.com

I realize this solution doesn't make anything easy, as you basically
have to write your own malloc/free routines, but hey, what are you
using your first year data structures course knowledge on anyway? :-)

-- 
Windows Sumo Wrestler                "Bo doesn't know software" - George Brett
  --(Windows 3.0, a combination of modern moodring technology and voodoo)--
"I guess she had a way, of making every night seem bright as day"
`I Don't Believe In Love`   -Queensryche (Oper. Mindcrime)     Glenn Steffler