PreviousMicrosoft Windows Applications Using GUIs from Third Party ToolsNext"

Chapter 17: Microsoft Windows NT Applications

This chapter explains how to use the 32-bit COBOL system to create 32-bit applications for running on Windows NT or Windows 95. It assumes you have a basic knowledge of the concepts involved in writing a Windows NT or Windows 95 program.

Windows NT and Windows 95 are referred to as 32-bit Windows in this chapter.

This chapter assumes you are using the 32-bit Win32 API. For details on writing applications for the 16-bit Windows API, see the chapter Microsoft Windows Applications.

17.1 Writing 32-bit Applications for Windows

Micro Focus offers the following approaches to programming 32-bit applications in COBOL for running on Windows:

The chapter Comparison of Methods for Creating User Interfaces explains the advantages and disadvantages of each of the above approaches.

17.1.1 Requirements

To develop 32-bit applications for running on 32-bit Windows and Windows 95, you need the following:

17.1.2 The Calling Convention Used by the Win32 API

The Win32 API uses the system linkage parameter-passing convention. This means that:

This convention is CALL-CONVENTION 74. See the chapter The COBOL Interfacing Environment in your Programmer's Guide to Writing Programs for details on the CALL-CONVENTION clause.

17.1.3 The 32-bit Windows Startup Module

Every 32-bit Windows program is passed four startup values by the operating system. These values are obtained by using the PC_WIN_INIT call which is shown below. The method whereby the parameters are obtained from a Linkage Section is not supported.

  local-storage section. 
  01 hIns                       pic x(4) comp-5. 
  01 hPrevInstance              pic x(4) comp-5. 
  01 lpszCmdLine                pointer. 
  01 nCmdShow                   pic x(4) comp-5.

  procedure division WINAPI.
  call "PC_WIN_INIT" using      hInst

17.1.4 Compiling, Linking and Debugging

The following sections describe how to compile and link both existing character-based applications, and graphical user interface applications using the Win32 API to run on 32-bit Windows. Compiling an Application

No special directives are needed when compiling applications for running under 32-bit Windows. Linking a Character-based Application

32-bit Windows systems provide a console subsystem for character-based applications. Therefore, no special support is required from the COBOL system.

If you do not need to specify any command-line compiler directives to compile your program, you can use the Cbllink link utility to compile and link your program in one step. See your Object COBOL User Guide for details on Cbllink.


To compile and link the sample program Tictac to run under 32-bit Windows with the shared run-time system:

cbllink tictac.cbl

The resulting program can be run just like any other 32-bit Windows application. Linking a Win32 GUI Application

You can compile and link an application that has a graphical user interface using the Win32 API in one step by using Cbllink:

cbllink -g app.cbl

Alternatively, you can use Cblnames and Link32 to link your 32-bit Windows application:

cblnames /m app-entry-point app-obj-files
link32 /out:app.exe /machine:i386
       /subsystem:windows app-obj-files cbllds.obj
       mfrts32.lib crtdll.lib Win32-SDK-libraries

The sample programs Winhello and Wincalc demonstrate how to write programs that can be compiled and linked to run natively on 16-bit or 32-bit Windows, depending on a value passed to the program when it is compiled. The sample programs are compiled and linked to run on 32-bit Windows if the value of the constant 32-bit is set to 1 when the program is compiled. Because this value is set using a compiler directive, you cannot use the Cbllink utility to perform the compilation stage.


To compile the Winhello sample program to run on 32-bit Windows and link it using Cbllink:

cobol winhello constant 32-bit(1);
cbllink -g winhello.obj

To compile the Winhello sample program to run on 32-bit Windows and link it using Link32:

cobol winhello constant 32-bit(1);
cblnames /mwinhello winhello
link32 /out:winhello.exe /machine:i386
      /subsystem:windows winhello.obj cbllds.obj mfrts32.lib
      /crtdll.lib kernel32.lib user32.lib gdi32.lib Creating Dynamic Link Libraries

Linking the object module to form a .dll file is similar to linking to form an .exe file, but an additional step is required to create an export module used when linking the .dll file.


Consider the following COBOL program, windll.cbl:

  procedure division using Return-String.
      move "Inside WINDLL" to Return-String
      exit program.
  entry "WINDLL2" using Return-String.
      move "Inside WINDLL2" to Return-String
      exit program.

To compile and link this program using Cbllink, use the following command:

cbllink -d windll.cbl

A module definition .def file is automatically created and used when creating the .dll file.

Alternatively, a typical compile and link command using Link32 would be:

cobol windll;
lib32 /out:windll.lib /def:windll.def /machine:i386
link32 /dll /out:windll.dll /entry:LibMain@12 /machine:i386
      windll.exp windll.obj mfrts32.lib crtdll.lib

where windll.def contains the lines:

library        windll
description    "a cobol dll for windows NT."
data           nonshared
  exports      windll

32-bit Windows systems do not require a Windows exit procedure (WEP) function in the module definition (.def) file for the .dll file. The LibMain function is now used for both initialization and termination of the .dll. For further details on 32-bit Windows definition files, see the documentation supplied with the Microsoft Win32 Software Development Kit. Statically Linked Calls

If you use statically linked calls to a .dll file, you must create an import library for the .dll file and link this library into the calling program.


Consider the following main program, winexe.cbl:

 procedure division.
   call "_ _windll"
   call "_ _windll2".

The double-underscore notation to force static linking is supported for backward compatibility with code written for the 16-bit COBOL system (see the description of the LITLINK directive). We recommend that you now use CALL-CONVENTION 8 to force static linking:

   call-convention 2 is win32
   call-convention 8 is static-dll.
 procedure division.
   call static-dll "windll"
   call static-dll "windll2".

To create an import library on 32-bit Windows, use Lib32 as follows:

lib32 /out:windll.lib /def:windll.def /machine:i386

Then, when you link Winexe, you specify the library windll.lib on the link command line. Dynamically Linked Routines

If you use dynamic calls, you do not need to supply any information to the linker. At run time, the run-time system module that handles dynamic calls first searches through loaded executable files to see if the required subprogram is already loaded. If it isn't, the disk is searched for an executable file whose filename matches the subprogram-name.

Therefore, if you use dynamic linking, the first call you make to the .dll file must use the name of the .dll file. For example:

 procedure division.
      call "windll"
      call "windll2". Debugging

Use Animator V2 in the 32-bit COBOL system to debug your 32-bit applications for Windows. See your Object COBOL User Guide for details of Animator V2.

17.1.5 Hints and Tips

17.2 32-bit Library Routines

There are some printer handling routines that are portable between the 32-bit COBOL systems running on Windows and OS/2. These routines are:

PC_PRINT_FILE Print a file
PC_PRINTER_CLOSE Close a printer channel
PC_PRINTER_CONTROL Send a printer command to a printer
PC_PRINTER_FREE_BMP Free bitmap from memory
PC_PRINTER_INFO Get printer information
PC_PRINTER_LOAD_BMP Load bitmap into memory
PC_PRINTER_OPEN Open a printer channel
PC_PRINTER_SET_COLOR Set printer color
PC_PRINTER_SET_FONT Set printer font
PC_PRINTER_WRITE Write text to a printer
PC_PRINTER_WRITE_BMP Write bitmap to a printer

These routines are described in the Library Routines chapter of the Programming Guide to Writing Programs.

Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousMicrosoft Windows Applications Using GUIs from Third Party ToolsNext"