Once text has been written to the screen, it's all just graphics. Scrolling is actually extremely easy:

!	scroll up previous contents

iret = GetClientRect (hwnd, crect)

iret = ScrollWindow (hwnd, 0, -cychar, crect, crect)

where hwnd is your window's handle and cychar is the height of the text line (in pixels). For what you'r looking for, you would adjust the client rectangle crect to exclude the bottom line of text in the window. So you would move everything up one line before writing output to line (n-1).

For the "standard windows console" (i.e. the thing that's typically called a command prompt) I'm not sure that the GUI scrolling functions will do what's wanted, for example - as soon as the console window was redrawn for whatever reason by the window manager the text would revert back to the un-scrolled form). (You might also run into permission issues - console windows aren't owned by the process for your program, they are owned by a system process that is rather privileged. I wonder if the system might get a bit cranky about you manipulating a window that technically belongs to a different user.)

Instead I think you'd have to use the console functions, which also implies that you need to intercept (perhaps through handle redirection to a pipe??) and then custom display standard output and input (for WRITE and READ respectively); or avoid Fortran console IO completely and use your own IO procedures that write and read from the console directly.

(How does quickwin intercept WRITE and READ? That might be useful to study.)

The "intercept" is done internally to the run-time library. The Fortran writes are converted to font rendering and bitmap updates of the window. Not something you can hook into.

Ok.

For a normal console program it seems you can sort-of intercept things within your own process. This gross hack prints subsequent lines of console output along alternating sin/cos curves. The runtime's not happy about it though at program termination - I think its caching the stdout handle so I end up closing a handle that its still trying to use. Work-around would be for the interception to be done in a wrapper process.

[It's been too long (not long enough?) since I was doing native Win32 stuff, so apologies for any silliness.]