ANSI / Unicode applications (all project type)
Easy Code is able to build projects for both, ANSI and Unicode versions, in order to take advantage of the full Unicode support offered by GoAsm, GoLink and GoRC.
From version 1.04.0.0001 Easy Code runs in Unicode mode (if running on Windows NT or later) in order to offer full support for differents languages. Even so, all names and files related to projects (names for projects, resources, windows and controls) are always managed as ANSI text for compatibility reasons.
To switch between ANSI and Unicode mode, just select/unselect the Use Unicode text strings option in the Project Properties. When that option is selected, the application will be Unicode, otherwise it will be ANSI (default). For those API functions having ANSI and Unicode versions (i.e. LoadString or SetWindowText), Easy Code will ensure that the compiler is calling the appropiated function. For example, if you call the LoadString function, Easy Code will tell the compiler to call LoadStringA or LoadStringW depending on whether ANSI or Unicode version is selected, so you do not have to worry about that (you can override this behaviour by calling directly to the "A" or "W" version of the function). Besides, when working with visual projects, all strings generated by the IDE (i.e. properties having text like Name, FontName, Text or any other strings like App.CommandLine, App.FileName, App.Header and App.Path) will be given in the right format to the assembler.
The only thing you have to keep in mind when defining strings for your application, is choosing the correct format, ANSI or Unicode, for the built application to work properly. You can use the GoAsm L and A macros (see the GoAsm compiler manual).
#Define IDS_HELLO_W L"Hello" ; Explicit Unicode string
#Define IDS_HELLO_A A"Hello" ; Explicit ANSI string
As said before, Easy Code takes care of all properties text strings (visual projects) and ensures the compiler is calling the appropiated API functions (all projects). The same applies to strings declared in the String Table of the Resource Editor for all project types. Strings from resources are always stored in Unicode format and they are converted to ANSI, if needed, when they are loaded from the executable file. You just have to be careful with strings defined as raw data (see the GoRC resource compiler manual).
In order to make easier to generate text strings being valid for both, ANSI and Unicode versions, Easy Code defines the TEXT macro and the DSS type. When ANSI version is selected (Use Unicode text strings option unchecked) TEXT will return an ANSI string, while DSS will be defined as DB (byte). On the other hand, if Unicode version is selected (Use Unicode text strings option checked) the string returned by TEXT will be Unicode, while DSS will be defined as DW (word).
IDS_QUIT DSS TEXT("Are you sure you want to quit?")
IDS_LF DSS 13, 10
IDS_NULL DSS 0
Also, Easy Code defines the CHARSIZE constant, which has a value of 1 or 2 depending on whether ANSI or Unicode mode is being used. So, if you need to increase a string pointer by one character, you can use the CHARSIZE constant as follows:
Depending on the mode you are working with (ANSI or Unicode), the Esi register will be increased by 1 or 2 bytes. Besides, you can always know whether you are working in ANSI or Unicode mode by using the #IFDEF UNICODE directive in the following way:
ANSI / Unicode applications
Taking into account a few considerations, you will be able to build a project in ANSI or Unicode format without having to modify a single word in the source code (just by checking/unchecking the Use Unicode text strings option). All examples included with this version of Easy Code are programmed in that way (except the CardFile example, which is just ANSI).
1 - Defining all text strings in the String Table of the Resource Editor will work fine in both ANSI and Unicode versions and translating the application to other languages will be easier.
2 - For any other text strings and control characters defined in the source code (.Code and .Data sections), always use the TEXT macro and the DSS defined type:
IDS_STRING1 DSS TEXT("String1")
IDS_STRING2 DSS TEXT("String2")
IDS_LF DSS 13, 10
IDS_NULL DSS 0
IDS_BUFFER DSS MAX_PATH Dup ?
As MAX_PATH has a value of 260, IDS_BUFFER will be 260 bytes long for ANSI and 520 bytes long (260 words) for Unicode.
3 - When calling API functions, never call to its ANSI or Unicode version directly, i.e. LoadStringA or LoadStringW. Always use its generic name, i.e. LoadString, and let Easy Code and GoAsm to deal with it.
4 - When increasing string pointers by one character, always use the CHARSIZE constant to make sure you are increasing 1 byte for ANSI or 2 bytes for Unicode. On the other hand, remember to use the #IFDEF UNICODE directive if you need to know whether the application is ANSI or Unicode.
REMARKS: For more information about Unicode, see the GoAsm compiler manual.
The GoLink linker /mslu switch
The /mslu switch causes GoLink to add Microsoft Layer for Unicode ("mslu") loader code in the generated file so that Unicode applications can run on Windows 95, 98 or ME. For classic projects you can add the /mslu switch to the GoLink linker options text box in the Project Properties. For visual projects this switch is added internally ONLY if the Microsoft unicows.dll file is in the same folder where GoLink linker is (GoAsm\Bin) or in the system directory, as the linker needs the unicows.dll file to be in any of those two folders when using the /mslu switch. If you do not have unicows.dll (although you can easily get it from Microsoft's web), do not use the /mslu switch.
REMARKS: For more information about "mslu", see the GoLink linker manual.
Remember that when Easy Code runs in Unicode mode (that is, on Windows
NT or later
systems) the dialog box for opening and saving files is also a Unicode
Even so, once a file is selected, its path and name are always
to ANSI for compatibility reasons, so please take that into account
folders or naming objects and files for your projects.