Windows DLL versions of the netCDF C library have usually come last in our list of supported platforms. This is not only because it was uncommon among science users, but also because we mostly don't develop in windows, and it's significantly different.

As a result we released DLLs for windows for almost all our versions, but this system broke down after the 4.0 release. Since then, we have not done a windows DLL release, and that is too long.

To try and bring windows into the mainstream of netCDF testing and development, we are now using Cygwin, with mingw32 libraries, to build netCDF DLLs.  This is something I just got working last week. The results can be seen on the daily snapshot page (you must be logged into the Unidata website to view this page):

https://www.unidata.ucar.edu/software/netcdf/builds/snapshot/

The builds on Carson are on a Cygwin machine, and the ones with description field "no OPeNDAP DLL build on Cygwin" are the DLL building tests. (The other tests on Carson are just straight Unix builds on Cygwin.)

The current results show that this is working for the non-netCDF-4 version of the DLL. But what do I mean by "working?" All tests pass, and I am left with a DLL, so that's good. But the DLL is not the whole story, Microsoft developers also need a .lib file, which describes the DLL. There is a way to produce this with my daily build too, and I have to get it working.

There is also the problem that the DLL is named cygnetcdf.dll, and it should be named netcdf.dll. A simple rename, but I have to look into why the tools put the "cyg" there in the first place, to see if it is important.

But, though much work remains to be done, I am happy to be producing a netCDF DLL as part of my daily snapshot. All this is much easier than it used to be, due to steady improvement in Cygwin and mingw32. To build this DLL, the configure must be run with options --enable-dll and --target=mingw32.

The next step is to get an automated binary release of the DLL, so that I can easily get it out to the users. In the meantime, if anyone would like to give it a try, email me and I will send it. This is the C API only, without netCDF-4 or OPeNDAP.

The end goal is to produce netCDF-4 and OPeNDAP capable DLLs, as part of the normal build process, and with the same autoconf/automake tool set we use for all other platforms.

I finally got a JNI connection to the netCDF-4 C library.

The idea is to test the Java and C libraries against each other. Since they are independent implementations, agreement likely indicates correct results.

Because I wanted to do the work on my Windows development machine, I needed to wait until Ed could build a Windows DLL for netCDF-4. He had to go through the learning hump for Visual Studio etc. I did that 8-9 years ago, and I was glad not to do it again.

I bought a commercial package JNIWrapper, a companion product for my IDE, IntelliJ. It wasn't much money for an academic license ($150 ?), but still I expected that the documentation would be more than minimum. Its OK, but not that good. It is supposed to make it easy to write JNI to native code libraries.

Anyway, I couldn't get the damn thing to work on the netcdf.dll (it worked on other dlls) so I mistakenly thought that there was something wrong with the dll. In googling around to try to solve the problem, I ran across another JNI helper library, JNA, an open source package on java.net that is actively being maintained and supported. I switched over to it - still didnt work with netcdf.dll.

I finally downloaded a trial copy of PE Explorer, which analyzed netcdf.dll and showed all the netCDF-4 DLL dependencies. So all I had to do is to make sure to explicitly load those libraries, then it all worked. I liked PE Explorer, and would buy it if I had to work much with DLLs.

So I immediately got things working with netCDF-3 files (I think I've written this code 5 times before). The 2 libraries agreed on reading all the test files I threw at it, so that's a nice feeling. There was a moment of panic on one test file - then it turned out to be truncated, and the C library silently fills in the missing parts with zeros. In the Java library, Im returning garbage. I'm going to change the Java library to detect truncation and reduce the record count to reflect the actual number of complete records.

I like JNA, simple stuff is simple. There are some dark corners in trying to write portable JNI. The netCDF library uses size_t a lot, which is an integer whose size is system dependent, and possibly compile-flag dependent. I'm mapping size_t to  JNA's NativeLongByReference which should do the right thing most of the time. Mapping to structures and pointers to arrays of Structures etc gets pretty complicated.

Im currently working on the netCDF-4 specific bindings, and learning the C API (again). I should have done this when Ed was designing it, to give him feedback, but oh well. There are a number of JNI mappings that I'm not yet sure how to do.

If things get too hard in JNA, I will see if JNIWrapper does a better job. At the moment I don't really have a comparison between them.

Oh yeah, am I glad I get to work in Java and not C. Thanks to Ed and Russ and Dennis who use that lovely language so I don't have to!