Writing assembly programs for DOS was incredibly easy: BIOS calls via interrupts, so you could already do a lot. Fixed video memory address... and the BIOS in order to enter the video modes without poking the video card directly. High level and low level mixed together.
I remember writing a pretty complicated "guess the number" program in 16-bit DOS assembler in the 90's for a college course. It used colour and everything and I spent a number of long nights getting tasm to do what I wanted on my 486 I had at the time. Except the colour didn't work on the college computers because the DOS prompt was differently configured (I might have been using PC DOS, and college had MS DOS.) Fun times.
I wrote something in x86 assembly a few years back... trying to write a TSR that reclaims half of its memory before going resident was an interesting experience...
I grew up "before Internet", so no quick download, and also when I was about 15, 16 years old, I played a bit with Assembler. I had a book about Assembler but no Software, so the only way to do something was with the Debugger from DOS. You wrote the program direct to the RAM. You could not use marks, so you had to calculate each jump. A lot of crashes but still fun times :-)
I downloaded the "Ralph Brown Interrupt List" in the "before internet" time, from my local BBS. IIRC, the whole thing took about a week or two of effort on my 2400 Baud modem, and limited phone time.
With it, I was able to write a mouse "driver" in QBasic, that I used for my HS programming assignment -- we had to prompt the user with math problems and then read the input back. I implemented a "simple" text GUI with mouse support.
I was a junior programmer on a team that built software, and managed the operations for a company with 27 offices across the continental US, with something like 2,000 different PC's deployed on the network in various locations around the country.
A new version of the business software we built was being deployed, and it required a proper shutdown/reboot of the system after installation. At that time in history, this reboot was done manually, by sub-contractors and fellow work colleagues who were flown from Burbank to New Hampshire to make sure the machines - which the clients weren't allowed to touch - were successfully rebooted after the update.
This cost tens of thousands in fees - subcontractors and plane tickets and whatnot - and my boss was sick of it .. he was a mainframe guy and hated these new DOS machines that didn't behave properly, having replaced dumb terminals with great fanfare, because per him, upper management just had to have The Newest Shit™ without thinking about it.
He tasked me to do the 'impossible' - work out how to safely reboot all these DOS PC's after a software update. If I could do it, I'd get a fat bonus - 1/3rd of the plane fare/travel budget that was on the block.
It was the easiest US$10K I ever made, looking (something like) this:
C:\>debug.com
a
JMP FFFF
s 5
n C:\reboot.com
w
q
It always amuses me to remember the look on his face when I showed him how easy it would be to remotely add a reboot.com to every machine by pasting this little script into a modem-connected system that had had its CON: redirected to COM1: (which was also how we were doing the software update remotely) ... and how annoyed my colleagues were that they didn't get the overtime pay for traveling across the country to do the CTRL-ALT-DEL dance, any more ..
I used to do this for fun to show how much of an old timer I was. Here's the detail from a different thread on HN 22 days ago[2]
How to create hello.com using debug in MS-DOS.
You can try it out here[1]. (Hit F3 twice to exit setup first)[1] https://www.pcjs.org/software/pcx86/sys/dos/microsoft/6.22/
[2] https://news.ycombinator.com/item?id=41475874
As far as I remember, when a COM program is executed¹, DS is set to CS, so it's not necessary to manually set it.
¹=confirmed here: https://stackoverflow.com/a/13663859.
Writing assembly programs for DOS was incredibly easy: BIOS calls via interrupts, so you could already do a lot. Fixed video memory address... and the BIOS in order to enter the video modes without poking the video card directly. High level and low level mixed together.
I remember writing a pretty complicated "guess the number" program in 16-bit DOS assembler in the 90's for a college course. It used colour and everything and I spent a number of long nights getting tasm to do what I wanted on my 486 I had at the time. Except the colour didn't work on the college computers because the DOS prompt was differently configured (I might have been using PC DOS, and college had MS DOS.) Fun times.
I wrote something in x86 assembly a few years back... trying to write a TSR that reclaims half of its memory before going resident was an interesting experience...
I was playing that a lot when I'm 15. I, however, used LEA instead of MOV, as suggested by the book I read. Miss those days.
I grew up "before Internet", so no quick download, and also when I was about 15, 16 years old, I played a bit with Assembler. I had a book about Assembler but no Software, so the only way to do something was with the Debugger from DOS. You wrote the program direct to the RAM. You could not use marks, so you had to calculate each jump. A lot of crashes but still fun times :-)
I downloaded the "Ralph Brown Interrupt List" in the "before internet" time, from my local BBS. IIRC, the whole thing took about a week or two of effort on my 2400 Baud modem, and limited phone time.
With it, I was able to write a mouse "driver" in QBasic, that I used for my HS programming assignment -- we had to prompt the user with math problems and then read the input back. I implemented a "simple" text GUI with mouse support.
I was a bit of a show off back then..
I was a junior programmer on a team that built software, and managed the operations for a company with 27 offices across the continental US, with something like 2,000 different PC's deployed on the network in various locations around the country.
A new version of the business software we built was being deployed, and it required a proper shutdown/reboot of the system after installation. At that time in history, this reboot was done manually, by sub-contractors and fellow work colleagues who were flown from Burbank to New Hampshire to make sure the machines - which the clients weren't allowed to touch - were successfully rebooted after the update.
This cost tens of thousands in fees - subcontractors and plane tickets and whatnot - and my boss was sick of it .. he was a mainframe guy and hated these new DOS machines that didn't behave properly, having replaced dumb terminals with great fanfare, because per him, upper management just had to have The Newest Shit™ without thinking about it.
He tasked me to do the 'impossible' - work out how to safely reboot all these DOS PC's after a software update. If I could do it, I'd get a fat bonus - 1/3rd of the plane fare/travel budget that was on the block.
It was the easiest US$10K I ever made, looking (something like) this:
It always amuses me to remember the look on his face when I showed him how easy it would be to remotely add a reboot.com to every machine by pasting this little script into a modem-connected system that had had its CON: redirected to COM1: (which was also how we were doing the software update remotely) ... and how annoyed my colleagues were that they didn't get the overtime pay for traveling across the country to do the CTRL-ALT-DEL dance, any more ..Hope one day we can build FreeDOS with 100% libre tools.