Current abilities in AccuTerm

Hi Tony -

1) AccuTerm is in the MV product group at Rocket. At this time I think its pretty much MV oriented. That said, I do use AccuTerm when working with Linux, and when it gets annoying, I try to look for ways to make it easier. I think the last update that really make it friendlier with Linux is programmer mode for screen size, where the terminal size scales to the window size, and the server is notified when the window is resized. This works nicely with bash, vi, and even jBASE jed.

2) Nothing at the moment for porting FTBP to other languages. 

3) Easy to use AccuTerm escape sequences from other environments but I don't know of any other language versions. Decades ago there were some Unix apps that were using AccuTerm and its private escape sequences, but don't think any of their work was public.

4) No, we went the other way. With AccuTerm Web, we include a VBA interpreter (written in Javascript) so that VBA scripts will run compatibly in web and desktop versions, to the extent that it is possible.

5) We periodically update the crypto algorithms in AccuTerm. Latest version of AccuTerm 8.1.1.1136 supports elliptic curve keys for host keys and user keys, AES-GCM cipher, SHA256, 384 & 512 for signatures, even Kerberos for SSO to Linux using AD.

6)  Native color settings would be nice. Maybe someday... A lot of Linux commands seem to have ANSI colors hard-coded, I guess expecting xterm as the client.

7) ATGUI-JS ? AccuTerm Web include GUI, same app on the server, rendered using Javascript on the client. Tmux? not really, but session resilience is included. Has a little similarity to tmux/screen in that a server side component sits between the MV (or any application) and the SSH server.

Hope that helps.

Thanks, Pete

Sincere thanks to ya, bud. I appreciate the consideration on every point.

Our MV colleagues used to differentiate MV from other platforms by citing the power of the command line. There was a time when MV took criticism for the "DOS-like" CLI compared to "modern GUI". Over time that shifted with DevOps and developer appreciation for Linux and the burden of GUI, and now the CLI is dominant. But there is still a very limited selection of quality terminal emulators.

Even without any server-side OS-level macro integration, AccuTerm remains (IMO) a superior TE for the OS CLI. You can honestly claim decades of ongoing support where most of the existing and still maintained offerings can't claim nearly as much longevity. AT has always been an under-appreciated gem - the industry's best kept secret. And it's unfortunate that in a time where profitability drives so many decisions, Zumasys and Rocket haven't seen its potential as a revenue opportunity for a mainstream audience - and as a Marketing gateway/ambassador to MV.

That said, unless the company decides to FOSS AccuTerm it looks like I will need to wean myself off of it in the next year. :(  The price tag has always been acceptable in the MV industry but these days comparable offerings at half the price are considered expensive. The cost for specialty features can't be justified to a broader audience where the features aren't relevant. BUT, if the features are adapted to that audience the entire game changes.

Rather than FTBP in the MV server component, consider the exact same functionality implemented in JavaScript. FTBP (FTSERVER and friends) is fine-tuned to output escape sequences and input results. Strip out MV-specific nuances and run the BASIC code through ChatGPT, and a really good JS codebase can be extracted to run over NodeJS. (For better BASIC processing use the OpenAI API.)

Where AccuTerm provides DBMS integration, replace it with OS integration : You have already built-in client-side file selection. Only the server side needs to change to open folders and save files, rather than opening MV files and saving items.

The Sax VBScript doesn't actually need to change in the client side, but the audience for that single option will be limited. Given that NodeJS  is quite often already installed in developer workstations, you don't need to rely on hosting all of that scripting functionality in AccuTerm itself (in the form of DLLs). JS scripts in AT can run in NodeJS, invoking AccuTerm-specific components for custom functionality. I haven't tried it but I'm sure the existing VBScript can be used as middleware, to capture character sequences output from the server, and then execute client-side scripts. For example, in my OP I provided this : CHAR(27):CHAR(2):'>notepad.exe':CHAR(13):CHAR(27):CHAR(2):'I' ... just replace ">notepad.exe" with ">node \\path\\to\\foo.js". Communications with client-side integrations can be handled with sockets or file-level exchanges.

Replace the launcher for wED with a launch for VSCode, which has its own SSH Remote functionality, very familiar to most devs who do this kind of work.

As you see, this isn't a big stretch at all. (Yeah, a big deal in the big picture, but not technically much of a challenge.)

What does AccuTerm bring to the table to non-MV users? It's a stable Windows application that already supports multiple windows, custom connection configurations (.atlp and .atsp), Windows integrations, fine-tuning of the communications, telnet, client-side printing, fonts, images, color-tuning, keyboard programability, customizable menus, and so much more. To my knowledge, bi-directional scripting integrations that MV devs depend on aren't even a thing outside of this space. That is, non-MV developers don't expect to execute a server-side operation that does something on their client, whether launching another program or sending or retrieving data. That includes opening X windows/applications. Of course the uninitiated could consider that to be a bug and not a feature, but we harness and enjoy the benefits.

Those are features that business users would pay for. I dunno if Rocket management is aware of these possibilities.

I'm still in Mission Viejo if you want to meet up for coffee sometime to discuss. :)

Crawling back under my rock...
T