1. Introduction
  2. Structure
  3. Packaging
  4. Logging
  5. Configuration
  6. Debugging EXEs
  7. Handling errors
  8. Testing
  9. Documentation
  10. Make
  11. Providing help
  12. Scheduled Tasks
  13. Windows Services
  14. Windows Event Log
  15. Windows Registry
  16. Creating SetUp.exe
  17. Regular Expressions
  18. Acre
  19. GUI
  20. Git


  1. Windows environment vars
  2. User commands
  3. aplcores & WS integrity
  4. Development environment
  5. Special characters


The workspace (WS) is where the APL interpreter manages all code and all data in memory.

The Dyalog tracer / debugger has extensive edit-and-continue capabilities; the downside is that these have been known occasionally to corrupt the workspace. However, there are many other ways the workspace may get corrupted:

The interpreter checks WS integrity every now and then; how often can be influenced by setting certain debug flags; see The APL Command Line in the documentation for details. Be warned that…

When the interpreter finds that the WS is damaged it will create a dump file aplcore and exit to prevent your application from producing (or storing) incorrect results.

Regularly rebuilding the workspace from source files removes the risk of accumulating damage to the binary workspace.

An aplcore is useful in two ways:

You can create an aplcore deliberately by executing:

      2 ⎕NQ '.' 'dumpws' 'C:\MyAplcore'

This might be a useful thing to do just before executing a line you already know will cause havoc in one way or another.

In order to create a real aplcore, in the sense of corrupting the workspace, this will do:

 :Trap 102
     ⎕NA'dyalog32|MEMCPY u4 u4 u4'
     ⎕NA'dyalog64|MEMCPY u4 u4 u4'
 MEMCPY 0 0 4

By default, an aplcore is saved with the name aplcore in what is at that moment the current directory. This is not nice because it means that any aplcore might overwrite an earlier one. That can become particularly annoying when you try to copy from an aplcore with :

     )copy C:\MyAplcore.

but this might actually create another aplcore, overwriting the first one. Now it might well be too late to restrict the attempt to copy to what is most important to you: the object or objects you have worked on most recently.

If the aplcore is saved at all that is, because if the current directory is something like C:\Program files\ then you won't have the right to save into this directory anyway.

When a program asks Windows to save a file in a location where that program has no write permission (e.g. C:\Program Files, C:\Program Files (x86), C:\Windows) then Windows will tell the application that it has fulfilled the request, but the file will actually be saved in something like C:\Users\{username}\AppData\Local\VirtualStore\Program Files\Dyalog\Dyalog APL-64 16.0 Unicode\

For that reason it is highly recommended to set the value aplcorename in the Windows Registry:

Defining home and names of aplcores

This means that aplcores…

The same can be achieved by specifying APLCORENAME=... on the command line. That's particularly important for Windows Services.