While I know FASM supports encoding ASCII as unicode (via the du directive) for application development for system that have applicable APIs for unicode, however AFAIK the original source must still be 8bit ASCII.

Are there any plans to allow source code in UTF-16 format? eg to allow symbols/labels to contain non-ASCII characters, and easier unicode string support from within the source file itself?

eg to be able to support source code like this:


Obvisously all directives and operands should remain as they are (in english as defined by Intel/AMD), but would be nice to have true support for userdefined labels and strings.

PS. I know the DOS API doesn't support unicode strings, but just used it for the example.

Look here: http://board.flatassembler.net/topic.php?t=307 (and also older thread which inspired it).
I believe something similar might be done for UTF-16.

I never quite understood the point in UTF-8/16 source files - obviously it's necessary when localizing strings, but for source code? Programming is international, and labels/data/comments should be in english, really.

Oh well, just my opinion. GoAsm has full unicode support.

Well, from the example, it allow non-english speakers to use labels, have comments, and strings in their native language, and within a single source file have ALL language scripts available.

While, I've implemented a few macros to construct UTF-16 strings from ASCII source, it doesn't help when I want to use some of the mathematical characters provided within the unicode definations. Generally I end up with:
{label} du "Greater or equal to symbol: ",2265h, 0h
even though I would prefer to see:
{label} du "Greater or equal to symbol: ≥",0h
within the source file.



Even though I agree that most of the world technology bases are english speakers (or languages that use a latinised character script), but one has to consider both India and China, which are upcoming in the technology arena. Why not cater for those non-english speakers?

I'm not saying it has to be done at all, but something that should be added to the TODO list and given some consideration.

Partially because of globalization - you have to "work without borders". I would hate being assigned a project with comments or, even worse, variable names, in non-english. People that don't speak english should really learn to, if they want to work with programming. I know this sounds harsh and cynical, but it's the reality of this world.

As for "and within a single source file have ALL language scripts available.", well... when projects get large enough, you need some external tool to manage the localized strings. I wouldn't even use unicode resource strings, as I haven't seen any resource editor that handles strings in a proper way. Also, you need to be able to ship the localization data + an editor to your translators.

Well, lots of software companies promised us "wellfare comes with unicode utf16", but still it is either badly supported or takes up a lot of space just for the fonts and other language resources.

While we watch software standards getting slowly accustomed, we could start using the full range of utf8 characters meanwhile - I mean char 128-255 have always been supported by fasm, and with proper keyboard codepages, you can even use them like this:

Even if I would have a compiler that supports russian characters for identifiers (and actually I CAN declare symbols with russian characters using FASM) I would never use this feature. First, because it's habit alike. Second, you never know who'll read your source, and English is an international language. So IMHO it's not a good idea to support Unicode source files.

This is the most obvious reason for me too. You know, I don't use German identifiers neither. (But my senile IT-teacher likes to use them, ' have no idea why )

One of my friends got a job for a company that makes software for the educational sector (exam planning and such). First, they use danish identifiers (including danish chars, æøåÆØÅ). Second, they use smalltalk . It's pretty damn awful. There's some pretty heavy calculations in there as well, and needless to say smalltalk isn't very fast.

Companies like that should have a thorough beating.

But it's unlikely that this will happen since all of those users (school mark and bulletin office users)don't care, e.g. would have no practical use of that nor have they any specific idea about the software itself. They are just used to using sloppy, lame software and won't change it ASAP, since this may actually reduce the time they need to work on it and may get less money. Thats the whole said story.

Unfortunately, they *are* used to slow and sloppy software - they don't question that it takes 10+ seconds from clicking a button until the resulting dialog shows up. Nor that the computations can take a couple hours when it should take max 15 minutes.

*sigh*