950328: netCDF for 32-bit Compiled Code

>Keywords: 199503282129.AA10529 netCDF MSDOS Watcom
>From: address@hidden
>Organization: SSEC

Ray,

Some time ago I received the following message from Ben Howell:

>When we first started using the WATCOM 32-bit FORTRAN compiler, a couple of
>years ago, I asked you about the availability of netCDF code which could be
>compiled, on a PC, with a compiler other than that of Microsoft.  At that
>time you indicated that this had not been done, but that you were interested,
>if we progressed with it.  Well, we (meaning personnel here at UW/SSEC) have
>developed a netCDF library, and C-language interface routines for FORTRAN,
>and have used these to read some netCDF data files and write the data in our
>own format, for comparison with the original data.  It has made our task of
>verifying netCDF files much easier, and I thought you might be interested.
>
>If so, contact Ray Garcia, the person who accomplished this development, at
>his E-mail address: address@hidden.  Ray, who is a student employee,
>works only part time, so he's hard to reach by phone.

I am interested in the work that you have done in this area and wish learn
more about what it took for you to get the netCDF working with the Watcom
32-bit compilers.

Tom

>From address@hidden Tue Jun 13 12:30:00 1995
>    Summarizing as best I can what was nearly a "whatever means necessary"
>port to OS/2 2.x, the NetCDF libraries I've generated were built for the two
>development platforms Ben and I use most here - IBM C/Set++ and Watcom
>Fortran. The resultant libraries (DLLs) pass the netCDF internal tests and all
>application runs Ben's run on them so far, though I would categorize this
>build as a beta.
>
>    There is a limitation that I haven't overcome yet which (once solved)
>would allow the use of the library from Watcom C: in using C/Set++, I was
>forced to use the register-passing convention ("Optlink") instead of the
>"System" convention, as the C libraries would crash if passed a "System"
>(stack passing) convention function pointer (e.g. qsort()).
>
>    My approach was therefore to limit the System convention to the fortran
>jackets code for Watcom (which required extensive modification anyway and
>were isolated from the main library), providing NetCDF.DLL for C/Set++ and a
>C/Set-compiled NCFort.DLL which would act as both a parameter and parameter
>passing convention jacket DLL.
>
>    The steps involved were to 1) pull down the 2.3.2 PL2 code, and 2) apply
>the PL4 patches; 3) modify for ICC (C/Set compiler) the makefile hierarchy
>for Watcom C that I found on an FTP site (this set of makefiles may suffice
>for a Watcom C generate, though I haven't tried it), 4) apply only necessary
>changes to the library source code, 5) generate a DLL for C and C++
>applications' use, and 6) change the jackets code to generate a fortran
>jacket DLL for Watcom Fortran32.
>
>    If you want to take a peek at an image of my development directory, I've
>placed it in \pub\netCDF\netcdf.zip (Info-ZIP format).  The changes to the
>library itself were pretty minimal; I compiled it using mostly MSDOS flags,
>but made an effort to enable proper file-sharing practices for OS/2.  I
>believe there may have been problems with incorrect (non-constant)
>initializations that caused me the most grief.
>
>    The modified makefile WATCOM.MK is the head of a network of WATCOM.MK
>files which build netcdf.lib and xdr.lib, statically linked libraries
>comprising the NetCDF release. These were then linked to a dummy.c file and
>by way of a set of emitted entry points (netcdf.def) was created NetCDF.DLL;
>an import library (ncdfdll.lib) was then ejected from the DLL using implib.
>Note that I generated the DLLs from the command line (I'm haven't gotten
>around to adding it to the Makefiles, sorry).  I believe the specific command
>used to generate the main DLL is in '.history'.
>
>    The FORTRAN jackets have been revamped to access Watcom Fortran32's
>string storage properly (removing the assembly language fslen) and compiled
>into a DLL using another .def export list and a .lib to link to.
>
>    In short, it's not all RCS'd up and prettified, and there are probably
>one or two apocryphal comments, but it does appear to do the job, and so far
>as I can recall, it doesn't have ugly hacks. I certainly wouldn't mind
>contributing toward getting blessed 32-bit OS/2 support into a future NetCDF
>release, and I personally have no problems with putting the code I've added
>into the public domain, though I think SSEC has a bit more say in the matter
>(though I doubt that'll be a problem).
>
>    On the other side of the coin, I've got plenty of tasks here at SSEC and
>am not sure how much priority I can assign, unless there are problems found
>which would threaten our present or future operational use of the libraries.
>If you or others want to ask questions, make recommendations, point out (or
>better yet, correct) errors or inconsistencies, et cetera, by all means do so
>and I'll try to respond expediently.
>
>
>Raymond Keoni Garcia, address@hidden
>University of Wisconsin - Madison  Space Science & Engineering Center
>"No ASCII characters were harmed or mistreated in the making of this .sig."