Hi all,
A quick update on what I'm looking at right now. I'm not as far along
as I wanted to be, but I lost a load of time fighting what turned out to
be a MinGW bug, and more time to a crashed hard disk on my main
development box. But all is back in order again now.
I'm near committing a Win32-GUI-DropFiles module to CVS. I've got a bit
of re-organising to do, and a couple of bugs to work around with
MakeMaker under perl 5.6, but I'm mostly there. Many thanks to Reini
for the ground-work on this.
I allowed myself to be sidetracked by Reini's comment that his code
didn't support Unicode file nmaes, and have spend a considerable time
looking at the options for how to do this. The dropfile code seemed
like a good place to start, as it's entirely new code, and has one api
that might return a unicode filename (DragQueryFile). I've reached a
conclusion on the 'right' way for us to proceed with Unicode support,
but wanted to document my findings, and ask for any further input.
Problem Statement: 'W' apis are only supported natively on WinNT and
above (not Win95/98/ME, which only support the 'A' apis). I want to
retain support for Win95/98/ME in the codebase, and only have a single
binary distribution**.
** the sinlge binary is important so that (a) we don't have confusions
with our PPMs, as I cannot find a sensible way to package both binaries
into a PPM, and get the right one installed, and (b) so that executables
packed with PAR/PerlApp etc. can be move between Win9X and WinNT systems.
Options:
(1) Use undecorated apis, and compile with -DUNICODE (and friends) on
WinNT and above. Workable, but requires 2 binary distributions.
(2) Use 'W' apis only, and do as Microsoft would have us do, linking
with their unicows.dll library. This was my preferred approach, as it
would leave us with the smallest code size, easy to understand source
and almost no performance penalty on WinNT systems. But ... MS don't
provide a link library for MinGW. Searching, I found an opensource
implementation (http://libunicows.sourceforge.net/ and it certainly did
the job for VC, MinGW and other compilers. But ... we'd need to
distribute unicows.dll, and the MS licensing terms for re-distribution
are just not compatible with our licence (we'd need to prevent our users
from further re-distribution, and need a click-through EULA at
installation) - we can't live with this. I suspect that this approach
would also leave us with problems with PAR/PerlApp packing, even if such
executables didn't also suffer from the same licensing problems. I did
find an opensource replacement for unicows.dll, but it doesn't implement
the full set of apis we need (not by a long way), and I don't want a
pre-requsite to be working on that codebase.
(http://opencow.sourceforge.net/)
(3) Drop support for Win95/98/ME - I don't want to do this yet.
(4) Write code that branches based on OS version and calls the 'A' or
'W' apis as appropriate for the platform. This will result in larger
code size, and an overhead for the switch, but is, I believe, the best
compromise. I want to work on reducing the code size anyway, and an
confident in the long term that we can minimise the number of places we
need to do this, and that the overhead can be made small. By writing
the branches carefully, and judicious usage of #ifdefs and macros it
will be possible for someone who knows that their code will only run on
NT and higher to compile a smaller and faster version with no Win9X/ME
support. This approach also makes it easy to strip the legacy Win9X/ME
code at a later date when we de-support these platforms.
Comments welcome. In the meantime I'll get on with the implementation.
Regards,
Rob.
