Developing 32-bit Windows programs
Developing with Stony Brook Modula-2 allows you to take advantage of all of Win32capabilities, including:
The Win32 API
Although using the runtime library to program for Win32 is possible, you willnot be writing true Win32 applications. In order to develop applications thatprovide your users with the menus, dialogs, windows and other features they willbe expecting you will have to use the Win32 Application Programming Interface(API).The Win32 API is provided in definition modules in the runtime library. Youcan call Win32 API functions in the same way you call run time library functions.
Many of the API calls have been altered from their original C style to a stylethat is more natural for the Modula-2 programming language. The parameters that havebeen converted are pointer parameters. The Modula-2 language in many ways does notneed such parameters and Stony Brook Modula-2 takes this a bit further. The parametersare either value or VAR parameters depending on the function usage of the parameter.
String Parameters. LPSTR, LPCSTR, LPTSTR, LPCTSTR, LPWSTR, LPCWSTR are pointersto characters. In the Modula-2 API definitions these where converted to ARRAY OFCHAR parameters without the implicit high bound. However, the Win32 API restrictionthat strings be NULL terminated still applies, so take care that strings you passare indeed NULL terminated.
RECORD type parameters. Pointers to RECORD types have been converted to valueor VAR parameters. This can be done because our compiler always passes RECORD typesby reference, even for value parameters.
ARRAY type parameters. Pointers to ARRAY types have been converted to value orVAR parameters. This can be done because our compiler always passes ARRAY types byreference, even for value parameters.
Pointers to scalar types. In these cases the API call is doing exactly what theModula-2 VAR parameter accomplishes. The VAR parameter is a cleaner and type safemechanism.
Here is a list of the Win32 API files provided and what they contain :
COMMDLG | Common dialog procedures |
CUSTCNTL | Custom Control interface |
DDE | Dynamic data exchange core functions |
DDEML | High level DDE functions |
DigitalV | MCI digital video functions |
HTMLHELP | Interface to HTML help |
lmcons | MS Lan Manager constants |
lmerr | MS Lan Manager errors |
LZEXPAND | File decompression functions |
MCIAVI | MCI functions for AVIs |
MIDLES | RPC support functions |
MMREG | Registered multimedia information |
MMSYSTEM | Multimedia functions |
MSACM | Audio Compression Manager interface |
Ole2 | Object Linking and Embedding version 2 interface |
OleDlg | OLE Dialogs |
PenWin | Pen Windows functions |
RAS | Remote Access interface |
RichEdit | RichEdit control interface |
RichOle | OLE interface to the RichEdit control |
RPC | Remote Procedure Call high level functionality |
RPCCore | Remote Procedure Call basic definitions |
SHELLAPI | Shell/desktop interface functions |
SHOBJ | Additional shell/desktop interface functions |
SQL | ODBC interface |
TOOLHELP32 | Toolhelp interface. |
VCR | MCI VCR interface |
VFW | Video for Windows functions |
WFExt | File Manger extensions |
WIN32 | Threads, Synchronization, Files, Memory and Data Types |
WINCON | WIN32 console (text mode) API calls |
WINERROR | Symbolic error definitions |
WINGDI | GDI calls (painting) |
WINNETWK | Network interface functions |
WINNLS | ASCII language support |
WINPERF | Application performance profiling |
WINREG | Registration database, registry, functions |
WINSOCK | Windows Sockets interface |
WINSOCK2 | Windows Sockets interface version 2.2 |
WINSPOOL | Printer printing/spooling |
WINSVC | Win32 system service functions |
WINUSER | Windowing and Messages |
WINVER | Version number management |
WINX | This is a conversion of WindowsX.h. This provides some functions to encapsulate features that are non portable or not strongly typed. It provides strongly typed versions of some of the more loosely typed API calls. |
Gdiplus | GDI+ types and constants |
GdiplusFlat | The flat (non C++) GDI+ API. |
SimpleMAPI | Simple MAPI |
LDAP | LDAP protocol |
WINX also contains some strongly typed constants, and some NIL variables for Modula-2modified parameters such as RECORD and ARRAY OF parameters. These NIL variablesexist because Windows often provides optional behaviors on API functions when a NILpointer is passed. In Modula-2, since these have been mapped to structuresand arrays, a clean way was needed to access these optional behaviors. Forexample, if you wanted to call an API that required a NIL string be passedyou would call the function as:
Api name(WINX.NIL_STR);
OpenGL
The OpenGL interface is compiled is a separate project, OpenGL. Add this project to any project that need to use the OpenGL interface. The project exists in the installation directroy.
Exception Handlers on Exports
Procedures which are marked with the EXPORT attribute will automatically generatean exception handler if you do not supply one. The exception handler will terminatethe program if it is activated. This is to avoid the situation of an exceptionpropagating to other programs. We strongly recommend that you provide an explicitexception handler on all exported procedures and handle any exceptions in a way thatbest suits your program (Returning an error code for example).
A compiler directive is supplied to allow a procedure with the EXPORT attributeto propagate and exception. This should only be used when Modula-2 is calling Modula-2code and all of the code is using the same instance of the runtime system. If yourexported procedure is in a DLL then you should be linking to the DLL version of theModula-2 runtime library for all DLLs and programs.
Important Variables
The information that Win32 provides when an application is run or attached/detachedis made available by the following six variables which exist in WINX. For informationon their usage please consult your Win32 reference manuals.
Instance : HINSTANCE;
PrevInstance : HINSTANCE;
CmdShow : UINT;
CmdLine : LPSTR;
The following variables are imported from the SYSTEM module.
IsInit : BOOLEAN; (* Initialization or termination of a DLL *)
IsThread : BOOLEAN; (* Process or Thread DLL *)
The meanings of the last two variables for DLLs are:
WIN32.DLL_PROCESS_ATTACH = IsInit AND (NOT IsThread);
WIN32.DLL_PROCESS_DETACH = (NOT IsInit) AND (NOT IsThread);
WIN32.DLL_THREAD_ATTACH = IsInit AND IsThread;
WIN32.DLL_THREAD_DETACH = (NOT IsInit) AND IsThread;
For programs IsInit is always TRUE and IsThread is always FALSE.
Name Clashes
Win32 contains symbols that collide with Modula-2 pervasive symbols. The symbolsin the API files have been renamed as follows.
ASCII and UNICODE
The Stony Brook development system provides comprehensive support in developingASCII and Unicode applications. The default mode is ASCII application development. To develop Unicode applications, the RunTime library may be built with thechar implementation set to Unicode. If this is done all string parameters in theRTL will be Unicode strings.
Mixed ASCII/Unicode development can be accomplished by calling the "W"and "A" versions of the API functions directly.
Note: The Windows 95/98/Me operating systems do not support Unicode applications.
Startup Code
The main program entry point for normal Modula-2 programs is called _start@0.The entry point is the module BEGIN block of your program.
If CMAIN is used the C entry point procedure is the entry point. The C entry pointwill then call your main program BEGIN block which has the public symbol name _WinMain@16.
For DLLs the entry point is called _startDLL@12. The entry point is theBEGIN block of the program module.
All of the programs initialization code is called automatically.
Using Resources
To include a resource in a program, put the compiler resourcedirective into your program. You can have more than one resource file per programwhen using the Stony Brook linker. If you use other linkers this may not be the case.The environment uses this directive to track a dependency between the source filewith the directive and the resource file. The resource file will be linked when thesource file with the directive is a part of the program.
Standard Input and Output
A normal Win32 program does not have any standard input of output handles unless explicitly given these handles by the program that starts the program. For standard input and output Win32 programs you must make sure that the Console Application Linker Option is set. Windows will automatically create a console window for a console program if the console program is not started from a console window. Windows will automatically delete the console window on program termination.