Glenn Linderman wrote:
On approximately 4/18/2006 2:56 PM, came the following characters from
the keyboard of Robert May:
[snip]
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.
There has been discussion recently on p5p about the fact that ActivePerl
implementation of operators like -d -r -f etc. also do not support
Unicode file names. The question has been asked if ActiveState has any
plans to fix that.
Thanks. I'm already following that thread, and have looked quite
extensively at the win32 parts of the perl source in the last weeks.
It's peppered with branches that call the W and A decorated win32 apis,
based on an USING_WIDE() macro, that is currently defined as 0.
[options for supporting Unicode in Win32::GUI]
(1) Use undecorated apis, and compile with -DUNICODE (and friends) on
WinNT and above. Workable, but requires 2 binary distributions.
And, it is not clear that it even works/helps. I experimented a while
with adding -DUNICODE to the compiles of Win32::GUI, and found no change
in behavior! So I know a lot less about Windows APIs than you do--maybe
you could get it to work, but I agree that since the expected result
doesn't meet the goal, that figuring out that direction isn't worthwhile.
It's not as simple as just defining -DUNICODE, as the W apis give us
UCS-2, and that needs converting to UTF-8 for perl usage - pretty much
anything that uses a string would need re-writing to work.
[snip]
(3) Drop support for Win95/98/ME - I don't want to do this yet.
I'd rather not drop support for Win9x yet either. Still have clients
using it...
I'm still using it, and I don't want to have to pay MS to upgrade yet
(althoug a new PC is on the horizon).
(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.
Sounds good to me. I'll be glad to hear what you are doing, and help as
able, which may not be much more than encouraging comments
Having finished coding the DropFiles implementation, I can confirm that
I have not yet found a reason why this will not work. Just some
documentation to go.
... right now
I'm discovering that the latest versions of ImageMagick and PAR don't
work together, and it seems that the solution is either to find a
solution other than PAR, or fix PAR.... :(
I've seen your threads in perl.par and on perl-win32-users. I'm not am
ImageMagick user, so can't help here.
Regards,
Rob.
