Let him suffer for not knowing English.
April 28, the comedy "The Diamond Arm" turned 50 years old.
I looked through the source code of fasm and thought that it might be possible to try to arrange in the past so that the author of the fasm would meet with the great Austalian humanist and show him the source code? Obviously, after this meeting, another shallow grave will appear in the Australian bush, and you will now be the elite programmer on MASM. What do you think?
On NASM, not MASM. Also I think:
OK, as you wish.
What code? Everything is linked with libraries.
I remembered that I have several small programs written without links to libraries. Here is one of them, written back in 2016. It shows the obvious superiority of using MASM over other Assemblers when creating programs with Unicode support. When non-MASM programmers use macros, strings from resources or stupidly manually translate Unicode letters into codes, modest MASM programmers simply write the source directly in Unicode.
Something like that, for example (at the same time, we will check how this forum supports Unicode):
;
.386
.MODEL FLAT, STDCALL
OPTION CASEMAP: NONE
;
IncLib MACRO fn
INCLUDE \Masm32\INCLUDE\fn.inc
INCLUDELIB \Masm32\LIB\fn.lib
ENDM
;
MovE MACRO dst, med, src
MOV med, src
MOV dst, med
ENDM
;
INCLUDE \Masm32\INCLUDE\Windows.inc
;
IncLib User32
IncLib Kernel32
;
INCLUDE HelloUcW.inc
;
WmMouseOverBtn EQU 7FFFh
MovTimerId EQU 1
MovTimerPer EQU 15
BtnStepNum EQU 10
;
WM TYPEDEF Dword
ID TYPEDEF Dword
ND TYPEDEF Dword
PSZ TYPEDEF Ptr CHAR
PWSZ TYPEDEF Ptr WCHAR
PCODE TYPEDEF Ptr Proc
;
BTN_MOV STRUCT
Xcur ND ?
Xstep ND ?
Xmin ND ?
Xmax ND ?
Y ND ?
Width_ ND ?
Height ND ?
BTN_MOV ENDS
;
prDlgMain PROTO hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
prBtnOk PROTO hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
calcBtnMov PROTO hdlgMain:HWND, htxtRef:HWND
setTextArrA PROTO hWnd:HWND, pArrSz:PSZ, ndSz:ND, idStartSz:ID
setTextArrW PROTO hWnd:HWND, pArrWSz:PWSZ, ndWSz:ND, idStartWSz:ID
;
.DATA
szDlgTitle CHAR 'Hello, Asm Unicode World!', 0
;
aszLang LABEL CHAR
szGreek CHAR 'Greek:', 0
szItalian CHAR 'Italian:', 0
szFrench CHAR 'French:', 0
szSpanish CHAR 'Spanish:', 0
szEnglish CHAR 'English:', 0
szGerman CHAR 'German:', 0
szHindi CHAR 'Hindi:', 0
szArabian CHAR 'Arabian:', 0
szHebrew CHAR 'Hebrew:', 0
szChinese CHAR 'Chinese:', 0
szJapanese CHAR 'Japanese:', 0
szKorean CHAR 'Korean:', 0
szVietnamese CHAR 'Vietnamese:', 0
szMongolian CHAR 'Mongolian:', 0
szTurkish CHAR 'Turkish:', 0
szAzerbaijani CHAR 'Azerbaijani:', 0
szUzbek CHAR 'Uzbek:', 0
szKazakh CHAR 'Kazakh:', 0
szTajik CHAR 'Tajik:', 0
szFinnish CHAR 'Finnish:', 0
szEstonian CHAR 'Estonian:', 0
szArmenian CHAR 'Armenian:', 0
szGeorgian CHAR 'Georgian:', 0
szSerbian CHAR 'Serbian:', 0
szBulgarian CHAR 'Bulgarian:', 0
szCratian CHAR 'Croatian:', 0
szCzech CHAR 'Czech:', 0
szPolish CHAR 'Polish:', 0
szUkrainian CHAR 'Ukrainian:', 0
Belarusian CHAR 'Belarusian:', 0
szRussian CHAR 'Russian:', 0
;
ALIGN WCHAR
.RADIX 16
awszHello LABEL WCHAR
wszGreek WCHAR "Γεια σου κόσμε!",0
wszItalian WCHAR "Ciao, mondo!",0
wszFrench WCHAR "Bonjour le monde!",0
wszSpanish WCHAR "Hola Mundo!",0
wszEnglish WCHAR "Hello, World!",0
wszGerman WCHAR "Hallo Welt!",0
wszHindi WCHAR "नमस्ते दुनिया!",0
wszArabian WCHAR "!مرحبا بالعالم",0
wszHebrew WCHAR "!שלום עולם",0
wszChinese WCHAR "你好，世界！",0
wszJapanese WCHAR "こんにちは世界！",0
wszKorean WCHAR "안녕, 세상!",0
wszVietnamese WCHAR "Xin Chào, Thế Giới!",0
wszMongolian WCHAR "Сайн байна уу, Дэлхийн!",0
wszTurkish WCHAR "Selam Dünya!",0
wszAzerbaijani WCHAR "Salam, Dünya!",0
wszUzbek WCHAR "Salom Dunyo!",0
wszKazakh WCHAR "Сәлем Әлем!",0
wszTajik WCHAR "Салом, ҶАҲОН!",0
wszFinnish WCHAR "Height maailma!",0
wszEstonian WCHAR "Tere, Maailm!",0
wszArmenian WCHAR "Բարեւ Աշխարհը!",0
wszGeorgian WCHAR "გამარჯობა მსოფლიო!",0
wszSerbian WCHAR "Здраво, Свет!",0
wszBulgarian WCHAR "Здравей, Свят!",0
wszCroatian WCHAR "Zdravo, svijete!",0
wszCzech WCHAR "Ahoj světe!",0
wszPolish WCHAR "Witaj, Świecie!",0
wszUkrainian WCHAR "Привіт, Світ!",0
wszBelarusian WCHAR "Прывітанне Сусвет!",0
wszRussian WCHAR "Дратути!",0
.RADIX 10
;
.DATA?
sBtnMov BTN_MOV <>
hInstance HINSTANCE ?
hdlgMain HWND ?
hbtnOk HWND ?
pprBtnOkSys PCODE ?
;
.CODE
START:
INVOKE GetModuleHandle, NULL
MOV hInstance, EAX
INVOKE DialogBoxParamW, hInstance, MainDlgId, NULL, Addr prDlgMain, NULL
INVOKE ExitProcess, EAX
;
prDlgMain PROC Uses EDI hwnd:HWND, umsg:UINT, wparam:WPARAM, lparam:LPARAM
MOV EAX, umsg
MOV ECX, LengthOf tblwm
LEA EDI, tblwm
REPNE SCASD
JNE procwm
ADD EDI, SizeOf tblwm
PUSH exit ; For supported WM only
procwm:
JMP PCODE Ptr [EDI]
.DATA
ALIGN WM
tblwm WM WM_INITDIALOG, WM_TIMER, WM_COMMAND, WM_CLOSE
PCODE skip ; If WM not supported
pmou PCODE wminitdialog
ptim PCODE processed, wmcommand, wmclose
.CODE
wminitdialog:
MovE hdlgMain, EAX, hwnd
INVOKE SendMessageA, hwnd, WM_SETTEXT, NULL, Addr szDlgTitle
INVOKE LoadIcon, hInstance, MainIconId
INVOKE SendMessage, hwnd, WM_SETICON, MainIconId, EAX
INVOKE GetDlgItem, hwnd, OkBtnId
MOV hbtnOk, EAX
INVOKE SetWindowLong, EAX, GWL_WNDPROC, Addr prBtnOk
MOV pprBtnOkSys, EAX
INVOKE setTextArrA, hwnd, Addr aszLang, LangRowNum, StartTxtAId
INVOKE setTextArrW, hwnd, Addr awszHello, LangRowNum, StartTxtWId
INVOKE GetDlgItem, hwnd, GreekTxtAId
INVOKE calcBtnMov, hwnd, EAX
INVOKE SetTimer, hwnd, MovTimerId, MovTimerPer, NULL
MOV tblwm, WmMouseOverBtn ; Instead WM_INITDIALOG
MOV pmou, setleftmov
STC
RETN
;
wmclose:
INVOKE KillTimer, hwnd, MovTimerId
INVOKE EndDialog, hwnd, NULL
STC
RETN
;
wmcommand:
CMP wparam, (BN_CLICKED Shl 16) Or OkBtnId
JNE notprocessed
INVOKE SendMessage, hwnd, WM_CLOSE, NULL, NULL
processed:
STC ; CF = 1: processed
RETN
notprocessed:
CLC ; CF = 0: not processed
RETN
;
; Mouse is over OK button: set motion handler on timer
setleftmov:
LEA EAX, movbtnleft
JMP mouoveroff
setrightmov:
LEA EAX, movbtnright
mouoveroff:
MOV ptim, EAX ; Set btn moving handler on timer
MOV pmou, processed ; Mouse over btn off
STC
RETN
;
; Button motion handlers
loadbtnmovstuff:
LEA EDX, sBtnMov
ASSUME EDX: Ptr BTN_MOV
MOV EAX, [EDX].Xstep
MOV ECX, [EDX].Xcur
RETN
movbtnleft:
CALL loadbtnmovstuff
SUB ECX, EAX ; Xcur = Xcur - Xstep
MOV EAX, [EDX].Xmin
CMP ECX, EAX
JG movbtn ; Xcur > Xmin
MOV ECX, EAX ; Xcur = Xmin
LEA EAX, setrightmov
JMP stopbtn
movbtnright:
CALL loadbtnmovstuff
ADD ECX, EAX ; Xcur = Xcur + Xstep
MOV EAX, [EDX].Xmax
CMP ECX, EAX
JL movbtn ; Xcur < Xmin
MOV ECX, EAX ; Xcur = Xmax
LEA EAX, setleftmov
stopbtn:
MOV pmou, EAX ; Trigger on mouse over btn
MOV ptim, processed ; Timer off
movbtn:
MOV [EDX].Xcur, ECX
INVOKE MoveWindow, hbtnOk, [EDX].Xcur, [EDX].Y, \
[EDX].Width_, [EDX].Height, TRUE
ASSUME EDX: Nothing
STC
RETN
;
skip:
CLC
exit:
MOV EAX, 0
ADC EAX, EAX ; Set to FALSE or TRUE accord. CF
RET
prDlgMain ENDP
;
prBtnOk PROC hwnd:HWND, umsg:UINT, wparam:WPARAM, lparam:LPARAM
CMP umsg, WM_MOUSEMOVE
JNE sysproc
INVOKE PostMessage, hdlgMain, WmMouseOverBtn, wparam, lparam
sysproc:
LEAVE
JMP [pprBtnOkSys]
prBtnOk ENDP
;
calcBtnMov PROC Uses EBX EDI hdlgm:HWND, htxtref:HWND
LOCAL srctxt: RECT
LOCAL srcbtnok: RECT
LEA EBX, srcbtnok
ASSUME EBX: Ptr RECT
INVOKE GetWindowRect, hbtnOk, EBX
INVOKE MapWindowPoints, HWND_DESKTOP, hdlgm, EBX, SizeOf RECT/SizeOf POINT
INVOKE GetWindowRect, htxtref, Addr srctxt
INVOKE MapWindowPoints, HWND_DESKTOP, hdlgm, Addr srctxt, SizeOf RECT/SizeOf POINT
LEA EDI, sBtnMov
ASSUME EDI: Ptr BTN_MOV
; MoveWindow requires height & width of window instead of bottom & right coords
MovE [EDI].Y, EDX, [EBX].top
MOV EAX, [EBX].bottom
SUB EAX, EDX ; Button Height
MOV [EDI].Height, EAX
MovE [EDI].Xmin, EDX, srctxt.left
MovE [EDI].Xmax, EAX, [EBX].left
MOV [EDI].Xcur, EAX ; Current X coord.
MOV ECX, [EBX].right
SUB ECX, EAX ; Button width
MOV [EDI].Width_, ECX
SUB EAX, EDX ; Button Xpath = Xmax - Xmin
XOR EDX, EDX
MOV ECX, BtnStepNum
DIV ECX ; Xstep= Xpath / XstepNum
MOV [EDI].Xstep, EAX ; Pixels per step
ASSUME EBX: Nothing, EDI: Nothing
RET
calcBtnMov ENDP
;
setTextArrA PROC hwnd:HWND, pasz:PSZ, nsz:ND, isz:ID
sendloop:
INVOKE SendDlgItemMessageA, hwnd, isz, WM_SETTEXT, NULL, pasz
DEC nsz
JZ exit
INC isz
INVOKE lstrlenA, pasz
INC EAX ; Skip 0
ADD pasz, EAX ; Next string
JMP sendloop
exit:
RET
setTextArrA ENDP
;
setTextArrW PROC hwnd:HWND, pawsz:PWSZ, nwsz:ND, iwsz:ID
sendloop:
INVOKE SendDlgItemMessageW, hwnd, iwsz, WM_SETTEXT, NULL, pawsz
DEC nwsz
JZ exit
INC iwsz
INVOKE lstrlenW, pawsz
INC EAX ; Skip 0
ADD EAX, EAX ; Words->Bytes
ADD pawsz, EAX ; Next string
JMP sendloop
exit:
RET
setTextArrW ENDP
;
END START
;
Screenshot notarized by SkyNet and executable are attached.
Using UTF-16 is not a good idea IMHO. In fact, there are two more or less reasonable alternatives: UTF-8 is you want to be small and ANSI compatible and UTF-32 if you want to be fast. FreshLib uses UTF-8.
Unfortunately, Micro$oft did not ask your HO and made this encoding as Unicode in Windows. However, as you might see, I use UCS-2 encoding in this program, not UTF-16, i.e. without surrogates, otherwise setTextArrW would look a bit more complicated.
I know. That is why I use batch file instead of any IDE, because they are convenient and very easy to modify for anything. For example, I used this batch file as IDE when developing that program:
@echo off
set PROJ=HelloUcW
call Settings.bat
:LOOP
@echo Project: %PROJ%
@echo [A]ssemble [R]un [D]elTrash [L]ist:%LST% [Q]uit
@choice /C:ARDLQ /N >nul
if errorlevel 5 goto QUIT
if errorlevel 4 goto SWLIST
if errorlevel 3 goto DELTR
if errorlevel 2 goto RUN
\Masm32\bin\nmake.exe /f %PROJ%.mak
goto LOOP
:RUN
%PROJ%
goto LOOP
:DELTR
call DelTrash.bat
goto LOOP
:SWLIST
if %LST%==Y goto LISTOFF
set LST=Y
goto SAVEVARS
:LISTOFF
call DelLists.bat
set LST=N
:SAVEVARS
@echo : Settings for MakeIt.bat>Settings.bat
@echo set LST=%LST%>>Settings.bat
goto LOOP
:QUIT
Because M$ never asked my HO, now I am using only Linux. 
Well, since you're writing in Asm under Linux, then why don't you translate Fresh to UTF-16 to bring the resentment of red-eyed penguins to the limit? In addition, this encoding is almost entirely fixed-width characters (excluding the 2K range), which will be a small but pleasant bonus to the basic motivation.
Well, "almost" is not enough. If I need fixed-width encoding, I will use UTF-32. But for now, I am considering the small size and ANSI compatibility more important, so I am using UTF-8. It is really not so hard for processing and the variable width is a performance problem very rarely.
On the other hand UTF-16 is the most inconvenient way to encode UNICODE. Why I should use it if I am not forced by the OS API?
Well, emoticons and Egyptian hieroglyphs can be ignored before the introduction of UTF-32 IMHO.
I would definitely use this encoding precisely because it is about the same as using Asm in Linux.
Actually, I slightly exaggerated the possibilities of MASM (you initially knew about this, of course). MASM, of course, does not support Unicode - I just use a converter.
But as a result, there was an interesting opportunity to use Unicode and ASCII encoding simultaneously. In general, with this converter any, even the most ancient mammoth shit, can work with Unicode (now UCS-2). The only requirement: Asm should understand the text in single quotes as strings (strings in double quotes are translated by converter into hex words).
Today I checked the ability to display surrogate pairs and found that the setTxtArrW procedure works correctly, because lstrlenW considers surrogate pairs as two words, not one character. So UTF-16 is supported.
Another thing is that even on Windows 7 x64 Unicode font in the field of surrogate pairs I did not find any characters at all.
In addition to the previous post: it is interesting that the ranges of the first and second surrogates do not match. Therefore, it is possible to make an incorrect pair and then this pair will be displayed as two non-printable characters (as two squares). If the pair is made correctly, then it is displayed as one square (no symbols were found in the surrogate range). That is, the developers have narrowed the maximum possible range of 4 million to 1 million characters.
If someone gave the alphabet to the Chinese, Koreans and Japanese before the introduction of Unicode, then UTF-16 would be enough without any surrogates.
By the way, about the missed opportunities: are you still a fasm programmer, not nasm one?
Yes, I am. Every compiler must be self hosted. Or there is no reason to use it. If even its authors preferred not to use it... 
Well, actually I tried to change something in the past, but apparently something went wrong, sorry.
I don’t know if you could compile the file without all the project files, but I didn’t publish the whole project, because I have long wanted to slightly expand the capabilities of the converter and used this opportunity to return to the development. As a goal, I chose one of the most monstrous assemblers - Atmel Avrasm, just look at its C-like syntax
As in C, strings in this asm can only be in double quotes, and characters only in single quotes. So I had to enter the key to convert single quotes into double quotes.
Source:
;
.NOLIST
.INCLUDE 'm48def.inc'
.LIST
.LISTMAC
;
.EQU CR = $D
.EQU LF = $A
.EQU DQ = $22
;
.MACRO LdiW
LDI @1, Low (@2)
LDI @0, High (@2)
.ENDMACRO
;
.ESEG
ewszDblQuo: .DW "Это ""UTF-16"" строка", 0
eszDblQuo: .DB 'This is ', """", 'ASCII', """",' string with dbl.quot.marks', CR, LF, 0
eszDQ: .DB 'This is ', DQ, 'ASCII', DQ, ' string with DQ EQU', CR, LF, 0
;
.CSEG
START:
LDI R17, "U"
LdiW XH, XL, "Ж"
D_LOOP:
RJMP D_LOOP
;
cwszDblQuo: .DW "Это ""UTF-16"" строка", 0
cszDblQuo: .DB 'This is ', """", 'ASCII', """",' string with dbl.quot.marks', CR, LF, 0
cszDQ: .DB 'This is ', DQ, 'ASCII', DQ, ' string with DQ EQU', CR, LF, 0
;
.EXIT
;
The result of the converter:
;
.NOLIST
.INCLUDE "m48def.inc"
.LIST
.LISTMAC
;
.EQU CR = $D
.EQU LF = $A
.EQU DQ = $22
;
.MACRO LdiW
LDI @1, Low (@2)
LDI @0, High (@2)
.ENDMACRO
;
.ESEG
ewszDblQuo: .DW $42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
eszDblQuo: .DB "This is ", $22, "ASCII", $22," string with dbl.quot.marks", CR, LF, 0
eszDQ: .DB "This is ", DQ, "ASCII", DQ, " string with DQ EQU", CR, LF, 0
;
.CSEG
START:
LDI R17, $55
LdiW XH, XL, $416
D_LOOP:
RJMP D_LOOP
;
cwszDblQuo: .DW $42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
cszDblQuo: .DB "This is ", $22, "ASCII", $22," string with dbl.quot.marks", CR, LF, 0
cszDQ: .DB "This is ", DQ, "ASCII", DQ, " string with DQ EQU", CR, LF, 0
;
.EXIT
;
Among other things, the example demonstrates how to place double quotes in strings (neither the Asm- nor the C-syntax is supported by this assembler). Hexadecimal numbers are defined in it using the prefixes 0x or $, so I had to enter the prefix definition key. In addition, fixed a bug that did not allow to specify any extension of the output file.
By the way, I had to modify the batch file to build the executable, because in the modern Masm32 package, there is no h2inc.exe utility, so you have to search it on the web or use h2incX.exe, developed by Japheth, instead. It can be downloaded from the developers site of a very cool Uasm assembler, the possibility of choosing which for assembly I also included in this batch file.
And of course in the Masm32 package there is no converter itself - this brilliant crutch, when meeting with the incredible capabilities of which the whistle of the great Australian humanist burnt so much that all his professionalism instantly fell off of him and he began bravely to spit shit in the back of the cyborg.
They said "a clever man"... However, sometimes people say strange things.
The complete packages for compiling examples consecrated by SkyNet are attached.
Upd: The converter is packaged separately and the M$ h2inc.exe utility package has been added.
Well, I can't see C-likeness in the avrasm syntax. BTW, I am using AVRA which is (almost) compatible:
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info
AVRA is an open source assembler for Atmel AVR microcontroller family
It can be used as a replacement of 'AVRASM32.EXE' the original assembler
shipped with AVR Studio. We do not guarantee full compatibility for avra.
AVRA comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of avra under the terms
of the GNU General Public License.
For more information about these matters, see the files named COPYING.
Description of strings and single characters: strings in double quotes only, single characters in single quotes only. In assembler free use of quotes.
C-style escape sequences \n \r, etc.
Using the prefixes 0x 0b instead of the suffixes h b.
Ability to use C-style comments.
C-style operators !~ << >> || == != etc.
Yes, I know this assembler and in my development there is an opportunity to quickly change the assembler. The main difference is that Avrasm uses a 64-bit internal representation of variables, and avra uses 32-bit and it is easier to get overflow in calculations (apparently, therefore, avra has no .DQ directive). But avra has more advanced macros (in the C-style, by the way).
Perhaps yesterday it made sense to place here not only the result of the converter, but also the listing (after all, the chips are outdated and not everyone has these assemblers).
So, Unicode on Atmel AVR microcontrollers... How do you like this, Elon Musk?
AVRASM ver. 2.0.28 UniAvr._as Thu May 32 02:08:14 2019
UniAvr._as(3): Including file '\AVR\INC\m48def.inc'
.LIST
.LISTMAC
;
.EQU CR = $D
.EQU LF = $A
;
.MACRO LdiW
LDI @1, Low (@2)
LDI @0, High (@2)
.ENDMACRO
;
.CSEG
START:
000000 e515 LDI R17, $55
+.MACRO LdiW
000001 e1a6 + LDI XL, Low ($416)
000002 e0b4 + LDI XH, High ($416)
LdiW XH, XL, $416
D_LOOP:
000003 cfff RJMP D_LOOP
;
000004 042d
000005 0442
000006 043e
000007 0020
000008 0022
000009 0055
00000a 0054
00000b 0046
00000c 002d
00000d 0031
00000e 0036
00000f 0022
000010 0020
000011 0441
000012 0442
000013 0440
000014 043e
000015 043a
000016 0430
000017 0000 cwszDblQuo: .DW $42D,$442,$43E,$20,$22,$55,$54,$46,$2D,$31,$36,$22,$20,$441,$442,$440,$43E,$43A,$430, 0
000018 6854
000019 7369
00001a 6920
00001b 2073
00001c 4122
00001d 4353
00001e 4949
00001f 2022
000020 7473
000021 6972
000022 676e
000023 0a0d
UniAvr._as(23): warning: .cseg .db misalignment - padding zero byte
000024 0000 cszDblQuo: .DB "This is ", $22, "ASCII", $22," string", CR, LF, 0
;
...
Assembly complete, 0 errors, 1 warnings
EEPROM section and some strings are removed from the source and the listing for compactness.
And that is not all.
So you say: "why does this cyborg use UTF-16 when everything works with UTF-8?". Well, you do not say it - you think. So I decided to check how well it works, and here is the result:
For the test, the simplest UTF-8 string was used, consisting of alternating consecutive Latin characters and one Chinese hieroglyph (to make it easier to orientate). On the right side of the picture, this string is displayed in the NotePad++ editor, and on the left in the Fresh IDE. The strings, starting with the second line, demonstrate consistent characters highlighting (the picture is maked with the Paint editor).
Yes of course, all this can be fixed, but this is a good example of the fact that simpler code is better because more reliable (and faster, by the way, which is important for microcontrollers). That is why I wrote this simple converter - so that I could use the true Unicode, and not bother with this crappy variable-length characters, this ugly crutch, invented by lazy C-developers. Ideally, they should have added the ability for the compiler to use the source code in Unicode UCS-2 (enter a special option for this), but instead they invented another type of Unicode. As a result, they facilitated the work of the compiler and turned the simplest programmer's work with strings into an intricate quest.
Test file attached.
Well, I can't see any relation between Unicode encoding and the buggy display of the Chinese hieroglyphs in Fresh IDE. And a proof of this is that the Fresh IDE v2.x editor uses exactly UCS-2 encoding. Because it is Windows API implementation.
Fresh v3.x will use another editor that uses UTF-8. But I am not sure it will display the hieroglyphs properly, not because of the encoding, but simply because there is no monospaced fonts containing Chinese hieroglyphs.
So, the hieroglyphs you see in Notepad++ and Fresh IDE are from substitution font and the sizes of the characters are different. Fresh IDE editor always expect the width of the characters to be the same. You can see the same effect if set in the editor some proportional font. In this case even latin characters will be displayed wrong.
And in reverse - if you have a monospaced font containing the needed characters, everything will work ok.
Yes, you're right - suddenly the thing is in different widths of characters. For verification, I even downloaded and installed the font of the last version of the Unifont. But even in it, the Chinese and other hieroglyphs have different widths, although it is declared as monospaced. You will have to take into account this feature for the correct display of all characters. Obviously, NotePad++ does not rely on the same width of characters when calculating the length of the string graphics; it sums the width of each character separately.
However, all this does not affect my opinion on UTF-8 encoding.