A-Shell/Windows, unlike the A-Shell/UNIX and A-Shell/LINUX, uses the Windows GUI for certain display and user interface operations. For example, system error messages are often presented in a Windows-style message box, rather than as simple text messages. Your programs might even explicitly call for a Windows-style message box using one of the TAB(-10,x) extended TCRT commands. Although these kinds of message boxes are not compatible with the Telnet interface, A-Shell running under ATS will for the most part trap them and convert them to text-based messages. (This is actually done using the INMEMO free-form memo capability, which allows text messages to be presented in pop-up boxes with text-oriented "buttons" which can be selected with the arrow and ENTER keys.)
For the most part this is self explanatory and works fine. But there are some Windows-specific user interface functions which cannot be translated to Telnet-compatible text. If your program attempts to perform some Windows-specific function which works exclusively through the Windows GUI interface rather than simply outputting characters to the "terminal", then the GUI operation will take place relative to the server’s GUI, not the client’s. (That’s because in a Telnet connection, the process is actually running on the server, not the client.) The A-Shell/Windows sessions running on the server are running in invisible mode though, so such GUI operations will not appear anywhere. Which is OK, except when the operation requires input. In that case, the session will simply appear to hang from the client’s perspective. (See the section below on printing for a specific example of this.)
The moral is that if you are going to accept ATS Telnet connections, you may need to review your programming architecture to make sure you are not doing anything which explicitly uses Windows GUI extensions. Or, use ATE (see next topic).
