Glenn Linderman wrote:
> On approximately 4/18/2006 2:56 PM, came the following characters from
> the keyboard of Robert May:
>> 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.
>> (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.