Interoperability

Workspaces and component files are stored on disk in a binary format (illegible to text editors). This format differs between machine architectures and among versions of Dyalog. For example a file component written by a PC will almost certainly have an internal format that is different from one written by a UNIX machine. Similarly, a workspace saved from Dyalog V11 will differ internally from one saved by a previous version of the interpreter.

It is convenient for versions of Dyalog running on different platforms to be able to "interoperate" by sharing workspaces and component files. However, this is not always possible. For example, if a new internal data structure is introduced in a particular version of Dyalog, previous versions could not be expected to make sense of it. In this case the load (or copy) from the older version would fail with the message:

this WS requires a later version of the interpreter.

Similarly, "large" (64-bit-addressing) component files are inaccessible to versions of the interpreter that pre-dated their introduction.

The second item in the right argument of ⎕FCREATE determines the addressing type of the file.

    'small'⎕fcreate 1 32    ⍝ create small file.
    'large'⎕fcreate 1 64    ⍝ create large file.

For the moment, if the second item is missing, the file type defaults to 32-bit-addressing (max 4GB file size), even on a 64-bit system for maximum inter-operability. We will change the default to 64-bit in version 11.1, by which time we believe the bulk of our users will be running versions which can use 64-bit files (version 10.1 or later)

Dyalog Version 11 adds to the interoperability problem by supplying versions for both 32-bit and 64-bit machine architectures.

Interoperability is summed up in the following tables. Table rows show the version that is attempting to access the file or workspace and columns show the version that saved it:

This version can access files created by this version →
↓

Version 10.1.5

Version 10.1.5 is an update to V10.1 issued specifically to enhance 10.1/11.0 compatibility. Version 10.1.5 is essentially version 10.1.2 with the addition of some Version 11.0 file system code. If Version 10.1 applications are moved to 10.1.5, they will be able to share files with code which has been moved to 64-bit Version 11.0. For example, this would allow a computational server to be moved to 64-bit Version 11.0 and provide data to an application which was still running Version 10.1.

The row and column titles show the Dyalog version 9.0, 10.0, etc; (32) and (64) indicate a version running on a 32-bit or 64-bit machine architecture, respectively.

Implementation

In general all writes are made in the format that is native to the writer. Readers do the work of any necessary translation. The exception is when writing from a 64 bit version to a 32 bit file. This has been allowed provided the machine architecture is the same. 32 bit files are the same architecture for the entire file. 64 bit files can have each component written differently.

Workspace interoperability - "can load/copy from …"

  9.0 10.0 10.1 10.1.5 11.0(32) 11.0(64)
9.0 Yes - - - - -
10.0 Yes Yes - - - -
10.1 Yes Yes Yes Yes - -
10.1.5 Yes Yes Yes Yes - -
11.0(32) Yes Yes Yes Yes Yes Yes
11.0(64) - - Yes Yes Yes Yes

Component files small (32-bit addressing) and External variables- "can access …"

  9.0 10.0 10.1 10.1.5 11.0(32) 11.0(64)
9.0 Yes ~t Yes ~f~n~t Yes ~f~n~t Yes ~f~n~t Yes ~f~n~t Yes ~f~n~t
10.0 Yes ~t Yes ~t Yes ~t Yes ~t Yes ~n~t Yes ~n~t
10.1 Yes ~t Yes ~t Yes ~t Yes ~t Yes ~n~t Yes ~n~t
10.1.5 Yes ~w Yes ~w Yes ~w Yes ~w Yes ~n~w Yes ~n~w
11.0(32) Yes ~w Yes ~w Yes ~w Yes ~w Yes ~w Yes ~w
11.0(64) Yes ~w Yes ~w Yes ~w Yes ~w Yes ~w Yes ~w

Notes
~f: Cannot read ⎕ORs of functions.
~n: Cannot read ⎕ORs of namespaces.
~t: Cannot tie files created on machines with different byte ordering (e.g. PC/UNIX).
~w: Can read from but cannot write to files created on machines with different byte ordering (attempting to write generates FILE ACCESS ERROR).

Component files large (64-bit addressing) - "can access …"

  9.0 10.0 10.1 10.1.5 11.0(32) 11.0(64)
9.0 - - - - - -
10.0 - - - - - -
10.1 - - Yes Yes ~b Yes ~n~b -
10.1.5 - - Yes Yes Yes ~n Yes ~n
11.0(32) - - Yes Yes Yes Yes
11.0(64) - - Yes Yes Yes Yes

Notes
~b: Cannot read a component with the wrong byte-ordering.
~n: Cannot read ⎕ORs of namespaces.

Sockets (type 'APL') - "can decode from …"

  9.0 10.0 10.1 10.1.5 11.0(32) 11.0(64)
9.0 Yes Yes ~fn Yes ~f~n Yes ~f~n Yes ~f~n -
10.0 Yes Yes Yes Yes Yes ~n -
10.1 Yes Yes Yes Yes Yes ~n -
10.1.5 Yes Yes Yes Yes Yes ~n -
11.0(32) Yes Yes Yes Yes Yes Yes
11.0(64) Yes Yes Yes Yes Yes Yes

Notes

~f: Cannot read ⎕ORs of functions.
~n: Cannot read ⎕ORs of namespaces.

Auxiliary Processes

A Dyalog process is restricted to starting an AP of exactly the same architecture. In other words, the AP must share the same word-width and byte-ordering as its interpreter process.

Session Files

Session (.dse) files may only be used on the platform on which they were created and saved.