Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Fragmentation on DOS - HELP !
Message-ID: <620@bsu-cs.UUCP>
Date: Sat, 16-May-87 02:33:31 EDT
Article-I.D.: bsu-cs.620
Posted: Sat May 16 02:33:31 1987
Date-Received: Sun, 17-May-87 01:03:57 EDT
References: <287@pyuxv.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 24

In article <287@pyuxv.UUCP> cim2@pyuxv.UUCP (Robert L. Fair) writes:
>Does anyone out there know how DOS handles massive amounts of dynamic
>allocation and freeing, in particular memory fragmentation.  
[Examples of problems omitted]

I have had problems with using malloc() when compiling with Microsoft C
version 3.0.  I found that repeated allocations and freeing would
eventually result in a hung system.

If that had been a bug in malloc() in version 3.0 of Microsoft C, it
would likely have been fixed in version 4.0.  Since that doesn't seem
to have happened, it may be a bug in MS-DOS itself.  On the other hand,
I have seen the problem occur under both versions 2.1 and 3.1 of
PC-DOS, and one would expect the bug to have been fixed going from 2.1
to 3.1.  So it's not clear where the bug lies.  But it's definitely a
bug either in Microsoft C or in MS-DOS or in both.  Since the Microsoft
C compiler is apparently compiled with itself, it will exhibit the
malloc bug like any other C program compiled with Microsoft C.

I wrote my own simply memory allocator that calls Microsoft's malloc()
function with requests for large blocks and then breaks them up into
smaller pieces as needed.  This worked fine.
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi