Problem:
A customer had a routine that used libcurses for screen handling. When this was called from Animator, the application crashed out of animator, displaying the command line prompt, locking up the session and leaving a looping "rts32" process.
Resolution:
This is actually a complex area. The libcurses routine does not work correctly if anything else changes the screen (without notifying it). curses works by keeping an internal representation of the screen contents, cursor position, etc. When the program asks curses to change what's on the screen (or, more precisely, when it wants to change anything about the state of the tty), curses computes a hopefully optimal set of control codes (based on the tty description in termcap/terminfo) and display characters and sends that to stdout. If anything else has changed anything about the tty state, curses' internal representation will be wrong, so the commands it sends to the tty will be wrong, so the final result will be wrong. (curses works this way because many types of terminals don't support querying the screen contents, and because it was written for slow devices working over slow links.)
The upshot of this is, if both Animator and the application are trying to use curses or an equivalent (Micro Focus' is called libscreen), neither of them will know what's actually on the screen, and the result will be unpredictable. Another problem is knowing what terminal mode you are in, for example if the libcurses puts the terminal into raw mode, the Micro Focus implementation has no knowledge of this. Similarly, if the application puts the terminal into extended charset mode, libcurses does not know. Even worse is handling signals such as SIGWINCH (does libscreen pass on a SIGWINCH etc..).
Fortunately all this complexity can be ignored - there is a simple (and reasonably elegant) solution. If the customer uses cobanimsrv, and therefore two sessions, the problem disappears immediately.
