NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/os/mswindo/misc/2518

Internet Message Format | 1992-08-30 | 1.8 KB

Path: sparky!uunet!math.fu-berlin.de!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!dfv.rwth-aachen.de!sungate.fido.de!p1.hippo.fido.de!eurologic.fido.de!Martin_Schloeter
Date: Fri, 28 Aug 92 09:59:52 +0200
From: [e-mail] (Martin Schloeter)
Subject: Re: Windows == OS
Message-ID: <[e-mail]>
Newsgroups: comp.os.ms-windows.misc
X-Comment-To: [e-mail] (Name)
Organization: Die ersten 100.000 Jahre...
Lines: 24

N > Execuse me!!!!  Windows WILL NOT touch your malloc memory blocks,
N > and it will sort of juggle with your memory only with near pointers and
N > that is also only because you got the same DS value; that is it does
N > not play with your memory blocks in relation to your malloc calls, it
N > will move your WHOLE program by changing the base address.  Compile
N > in the compact or huge models where everything is far and windows will
N > die a horrible death if it tried to play with it.
N >
You are definitly wrong.
Don't mix it up. You description is only correct for static data in the apps
default data segment(s) and data allocated with the default malloc (identically
with LocalAlloc-LocalLock) in the Local Heap (which is inside the default data
segment(s)). Even this problem is better managed with Win 3.1 then with 3.0 (no
more sandbank effekt with such memory).
Memory allocated with GlobalAlloc-Global lock (also far pointers) is perfectly
juggled by windows.
Simply write an app which uses such call, start heapwalker and make some memory
intensive things and you will see your memory blocks juggling around.
And to say it again. Is not aspect of the system design, that malloc of the
C-Library is translated to LOCALAlloc-LOCALLock, that a decision of the
compiler factorer. You can make simply a new malloc which works in the Global
Heap (with real juggling and so on).

Martin