I like HDF5 a lot, and I've been developing on LabVIEW bindings for HDF5
(h5labview) for some time now. However, I was recently caused some
headaches by the way version mismatch is handled by HFD5.
To summarise, when using certain constants (e.g. H5F_ACC_RDWR) the function
H5check_version (H5.c) gets called automatically, which compares the
version of the library loaded into memory to the version the code was
compiled against. If they differ at all, debug info is dumped to stderr and
abort() is called.
This might make sense on Linux, but is very annoying on Windows for the
- stderr usually goes nowhere for GUI applications, the debug message is
lost and no explanation is provided
- abort() kills the entire parent process. In the case of a managed
environment like LabVIEW, the entire runtime engine gets killed- including
the editor, and whatever other *independent* programs are running in it
simultaneously. This is especially bad because LabVIEW is often used to
control hardware, and the termination is *part-way through execution*
(usually when H5Fopen is first called), potentially causing undefined
hardware states. This eventuality is potentially unique to LabVIEW, but is
obviously a concern for me.
- The DLL has its own environment variables defined at load time,
so HDF5_DISABLE_VERSION_CHECK cannot be set locally. It can only be set
with a registry modification, making it global and potentially affecting
other installed programs.
- It goes against the "DLL philosophy" (if such a thing existed) that
libraries should be modular, shareable and upgradeable. This makes the "DLL
Hell" problem so much worse because ALL different versions of hdf5dll.dll
(now hdf5.dll) have the same name yet are mutually incompatible by design!
No two applications can share a DLL (unless they can somehow magically
guarantee version number) and the DLL can't be upgraded, which defeats the
whole point of dynamic linking!
From the user's perspective, they download some code, and as soon as they
run it the runtime is promptly killed and they have no idea why.
I understand that it is desirable to protect users from inadvertently using
incompatible versions of the library, but it seems crazy to me that one
change in the release number should break everything - particularly if you
know it's compatible because you've tested it! As an application writer I
should be allowed to implement my own check on the version and decide a
course of action, not have one forced on me (an unexplained abort() at
I propose either or both of the following:
- #ifdefs be used in H5check_version so abort is not called on Windows, and
that Win32API's MessageBox be used to present debug information instead of
- allow the version check to be disabled with an explicit command, so that
the application writer can take responsibility for compatibility problems
Actually I did think of a hack to achieve the second point just now, but
I'd rather not have to use it.