APL*PLUS II Release 3

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 73

This is an account of the experiences of me and my colleagues in moving from APL*Plus Version 2 to Version 3. They are unlikely to be everyone’s but they will give a flavour to those contemplating the move.

The main differences between versions 2 and 3 are as follows.

• Location of the session manager in memory
• ⎕NA enhancements
• Support workspaces
• Mouse support
• User command processor

These are all of benefit to a greater or lesser extent. However the garden is not all roses. I will cover the advantages offered by these five things and then go on to share some of the troubles that we have had with the move.

Session Manager¶

In version 2 there are two components to the Plus II system. There is a standard DOS program which handles the APL session and editing ring and an interpreter which uses the Pharlap DOS Extender to run in 80386 32-bit protected mode.

So we have:

The majority of PC programs are for normal DOS and have to fight with each other for their share of the 640k available. No matter what you do to the machine, if you use DOS then 640k is all you get for these programs so memory here is valuable to anyone who wants to have more than one program resident in memory at the same time. For corporate users one of the main uses for this type of program is communication over a network or terminal emulation for the mainframe. These can take over 100k away from you. With the standard configuration of 80k of session manager APL takes over 300k of extra memory.

Above the 640k line, memory is not a considerable problem. At about £50/meg the cost of circumventing WS FULL is not astronomical, so the more that can be placed up here the better.

In version 3 the session manager is bundled with the interpreter as one .exe file and is loaded into high memory. This still leaves 230k of the DOS Extender program in the first 640k but the additional 80k or so (depending on your configuration) that you have is worthwhile.

Quad-NA¶

The improvements to ⎕NA are twofold. For programs written in Metaware High C to run in protected mode, there is the facility to pass as arguments to an associated function nested arrays. The interpretation of the content of the nested array is the problem of the C program, or, more to the point, the C programmer and to aid this a text file is provided explaining the structure in the workspace of a nested array. Fine! This is in stark contrast to Dyalog APL which comes with a library of C functions to aid the conversion of data between APL arrays and other more normal formats. The APL*Plus II for UNIX interpreter is provided with such a library. Let’s hope that STSC get round to providing it for the humble PC users.

Unfortunately if you want your C program to talk to anything else on your machine you are stuck with Microsoft or Borland and have to work in real mode. This is where the extra 80k from the session manager becomes very handy. What STSC have done here is to allow the use of programs compiled for the Large memory model. A C program has two parts, the data and the code. Each part can occupy one or more segment (64k chunk) of memory. Then depending on how many are used by either part we have four possible combinations:

The documentation for version 3 says that all four memory models are supported. The truth of this depends entirely on one’s interpretation of support. I found that identical source compiled for the small or compact models worked fine but for the medium or large models it did not. It turned out that in order to use programs with more than one code segment I needed to change a word in an assembler source file (msc51stk.asm) and re-assemble it. Luckily I was using Microsoft Quick C and had an assembler bundled with my compiler, so I am now able to use my large model programs without problems. I am grateful to Cocking and Drury and STSC for pointing out what I needed to do, but I believe that it should not have been necessary.

Support Workspaces¶

Here is a really useful enhancement to the APL*Plus II product. They have taken the workspaces from Library 11 on the mainframe and provided them free with the interpreter (with APL*Plus/PC you have to buy them as APL*Plus/PC Tools). For me the significant facilities provided are in the area of workspace maintenance. The workspace WSDOC and those associated provide an extremely comprehensive documentation of a user’s own workspace with complete cross reference. This includes for each identifier used a list of all references (indicating for variables any assignments). This, together with trees and tables for each function of all its global objects, is all that you could desire to help you when you pick the short straw and have to wade into someone else’s code to try to find where the global TMPDATA is being mysteriously changed. There is also a workspace WSCOMP which does a very intelligent comparison of two workspaces. There are other workspaces which I have not had time to investigate but for me these two alone make the change worthwhile.

Mouse Support¶

After about three years STSC have worked out what those funny things attached by string to the back of the computer are for. So they have provided "mouse support". In the session, the mouse block (cursor?) can be used to move the real cursor, to move between sessions, to operate the top menu, to scroll the session, to tag blocks and to open new sessions for identifiers clicked on. This makes the session considerably easier to use and is all very sensibly managed.

My concern is in the area of the programming interface. As explained in Ray Cannon’s article on mouse control there are a number of ways in which you can control, via DOS interrupts (⎕INT), the behaviour of the mouse. The ⎕MOUSE function gives but a small subset of these allowing the setting and reading of the mouse position, the setting of the behaviour of the mouse with respect to the cursor and a few related things. There is not the facility to place bounds on the movement of the mouse or to track user drag events which as a programmer I need if I am going to provide all but the most rudimentary support. My advice is leave it out or use the ⎕INT through your own functions. I hope they do better when it comes to windows.

User Command Processor¶

This is a facility available on the mainframe for some time and in release 10 of APL*Plus/PC that lets you write your own system commands, available wherever you are with no messy functions to clear up afterwards. It basically puts the functions on a file and provides access to that file via commands of the form ]COMMAND. It gets the functions required, executes them then erases them afterwards. It’s a pity they didn’t think to get it to untie the file as well, but never mind.

I think that this is a lot of fun. My manager thinks that what I get paid for is doing REAL work. Ay, there’s the rub. If you sit down and submerge yourself in it for a few days, or a week then you can start to be able to provide some really useful programming tools, but don’t expect anything before that. Even if you don’t write your own user commands there are some useful ones on the demonstration file, like a FNS with wildcards, a WSLOC and a function to find the free space on a disc. Some of the utilities used to do these things can be pulled off the file and are genuinely useful in their own right. I have taken all my small workspace management utilities and converted them to user commands and I now have immediate access to them without needing to remember which library I put them on this week.

I suppose when it comes down to it you either love it or think it’s a waste of time. I love it but I can see why some might not.

Summary¶

So after all that we have to weigh up the pros and cons and decide whether it’s worth the extra money. For me it undoubtedly is. The facilities provided by the new workspaces et al together with the extra room below the 640k line are a great boon. It seems a shame though that they didn’t finish the job. The limited nature of the mouse support and the trouble with ⎕NA, together with problems that we have had getting the DOS PRINT program to work make me feel that their minds were somewhere else when this one slipped through the door.