Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!mtune!codas!peora!ucf-cs!usfvax2!chips
From: chips@usfvax2.UUCP (Chip Salzenberg)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Fragmentation on DOS - HELP !
Message-ID: <768@usfvax2.UUCP>
Date: Fri, 22-May-87 14:08:39 EDT
Article-I.D.: usfvax2.768
Posted: Fri May 22 14:08:39 1987
Date-Received: Sat, 23-May-87 17:28:46 EDT
References: <287@pyuxv.UUCP> <764@usfvax2.UUCP> <3617@gitpyr.gatech.EDU>
Organization: AT Engineering, Tampa, FL
Lines: 40
Summary: Oops .. mea culpa

In article <3617@gitpyr.gatech.EDU>, roy@gitpyr.gatech.EDU (Roy Mongiovi) writes:
>In article <764@usfvax2.UUCP>, chips@usfvax2.UUCP (Chip Salzenberg) writes:
>> DOS does not reclaim these little blocks automatically.  Only the block that
>> contains the program's Program Segment Prefix (PSP) is automatically freed on
>> exit.  (Good thing, too, since to free your own code could be hazardous.)
> 
> This isn't at all true.  Each block of memory allocated via the DOS functions
> has a 16 byte (1 paragraph) header which contains, among other things, the PSP
> of its owner.  When a program terminates by any function except one of the
> terminate and stay resident functions, all memory blocks owned by its PSP
> are freed.

I believe you're right.  The Terminate and Stay Resident function does not free
any memory allocated by the calling process, but the normal Terminate function
does.  That's one misteak this week.  :-)
 
> I don't understand the last quoted sentence.  How exactly could freeing the
> code segment for the program that just terminated be hazardous?  That seems
> to me to be exactly what ought to happen....

It would be hazardous for a process to free its own code segment, esp. in a
multitasking environment such as Windows.  DOS's freeing a process's code
segment when that process Terminates is, as you suggest, normal.  :-)

> I sincerely hope that MSC does not use the DOS functions directly to allocate
> memory, since 16 bytes is a tremendous overhead for small blocks.  I don't
> own Microsoft C, so someone else will have to look into it.

I am quite sure that MS-C does call DOS to allocate "far" memory.  This
`feature' of MS-C makes accurate determination of available "far" memory
quite difficult, if not impossible.

I don't know whether or not the MS-C library is smart enough to ask for large
chunks when a C program asks for many small chunks.  Perhaps someone from MS
can answer this...  (1/2 :-)

-- 
Chip Salzenberg		    Address: "{gatech,cbatt,akgua}!usfvax2!ateng!chip"
AT Engineering, Tampa, FL   Redress: "chips@usfvax2.UUCP"
"Use the Source, Luke!"	    My opinions do not necessarily agree with anything.