Earlier quoted context omitted.
> It's actually terminal software, that's translated into a GUI from a text interface on the fly I am intrigued - you mean terminal output is actually parsed, and a GUI view is then generated from it? E: this would certainly explain the issue of listboxes only having the currently shown items loaded (described by another commenter) - everytime you scroll, the terminal output has to be produced + parsed again
Historically, yes. It was basically like translating an ncurses (semi-GUI command line thing) into a UI. There were attempts to move away from that model, but at least when I worked for SAP, most actual deployments were still text-to-UI. It was basically a way of slapping some varnish on what was fundamentally an old-school mainframe system.
Remember that back in the late 90s SAP had a native GUI that ran on Windows, OS/2 and Unix (Motif-based) and each had their own native controls (a native Windows listbox is implemented differently from a Motif one, for example). Developers would develop a UI in ABAP with platform-independent controls and that UI would be sent over the wire to the client as DIAG and the client would translate that into the native control and data, etc for the end user.