Taking the *Migraine* out of *Migration*

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

This paper was presented at the APL2000 Users’ Conference, Orlando, Nov. 1999

Interesting Times¶

"May you live in Interesting Times" – goes the old Chinese curse. Well, Interesting Times are finally here. With Y2K issues hopefully safely over, but between the Redmond-mandated disappearance of DOS and 16-bit Windows, to the disappearance of numerous European currencies to give way to the Euro, life could not be more interesting. Our customers have quite a bit to do. With the introduction of Windows NT a few years ago, our customers somehow can’t help but migrate – not an unreasonable decision in the face of remaining current. Nevertheless, one of the things which simply does not work reliably under Windows NT is APL+DOS, previously known as APL*Plus II/386.

And for good reason. The world has changed considerably from those heady days in the late 1980s when the Intel 386 processor and APL*Plus/II ware first unleashed. From the point of view of an APL programmer, finally, here was a platform which could realistically handle mainframe-sized applications which would run at reasonable, or compared to VSAPL on an overloaded VM machine, excellent speed. Nonetheless, with the astronomical growth of Windows usage, APL applications could only survive as Windows applications, thus APL*Plus/III, forerunner to APL+Win, was born. Among other things, the mechanics of managing large amounts of memory, amounts well over the long-forgotten 640K barrier, were different and not entirely compatible between Windows and DOS applications. Windows took over control of all peripherals, everything from the mouse to the printer. Where previously these sorts of things were handled in applications, Windows now usurped this responsibility. The fact that some DOS applications worked in Windows at all was a minor miracle.

DOS, Windows 3.1, and everything in between were 16-bit operating systems. Windows NT is largely a 32-bit operating system. Windows 95 and Windows 98 are in fact bridges between the 16- and 32-bit worlds, containing a compromised mix of features, designed to facilitate the incremental migration of your applications from one world to the other. As for DOS emulation, Windows 98 contains enough vestiges of DOS and the 16-bit world for APL+DOS to run reliably. Windows NT does not.

Welcome to Windows¶

Windows requires numerous changes to your applications. First, there are the Windows themselves – volumes on GUI design and programming are the things that line bookstore shelves. The Windows GUI offers an incredible choice of controls and various gadgets and incredible flexibility for the finished product. Not surprisingly, compared to the old way of doing things, it requires considerable programming effort. With ODBC, a completely new perspective on how and where to put your application’s data is available. Coupled with the SQL database of choice, your data is no longer subject to entombment in APL component files – in an SQL database, it is available for other applications to use. No longer is application data stuck in something some people might call "proprietary". Finally, the mechanics of true Windows printing are rather different, in fact, an application developer might opt to have another product handle complex printing tasks. With Windows, connectivity between different products allows your APL applications to be true team players with respect to everything else running on the computer.

When you look at different APL systems and the way they evolve with time, you seldom see language features taken away. As Windows is conceptually superior to DOS, it was not surprising that many DOS-specific features of APL+DOS had been removed. Some of the things, like the ⎕G suite of graphics functions, were easily and readily rewritten with Windows. Other things, such as the ⎕WIN suite of functions, are somewhat more difficult to replace, the ideal solution being to rewrite the application in Windows. We considered the lack of a ⎕WIN replacement to be the only real obstacle in migrating APL+DOS applications to APL+Win when it needed to be done expediently. Other changes, such as the removal of ⎕ARBIN as a facility to do printing, were minor, and often required a small amount of rethinking. One application used Hewlett-Packard-specific escape sequences to change printer fonts – this was easily changed with simple Windows programming.

DOS-style APL applications brought with them a style of full screen input which was implemented with the ⎕WIN suite of functions: these included the functions ⎕WGET and ⎕WPUT for reading and writing text and attributes to the screen, ⎕INKEY for accepting characters, and ⎕WIN and ⎕ED for full featured data display and entry. This DOS style of full screen input and the suite of system functions themselves have been rendered obsolete by Windows. Consequently, they have not been included in any version of APL+Win. Clearly, the Right Thing to do is to rewrite any application making heavy use of obsolete language features.

There are many times when the Right Thing just is not possible to do. Either rewriting the application in question is not economically feasible or justifiable, as the plan is for it to disappear soon. Or maybe it’s just too hard to do in a short time. Or maybe there’s not the time to do it now, with the Euro just around the corner. But whatever the reason, the application must run under Windows NT, and soon! For whatever excuse, our solution was to implement a usable subset of the ⎕WIN suite of functions for APL+Win, collectively known as Qwin.

Our philosophy is, where applicable, to try to accomplish the migration incrementally. Do the work a piece at a time, such that if anything goes wrong, you are only one step away from something that worked. Our feeling is that all systems migrated with the aid of Qwin should eventually be rewritten to use a proper GUI interface. Good GUI design and programming is a lot of work and could easily be the single most difficult item on the migration agenda. Qwin was designed to help you get your application working now, giving you the freedom to concentrate on the GUI later.

Finally, a good migration will guarantee the success and staying power of your application. Your application contains a lot of knowledge, collected over time. When you migrate your application from APL+DOS to APL+Win, you have at your disposal a large number of new facilities that can add incredible value to your application. On the surface, there is the GUI of Windows, but don’t forget about ODBC, Open Database Connectivity, or TCP/IP, providing access to services on your network or over the Internet continents away. Products like Microsoft Excel and Word can assist in document preparation and data import and export. Your APL application can re-emerge in Windows NT and look and feel exactly like a Windows application should. The heart of the application, the valuable application knowledge, the code which comes up with the right answer, could remain relatively undisturbed.

Qwin replaces some missing functions¶

Looking at the APL interpreter when migrating from APL+DOS to APL+Win, the core features of the language have hardly changed. With the exception of support for long file names, the ⎕F file functions are fundamentally unchanged. Files written with APL+Win can be read with APL+DOS, providing backwards compatibility that offers some interesting options for running your application in parallel during its migration. Native file support is the same. Event handling is unchanged. )EVLEVEL, the evolution level, is set higher by default, but that too can be set lower if needed.

However, several groups of functions are conspicuously missing. First and foremost are the suite of functions to do the DOS style of full screen input, such as ⎕WIN, ⎕WGET, ⎕WPUT, and so on. Included in this group are the functions to do keyboard input, ⎕INKEY and ⎕INBUF. The functions to allow graphics are gone but do not pose a significant barrier to migration since their functionality is relatively easily duplicated with the native Windows GUI.

Some functions are there but need extra attention – ⎕CALL has been carried over from APL+DOS to APL+Win, but its argument – the representation of a compiled program – will have to be changed as the original program will have to be recompiled for the new environment. Many utility functions which use ⎕CALL have 100% APL replacements. ⎕CALLs are accompanied by ⎕STPTR, a clear indication of a system dependency.

For our migration work, the lack of the ⎕WIN suite of DOS full screen function was the largest single obstacle to getting APL+DOS applications over to Windows NT, where they would be safe for at least the next few years. Our workload was far too much to even consider rewriting the applications in Windows, and the customer’s priorities were more oriented toward instant ODBC connectivity. The solution was clear – although the ideal thing would be to rewrite the application with Windows, the lack of time and funding dictated the regressive yet practical approach of emulating ⎕WIN in APL+Win.

False Starts¶

When we first started development of Qwin, we were of the opinion that we had to use a lower-level language to do the job, on the account of execution speed. We knew enough Windows programming to design a form, execute a callback, and so on, but little else. The first goal was to implement the ⎕WGET, ⎕WPUT and ⎕INKEY functions, that is, be able to do rudimentary screen painting and keyboard input.

The first attempt was with the Microsoft Visual Basic language. We found the environment friendly enough, but in the end, cumbersome, as VB was designed to insulate the developer from details of Windows programming to speed application development.

Our second attempt was with Microsoft Visual C++, where the goal was to produce a custom control (.OCX) which was to be integrated with an APL+Win Form object. In the end, we had a working .OCX control, however a few things became very clear. Firstly, development in this environment was painfully expensive. In the end, we had a facility to paint a screen and accept keyboard input, but to add any complex functionality, such as ⎕WIN, ⎕ED, or ⎕EDIT was going to be much too expensive and would take too long with this approach. The productivity we had come to expect with using APL all those years just wasn’t there, even with an extremely experienced and competent developer doing all of the C++ work. Secondly, and perhaps more importantly, the isolation of the .OCX control from the APL environment was technically inappropriate. For QINKEY, the emulation of ⎕INKEY, the control returned key scan codes but required a high level of interaction, i.e. a large number of repetitive calls, to accomplish this. To be able to support a facility like ⎕MOUSE would require even more close interaction. A KeyPress or a MouseClick event needed to be handled somewhere locally in the APL environment, not in a distant .OCX control, only to be passed back to APL to be dealt with. In short, all of this really needed to be happening much closer to the action in the APL workspace.

In the end, we chose to stick with a 100% APL solution. One problem which popped up at a customer’s site was that installing and registering the .OCX control required more privilege than the user had. A needless complication was the requirement of configuring and using installation software such as InstallShield for what amounted to a small component. It was clear that fewer disparate moving parts would be better.

During a talk in the summer of 1999, Eric Baelen, president of APL2000, demonstrated the APL+Man game, an example of where APL+Win is convincingly used in a real time context with excellent all-around performance. Qwin is very much a real time programming exercise. Best of all, with APL, Qwin is easy to extend and maintain, as we do not rely on third party support of non-APL software.

The Window¶

Just how hard can it be to write a function that displays a 24 by 80 window of characters? First of all, it’s a 25 by 80 window or a 50 by 80 window, depending on the video mode used in DOS. Secondly, it’s only part of the problem – keyboard input has to be done as well. Third, absence of little details such as a blinking cursor, render the emulation unusable. A little knowledge is a little dangerous, but fortunately for us, we had no real knowledge of grass roots Windows programming whatsoever.

The Qwin main window is a program not entirely unlike the APL+Win function editor. With syntax colouring, different items in your APL programs are displayed in different colours depending on the type of token the text represents. Turning insert mode on or off changes the style of the blinking cursor. Not to be taken for granted, these features are implemented by programs working behind the scenes of the APL+Win function editor.

As our Windows programming experience was limited to dialog boxes and the like, our first idea was to utilise the existing Windows controls, such as Edit and RichEdit, to handle the application display area. The Qwin window would contain a single edit field which occupied the entire window. This couldn’t work for several reasons. First, neither the Edit nor the RichEdit controls allowed you to arbitrarily change both the foreground and background colours of the text displayed. With a RichEdit control, you could change the foreground, but not the background, colours of the text. With an ordinary Edit control, you could not vary the colours at all. The blinking cursor was inflexible to the extent that only one shape was available, a vertical bar, and it could not be made to disappear. Any edit control had simple program logic behind it, which was to accept a keystroke and insert it wherever the cursor was, which could be at the end of the last character in the field. Although you could alter this somewhat with ⎕WRES, for use with Qwin, character entry and display are best completely divorced from each other.

In the end, the Qwin main window is a featureless window with no controls at all. Text is written, or more accurately, painted, a line at a time, with complete, explicit control of the foreground and background colours. The Windows font used with Qwin is the same as the Windows font supplied with APL+DOS, with a few minor modifications. This is a bitmapped font where all characters are exactly the same width – this means that characters can be drawn a "strip" at a time. This also means that the APL code to repaint a screen is fairly simple and efficient. The APL+Win system also supplied a bitmapped font which is typically used for the session manager and the editor – it is usable except that it is missing many of the line drawing characters!

Ordinary character input is accomplished collecting keystrokes in a buffer, then using them when needed. The Qwin main window invokes a callback for every keystroke. These are in turn mapped into the familiar numeric codes returned by ⎕INKEY and placed into a buffer, or discarded if invalid. When the next character is needed, the first character is removed from the buffer. When a character is needed but the buffer is empty, the ⎕INKEY emulation loops, with the help of a generous ⎕WGIVE, until a character appears in the buffer. Qwin translate tables were reconstructed from the documentation available from APL+DOS. Although a few differences exist between the APL+DOS and Qwin keyboards owing to various differences in low level keyboard handling in DOS, Windows NT, and APL+Win, the Qwin keyboard is a faithful reproduction of the APL+DOS keyboard.

Other details, such as cursor handling, are accomplished with ⎕WCALLs to Win32 API functions. The cursor, known as a caret in Windows parlance, is called into existence when the Qwin window is active, moved as characters are typed, and is wiped out when the Qwin window is inactive. When Qwin is first invoked, the Caps Lock and Num Lock keyboard states are checked by calling the appropriate API functions. These things are not supported in the various ⎕WI properties, and since this type of programming is probably so far away from the mainstream of Windows programming in APL+Win, language developers have not included these sorts of features.

On the surface, the Qwin main window would appear to be a modal dialog box, meaning one which causes all application activity to cease until the input in the dialog box is complete, at which time it goes away. The problem is that the Qwin main window cannot go away until the entire application is finished. The dialog box you see when you finish editing a function reminding you that the text of the function has changed and asking if you want to save the changes is a canonical example of a modal dialog box.

With details of screen painting and keyboard entry out of the way, the remainder of the functions are the most difficult ones, namely ⎕WIN and ⎕ED. ⎕WIN is the backbone of many complex screen entry programs, it provides the ability to break up a screen into separate fields, validate input, change the colour of a field depending on whether it is active, and so on. ⎕ED allows you to browse a character matrix in your application, or even have a custom editor session going, possibly integrated with other fields entered by ⎕WIN. Further, utility functions such as the screen design workspaces supplied by Zark Incorporated and delivered with the APL+DOS system combined the functionality of ⎕WIN and others functions to provide APL application programmers a truly comprehensive set of building blocks which are difficult to replicate with native Windows features. ⎕WIN and ⎕ED display their fields and take care of, keystroke by keystroke, entry into fields, moves between fields, and the return codes upon exit of the respective function.

Migraine-free Migration Strategy¶

Our APL application migration strategy, used with many different combinations of APL systems, is:

• Where it makes sense, start making changes in the old environment, as soon as possible.
• Do as little as possible to make the application work exactly as before in the new environment.
• Add new features, one by one, to the application in the new environment, taking care to make sure one task is finished before starting another.

When migrating from APL+DOS to APL+Win, many of the old problems related to moving the APL code, variables, and data from the old environment to the new environment simply disappear. Workspaces from APL+DOS can be freely )LOADed, plus the component file system is identical, to the extent that file system data written with the newer APL+Win can be read with the older APL+DOS. This feature makes it much easier to run your application in parallel.

In a more traditional migration, such as from a mainframe APL2 system to APL+Win, you still have the problem of physically moving the code and data from one place to the other. Once you have the code over, there are countless language differences which need to be detected, isolated, and solved. Some facilities exist for doing some of these jobs and are usually easy to use, but nothing beats the ease of movement from APL+DOS to APL+Win.

Back to the strategy – when you know that certain conditions will exist in the destination APL system, you can start making changes as early as possible to accommodate them. If you know that eventually your system will read its data from an SQL database, and that APL variables in the workspaces will correspond to SQL field names, but that a few of these variables are SQL reserved words (such as SELECT, INT, UPDATE, FLOAT, and so on), change them now. If you are moving an APL2 (or VSAPL) workspace which uses the system function ⎕EA, and nearly all uses are of the trivial case, typically used to supply a default value to the left argument of a dyadic function when used monadically, change it now. With APL+DOS, maybe now is the time to change your code so that it operates with the highest, rather than the lowest, evolution level in APL+Win. At this stage, you are probably more familiar to the old environment than the new and making changes would be less risky. The point of this is to increase productivity and reduce overall migration stress by carefully spreading the activities over time.

When you run into a non-portable feature, it usually is best to code a cover function to provide duplicate functionality in the destination system, at least initially. Cover functions have the following design advantages:

• You can make mechanical replacements in the destination system
• You can use it over and over again
• All of the knowledge is contained in one function
• It is easy to prove it correct
• It is easy to fix
• Changes to the cover function are not intrusive with respect to the rest of the application

The only design disadvantage to using cover functions in this manner is that they may be slightly slower than a more direct solution. Our Qwin product is built on the design principle that it should be possible to )COPY the Qwin functions into your workspace, make the appropriate mechanical replacements, make a few changes, and be pretty close to finished.

Once the application, in its preliminary form, has been moved to the new environment, the only thing to think about and do is to get it to work. Now is not the time to add GUI features or ODBC support. Instead, the application should be tested thoroughly to uncover whatever surprises may be lurking. If circumstances permit, the application should even be put into production. This is also not to say that you should work slowly, just that you should focus only on one problem at a time before moving on to the next one.

One of the pleasant surprises which awaits you in the new environment is a significant increase of the available workspace – ⎕WA. Back in the early days of the 386, it was not uncommon to have just 4 or 8 megabytes of memory in your computer, leaving you with a corresponding number of megabytes of workspace. That seemed like a lot, especially when you just moved your application from APL+PC or even some of the timesharing services. Later, when Windows arrived on the scene, 16 megabytes was not an unreasonable amount of memory to have. Today, for Windows NT, 64 megabytes is the lower boundary for an acceptable amount of memory for a typical NT computer. As for your application, the added memory can make your programming job easier and more productive. Your application will run faster. Be sure to use it.

Our migration toolkit consists of a search and replace facility which goes through all of the functions in a workspace, and a collection of Q... functions we’ve written over the years to emulate many different functions from many different systems. Good migration productivity has amounted to:

• Understanding as much as possible as early as possible about the differences between the two systems
• Having the tools to isolate calls usage of certain primitives or code fragments and to replace them with calls to functions
• Having those replacement functions on hand

Since Qwin functions directly replace ⎕-functions, converting applications is fairly straightforward. We supply a migration function with the Qwin functions. There are, however, a few differences which may have to be dealt with on a case-by-case basis. As the majority of our applications we had experience with used the Zark-supplied screen functions, our primary emphasis was to insure that the utilities worked correctly. Also, the SITDEMO workspace supplied by Zark offers a convenient migration demonstration.

To modify your application to use Qwin, you have to:

• Run the supplied conversion program to make all Qwin-related replacements
• Insert code in the application to start and stop Qwin
• Test the application
• Check for and deal with known problems and special cases, such as setting ⎕MOUSE to iota 0, hard-coded ⎕AV references to line drawing characters, and so on.
• Test some more

Qwin supplies replacements for the following system functions:

Qwin respects the settings of the following variables:

Using Qwin¶

As Qwin runs in a separate execution window, it must be initialised at the time the application is started and cleared at the time the application is exited. This is accomplished with the QWININIT and QWINCLOSE functions. These would be typically placed in the function started by ⎕LX. For developing and maintaining these Qwin applications, life is made much more agreeable by the fact that the APL session window is separate from the Qwin execution window. Any errors are visible and not artistically fused into the application display.

Qwin does not add any additional global variables to application execution other than variables which were system variables in APL+DOS. All Qwin variables are neatly tucked away inside Qwin as user-defined properties and will not interfere with variables inside of your workspaces or applications.

An important difference of Qwin versus APL+DOS is that the display screen is refreshed for display only at the time it is actually needed, with is usually immediately before a QINKEY. In application programs, screens may be built up by successive calls to QWPUT. As a performance measure, no actual screen output takes place during a QWPUT. This technique fails, for example, when a message is to be displayed with QWPUT for a short duration then removed. The solution is to use QDL, which first forces a refresh of the screen, then behaves like an ordinary ⎕DL. Users of IBM’s GDDM and numerous AP124 versions should remember similar behaviour where by default, the screen would be refreshed immediately prior to character input. Only by executing an FSFRCE command in GDDM, or using an immediate write in AP124, would you get the desired effect of seeing everything on the screen prior to any input.

A second important difference is that system variables such as ⎕CURSOR and ⎕WINDOW in APL+DOS are ordinary variables named QCURSOR and QWINDOW in Qwin. True system variables are subject to passthrough localisation whereby values in a function which localises these names are inherited from the function which called it. Ordinary variables are not subject to passthrough localisation and have no value unless assigned. Qwin attempts to duplicate passthrough localisation for its key variables by assigning the last values it has seen if it encounters what would have otherwise been a VALUE ERROR. If a function reassigns one of the key Qwin variables, then immediately calls a function with the key Qwin variables localised, those latest values will not be propagated to the called function. Again, the solution is to use QDL 0, which has the beneficial side effect of refreshing cached variables for emulating passthrough localisation.

Replacements for ⎕PEEK and ⎕POKE are supplied with Qwin. Strictly speaking, you will be able to QPEEK and QPOKE into a 1000 element integer vector but relatively few of these locations have any meaning or effect. Reading and writing into the workspace, i.e. QPEEK and QPOKE with QSEG set to something other than iota zero has no effect.

Incidentally, the ⎕INKEY function exists in APL+Win. This ⎕INKEY, however, is separate from the QINKEY supplied in the Qwin package.

Using Windows 95 and Windows 98¶

Qwin was developed with only one goal in mind – to facilitate emergency migration of legacy APL+DOS application to APL+Win under Windows NT. Windows 95 and Windows 98 both run APL+DOS reliably, thus we consider them a stepping stone to a proper migration to Windows NT. There is considerable appeal and practical migration value, however, in having APL+DOS and APL+Win applications running side-by-side on the same computer. Our priority is to concentrate on Windows NT first, and Windows 95 and Windows 98 second.

The reality of the situation is that although all of the 32-bit Windows platforms share a common application programming interface, they have subtle differences. The application programming interface is the library of Windows programs available to APL programmers using the ⎕WCALL system function. Workarounds exist for many differences, but incorporating them may compromise the quality of the Qwin product. Known differences include:

• Cursor keys repeat in 95 and 98 but not in NT
• Differences in KeyUp and KeyDown
• Different Shift+Ctrl+Alt combinations with Caps Lock will set the Shift Lock state differently
• In NT, ⎕CMD operates synchronously, i.e. ⎕CMD waits until the other program is done; under 95 and 98, ⎕CMD returns immediately
• QSOUND does not work

Our tactic with Windows 95 and 98 is to concentrate on Windows NT, while attempting to maintain as much functionality as is practical to include in Windows 95 and Windows 98.

On to Printing¶

One other major topic of migrating to APL+Win is the issue of how to do printing. In APL+DOS, the technique was usually something like this:

• Prepare text to be printed as a character matrix
• Add titles, headings, page numbering, etc.
• Add a carriage return and line feed to every line
• Write this text to a DOS file and issue PRINT command, or write directly to LPT, or use 3 ⎕ARBIN

Qwin includes a QARBIN function which emulates some of the features of ⎕ARBIN. A replacement for 3 ⎕ARBIN is provided, and can send text containing device-specific codes (such as PostScript or HPCL) to your default Windows printer without interference from whatever printer driver you may have installed.

Due to the wide variety of styles of printing, this problem does not easily lend itself to mechanical solutions. To use Windows facilities, APL code which does printing will have to be examined and replaced manually. If you can modify your application while you’re still in the old system to use a small number of print utilities for printing a page of output at a time, then this becomes much less of a problem in the new environment. Windows printing is page oriented. If your application already prints pages of text through a cover function in APL+DOS, then your task is to write a replacement printing function in APL+Win. If it doesn’t but can, the time to do this is now.

Strictly speaking, you can still write your text to be printed to a file then print it with the PRINT command, or write the text directly to LPT with ⎕NAPPEND. However, you lose the ability to route your printout to the Windows printer as it is set in the Windows Control Panel. Also, on some networks, it will take some work to have the network software "capture" whatever is being sent to LPT1 and to redirect it to wherever it is supposed to go. Lastly, a ⎕ARBIN function is supplied with APL+Win, but has few of the features of the ⎕ARBIN function from APL+DOS.

If you have printing which requires use of device-dependent codes to change fonts, switch to bold, change sizes, and so on, you should consider farming out your printing to Microsoft Excel and Microsoft Word. With the advent of APL+Win Version 3.5 and ActiveX, it is possible to have either of these products silently do your printing for you. Microsoft Excel is extremely well suited to doing tabular-style reports, and best of all, you have the option of delivering machine-readable output to your users instead of or in addition to paper hardcopy. Microsoft Word is suited to letter writing, where you have letters which consists of blocks of text where your application "fills in the blanks".

Don’t Bother¶

Certain features of APL+DOS and other APL systems do not lend themselves well to emulation. In APL+DOS, you can write directly into the workspace – ⎕PEEK and ⎕POKE with ⎕SEG set to something other than iota 0 immediately come to mind, where you directly peek and poke into you computer’s memory. Another DOS casualty is the ⎕CALL function where an integer representation of a compiled routine is supplied as its argument. True, ⎕CALL does exist in the new environment, however the compiled routine must be recompiled and rebuilt to work. Unless execution speed is critical, these might be best to replace with a straight APL solution. ⎕NA exists in a variety of systems, but they are all different.

Conclusion¶

When migrating APL+DOS applications to APL+Win, things should go pretty smoothly as the core language is very compatible. Peripheral features of APL+DOS will be different or not present in APL+Win, features such as DOS-style windowing, printing, and interfaces to low-level facilities. In our migration work, we have isolated the ⎕WIN suite of functions as a realistic chunk of APL+DOS which could be duplicated in APL+Win. Qwin enabled us to move quite a few applications to Windows NT which could have otherwise been discontinued, abandoned, replaced, rewritten, or would have caused problems for customers who otherwise had no plans to maintain DOS, Windows 3.1 or Windows 95/98 workstations on their Windows NT networks. Other missing language features or different migration items are smaller in scope and often don’t lend themselves to mechanical replacement – these you have to develop. Finally, once your application is working in Windows, a wide range of services is available to you, the application developer, which will enhance your productivity and improve the perceived quality of the application.

And remember, Qwin, as described here, is experimental in this version of APL+Win; it may be changed, replaced, or removed in future versions.

References¶

1. Richard J. Busman, Walter G. Fil, and Andrei V. Kondrashev, Recycling APL Code into Client/Server Applications, APL95 Conference Proceedings, APL Quote-Quad, Volume 25, No. 3, 1995
2. Gary A. Bergquist, The Zark Library of Utility Functions, APL99 Conference Proceedings, APL Quote-Quad, Volume 29, No. 2, 1999
3. APL*PLUS II/386 Version 4 Reference Manual, STSC Inc., 1992
4. APL+Win Version 3 Reference Manual, APL2000 Rapid Application Development, 1997
5. APL+Win 3.5 Update Manual, APL2000 Rapid Application Development, 1999