Super Prev Next

TopSpeed Compatibility Pack

The TopSpeed Modula-2 compiler for DOS and OS/2 by Jensen and Partners International had been rather popular in late 1980s. There are millions of lines of TS Modula-2 code still used in various environments. Unfortunately, since that time the world has moved to Windows and Linux, and TopSpeed users could only watch this process as their compiler is no longer available as a standalone product, and is not actively developed, marketed, and supported by its new owners. So there is a need for them to simultaneously change the compiler and the target operating system.

XDS Modula-2 compilers, available for Windows and Linux, are likely to be considered as a replacement for TopSpeed. But moving from TopSpeed to XDS can be difficult: the JPI implementation of the language is based on PIM, whereas XDS follows the ISO 10514 standard, which is not a superset of PIM. In addition, both compilers provide different sets of language extensions.

That’s why the TopSpeed Compatibility Pack (TSCP) has been developed by Excelsior. The XDS compiler which is part of TSCP has one additional option — TOPSPEED. Setting it ON enables a set of language extensions that makes the compiler more compatible with TopSpeed. These extensions are described in the following sections.

TSCP also contains a set of TopSpeed-like library modules.


Super Prev Next

Conditional compilation

The existing users of your DOS and/or OS/2 software products are not likely to move to Win32 at once as you do it. So it is desirable to be able to compile the same sources with both TopSpeed and XDS. To facilitate this, XDS supports TopSpeed conditional compilation syntax.

Note: In TopSpeed, an identifier used in a conditional compilation clause must be a boolean constant, either predefined, defined in the project file, or in the source text. In XDS, it has to be an option name.

The __XDS__ option is always set to TRUE in XDS Modula-2, so we recommend you to define the __XDS__ constant in your TopSpeed project file:

    #pragma define(__XDS__=>off)

and then use the above scheme to isolate TS- and XDS-specific portions of code. See example in section Pragma syntax.


Super Prev Next

Declarations and visibility


Super Prev Next

Alias declaration

TopSpeed alias declaration (CONST id1 ::= id2;) is available in XDS if the option TOPSPEED is turned ON.


Super Prev Next

Types


Super Prev Next

Numeric types

Types LONGCARD, LONGINT, SHORTCARD, and SHORTINT are not part of ISO Modula-2, but they are available in XDS Modula-2 if the M2ADDTYPES compiler option is switched on. Usage of types SYSTEM.INT8, SYSTEM.INT16, etc. may also be considered.

TopSpeed Modula-2 types TEMPREAL and FIXREAL have no analogs in XDS.


Super Prev Next

Sizes of base types

XDS compilers generate 32-bit code, so the base Modula-2 types, such as CARDINAL, INTEGER, and BITSET, are 32-bit by default, whereas in TopSpeed Modula-2 these types are 16-bit. To achieve better performance, it is recommended to use 32-bit types anywhere except in declarations that represent externally defined data structures, such as network packet layouts or database records. Unfortunately, this requires a lot of analysis that can only be done manually and requires deep understaning of the program being migrated, and therefore is error prone. This problem resembles the famous Year 2000 problem — no one can tell where in a million of source lines your program relies on base types being exactly 16 bits wide.

You may consider usage of the following techniques that do not require this analysis:


Super Prev Next

Based and virtual pointers

There are no based and virtual pointers in XDS.


Super Prev Next

Compatibility with system types

In TopSpeed Modula-2, types BYTE, WORD, and LONGWORD are assignment compatible with any type of corresponding size (1, 2, or 4 bytes), and allow testing for equality or inequality. Due to a far more complex definition of the BYTE and WORD types in ISO Modula-2, the only operation directly defined for them is an assignment and there are special rules affecting parameter compatibility (see XDS User Guide, System parameter compatibility for further details). The LONGWORD type does not exist in XDS.


Super Prev Next

Objects and values


Super Prev Next

Fixed variable placement

In TopSpeed, a variable can be placed at a fixed physical address which is specified in segment:offset form:

    VAR Screen [0B800H:0] : ARRAY [1..25][1..80] OF Cell;

In XDS, the SYSTEM.MAKEADR function has to be used:

    VAR MyCardIO [SYSTEM.MAKEADR(0FFFF0000H)] : BITSET;


Super Prev Next

Value constructors

In ISO Modula-2, constructors of array type and record type value use curly braces ({}) rather than parenthesis (()).

    TYPE
      Struct = RECORD
                 date :CARDINAL;
                 time :CARDINAL;
               END;

    CONST
      (* s = Struct ( 10, 12 );   TS manner *)

      s = Struct { 10, 12 };  -- XDS (ISO) manner


Super Prev Next

Expressions


Super Prev Next

Function calls in designators

If the option TOPSPEED or the option M2EXTENSIONS is set ON, XDS recognizes function procedure calls in designators, including predefined, SYSTEM, and type transfer procedures:

    CurPos(point[i,j])^.x
    GetCurDate().year
    REC_PTR(adr)^.field


Super Prev Next

Logical shift operators

The ’<<’ and ’>>’ infix operators of logical left/right shift, defined for cardinal types in TS, are available in XDS if the option TOPSPEED or the option M2EXTENSIONS is set ON.


Super Prev Next

Comparison of structured values

TopSpeed Modula-2 supports comparison of structured values (arrays and records) as a language extension. In general, alignment and packing rules of the target environment may cause existence of gaps between elements of an array or fields of a record. So comparison of structured values in raw mode (e.g. using Lib.Compare) is likely to produce incorrect results. In ISO Modula-2, you have to compare stuctured values element by element or field by field,


Super Prev Next

Statements


Super Prev Next

CASE without ELSE

In TopSpeed Modula-2, absence of the ELSE clause in a CASE statement is equivalent to presense of an empty ELSE clause. In XDS Modula-2, according to ISO 10514, if the value of the case selector is not contained in any case label list and the ELSE clause is not present, an exception shall be raised. Therefore, the CASE statement in the following code fragment:

    x := 2;
    CASE x OF
    |0: p0;
    |1: p1;
    END;

does nothing if compiled by TopSpeed, and raises an exception if compiled by XDS.

The recommended solution is to add empty ELSE clauses to all your CASE statements that lack it, as this would make no difference in TopSpeed. To quickly find all such statements, turn on warning 319:

    C:\WORK>xc t.mod -woff319-'

    XDS Modula-2 v2.40 [x86, v1.08] - build 20.10.1998
    Compiling "t.mod"

    * [t.mod 12.05 W319]
    * CASE statement without ELSE


Super Prev Next

FOR loop control variable

ISO Modula-2 requires that a FOR loop control variable must be declared in the scope to which the loop belongs. TopSpeed does not make this restriction, so you may need to redesign some of your FOR loops.


Super Prev Next

GOTO statement

There are no GOTO and LABEL clauses in ISO Modula-2. XDS provides them as an extension if the option TOPSPEED is turned ON.


Super Prev Next

Procedures


Super Prev Next

External procedures

XDS compilers allow only foreign procedures to be declared as external.

A declaration of an external procedure consists of a procedure header only, with the procedure name preceded by the symbol "/":

    PROCEDURE ["C"] / putchar(ch: SYSTEM.CARD8): SYSTEM.INT32;


Super Prev Next

Open arrray parameter compatibility

In TopSpeed Modula-2, an expression of type T can be substituted as a parameter whose formal type is ARRAY OF T. XDS supports this if on of the M2EXTENSIONS or TOPSPEED is turned ON.


Super Prev Next

Procedure types

In ISO Modula-2, a procedure belongs to a particular procedure type if the types of each formal parameter, taken in turn, are exactly the same. In TopSpeed Modula-2, there is one exception: if one of the two types is SYSTEM.ADDRESS, another type can be any pointer type, so the following piece of code is legal:

    TYPE
      SetNameMethod = PROCEDURE(SYSTEM.ADDRESS,ARRAY OF CHAR);

      NodePtr = POINTER TO Node;
      Node = RECORD
               name   : ARRAY [0..63] OF CHAR;
               setname: SetNameMethod;
             END;
                 
    PROCEDURE SetNodeName(p: NodePtr; name: ARRAY OF CHAR);
    BEGIN
      Str.Copy(p^.name, name);
    END SetNodeName;

      .  .  .
   
     NEW(node);
     node^.setname := SetNodeName;

In TopSpeed Modula-2, a procedure type definition may reference an incomplete type containing that definition, provided that the incomplete type has already been referenced:

    TYPE
      P = POINTER TO R;
      R = RECORD
            data: CARDINAL;
            proc: PROCEDURE(R);
          END;

XDS does not allow this, so you have to define the procedure type separately:

    TYPE
      P = POINTER TO R;
      R_proc_type = PROCEDURE(R);
      R = RECORD
            data: CARDINAL;
            proc: R_proc_type;
          END;

The NULLPROC value is absent in XDS; NIL should be used instead. You may consider declaring NULLPROC under conditional compilation in modules that use it:

    (*%T __XDS__ *)
      CONST 
        NULLPROC = NIL;
    (*%E *)


Super Prev Next

Predefined procedures

Predefined procedures FarADR, NearADR, Ofs, and Seg are specific to the 80x86 16-bit real and protected modes and therefore are not available in XDS.

The FieldOfs and VSIZE procedures are predefined if the option TOPSPEED is set ON and are available from the module SYSTEM otherwise.


Super Prev Next

Type conversion vs type cast

In TopSpeed Modula-2, the predefined function procedure VAL(type, expr) performs type conversion if both type and expr are numeric or ordinal, and performs type cast otherwise. In ISO Modula-2, VAL may only be used in the former case; SYSTEM.CAST has to be used for type casting.

According to PIM, a type transfer function type(expr) shall not affect the bit pattern representaion of the result of expr. Unfortunately, TopSpeed does not follow this specification and treats type(expr) exactly as VAL(type,expr) (see above). Due to introduction of such ambiguities by pre-ISO compiler vendors, this feature was not included in the International Standard. XDS provided it as a language extension (option M2EXTENSIONS ON), but treated it as SYSTEM.CAST(type,expr). Now, if the TOPSPEED option is turned ON, XDS will treat this construction exaclty as TopSpeed. This ambiguity may lead to porting problems that are hard to detect, so the compiler issues a warning upon encountering a type transfer function. It is recommended to use the built-in VAL and SYSTEM.CAST function procedures for type conversion and type cast respectively.


Super Prev Next

Inline and code procedures

In XDS, there is no way to point out an inline procedure explicitly (yet), however native-code compilers can make inline substitutions of some procedures automatically. It is also not possible to define inline procedures in a definition module. You have to move such procedures into implementation modules.

As for TopSpeed binary inline procedures, they also have no equivalent in XDS. Since they contain 16-bit mode instructions, they would have to be rewritten anyway. XDS inline assembler may be used to implement machine code routines.


Super Prev Next

Modules


Super Prev Next

Import

In TopSpeed, any entity imported into a definition module is "automatically" imported into the corresponding implementation module. In ISO Modula-2, all entities required by an implementation module should be explicitly imported into it.

TopSpeed Modula-2 supports qualification of entities defined in a definition module in the respecive implementation module. In XDS, this is not possible.


Super Prev Next

Hidden pointer base types

In TopSpeed, if T is a type defined in an implementation module, it is still possible to declare a type POINTER TO T in a definition module:

    DEFINITION MODULE T;
    
    TYPE 
      p1 = POINTER TO t1;
      r1 = RECORD
             p2: POINTER TO t2;
           END;
    
    END T.

XDS does not allow this, so you have to either


Super Prev Next

Export from local module

In TS. the keyword QUALIFIED (in local modules) has no effect and a name of an object exported from a local module can be used with or without qualification. In ISO Modula-2, there is a distinction between qualified an unqualified export. You will have to introduce uniformity here: if you mostly use objects exported from local modules with qualification, ensure presence of the QUALIFIED keyword, otherwise remove it. Compilation errors will then indicate places where you have to add or remove qualification.


Super Prev Next

The module SYSTEM

In ISO Modula-2, all objects from the module SYSTEM, such as types ADDRESS, WORD, BYTE, and the procedure ADR have to be explicitly imported. In TopSpeed Modula-2, they are predefined.

Although the XDS module SYSTEM contains procedures NEWPROCESS, TRANSFER, and IOTRANSFER, it is recommended to replace them with more powerful mechanisms provided by the ISO system module COROUTINES. See also Multithreading.

The set of platform-specific facilities is almost completely different in TopSpeed and XDS variants of the module SYSTEM.


Super Prev Next

Intel x86 16-bit mode specifics

TopSpeed Modula-2 supports Intel x86 16-bit real and protected modes, whereas XDS produces code for the 32-bit flat memory model. Therefore, code that deals with segment:offset addresses has to be rewritten for XDS.

In XDS, there is no analog for TopSpeed pointer constructors of the form [seg:ofs type]. These constructors are commonly used to directly interface to hardware and to access DOS and BIOS data areas, so routines that utilize this feature have to be redesigned anyway,

The following TopSpeed Modula-2 types and procedures, specific to Intel x86 16-bit real and protected modes, are absent in XDS:

    FarADDRESS   FarNIL   FarADR
    NearADDRESS  NearNIL  NearADR
    Ofs Seg

There are so called based pointers in TopSpeed, i.e. pointers belonging to a particular segment. This feature is useless in 32-bit flat mode, so it is not available in XDS.


Super Prev Next

Object oriented extensions

There are no object-oriented extensions in XDS Modula-2. Although XDS features Oberon-2 as well, its OO facilities are dissimilar in many aspects from provided in TopSpeed Modula-2. So, unfortunately, the required porting efforts for a program that makes heavy use of TS OO extensions may be unaffordable.


Super Prev Next

Pragmae


Super Prev Next

Pragma syntax

XDS pragma syntax is completely different from TS. Most TopSpeed pragmae have no analogs in XDS, and many of them are pretty useless in the 32-bit flat memory model. Conditional compilation has to be used to isolate TopSpeed and XDS pragmae:

    (*%T __XDS__ *)
      <* PUSH *> <* COVERFLOW - *>
    (*%E *)
    (*%F __XDS__ *)
      (*# save, check(overflow=>off) *)
    (*%E *)
      hash := hash*alpha+ORD(ch);
    (*%T __XDS__ *)
      <* POP *>
    (*%E *)
    (*%F __XDS__ *)
      (*# restore *)
    (*%E *)


Super Prev Next

Open array parameters passing

When an array is passed as a value parameter in TS, it can be either copied onto the stack or passed by reference, depending on the call(o_a_copy) pragma setting. In XDS, an array is always copied onto the stack unless the formal parameter is marked as read-only, for instance:

    PROCEDURE PrintStr (s  : ARRAY OF CHAR);  -- pass by value

    PROCEDURE PrintStr (s- : ARRAY OF CHAR);  -- pass by reference

Note: the M2EXTENSIONS option should be turned on.

When a procedure parameter has type ARRAY OF CHAR, TopSpeed allows an actual parameter of type CHAR to be passed. This is not allowed by the ISO standard, and XDS will not accept it.


Super Prev Next

Bitwise operations on cardinals

In TopSpeed Modula-2, the pragma option(bit_expr=>on} enables bitwise operations AND, OR, and NOT to be applied to cardinals. In XDS, this feature is enabled if the M2EXTENSIONS option is set ON.


Super Prev Next

Other pragmae

More information on TS-to-XDS pragmae mapping will be provided in future releases.


Super Prev Next

XDS TS-like library

Table 16. Module/product availability matrix shows which TopSpeed-like library modules are implemented in which edition of TSCP.

In order to preserve the overall level of the XDS libraries portability, a number of modifications was made to the original interface and functionality of the modules. Also, some restrictions were induced by differences between target operating systems. There are also some useful extensions. See the following sections for details.

Note: The library is compiled with the M2BASE16 compiler option turned OFF, so types INTEGER, CARDINAL, and BITSET are 32-bit.

Table 16. Module/product availability matrix

Module XDS-x86 XDS-x86 XDS-C
name (Windows) (Linux) (all platforms)
BiosIO
FIO √- √-
FIOR
Graph - -
IO
Lib
MATHLIB
MsMouse -
ShtHeap
Str
Window -


Super Prev Next

Module FIO

MODIFICATIONS

  1. Since the module FIO is implemented on top of the ISO standard library, the procedural variable RunTimeError has been removed. If IOCheck is set to TRUE, an I/O error raises an exception, so ISO Modula-2 exception handling facilities can be used. Exceptions raised in FIO can be indentified in an exception handler by means of the procedures FIO.IsFIOException() or IOChan.IsChanException().
  2. The constant MaxOpenFiles is no longer needed, since the maximum number of open files is limited only by the system resources. If there are too many open files, either an exception will be raised or the error tooManyOpen will be returned by the procedure FIO.IOresult() (it depends on the state of the variable IOcheck).
  3. File share modes are defined as an enumeration type:

        TYPE
          SHAREMODE = (ShareCompat,
                       ShareDenyRW,
                       ShareDenyRD,
                       ShareDenyWR,
                       ShareDenyNone);
    

    Supported target operating systems do not distingiush between subsequent opens of a file done by the same or different process, so ShareCompat works as ShareDenyWR in OpenRead and as ShareDenyRW in other file open procedures.

  4. Standard file handles (e.g. StandardInput) are predefined variables of the File type rather than constants.
  5. Type of the buffer parameter for RdBin and WrBin has been changed to ARRAY OF SYSTEM.LOC which works perfectly the same as ARRAY OF BYTE.
  6. When a file opening error occurs, the procedures Open, OpenRead, Create, etc. return a special invalid value instead of MAX(CARDINAL). The procedure InvalidFile always returns that value.
  7. A disk label can be obtained by calling FIO.GetLabel rather than FIO.ScanFirst with the volume attribute set.
  8. After directory scanning (FIO.ReadFirstEntry, FIO.ReadNextEntry) process is completed, a call to the FIO.ReadClose procedure has to be issued with the scan-buffer passed as a parameter.
  9. The procedure FIO.SetDrive does not return the total number of drives available on the system.
  10. The EOF flag is not set when the current read position reaches end of file, but on attempt to read past it, as in ISO routines.
  11. The Ctrl-Z character is not recognized as an end-of-file mark.
  12. For all procedures accepting or returning a drive number, drive numeration starts from 1 (1 is drive A, 2 is drive B and so on).
  13. The SysErr module contains constants defining symbolic names of error codes. Those constants may be used to test a return code obtained from FIO.IOresult. The constant SysErr.allRight corresponds to a normal procedure termination (it is recommended to use this constant instead of zero value).
  14. 32-bit file length is supported.
  15. A file handle obtained from a system call can NOT be directly passed to FIO procedures. It has to be converted to a value of the type File using the AppendHandle procedure:

        PROCEDURE AppendHandle(fh : LONGCARD
                              ;ReadOnly : BOOLEAN
                              ) : File;
    
  16. The type FIO.FileStamp is declared as equal to SysClock.DateTime.
  17. The parameter of FIO.Close now is a VAR parameter and the procedure shall assign an "invalid" value to it if the close operation succeeds,

RESTRICTIONS

  1. There is no multithread program support yet. Namely, the IOresult, ThreadEOF and ThreadOK procedures are not implemented yet, Nevertheless, the module can be used in multithread programs with the reservations listed above.
  2. File share modes are only supported by Native XDS-x86 for Windows.
  3. Assinging a buffer to a file is not implemented yet. I/O operations are buffered internally, but there is no way to flush an internal buffer (yet).
  4. The procedures GetStreamPointer and AppendStream have been excluded,
  5. The predefined variable PrinterDevice is not eliminated yet.
  6. RdReal and RdLngReal do not recognize exponent-only zeroes, such as E+0.

PRODUCTS

Native XDS-x86 for Windows
Native XDS-x86 for Linux (with limitations)
XDS-C (with limitations)


Super Prev Next

Module Graph

MODIFICATIONS

  1. The major difference between TS original and XDS implementations of the module Graph is a windowed mode: a program, which uses the module, opens the Graph window by a call to the Graph.Init procedure, invokes the procedures provided by the module to draw in the window and set some parameters (e.g. a clipping region) and calls to the Graph.Exit procedure to close the Graph window. It is possible to open only one Graph window at a time.

    The Init procedure has been changed to

    PROCEDURE Init(xLeft, yTop, xd, yd : LONGCARD) : BOOLEAN;

    The position of the left upper corner of the Graph window is passed in the xLeft and yTop parameters, horizontal and vertical sizes of the window are passed in the xd and yd parameters. The Graph window is closed automatically upon program termination. The Exit procedure can be used to close the Graph window before the program execution is finished:

    PROCEDURE Exit;

    The Init procedure returns success indicator (TRUE means succesful module initialization) and it is recommended to test the value in the program.

  2. The procedures GraphMode and TextMode switch focus between the console window and the Graph window and appropriately change their z-order.
  3. The procedure SetGraphWindowTitle, which sets the title of the Graph window, has been added:

    PROCEDURE SetGraphWindowTitle (text :ARRAY OF CHAR);

  4. The procedure GetVideoConfig has been removed. The fields of the VideoConfig record, which were typically used, are exported as variables:

    Name Explanation VideoConfig field
    Width width of the Graph window work area numxpixels
    Depth depth of the Graph window work area numypixels
    NumPColors number of colors in use numcolors
    Columns number of text columns available numtextcols
    Rows number of text rows available numtextrows

    Note: By "number of text columns" ("text rows") a maximum number of monospaced font characters which can be placed into the Graph window in one column (row) is meant.

  5. The Fill parameter has been added to the procedure Polygon:

    PROCEDURE Polygon(n : CARDINAL;
                      px, py : ARRAY OF CARDINAL;
                      FillColor : CARDINAL;
                      Fill : BOOLEAN);
    

    The variable FillState, influencing on Polygon’s fill mode, has been excluded.

  6. The procedure Pie_a has been added:

    PROCEDURE Pie_a (x1, y1, x2, y2 : LONGCARD;
                     startAngle, sweepAngle : LONGREAL;
                     Color :CARDINAL; Fill : BOOLEAN);
    

    A pie is defined as a part of an ellipse enclosed in the rectangle ( x1, y1, x2, y2 ), with a start angle passed in the startAngle parameter and a sweep angle passed in the sweepAngle. Angles are measured in degrees. The pie is drawn counterclockwise.

  7. It is recommended to invoke the CancelClipRgn procedure to disable clipping instead of a call to SetClipRgn with a whole window position and sizes passed as parameters.
  8. The procedure RawOutText draws a text at the position (x,y) defined in pels rather than in text columns and rows:

    PROCEDURE RawOutText (x, y : LONGCARD;
                          Color : LONGCARD;
                          Text :ARRAY OF CHAR);
    
  9. Since Win32 GDI engine keep a bitmap in a system heap, there is no need to allocate memory for a bitmap in a program which uses the module, so the procedure ImageSize always returns 0.

    The following scheme shows the standard order of procedure calls within the program which uses bitmaps:

    1. Invoke the GetImage procedure to create a bitmap:

      PROCEDURE GetImage(x1, y1, x2, y2 : LONGCARD; 
                         VAR bmpHandle : HBITMAP );
      

      The handle of the created bitmap will be returned in the bmpHandle parameter (the HBITMAP type is exported from the module).

    2. To draw the previously created bitmap, call the PutImage procedure, passing the bitmap handle in the bmpHandle parameter:

      PROCEDURE PutImage(x, y : LONGCARD; 
                         bmpHandle : HBITMAP;
                         Action : LONGCARD);
      
    3. When a bitmap is no longer needed, it is recommended to delete it in order to release system resources by calling the DelImage procedure:

      PROCEDURE DelImage(hbmHandle :HBITMAP);

  10. Because of an OS/2 GPI restriction, there is no way to set an arbitrary line style (e.g. to draw outline circle ), nevertheless there is a number of the predefined line styles which can be set by means of a call to the SetLineStyle procedure. Any of the following constants, exported from the module, can be passed to the SetLineStyle procedure:

        LNSTYLE_DOT
        LNSTYLE_SHORTDASH
        LNSTYLE_DASHDOT
        LNSTYLE_DOUBLEDOT
        LNSTYLE_DASHDOUBLEDOT
        LNSTYLE_SOLID
    
  11. A program can define its own fill mask (the SetFillMask procedure). Also the Graph module provides the SetStdFillMask procedure to use several standard fill masks. The following constants, exported from the module, define different fill masks :

        PATSYM_DENSE1
        PATSYM_DENSE2
        PATSYM_DENSE3
        ...
    
  12. The SetBkMix procedure has been added to the original functionality.

    PROCEDURE SetBkMix (isOpaque : BOOLEAN);

    The _TRANSPARENT and _OPAQUE constants can be passed to the isOpague parameter. The procedure sets background color mixture mode. Namely, if _OPAQUE passed, bits of a fill mask, set in zero, are painted in background color when filling with a non-solid mask is used. If _TRANSPARENT passed, screen pixels corresponding to zero bits of a fill mask, are not changed.

  13. The RemapPalette and RemapAllPalette procedures are provided to set a logical palette. The InitStdPalette procedure allows to set the palette to the initial state, in which only 16 colors, corresponding to the colors constants (e.g. _clrLIGHTBLUE ), are defined.
  14. The procedures TrueCircle and TrueDisc are defined as equal to Circle and Disc respectively, as pixels are square in all commonly used video modes provided by modern display adapters.

RESTRICTIONS

  1. Device specific constants and routines, such as CGAWidth, InitCGA, etc., have been removed
  2. The following procedures have been excluded: SelectPalette (CGA only), SetVideoMode, SetActivePage, SetVisualPage,
  3. It is possible to set a custom palette by means of a call to the RemapPalette or RemapAllPalette procedures. However, the palette colors map to the nearest colors of the current physical palette on your device.

PRODUCTS

Native XDS-x86 for Windows
Native XDS-x86 for Linux (with limitations)


Super Prev Next

Module IO

RESTRICTIONS

  1. The IO.KeyPressed() and IO.RdKey() procedures, providing direct read from keyboard, are available in console applications only.
  2. RdReal and RdLngReal do not recognize exponent-only zeroes, such as E+0.

PRODUCTS

All XDS products


Super Prev Next

Module Lib

MODIFICATIONS

  1. Although address operations (SubAddr, AddAddr etc.) and other low-level procedures (such as Fill, Move) are available, usage of their analogs from the module SYSTEM (ADDADR, SUBADR, FILL, etc.) would improve performance. Please consult the User’s Guide, Chapter "XDS Modula-2" for more information.
  2. The procedural variable RunTimeError has been removed. In ISO Modula-2, exceptions should be used for error handling purposes. The MathError procedure has been excluded because of the same reason. See also the description of changes made to the FIO module.
  3. The Terminate procedure has been removed because the same effect can be obtained by means of ISO Modula-2 standard mechanisms, such as module finalization and the system module TERMINATION (see XDS User Guide, new language’s features)
  4. SetDate and SetTime are now pure procedures.
  5. The Environment procedure definition has been changed to

        PROCEDURE Environment (N :CARDINAL;
                               VAR result :ARRAY OF CHAR);

  6. The WordFill procedure definition has been changed to

        PROCEDURE WordFill(Dest: ADDRESS;
                           WordCount: CARDINAL;
                           Value: SYSTEM.CARD16);

RESTRICTIONS

  1. The following platform-specific procedures have been removed:

          AddressOK               CpuId
          GetInProgramFlag        Execute
          NoSound                 ProtectedMode
          SelectorLimit           SetReturnCode
          SetInProgramFlag        Sound
          SysErrNo                UserBreak
          WrDosError
    
  2. The EnableBreakCheck and DisableBreakCheck procedures are not implemented; the CtrlC module from the XDS run-time library should be used to handle Ctrl-C and Ctrl-Break events.

PRODUCTS

All XDS products


Super Prev Next

Module MATHLIB

RESTRICTIONS

  1. The following procedures are not implemented: LongToBcd, BcdToLong
  2. ISO Modula-2 exception handling (see New language’s features) is used to report floating point errors, therefore the procedure variable MathError is not provided.

PRODUCTS

All XDS products


Super Prev Next

Module ShtHeap

MODIFICATIONS

  1. If a memory allocation failure occurs, NIL is returned.
  2. The type ShtHeap.Pointer was replaced with the type SYSTEM.ADDRESS.
  3. The ShtHeap.Increase procedure has been eliminated.
  4. Heap size is not resricted by 64 Kbytes (so ShtHeap is a historical name).

PRODUCTS

All XDS products


Super Prev Next

Module Str

MODIFICATIONS

  1. The LowS procedure (conversion to lower case) has been added to the module.
  2. In TopSpeed, the procedure FixRealToStr does not output more than 17 digits, whereas in XDS there is always Precision digits after decimal point.

    As a result, after a call FixRealToStr(V,5,S,Ok) variables S and Ok have the following vaues in TS and XDS respectively:

    V SIZE(S) S OK
    0.99E17 30 99000000000000000.0 TRUE
        99000000000000000.00000 TRUE
    0.99E18 30 990000000000000000 TRUE
        990000000000000000.00000 TRUE
    0.99E18 18 990000000000000000 TRUE
        ? FALSE

PRODUCTS

All XDS products


Super Prev Next

Module Window

EXTENSIONS

  1. An arbitrary screen size (number of rows and columns) is supported. The ScreenWidth ( = 80 ) and ScreenDepth (= 25) constants are remained, but in the case of non-standard screen size, actual values can be obtained from the CurrentScreenWidth and CurrentScreenDepth variables (the CurrentScreenWidth variable has been added to the original TS Window functionality).
  2. Input and output in any window, can be performed not only by means of the XDS TS-like module IO, but also through ISO standard input/output modules, such as STextIO or SRawIO.

RESTRICTIONS

  1. The CGASnow constant has been removed.
  2. It is needed to call the GetWDescriptor procedure to obtain pointer to the WinDescriptor record, since in the XDS implementation of the Window module, WinType is an opaque type rather than pointer to record. The following declarations were added to the definition module:

        TYPE
          p2WDescriptor = POINTER TO WinDescriptor;
    
          PROCEDURE GetWDescriptor ( W :WinType ) :p2WDescriptor;
    
  3. The SetProcessLocks procedures has been removed (multithread support implemented in such a way, that there is no need to use it).

PRODUCTS

Native XDS-x86 for Windows
Native XDS-x86 for Linux (with limitations)


Super Prev Next

Multithreading

The TopSpeed module Process implements its own scheduler which does not make use of the underlying operating system multithreading capabilities, in order to enable the development of multithread programs portable between DOS and OS/2. In case of XDS, the ISO Processes module should be used. Under Windows, its functionality is mapped onto the corresponding thread control API.

Note: The MULTITHREAD option should be set on to enable the functionality described above. Otherwise, the module Processes will work in coroutines mode.

An example of the Processes module usage is the WinDemoM sample which was ported from TopSpeed Modula-2.

The Processes module does not provide direct way to start or stop the process scheduler, which is possible in TopSpeed Process module, but this problem can be easily solved by writing some extra code (see WinDemoM.mod).

The ISO standard module Semaphores can be used to utilize the underlying operating system semaphore API.