On 5/11/19 2:00 PM, Fred Cisin via cctalk wrote: > Although I enjoyed DeSmet C, I used Microsoft C for all subsequent high > level language progams that I wrote. For example, I wrote the screen > capture TSR of "XenoFont" in MASM, and the printing program in Microsoft > C; I wrote "Sales tax Genie" (TSR) in MASM, but then later renamed the > .COM file to .EXE to use it as the "stub" program of a Microsoft C > Windoze program, to have a single file that could load the TSR in DOS, > AND be able to run as a Windoze program. I never got around to redoing > the TSR formats to be able to ALSO load them as device drivers (lets you > get them into lower memory!); I intended to eventually create a single > executable file format that could be loaded by CONFIG.SYS, CMD.COM, AND > Windows.
My first FILES-11 RX01 read-conversion tool was written in PL/M and ran on an MDS800. My second FILES-11 RX01 reading/conversion utility was written largely in FORTRAN. System was an 8080 S100 box with a WD1771 controller. C on an 8080/85 system seems like a horrible waste of hardware, owing to the need for procedure-local variables. Stack-based addressing isn't pretty. Basically to load a 16-bit stack-based integer into BC you have to do something like this: LXI H,offset DAD SP MOV C,M INX H MOV B,M Add to that, that really good "C" compilers for the x80/x86 took some time to mature. My first C on an 8086 was Lattice; compiled on a floppy-based system. But then Microsoft MASM 1.0 was terrible in its own right as well--the list of errata was quite long. I remember mumbling to myself "that's not what I wrote!". --Chuck
