3 ms·

Sure - but I think the title is referencing the fact that 640K is the minimum required for a basic DOS system to run. Using that system you can write code for f

by lnx01 9y ago

Sure - but I think the title is referencing the fact that 640K is the minimum required for a basic DOS system to run. Using that system you can write code for fun that would by definition fit in 640K.

raverbashing 9y ago
I'd rather pay for more hardware than use segmented memory again
sp332 9y ago
640k is the maximum available to applications on the original IBM PC. https://en.wikipedia.org/wiki/Conventional_memory#640_KB_barrier https://en.wikipedia.org/wiki/Conventional_memory#640_KB_bar...
hsitz 9y ago
Probably not this. 640k was actually the maximum amount of memory available for a user's DOS applications on an IBM PC or clone. There were many PC's sold that had only 64k of use-accessible RAM. It was only in later years, as memory got cheaper (and apps "ballooned") that machines maxed out at the 640k limit. With the 16-bit system the actual CPU-addressable limit was 1024kb (or 1MB), but the difference was reserved for use by the system for things like the ROM BIOS, graphic adapter bios, etc. My memory is vague on this, but I believe the core DOS commands (e.g., copy) were part of the ROM BIOS (or maybe they were just always loaded into non-user-accessible RAM as part of boot). So they were always present and did not affect available user RAM. The non-core DOS commands (e.g., xcopy) had to be loaded into user RAM to run. What's more, if you had a diskette-based system (i.e., no hard drive), you would have to load the floppy diskette that had the particular extended DOS command you wanted to run, before you could run it (because it had to be read off the diskette).
- dfox 9y ago
  640k is not maximum available to applications, but the maximum amount of RAM that would fit into PC, restof the 1MB address space was reserved for ROMs and memory mapped IO. No dos commands were normally part of ROM. In fact even command.com was designed such that large part of it could be thrown away if additional memory was required and then reloaded from disk when user program terminated (this was implemented by relocating the "transient" part onto the end of usable address space and detecting whether it was overwritten by user programs). Larger DOS file managers usually use similar approach, but simpler: the UI is implemented by separate binary that simply records what the user wants to run somewhere and then exits passing control to small stubbinary that starts requested program and restarts the UI when the program ends. Edit: MS-DOS 2.0's command.com detects that the transient part was overwritten by means of single byte checksum. The reason why it is done in this somewhat hackish way is that DOS allocates all of the available memory for most MZ EXE programs regardless of how many they actually use (MZ header specifies minimum and maximum amount of unitialized memory needed, with no maximum being the default).
Stratoscope 9y ago
The minimum memory that IBM offered in the original PC was the 16KB my first PC came with. I upgraded it to 64K right away, but DOS certainly ran in the 16K configuration.

by lnx01 9y ago

raverbashing 9y ago

I'd rather pay for more hardware than use segmented memory again

sp332 9y ago

640k is the maximum available to applications on the original IBM PC. https://en.wikipedia.org/wiki/Conventional_memory#640_KB_barrier https://en.wikipedia.org/wiki/Conventional_memory#640_KB_bar...

hsitz 9y ago

Probably not this. 640k was actually the maximum amount of memory available for a user's DOS applications on an IBM PC or clone. There were many PC's sold that had only 64k of use-accessible RAM. It was only in later years, as memory got cheaper (and apps "ballooned") that machines maxed out at the 640k limit. With the 16-bit system the actual CPU-addressable limit was 1024kb (or 1MB), but the difference was reserved for use by the system for things like the ROM BIOS, graphic adapter bios, etc. My memory is vague on this, but I believe the core DOS commands (e.g., copy) were part of the ROM BIOS (or maybe they were just always loaded into non-user-accessible RAM as part of boot). So they were always present and did not affect available user RAM. The non-core DOS commands (e.g., xcopy) had to be loaded into user RAM to run. What's more, if you had a diskette-based system (i.e., no hard drive), you would have to load the floppy diskette that had the particular extended DOS command you wanted to run, before you could run it (because it had to be read off the diskette).

dfox 9y ago
640k is not maximum available to applications, but the maximum amount of RAM that would fit into PC, restof the 1MB address space was reserved for ROMs and memory mapped IO. No dos commands were normally part of ROM. In fact even command.com was designed such that large part of it could be thrown away if additional memory was required and then reloaded from disk when user program terminated (this was implemented by relocating the "transient" part onto the end of usable address space and detecting whether it was overwritten by user programs). Larger DOS file managers usually use similar approach, but simpler: the UI is implemented by separate binary that simply records what the user wants to run somewhere and then exits passing control to small stubbinary that starts requested program and restarts the UI when the program ends. Edit: MS-DOS 2.0's command.com detects that the transient part was overwritten by means of single byte checksum. The reason why it is done in this somewhat hackish way is that DOS allocates all of the available memory for most MZ EXE programs regardless of how many they actually use (MZ header specifies minimum and maximum amount of unitialized memory needed, with no maximum being the default).

Stratoscope 9y ago

The minimum memory that IBM offered in the original PC was the 16KB my first PC came with. I upgraded it to 64K right away, but DOS certainly ran in the 16K configuration.