Problem:
This example illustrates how to use Win32 Api functions to search a directory. File and directory attributes are interpreted and displayed.
Resolution:
INTRODUCTION
==========
This example illustrates how to use Win32 Api functions to search a directory. File and directory attributes are interpreted and displayed.
SOURCE FILES:
=============
Program Files Description
-------------------- -----------------------------------------------------------
FindFile.cbl Application program
Win32 Api Functions
============
FindFirstFile
FindNextFile
FileClose
FileTimeToLocalFileTime
FileTimeToSystemTime
PROGRAMMING:
==========
The FindFirstFile and FindNextFile Win32 Api functions require a suffix as they are passing a null terminated string. The other Win32 Api functions are numeric and a suffix is not required for these functions. All of these Api functions are in Kernel32.dll so there is no need to specify any link libraries in Build Settings as this import library is a default library for Cbllink.
The project directory includes some additional directories and files that are not normally part of a project. They are present only to see how well the names are handled by the Win32 Api functions.
You will notice that the FindFile value never changes from its initial setting. Also notice that when the search is complete the FindClose function is used to terminate the search. This is important to ensure that memory supporting the search is deallocated.
In general, I use the data names used in the Api definition. Hopefully this makes it easier to relate the COBOL code back to the Api documentation. For the COBOL data names I remove the type prefix on pointers as passing by reference in COBOL accomplishes the same as passing a pointer by value in 'C'. For other data items I keep the type prefix in place as they serve to help me get the picture and usage correct when I code the data definition. In the Win32 SDK return values are typed, but not named. For these I incorporate the type into the COBOL data name, again to help me get the picture and usage correct.
The Win32 SDK definition for the WIN32_FIND_DATA structure lists several constants, such as FILE_ATTRIBUTE_ARCHIVE. Constant definitions can be located by searching the 'C' header file identified in "Quick Info". I chose to simplify the names for these constants and coded them as level 78 COBOL constants.
Another constant from the SDK is INVALID_HANDLE_VALUE. This is a signed numeric value and requires that the handle returned by the FindFirstFile function be redefined as a signed, numeric in COBOL. In this situation I've used the actual numeric constant and included the SDK constant name as a comment.
The purpose in the seeming inconsistencies described above is to provide examples of the various ways in which you can handle these mixed language coding problems. I leave it to you to pick what is best.
With respect to the translation of file size, this example was created using Windows95. This operating system is not capable of creating files that would require using the high double word of file size. You will need to use the high double word with WindowsNT and NTFS drives.
==========================================================
Keywords: demonstration, sample, example, demo, win32 api, findfirstnetx.zip
demo.ex
demo.ne
