UNICODE version of AutoHotkey

It always puts "a character" at the tail of the buffers, hence it is 2 bytes in this version.

The bugs in NumGet() and NumPut() will be fixed in the next release, thank for your report. However, since AutoHotkey always set the capacity of a variable >= 4 bytes, there are some differences between original version and Unicode version in your examples. Because it attempts to read a "UInt" (4 bytes) from a variable but it set its capacity to 2 (AutoHotkey extends it to 4 bytes internally).

@JimKarvo

I'll add some options to File* to support files in different charsets.

The script files must be saved with a BOM if your scripts contain the characters outside your system codepage.

How about checking next with IsTextUnicode API when there is no BOM? I suppose it can detect many scripts in UTF-16LE at least. BTW, it seems now have to specify the dll file name, even for kernel32 etc, in DllCall.

I think UTF-16LE w/o BOM files are used rarely, and only few text editors support to edit them. The files in UTF-8 w/o BOM are used much more, but IsTextUnicode() cannot handle that if I didn't misunderstand the document.

The sendinput function doesn't support Unicode characters, such as Chinese characters.

Because SendInput was intent to send a series of key events (not characters). When we type Chinese characters we need a software called input method engine (IME), but the keyboard is the same with the ones in U.S. (same keymap).

However, I'll try to work on it since the SendInput() Windows API seems to support this case.