News for hackers. Stuff that matters.

A comment on The history of Unix's confusing set of low-level ways to allocate memory (2018).

Re:The history of Unix's confusing set of low-level ways to ... by userbinator on Tuesday November 02, 2021 @10:30PM (#29090443)
On the other hand, as far as I know, there was never the concept of a "brk" in the DOS/Windows world; in DOS, by default programs got all memory (no virtual memory, all physical), and there was a set of malloc/free/realloc-ish functions for TSRs and other "advanced" techniques. DOS-based Windows memory allocation goes through DPMI which again provides similar functionality to malloc/free/realloc, as well as mmap. NT-based Windows is similar but without the DPMI.
[ Parent | on HN ]
Re:The history of Unix's confusing set of low-level ways to ... by oso2k on Wednesday November 03, 2021 @01:19AM (#29091337)
Not quite true. DOS programs were not automatically given all memory. DOS programs needed to allocate various memories (Conventional, EMS, XMS memory) via API specific to each type. DOS programs running under Windows 95 and later were presented with a DPMI compatible API if they so choose to use. DPMI DOS Extenders were intended to provide DOS compatibility for 16-bit and 32-bit Protected Mode applications. Memory allocation was just one service type they provided. Some also provided virtual memory or Win32 API emulation.

https://fd.lod.bz/rbil/interrup/dos_kernel/2148.html#sect-29...

https://fd.lod.bz/rbil/interrup/memory/2f4310.html#sect-4815

https://fd.lod.bz/rbil/interrup/memory/673f_cx5145.html#sect...

https://en.wikipedia.org/wiki/DOS_extender#DOS_extenders

https://en.m.wikipedia.org/wiki/CWSDPMI

https://www.japheth.de/HX.html

[ Parent | on HN ]
Re:The history of Unix's confusing set of low-level ways to ... by dfox on Wednesday November 03, 2021 @07:51AM (#29093395)
In real-mode DOS the situation is that the program is loaded to continuous block of memory that is followed by it's BSS and heap. The MZ header only specifies how big the BSS+heap part should be. Typical MZ format EXE has the size specified as BSS size by minimum and no maximum, which causes the MZ loader to allocate everything from PSP to the end of present conventional memory to the process. One consequence of that is that if you want to run other programs you have to either change the usual default of "unlimited" heap size or free some memory manually (or use COM format executable which by default only gets one DS=CS=SS segment).
[ Parent | on HN ]