Native unicode file support in BlitzMax
BlitzMax Forums/Brucey's Modules/Native unicode file support in BlitzMax
| ||
| Well, thought it was worth giving it a go, and see how we'll get on... ( I'm doing it in this forum just to keep out of the way ) First things first, I'll probably just hack in some "tweaks" to get something working. Then I imagine it's a case of putting forward the proposal for acceptance proper ;-) So... what are the current issues? 1) Complete lack of non-ascii file/dir support on all platforms. (indeed... issues on Mac too!) Possible ways to fix issues A) Implement on-the-fly Max (Wide) strings -> UTF-8 String conversion where required. (and back again, probably) B) Implement native unicode functions where required. ... anything else? Oh, I'll need some volunteers to test this on systems where there are currently problems. There's only so much "pretend" folder naming I can do myself. Please !? fun fun ;-) |
| ||
| I'm all for A) because I'm desperate to get BlitzMax core support for UTF8<->Wide string conversion. At the moment, each module that requires it, implements its own function. Messy. |
| ||
| Oh... seems the unicode friendly functions on Windows are only available from : Win NT, Win 2000, Win XP + ... That's a shame... |
| ||
| Nice! seems the unicode friendly functions on Windows are only available from : Win NT, Win 2000, Win XP + ... Unless you make use of MSLU (Microsoft Layer for Unicode). In case you haven't heard of it before, it allows wide character functions to be called on the older Windows 9X OSs. I got Mark to include libunicows into the last BlitzMax v1.30 release for MaxGUI.Win32MaxGUIEx, so you can just import it using something like... Import "-lunicows"...and then you can use all the wide-character Win32 API functions providing that a unicows.dll is distributed alongside the EXE or the Windows 9X users have MSLU installed on their system. The downside is that if the end-user has neither of the above, then they can't run the EXE. Don't know if this helps... Obviously it would be nice if it were possible to do this without breaking Windows 9X support immediately but if needs-must. |
| ||
| But do you have to Import that only if you are using the dll? How do you know when to include it? Have a 9x specific build? |
| ||
| do you have to Import that only if you are using the dll? How do you know when to include it? Have a 9x specific build? The idea is that you import it regardless and the library should check the platform and only require the DLL (or MSLU package install) if you are on the older OSs. On Windows 2000/XP/Vista it should just use the internal system DLLs like it normally would. To reiterate, if you import the library, Windows 2000/XP/Vista users will not require the DLL. It sounded like the perfect excuse to ditch MaxGUI.Win32MaxGUI, but the emulation layer is not quite as polished as the UI integrated into Windows 9X and it that specific library (libunicows) simply terminates you program if the DLL isn't found on the older OSs. There is no way of catching it (to my knowledge) so it would force Windows 9X users to carry the DLL around with them for all programs or copy the DLL into the system directory. The other problem is that there are some licensing issues with distributing the official Microsoft DLL. See the following page (specifically the 'Alternatives to MSLU') for more info: http://libunicows.sourceforge.net/ |
| ||
| Looking good so far... My unit tests are passing on all the basic file stuff (on Mac only for now) - RealPath, ChangeDir, FileType, CreateDir, DeleteDir, CreateFile.... Still more tests to write, but I'm pretty confident now. Same changes should work on Linux too, by all accounts. Heh, which will be the two important platforms done first ;-) |
| ||
| Everything works on Linux too... yay :-p |
| ||
| Ta Da!!!! All tests pass on Win32 :-) If anyone is interested in being guinea pig for this Unicode/UTF8 savvy Pub.Stdc module (and test), please drop me an email, and I'll send you the stuff to play with. Bit quick though.. dunno what I'm going to find to do tomorrow now... :-/ |
| ||
| Hey Brucey, If you send them on over, I'll have a quick look if I have time. I can't promise any serious testing though... Thanks |
| ||
| I'd help, but all my systems are english. I suppose i could rename some folders something silly, but i guess you've already tried that? This will be a really useful module though, as Bullet Candy came up against some funny languages and didn't like them, so it would be useful to get the game working in those, and also add it to my new one. This would work with your Volumes.mod right? Cheers Charlie |
| ||
| This would work with your Volumes.mod right? Yes, it should do - perhaps with a small update of it. I'm now looking at brl.system and others, to see where else we are missing unicode support. Like in requesters and so forth. |
| ||
| Wow, I post a problem and within 24 hours Brucey has it nailed. Nice work, I look forward to testing it. :) |
| ||
| It's getting there... been fixing some of the dialogs (RequestFile etc) which were bit shoddy too. Still some issues with AppDir and co, I think... |
   |