Unicode support arrives (in SVN)

The SVN version of Blitzmax now supports Unicode filesystems.

If you have problems, remembering that SVN is "in development", then feel free to shoot the messenger, as it is all my fault.

I'm 99% sure I've covered everything, but you know how it goes... so if stuff stops working, you should be vocal about it. (although verbal abuse should remain at your end of the keyboard) :-)

BlitzMax compiling is NOT Unicode friendly yet. So if you try to build something in a non-ASCII folder, don't expect to get very far ;-)
Hopefully, it'll all filter down into the toolset over time.

For pre Win2k/NT systems, you may need to include Unicows, but Seb knows more about that than me, so I think he should explain what that's all about. (Go Seb!)

Otherwise, everything should work as it did before. ie. you shouldn't notice any difference. Obviously if your app doesn't work at all now, then there's a bug somewhere :-)



Enjoy

:o)

Nice!

I think it's time they issue you one of these:

EDIT: Hmmmm... some problems with the new version.

The Threading version of MaxGUI fails now building with the following error:



I wiped the MaxGUI folder and re-downloaded it, but the build still fails with the same error. Any ideas? :-?

in brl.mod/blitz.mod/blitz.h

try adding :

#define UNICODE

before this

#ifdef THREADED
#include "bdwgc/include/gc.h"
#endif

And let me know if that solves it.

Yup, that appears to have fixed it, with that addition it compiled without errors.

Thanks again!

You sir, are my hero.

Hold on, Brucey can't be *both* Superman and Batman, that's just silly.

...and anyways... I don't really have time to be saving the world. Got modules to work on!! :-p

It's surprising what brucey can pull off =p

hi,

unfortunately i got the same error, but bruceys solution did not fix the problem, bmk throws again the error

any suggestions?

It should solve the issue. Otherwise you must have a different error?

it happens both on building threaded or non threaded


This ist beginning of my modified blitz.h

#ifndef BLITZ_H
#define BLITZ_H


#include <pub.mod/stdc.mod/stdc.h>

#define UNICODE
#ifdef THREADED
#include "bdwgc/include/gc.h"
#endif

MinGW Version

D:\BlitzMaxSNV\dev\main\bin>gcc --version
gcc (GCC) 3.4.5 (mingw-vista special r3)

Have you sync'd your MaxGUI with the latest in SVN?

oh, many thanks for the tipp - it is in the same dir, but has to be updated seperately

after syncing it worked flawlessy :)

Hi Brucey,

Just noticed that, after a "Rebuild All Modules" on Windows, MaxIDE now chokes at start-up complaining about not being able to find the BlitzMax version which means that CreateProcess() is failing to start the 'bcc' process.

Looks like Pub.FreeProcess perhaps needs some Brucey-love. Replacing the fdProcess declaration in freeprocess.bmx with...

?Win32
Function fdProcess(exe$w,in_fd Ptr,out_fd Ptr,err_fd Ptr,flags)="fdProcess"
?Not Win32
Function fdProcess(exe$z,in_fd Ptr,out_fd Ptr,err_fd Ptr,flags)="fdProcess"
?

...seems to fix this particular case, but the fdRead() and fdWrite() stuff probably needs some attention and the *nix declarations probably want UTF8'ing. ;-)

Any thoughts?

ahh... it's complicated..

ReadFile() - which is used internally, will be working on wchar_t, I guess... which complicates things somewhat probably.

Since Skid is the mastermind behind this, perhaps he has an idea of the best way to handle this.

I wouldn't want the API to be different (ie. Short Ptr instead of Byte Ptr) for Read() or Write().
Perhaps internally it wants to use a wchar_t buffer and copy the byte data???

Unless we don't care what the bytes are - since it may well be binary data... and you don't want to mess with it.
Leave it up to the user to worry about the data stream?

fdProcess of course needs the fix.

After further review, I think we can get away with not changing fdread and fdwrite... (heh.. at least until it doesn't work!) :-p