5 ms·

Just crazy they wrote all of the command line tools in ASM - was that because C would have resulted in binaries that were too large?

ok123456 3y ago
They wrote a this before they had a good C tool chain. Microsoft didn't have a C compiler until 1985 which was a repackaged version of Lattice C.
- nottorp 3y ago
  Also the first IBM pc had what, 64kb of ram? It makes sense to do hand optimized assembler for that. Segmented architecture has nothing to do with it, there was support for it in any Compiler that targeted the platform. And besides, it was how you did things back then, no surprises there.
asveikau 3y ago
I don't think C and x86 real mode with segment:offset addresses mix that well. Obviously there were compilers that did it (and then those "near" vs "far" pointers ...), but it's not great. I think once you got to a flat 32 bit address space and more than 1mb of memory, C starts to make more sense.
- deleted 3y ago
  [deleted]
- nxobject 3y ago
  IIRC the classic Macintosh for example, even despite the flat memory model, had relocatable code segments to deal with real memory limitations, with a relocatable base + fixed offset jump table. They're not identical situations, but I think Think C had pragmas to delineate segments (although my memory is shaky there).
  - pjmlp 3y ago
    It had them yes, and was mostly coded in Assembly and Object Pascal.
- torusle 3y ago
  It wasn't that bad. You had different memory models back then. If you wanted to keep things easy you just compiled for a memory model in which each pointer was either 16 bit (for code/data smaller than 64kb) or a memory model with far pointers (access to all the memory). There have been mixed memory models and you could go crazy with near and far to break out of the limits of the easy memory models. Most of the time it was just a mater of picking a suitable memory model for your code and forget about near/far though. Not so different than today.
  - a_e_k 3y ago
    Yep. The "tiny" model gave you a single 64KB segment shared by both code and data. And the "small" model was the one where there was one 64KB segment each for code and data. IIRC, with the tiny model you could often compile those to .COM files where MS-DOS would pick a free segment, load the file to the 0x100 offset, set all the segment registers to it, set the stack pointer to 0x0, and jump to the start at 0x100. Super simple (not even an executable header)!
- pan69 3y ago
  C and x86 real-mode works just fine, why would it not? Yes, the segmented model is a bit of a pain but totally doable and it's not just a problem when programming C but also x86 Assembler, Pascal, etc. Even in Q(uick)Basic you won't get around it once you start to do more advanced system things. http://alexfru.narod.ru/os/c16/c16.html http://alexfru.narod.ru/os/c16/c16.html But indeed, we were all glad when the 32bit flat model was introduced with the 386.
pjmlp 3y ago
Contrary to urban myths, C was only yet another language during the 1980's, and hardly used outside UNIX.

ok123456 3y ago

They wrote a this before they had a good C tool chain. Microsoft didn't have a C compiler until 1985 which was a repackaged version of Lattice C.

nottorp 3y ago
Also the first IBM pc had what, 64kb of ram? It makes sense to do hand optimized assembler for that. Segmented architecture has nothing to do with it, there was support for it in any Compiler that targeted the platform. And besides, it was how you did things back then, no surprises there.

asveikau 3y ago

I don't think C and x86 real mode with segment:offset addresses mix that well. Obviously there were compilers that did it (and then those "near" vs "far" pointers ...), but it's not great. I think once you got to a flat 32 bit address space and more than 1mb of memory, C starts to make more sense.

deleted 3y ago
[deleted]
nxobject 3y ago
IIRC the classic Macintosh for example, even despite the flat memory model, had relocatable code segments to deal with real memory limitations, with a relocatable base + fixed offset jump table. They're not identical situations, but I think Think C had pragmas to delineate segments (although my memory is shaky there).
- pjmlp 3y ago
  It had them yes, and was mostly coded in Assembly and Object Pascal.
torusle 3y ago
It wasn't that bad. You had different memory models back then. If you wanted to keep things easy you just compiled for a memory model in which each pointer was either 16 bit (for code/data smaller than 64kb) or a memory model with far pointers (access to all the memory). There have been mixed memory models and you could go crazy with near and far to break out of the limits of the easy memory models. Most of the time it was just a mater of picking a suitable memory model for your code and forget about near/far though. Not so different than today.
- a_e_k 3y ago
  Yep. The "tiny" model gave you a single 64KB segment shared by both code and data. And the "small" model was the one where there was one 64KB segment each for code and data. IIRC, with the tiny model you could often compile those to .COM files where MS-DOS would pick a free segment, load the file to the 0x100 offset, set all the segment registers to it, set the stack pointer to 0x0, and jump to the start at 0x100. Super simple (not even an executable header)!
pan69 3y ago
C and x86 real-mode works just fine, why would it not? Yes, the segmented model is a bit of a pain but totally doable and it's not just a problem when programming C but also x86 Assembler, Pascal, etc. Even in Q(uick)Basic you won't get around it once you start to do more advanced system things. http://alexfru.narod.ru/os/c16/c16.html http://alexfru.narod.ru/os/c16/c16.html But indeed, we were all glad when the 32bit flat model was introduced with the 386.

pjmlp 3y ago

Contrary to urban myths, C was only yet another language during the 1980's, and hardly used outside UNIX.