A-Shell Development History

(ATE) Additional minor adjustments to the ATE protocol to improve the interoperability between mismatched versions of ashell on the server and ATE on the client, particularly as it relates to the auto-update and auto-licensing feature. The goal is to allow you to put the latest version of ashell on the server, along with the latest ATE install package in the atesetup directory, and then be able to connect to it from older clients and perform the auto-update.

949.2.1   ATE

ATE now supports local licensing (tied to the MAC address of one of the Ethernet interfaces on the local machine).

949.2.1   ATE

Minor adjustment to server startup logic to avoid hanging older ATE clients.

949.1.1   GETVER.SBR

Fix bug in GETVER.SBR handling of special program header flags on big-endian systems.

949.1.1   ATE

Minor improvement in auto-update logic over slow connections.

949.0.1   ATE

Implement "node" licensing model for ATE. This model permits licensing of a block of ATE nodes independent of the number of A-Shell licenses. Requires LICENS.LIT 2.2(114)+ and ABOUT.LIT 2.2(104)+.

949.0.2   ATE

A-Shell now automatically attempt to issue license to ATE client on startup if client does not have a license and server either has the ATS/ATE license flags (i.e. is licensed for unlimited ATE clients) or has a "node" license.

949.0.3   STOP command in BASIC

The STOP command in BASIC was sometimes causing a segmentation fault.

949.0.4   ATE

(ATE) XCALL AUI,AUI_ENVIRONMENT,0,FLAGS{,ATEVER$} now returns ATE version if the fourth parameter is specified and the client is ATE.

949.0.5   MIAMEX 112

(Windows) XCALL MIAMEX,MX_AMOUSEXLT (MIAMEX 112) supports three additional opcodes related to disabling/enabling the AutoMouse double-click feature:

 

This is primarily of interest for eliminating the situation in which double-clicking on an empty part of a form sends a CR, which is treated the same as clicking on the currently focused button.

949.0.6   GET.SBR

New parameter added to XCALL GET to facilitate raw input:

xcall GET, buffer {,chan {,bytes'req {,bytes'rcvd {,timeout {,flags}}}}}

Setting flags to a non-zero value activates 'raw' mode input, which eliminates all input processing and filtering (such as function key support, terminal driver input translations, and the ability to input null bytes). Otherwise, null bytes are stripped out of the input stream before your application gets a chance to see them.

Note the following restrictions:

949.0.7   ATE

(ATE) Host-initiated FTP transfers can now be made silent by using direction codes A-D in place of the normal 0-3, i.e.:

 

This applies both to TAB(-10,22) and to the ZTERM-style ESC sequence:

? TAB(-10,22); DIRECTION$; HOSTPATH$;"~"; LOCALPATH$; chr(127);

or

? chr(27); chr(1); chr(127); DIRECTION$; HOSTDIR$; chr(0); HOSTFILE$; chr(0); LOCALPATH$; chr(0);

Note: codes A though D are not ZTERM-compatible, so should only be used when you know the client is ATE. Note that with ATE, the msg/dialog is hardly noticeable (unlike with ZTERM, where it looks just like the standard interactive FTP dialog), so the silent feature isn't that much of an improvement. Still, some people prefer to have their file transfers be invisible to the user.

949.0.8   GETMAC.SBR

(Windows) GETMAC.SBR updated to be more reliable across a wider range of Windows platforms.

949.0.9   SYSTAT.LIT

SYSTAT.LIT 3.0(155) supports a /E switch which displays the client MAC address if known. (In practice, this will only be known when the client is ATE.) This could be useful for distinguishing between clients that share an IP address due to some kind of proxy server, and those that are really from the same PC.

949.0.10   ATE

(ATE) Correct client IP address is now registered on server (as shown in SYSTAT/I), including when using the SSH tunnel and other kinds of proxies.

949.0.11   ATE

(ATE) The standard setup file naming convention has been changed slightly, to eliminate the ATE version number and just use the A-Shell version number, e.g. instead of ate-3.0.170-949.exe, we will now use ate-4.9.949.exe. Although ATE is technically a standalone module of which ASHW32 is just one part, and thus may deserve its own version number, in 99% of the cases, it is being used hand-in-hand with A-Shell and thus the only version number that seems to matter to anyone is the ASHW32 version number. This will also simplify the server-based ATE updating system (see next item).

949.0.12   ATE

(ATE) A server-based auto-updating system is now available for keeping ATE clients updated. As a background, one problem with intelligent clients such as ATE is that they are typically installed independently on multiple clients, thus creating a logistical challenge to keep them updated. Many commercial programs are moving to an Internet-based model for doing this, whereby the client queries the developer's website each time it executes to see if there are any updates, and if so, offers to download and install it.

Although we considered this model, there are two problems which seem to make it less than ideal for our circumstances: A) not all clients have Internet access, or if they do, it may be blocked by their VPN software. B) It may or may not be appropriate for the end-user to update to the latest ATE level. That decision should be left to the dealer to make, and it should be made relative to the software level running on the application server. (In general you want the client version to match the server version, although in some cases it might be desirable to update the client or the server to a higher level than the counterpart.) Since much depends on the level of the software on the application server (both A-Shell and the application itself), and since updating the server is much more difficult to automate (due to the need to coordinate with many users at once), we decided that the best way to manage the client update process is for the dealer or site administrator to place the desired version of ATE in a special place on the server, from which the clients can be updated on an as-needed or as-wanted basis. This eliminates the connectivity issue (since the client must necessarily have connectivity to the application server) and it allows for site-based control of the update process.

Here's how it works:

Step One:  Create a directory atesetup underneath the directory where the miame.ini resides (e.g. /vm/miame/atesetup).

Step Two:  If you want to make an ATE update available to the clients connected to this server, put the ATE setup executable file in that directory. It should be named as follows:

ate-a.b.c{.d{-optional stuff}}.exe

where a,b,c and d are the major, minor, edit and patch levels. Examples:

ate-4.9.949.exe

ate-4.9.949.1.exe

ate-4.9.949.1-madics-1.2.3.4.exe

 

In the last example above, everything after the second dash (-madics...) is ignored.

You can have multiple files in the directory, as it will locate the one with the highest version number.

Step Three:  Optionally, you can also put a message file in the directory, which will be displayed in a message box that presents the user with a YES/NO option of whether to update. The file must be named ate.txt and can contain up to 1024 characters, on one or more lines. For example:

A new version of your client connection software is available, and your dealer, ACME TECHNO, recommends that you update. The process will only take a minute, during which your client window will close and you will be prompted thru the installation program. At the end, you will be able to just launch the connection again. If you have a problem during the update, call us at 800-555-1212. Do you want to proceed?

If you do not supply your own ate.txt file, a generic message will be displayed asking the user if they want to update.

Step Four:  When a new ATE session is launched, the server queries the ATE client to get its version, and then checks the atesetup directory to see if there is an update later than that version. If not, is just proceeds normally. If so, it prompts the user to update, and if the user agrees, it proceeds to FTP the setup file from the server to the client (ATECACHEDIR), close down the client, and launch the setup program.

There are probably a number of refinements that will be needed or desired in this process, so dealers are encouraged to start experimenting with it. A simple way to experiment is to first install the 4.9.949 ATE update, then copy that setup module (or any later one) to the atesetup directory. Even though the version of the server may be the same as on the client, you can fool it by just naming the file accordingly (i.e. call it ate-4.9.949.1.exe even though it is really 4.9.949.0).

The three most likely things that can go wrong are:

We want to implement hooks or standard dialogs or other strategies for helping the users deal with these issues. But in any case, a failed update should be no worse than no update, and thus the user is unlikely to be left worse off than before.