From: Robert M. <rm...@po...> - 2006-04-18 22:01:18
|
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. |
From: Robert M. <rm...@po...> - 2006-04-19 19:41:14
|
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. |
From: Jeremy W. <jez...@ho...> - 2006-04-20 07:12:20
|
>>>(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). With Vista just round the corner and native 64bit soon to be a requirement... jez. |