15

In modern operating systems (for example: Windows), you can't access a memory location before you allocate that memory location to your program (or else a segmentation fault will occur).

I am wondering, do you need to also allocate memory before you use it in MS-DOS?

  • 2
    Which bit of memory? EMS, XMS, main? – Chenmunka Oct 17 '17 at 13:53
26

The basic answer is “yes”, assuming you want to be a good DOS citizen, however in many cases you don’t need to worry about it because the operating system takes care of it for you.

If you’re talking about conventional memory, allocating it explicitly isn’t necessary:

  • EXE files’ headers specify the minimum and maximum amount of memory the program needs, and DOS pre-allocates that (if it can) for the program before passing control to it (by default, the maximum is “all available memory”);
  • COM files don’t have a header, so DOS pre-allocates the largest available block of conventional memory for the program’s use.

DOS does provide APIs to allocate memory blocks, resize them and free them: respectively, interrupt 0x21, function 0x48, interrupt 0x21, function 0x4A and interrupt 0x21, function 0x49. Function 0x58 (sub-functions 0x00, 0x01, sub-functions 0x02, 0x03) affect how memory is allocated.

Some programs need to allocate memory separately, and therefore use these functions. One example is TSRs, since they need to reduce their pre-allocated block as much as possible and perhaps allocate other memory blocks, in order for them to remain allocated after they return control to the operating system but use as little as possible. It can also be useful to allocate memory if you want to use all the available memory: memory fragmentation might mean you wouldn’t get all the available memory in your pre-allocation.

You’d need to explicitly manage memory allocations if you wanted to use anything outside conventional memory: upper memory blocks, the HMA, EMS, XMS or plain extended memory.

  • 2
    Little clarification: EXE Programms also did get all memory (i.e the largest block available) assigned at startup, as in ye olde days(tm) (that is al least until about DOS 4 times) the maximum extra paragraph value was by default set to FFFFh, thus asking for the biggest chunk available. So rather 'no', no meory request needed, but reasonable management of anything available after the last assigned symbol until the size of the block. – Raffzahn Oct 17 '17 at 14:28
  • 3
    @Raffzahn that doesn’t contradict what I wrote: the header specifies the maximum amount needed, and DOS allocates at most that. This behaviour was documented early on (I had checked the MS-DOS Encyclopedia before writing my answer). I wrote “yes” in the first line because the memory is being allocated before being used. – Stephen Kitt Oct 17 '17 at 14:35
  • 3
    Your answer is great and correct (I upvoted it). Thats why I didn't address you, but added to your answer. I belive the correct answer is 'no', as his question was if memory has to be allocated (explicit by his program) before using it, which is not neccesarry, as it's already allocated before any operation of his program gets executed. I guess it can be a different view if this implicit allocation is something one 'has to do' or something that 'has been done already'. Can't it? (P.S.: got the same book right on my desk :)) – Raffzahn Oct 17 '17 at 15:03
  • 4
    Yes, indeed; memory allocation is perhaps one of the few areas where it’s straightforward ;-). (Unsurprisingly, DOS itself is not a good citizen, since COMMAND.COM uses unallocated memory, or should I say leaves part of itself resident without allocating a memory block as an interesting optimisation.) – Stephen Kitt Oct 17 '17 at 15:43
  • 4
    MS-DOS 1.x didn't have the memory allocation functions and COMMAND.COM's separate resident and transient parts date back to its original implementation. Even after the allocation functions were added to MS-DOS 2 there was no way to allocate "discardable" memory that the OS could automatically free if something else needed it. – Ross Ridge Oct 17 '17 at 19:20
17

For the sake of offering a contrary answer: there is no memory protection and there are no access levels, so there will be no segmentation fault or other hardware interrupt if you access memory that is there and which you have not asked for ownership of. If you are an MS-DOS program then you are driving the computer. Various of the interrupts will be set up to route through DOS when your program starts, but there is no access control to prevent you from disabling or rerouting every single one of them.

So you don't need to request ownership of memory provided that:

  • you happen somehow to know exactly what memory exists; and
  • you happen also to know exactly how that memory is being used by the various TSRs and drivers the user has loaded.

In practice you probably don't know those things. So instead of your code being declared faulty and evicted without harming the system as it would under a modern OS, you'll probably continue to run until you've broken some other part of the system and that part tries to run. E.g. maybe the user has a Gravis Ultrasound emulating a Sound Blaster, or is using MSCDEX plus their particular CD driver, or has their manufacturer's VESA driver occupying a certain block of memory, you stomp on that storage, then attempt to output audio, read from the CD or change the graphics mode.

I think that as to your question, the answer is therefore both yes and no. You don't need to allocate memory to be able to use it, but if you don't then you accept the risk of causing some other part of the system to crash or otherwise misbehave.

It's up to you though.

  • 5
    A valid point. In fact, you could decide to evict DOS entirely if you expect your program never to return to DOS by setting up your own interrupts, programming the various chips to do your bidding, etc. At which point, you've written an OS. – phyrfox Oct 17 '17 at 20:28
  • 3
    @phyrfox: There's also some middle ground: a program that overwrites DOS while it runs, then "returns to DOS" via (for example) int 19h (i.e., it basically reboots DOS). – Jerry Coffin Oct 17 '17 at 21:30
  • 1
    You're right for "plain old DOS", but the more complicated memory management got (HIMEM, EMS, EMM386) to work around PC limitations, it became more and more advisable to "go the official route" – tofro Oct 18 '17 at 9:25
  • @phyrfox which is something projects like DosLinux did – SztupY Oct 18 '17 at 11:06
  • Of course, if one wanted to be contrary to the contrary answer, one could point out that under a DPMI DOS extender there was memory protection. (-: – JdeBP Oct 18 '17 at 13:10
3

Technically, no. You DO NOT absolutely have to allocate memory before you use it in MS-DOS (for versions prior to the DOS that was included in OS/2 or the one in Windows 3.0). But note also that the ability to access any memory space (or not) in a machine is also determined by the hardware architecture (i.e., 8088, 8086, 80286, 80386, etc.) Now, to focus solely on the responsibility of the operating system (OS) here, Robert J. Moore wrote in a November 01, 1988 article on Dr. Dobbs that, "Starting with Version 2.0, all versions of DOS contain functions to allocate memory (function 48H), free allocated memory (function 49H), and modify allocated memory (function 4AH)," via the use of Memory Control Blocks (MCBs). "If DOS detects any corruption in the MCB chain, it prints out an error message and halts the system." However, it is possible to, "break the MCB chain deliberately . . . DOS doesn't always notice." In fact, "DOS could be bypassed altogether for memory management," said Mr. Moore. Simply put, that's because BOTH the OS and the hardware allows it. Per the book, Intel Microprocessors: 8086/8088 - 8th Edition (available on Google Books), "Real mode, is an operating mode of 80286 and later x86-compatible CPUs. . . Real mode provides no support for memory protection, multitasking, or code privilege levels. 80186 CPUs and earlier, back to the original 8086, have only one operational mode, which is equivalent to real mode in later chips." Now, protected mode, as opposed to real mode, first available on the 80286, could allow your DOS programs to come under protected mode memory management--but that can happen only if you've installed OS/2 or Windows 3.0 (which are the first operating systems to implement versions of DOS capable of DPMI--the protected mode specification) which would allow your DOS programs to run in protected mode on 80286 series and later processors. Only then would you actually need to allocate memory before using it in your DOS programs.

  • 3
    Note that bypassing MS-DOS and manipulating the MCB chain yourself means you're still allocating (or deallocating) memory, you're just using your own code to do it rather than MS-DOS's. – Ross Ridge Oct 18 '17 at 16:12
  • Protected mode doesn't mean you have to allocate memory, it just means you have to have the right to write to it once you do use it. Not quite the same thing. For an example, I suspect that on an IBM PC it was still possible to write to 0B8000H after switching a 286 into protected mode, if you just set up the segment descriptors properly first. – a CVn Oct 18 '17 at 18:17
  • Michael, I too suspect that it is still possible to write to 0B8000H after switching a 286 into protected mode. But address 0B8000H is the base of video memory. I think any program ought to be able to write to that address by virtue of its function; someone here might be able to verify that. But just randomly picking some other address outside of your scope of memory should produce a segmentation fault on a 286 machine running in protected mode. – ShieldOfSalvation Oct 19 '17 at 14:10
  • I used to program on 286 computers in protected mode under OS/2 1.3 and I'm pretty confident you got a segmentation fault if you wrote outside your data segment. I seem to remember you could write anywhere inside a locked page? Eg you could overrun your allocation but you wouldn't affect any other process. – Mark Williams Oct 30 '17 at 16:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.