Damn that actually sounds superior. How did changing the size work?

The standard screen was 80 by 25. There were two addresses you needed to know 0xb000 for monochrome displays and 0xb800 for color. For monochrome you could just blast characters/attributes to the address and everything looked great. For color you had to add a little bit of assembly so writes didn't happen when the monitor was doing certain things (or else you would get some flickering). The little hacks were all well known. Then you could build your own 'windowing' system by just maintaining separate screen buffers and having a little bit of code to combine for buffers when writing the actual hardware. In the early days everyone code was synchronous and code would start listening for keyboard events and react and repaint in a very ad hoc fashion. Mouses made things a bit more complicated as you needed to maintain a persistent model of the UI to process their events. So the UI code was simple and easy to work on, but you had to squeeze these programs into tiny memory footprints so you would spend a lot of time trying to find more memory. One of the bigger projects I worked on had a memory manager that relocated blocks to create contiguous space but since there was no OS support for things that like the code was actually updating pointer in the heap and stack - which was a great source of complicated bugs. Whoa onto anyone that tried to use a linked lists in such an environment. But yeah, it was a fun time.

Unless the program specifically allowed for it, you couldn’t change the size (video mode, really) without exiting and restarting the program after changing modes on the DOS prompt.

Remember, the video hardware rendered text mode full-screen, and it had to be reconfigured to change to a different number of lines and columns. Only specific sizes were supported.

There were a bunch of predefined modes in the video BIOS, and with a little bit of assembler you'd issue an interrupt (a system call really) which would change the video mode. Then as the parent comment said, you could write to video memory directly and your writes would either be interpreted as ASCII character/attribute pairs in a text mode, or colour palette indices in a graphical mode.

Most games at that time used mode 13h which was 320x200 with 8-bits per pixel which therefore indexed into a 256-colour palette (which could itself be redefined on the fly via reading from and writing to a couple of special registers - allowing for easy colour-cycling effects that were popular at that time). Here's a list of the modes: https://www.minuszerodegrees.net/video/bios_video_modes.htm

You called an "interrupt," which was basically a system call. That changed a bunch of timing registers within the video hardware. For a long time you basically could only do 40, 80 columns of text and 25, 43, or 50 lines. With some trickery you could get the video hardware to output 90 columns and with even more trickery you could get 60 rows.

If you made a custom font you could also have more diversity in the number of rows too but this was rarely done.

Eventually different text modes became available with higher resolution video cards and monitors. 132 columns of text were common but there were others.