GUI ScreenIO for Windows

Getting Started - Common Problems

It's not difficult to get started with GUI ScreenIO, but people still occasionally have minor problems.  Here are the usual ones, and the fixes.

Wrong version of GS.COB for your compiler

Incorrect directive(s) used when compiling GS.COB.

LINK error: Unresolved external: GS

LINK error: Unresolved externals: GS32 and/or GSWINAPI

LINK error: Unresolved externals:_GS32@16 and/or _GSWINAPI@28

Runtime error: GS32 not found

A console window appears when I run my application

Ws2_32.dll not found

I upgraded, but still seem to be running an old version of GUI ScreenIO

I use CA-Realia COBOL and get weird errors

Wrong version of GS.COB for your compiler

GS.COB, which we provide, is an intermediate module that makes it possible for any COBOL compiler to call GUI ScreenIO.  This page shows where it fits into the scheme of things.

If you use the syntax for the wrong compiler in GS.COB, it won't work correctly.  You may get compiler errors, or if it compiles, you will encounter LINK errors.

If you use Micro Focus or mbp COBOL, be sure that GS.COB includes the appropriate CALL-CONVENTION line in the SPECIAL-NAMES section. This is what causes Micro Focus Net Express and mbp COBOL to generate the CALLS to GS32 and GSWINAPI with the correct linkage conventions.

Incorrect directive(s) used when compiling GS.COB

We recommend that you set your compiler options when you compile GS.COB so that it will generate the CALLs to GUI ScreenIO as static, rather than dynamic, CALLs.  You can learn about static and dynamic CALLs in Technical Tips.  This is stuff every developer should know.

For Micro Focus and mbp COBOL, this is the compiler directive LITLINK.  Other compilers have other means of setting this. 

Note:  GUI ScreenIO will work correctly if you generate GS.COB to call it dynamically, it's just less efficient.

LINK error: Unresolved external: GS

LINK error:  Unresolved externals: GS32 and/or GSWINAPI

You did not use the correct version of GS.COB, or the correct compiler directives.

When you compile GS.COB correctly for your compiler, it will create CALLs to GUI ScreenIO's entry points GS32 and GSWINAPI using the standard Windows linkage conventions.  This causes the entry point names to be "decorated" by adding an underscore prefix and a suffix that specifies the number of bytes to be passed to the subroutine. 

In the case of GUI ScreenIO, then, the entry points GS32 and GSWINAPI are actually rendered to _GS32@16 and _GSWINAPI@28

If you didn't modify and compile GS.COB correctly, your compiler will not generate the CALLs in GS.COB using the correct linkage conventions.

You'll know this because the LINK will generate an error that GS and GSWINAPI (note the lack of name decoration) cannot be found, instead of using the correct names _GS32@16 and _GSWINAPI@28, as shown above.

LINK error: Unresolved externals:_GS32@16 and/or _GSWINAPI@28

You compiled GS.COB correctly, but you failed to include GS32.LIB (provided with GUI ScreenIO) in your LINK command.

Runtime error: GS32 not found

Why does a console window appear when I run my application?

I get the message "Ws2_32.dll not found" when I try to run a GUI ScreenIO application.

I downloaded and installed your latest version, but when I run my application it seems to be running an older version.

I use the CA-Realia compiler, and I'm getting weird CA-Realia errors.

This problem is caused by a version mismatch between the CA-Realia runtime modules distributed with GUI ScreenIO, and the CA-Realia runtime modules distributed with your compiler. 

GUI ScreenIO is distributed with several CA-Realia runtime modules because our runtime, GS32.DLL, was compiled using CA-Realia COBOL. 

When you distribute your application, you must ship the CA-Realia runtimes supplied either with your compiler, or those supplied with GUI ScreenIO - but you must not mix them! 

GUI ScreenIO only requires the CA-Realia module CARCLW60.DLL.  The panel editor uses CARCLW60.DLL (the COBOL runtime) and CARFSW20.DLL (the 32-bit file system). The conversion module may also use CARFSW16.DLL (the 16-bit file system) if you're converting a very old legacy ScreenIO application.

If you copied the CA-Realia runtimes from your compiler installation to a directory on the PATH, and then arbitrarily copy the CARCLW60.DLL from the GUI ScreenIO installation to that directory, you'll replace the DLL that came with your compiler with the one that we distribute.

If the DLLs are from different versions of the CA-Realia compiler, this may cause completely wacky errors.   It's OK to replace the CA-Realia runtime modules that we provide with later ones from your compiler installation, but just be certain that you don't mix-and-match runtimes from our installation with those from your compiler installation.  

Incidentally, this problem is not unique to GUI ScreenIO, we've seen it happen when developers ship runtimes for Visual Basic and other applications, too. You need to be careful about this stuff!

2000-2019 Norcom, all rights reserved 


Send feedback to Norcom