Dear list,
Before 1.8.8 it was quite easy to extend H5FDwindows.c (windows vfd) to cope with Unicode by using the wopen/w_char API for IO access on Windows OS'.
With 1.8.8. the windows driver was reduced to be a wrapper for the H5FD_SEC2 driver.
My question is what is the best way to come back to Unicode Windows support for file access? H5FDstdio is not recommended for productive use but could be extended similar to H5FDwindows.c in the early versions. Re-animating the the full H5FDwindows seems to be against the development of the drivers, right?
I found some discussion on this topic on this list dating the year 2009 but no conclusions.
Any ideas, help or pointers to some more info is highly appreciated.
Best regards,
Felix Gorny
This message is intended only for the use of the addressee and may contain information that is confidential and/or subject to copyright. If you are not
the intended recipient, you are hereby notified that any dissemination, copying, or redistribution of this message is strictly prohibited. If you have
received this message in error please delete all copies immediately. Any views or opinions presented in this email are solely those ofthe author
and do not necessarily represent those of Andor Technology Plc Companies. Andor Technology Plc has taken reasonable precautions to ensure
that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. Andor Technology PLC
is a registered company in Northern Ireland, registration number: NI022466. Registered Office: Andor Technology, 7 Millennium Way, Springvale Business
Park, Belfast, BT12 7AL.
Hi Felix,
Before 1.8.8 it was quite easy to extend H5FDwindows.c (windows vfd) to
cope with Unicode by using the wopen/w_char API for IO access on Windows
OS’.
With 1.8.8. the windows driver was reduced to be a wrapper for the H5FD_SEC2
driver.
My question is what is the best way to come back to Unicode Windows support
for file access? H5FDstdio is not recommended for productive use but could
be extended similar to H5FDwindows.c in the early versions. Re-animating the
the full H5FDwindows seems to be against the development of the drivers,
right?
I would say you have two options, assuming you are ok with modifying
the HDF5 code and rebuilding the library (as it seems from your
email):
1) Just modify the SEC2 driver the way you used to modify the Windows
driver. They were basically the same, which was the reason that we
tossed the Windows VFD.
2) Copy the SEC2 VFD code, rename it H5FDWindows.c, adjust the
internal names to use 'Windows' instead of 'sec2', make your fix, and
recompile.
A true Windows driver could be written pretty easily, and is at the
back of my queue, but is currently unfunded. Also, the stdio code is,
in fact, intended to be a demo driver for writing your own VFD (it
only uses the public API, not our internal API). It isn't
particularly well tested and there are a few open bugs related to
external links that have yet to be fixed.
Cheers,
Dana
Hi Dana,
Thanks for your answer!
Interesting to hear that there are plans to bring back a windows driver. Any info possible about when it might get funded and implementation time could be scheduled?
What would be the differences between a "true" windows driver and the one that was in prior to 1.8.8?
I thought of option 2) as well because 1) is nasty since we need the same code base for unix builds as well.
Best regards,
felix
···
-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@hdfgroup.org] On Behalf Of Dana Robinson
Sent: Freitag, 12. Oktober 2012 17:45
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] 1.8.8+ Unicode and Windows OS
Hi Felix,
Before 1.8.8 it was quite easy to extend H5FDwindows.c (windows vfd)
to cope with Unicode by using the wopen/w_char API for IO access on
Windows OS'.
With 1.8.8. the windows driver was reduced to be a wrapper for the
H5FD_SEC2 driver.
My question is what is the best way to come back to Unicode Windows
support for file access? H5FDstdio is not recommended for productive
use but could be extended similar to H5FDwindows.c in the early
versions. Re-animating the the full H5FDwindows seems to be against
the development of the drivers, right?
I would say you have two options, assuming you are ok with modifying the HDF5 code and rebuilding the library (as it seems from your
email):
1) Just modify the SEC2 driver the way you used to modify the Windows driver. They were basically the same, which was the reason that we tossed the Windows VFD.
2) Copy the SEC2 VFD code, rename it H5FDWindows.c, adjust the internal names to use 'Windows' instead of 'sec2', make your fix, and recompile.
A true Windows driver could be written pretty easily, and is at the back of my queue, but is currently unfunded. Also, the stdio code is, in fact, intended to be a demo driver for writing your own VFD (it only uses the public API, not our internal API). It isn't particularly well tested and there are a few open bugs related to external links that have yet to be fixed.
Cheers,
Dana
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
This message is intended only for the use of the addressee and may contain information that is confidential and/or subject to copyright. If you are not
the intended recipient, you are hereby notified that any dissemination, copying, or redistribution of this message is strictly prohibited. If you have
received this message in error please delete all copies immediately. Any views or opinions presented in this email are solely those ofthe author
and do not necessarily represent those of Andor Technology Plc Companies. Andor Technology Plc has taken reasonable precautions to ensure
that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. Andor Technology PLC
is a registered company in Northern Ireland, registration number: NI022466. Registered Office: Andor Technology, 7 Millennium Way, Springvale Business
Park, Belfast, BT12 7AL.
Hi Felix,
Interesting to hear that there are plans to bring back a windows driver. Any info possible about when it might get funded and implementation time could be scheduled?
What would be the differences between a "true" windows driver and the one that was in prior to 1.8.8?
We have no time frame for it since it's unfunded and is unlikely to be
funded in the near future. All I can say for certain is that it's not
scheduled for HDF5 1.8.10 or 11. The difference would be that all
file I/O in a proper Windows VFD would be via Win32 API calls
(CreateFile, WriteFile, ReadFile, etc.). This would potentially allow
us to use more advanced features like Win32 asynchronous I/O, NTFS
sparse files, etc.
I thought of option 2) as well because 1) is nasty since we need the same code base for unix builds as well.
Making a copy is probably what I would do. You don't even have to
change the build environment since H5FDwindows.c/h already exist. 
Dana
