30

As an example, say we have a DOS MZ EXE file that's around 20 KiB in size. The EXE header contains the value 0x1400 at offset 0x0A indicating that the program is requesting 5,120 paragraphs (or 80 KiB) to be allocated in addition to the space occupied by the load image. When the load is complete, a total of 100 KiB will be available for the program's direct use.

I don't know what the "official" term was for the 80 KiB allocation in this example, but I know it as BSS from the *nix world.

My question is simply, did DOS zero out this area when it loaded the program, or could there be garbage inside it from whatever held the memory previously? If DOS did not zero it out, was it something that most programs (or the runtimes they were compiled/linked with) did on their own?

I'm mainly interested in the perspective from a typical C program of the day. If I understand it correctly, C guarantees that all static variables without an explicit initializer get set to 0, and those variables seem to end up being stored in the BSS area. So whose job was it to ensure they were properly zeroed?

Improve this question
2
  • 8
    I don't know if DOS did it or not, but if it didn't, the C runtime would have almost certainly ensured that uninitialized global and static data zeroed as required by the language (or else lots of programs would not have worked).
    – Erik Eidt
    Aug 14, 2019 at 1:04
  • I would have guessed it didn't, purely because GO.COM existed.
    – grawity
    Aug 15, 2019 at 18:13

1 Answer 1

Reset to default
50

No, it didn't. MS-DOS never bothered to zero out allocated memory, as there was no security reason to do so like there is in a multi-user operating system. It was up to the C runtime startup code to zero out the BSS segment.

For example, from the Borland C++ 3.1 startup code: 

;       Reset uninitialized data area

                xor     ax, ax
                mov     es, cs:DGROUP@@
                mov     di, offset DGROUP: bdata@
                mov     cx, offset DGROUP: edata@
                sub     cx, di
                cld
                rep     stosb

_BSS            SEGMENT
bdata@          label   byte
                ENDS

_BSSEND         SEGMENT
edata@          label   byte
                ENDS
Improve this answer
4
  • 11
    And the source code for DOS’s exec routine is now available (for version 2.0), which shows how BSS is allocated but not zeroed (see also the memory management routines elsewhere).
    – Stephen Kitt
    Aug 14, 2019 at 11:27
  • 4
    The "no security reason because it was a single-user system" argument was indeed how it was thought about in those days. It doesn't really work in today's world -- smartphones are definitely single-user systems, as are (in practice) most laptops, but security is a paramount cocern there even so. What saved MS-DOS (and yet not really!) was that most of the systems were not networked, or if they were then only with a few other machines in the same office.
    – hmakholm left over Monica
    Aug 15, 2019 at 17:07
  • 2
    @hmakholmleftoverMonica: Phones and laptops run large amounts of code on behalf of entities other than the owner. There may be only one human user, but there are many other "users".
    – supercat
    Jul 29, 2021 at 20:48
  • @supercat Well put
    – Wayne Conrad
    May 3 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .