5 ms·

This trick generally works, but is not guaranteed to work by DOS API. COM binary gets 4k paragraph allocation and nothing more, the fact that this allocation es

by dfox 6y ago

This trick generally works, but is not guaranteed to work by DOS API. COM binary gets 4k paragraph allocation and nothing more, the fact that this allocation essentially always is at the bottom edge of free conventional memory is not even an implementation detail, it is consequence of everybody trying to be frugal with their memory allocations. ie. if there was TSR that allocates and then frees 64k region, you will get exactly this region and this trick will break and you will overwrite who knows what.

WalterBright 6y ago
As I recall an operating system call was used to extend the memory, so it should never have broken unless a broken TSR was used. There weren't any issues with it that I know of, used it all the time for many years.
- hyperman1 6y ago
  To be honest, I remember something different. Dos was originally a single process OS. So memory was allocated like a stack, at least for a .COM. Some detail:All memory above your starting address is yours. You call int 12 to find out how much base memory is installed, which in later computers was either 640K or 639K if the bios wanted a bit or storage. If you want to start another program, you first resize your part of the memory with INT 21 (ah=4D? Its too long ago, don't quote me on this) Later, there came TSRs, EMS/UMBs/high memory/... to muck this scheme up. A TSR was not allowed to allocate memory after it terminated, exactly because it runs code in another process while it should have been terminated. It had to always stay under all other programs, memory address wise. It was not allowed to do much, in fact, because DOS was not reentrant, and running int21h while running int21h had a good chance of making DOS overwrite its own variables.
  - hyperman1 6y ago
    UPDATE: It was quite hard to find reference information about all this. I vaguely remember reading it in one of the Peter Norton books at the time, but I can't really find them. The most relevant thing I can still find on todays internet is this: https://www.pcjs.org/documents/books/mspl13/msdos/advdos/ https://www.pcjs.org/documents/books/mspl13/msdos/advdos/ chapter 3: ... the operating system simply makes the worst-case assumption and gives .COM programs everything that is available. If a .COM program wants to use the EXEC function to invoke another process, it must first shrink down its memory allocation ...
alfiedotwtf 6y ago
Is there any restriction going from tiny to protected mode? If so, that sounds like the best of both worlds.
- bleepblorp 6y ago
  DOS was much more of a glorified process loader than an operating system as we think of one today. It had no knowledge of memory models, very limited knowledge of protected mode, and no means to constrain application behavior. "DOS" memory models were styles of programing rather than features the DOS kernel understood, much less supported. The DOS API always used far pointers for addressing and had no notion of which memory model a calling process used. As far as protected mode is concerned, DOS has very limited knowledge of protected mode. Any DOS application could switch to protected mode at any time. In earlier versions of DOS, this was done by setting up the processor hardware directly. In version 4 and beyond, DOS software entered protected mode using VCPI or DPMI functionality through emm386. Any DOS process which went into protected mode essentially became the running operating system and was on its own and had no support from the DOS kernel. Technologies were eventually developed to allow protected mode software to call the DOS kernel and BIOS--typically used for filesystem access and video mode setup--but the protected mode code was ultimately in control of the computer. DOS was a second-class citizen at best.
  - alfiedotwtf 6y ago
    > The DOS API always used far pointers for addressing and had no notion of which memory model a calling process used Ha, yeah it's all coming back to me. > Any DOS process which went into protected mode essentially became the running operating system and was on its own and had no support from the DOS kernel. Technologies were eventually developed to allow protected mode software to call the DOS kernel and BIOS--typically used for filesystem access and video mode setup--but the protected mode code was ultimately in control of the computer. I don't know what it is, but it really felt like a superpower after setup and then flipping CR0. You knew that every single bit of code running on that box after that was hand crafted by you. Unless you go embedded, gone are those days. Computers are too complex these days to know what every single think is doing... we've all now been delegated to mere mortals :(

by dfox 6y ago

WalterBright 6y ago

As I recall an operating system call was used to extend the memory, so it should never have broken unless a broken TSR was used. There weren't any issues with it that I know of, used it all the time for many years.

hyperman1 6y ago
To be honest, I remember something different. Dos was originally a single process OS. So memory was allocated like a stack, at least for a .COM. Some detail:All memory above your starting address is yours. You call int 12 to find out how much base memory is installed, which in later computers was either 640K or 639K if the bios wanted a bit or storage. If you want to start another program, you first resize your part of the memory with INT 21 (ah=4D? Its too long ago, don't quote me on this) Later, there came TSRs, EMS/UMBs/high memory/... to muck this scheme up. A TSR was not allowed to allocate memory after it terminated, exactly because it runs code in another process while it should have been terminated. It had to always stay under all other programs, memory address wise. It was not allowed to do much, in fact, because DOS was not reentrant, and running int21h while running int21h had a good chance of making DOS overwrite its own variables.
- hyperman1 6y ago
  UPDATE: It was quite hard to find reference information about all this. I vaguely remember reading it in one of the Peter Norton books at the time, but I can't really find them. The most relevant thing I can still find on todays internet is this: https://www.pcjs.org/documents/books/mspl13/msdos/advdos/ https://www.pcjs.org/documents/books/mspl13/msdos/advdos/ chapter 3: ... the operating system simply makes the worst-case assumption and gives .COM programs everything that is available. If a .COM program wants to use the EXEC function to invoke another process, it must first shrink down its memory allocation ...

alfiedotwtf 6y ago

Is there any restriction going from tiny to protected mode? If so, that sounds like the best of both worlds.

bleepblorp 6y ago
DOS was much more of a glorified process loader than an operating system as we think of one today. It had no knowledge of memory models, very limited knowledge of protected mode, and no means to constrain application behavior. "DOS" memory models were styles of programing rather than features the DOS kernel understood, much less supported. The DOS API always used far pointers for addressing and had no notion of which memory model a calling process used. As far as protected mode is concerned, DOS has very limited knowledge of protected mode. Any DOS application could switch to protected mode at any time. In earlier versions of DOS, this was done by setting up the processor hardware directly. In version 4 and beyond, DOS software entered protected mode using VCPI or DPMI functionality through emm386. Any DOS process which went into protected mode essentially became the running operating system and was on its own and had no support from the DOS kernel. Technologies were eventually developed to allow protected mode software to call the DOS kernel and BIOS--typically used for filesystem access and video mode setup--but the protected mode code was ultimately in control of the computer. DOS was a second-class citizen at best.
- alfiedotwtf 6y ago
  > The DOS API always used far pointers for addressing and had no notion of which memory model a calling process used Ha, yeah it's all coming back to me. > Any DOS process which went into protected mode essentially became the running operating system and was on its own and had no support from the DOS kernel. Technologies were eventually developed to allow protected mode software to call the DOS kernel and BIOS--typically used for filesystem access and video mode setup--but the protected mode code was ultimately in control of the computer. I don't know what it is, but it really felt like a superpower after setup and then flipping CR0. You knew that every single bit of code running on that box after that was hand crafted by you. Unless you go embedded, gone are those days. Computers are too complex these days to know what every single think is doing... we've all now been delegated to mere mortals :(