I have found what appears to be a small Unicode/UTF-8 issue in Ring on Windows.
Ring itself works correctly with Cyrillic file and directory names. For example, this main file runs successfully:
C:\Ring\Обучение\main.ring
Also, loading a Ring source file with a Cyrillic filename works correctly:
load "модуль.ring"
I tested this with the following structure:
C:\Ring\Обучение
main.ring
модуль.ring
main.ring:
load "модуль.ring"
And модуль.ring:
see "Модуль загружен" + nl
x = 10
x.test()
Ring successfully loads the module, and the error message correctly displays its Cyrillic filename:
Line 4 Error (R13) : Object is required
in file модуль.ring
However, when an error refers to the main source file, the Cyrillic part of the full path is corrupted.
For example, the actual path is:
C:\Ring\Обучение\Untitled-4.ring
but Ring reports something similar to:
C:\Ring\��������\Untitled-4.ring
This happens not only in VS Code, but also in Ring Notepad, so it does not appear to be an editor or terminal encoding issue.
Based on these tests, Ring's UTF-8 file handling itself seems to work correctly. The issue appears to be specifically related to the main source filename/path received from the Windows command line, while filenames loaded through Ring's own load mechanism are handled correctly.
It may be related to how the Windows argv value for the main source file is converted or stored before being used by the VM for diagnostic messages.
Environment:
Windows
Ring
Cyrillic directory names
Cyrillic filenames loaded with load work correctly
I thought this might be useful to report because the issue seems quite localized and may be relatively easy to fix.
I tested Ring file-system functions on Windows using paths that contain Cyrillic characters, and it looks like the Unicode support is inconsistent across different functions.
The following functions worked correctly with Cyrillic file paths:
write()
read()
fopen() / fputs()
fexists()
However, these functions failed with the same kind of Cyrillic paths:
dir()
getfilesize()
getpathtype()
rename()
remove()
makedir()
direxists()
chdir()
Some examples from my tests:
fexists("...\Тестовый файл Ёжик.txt") -> 1 getfilesize("...\Тестовый файл Ёжик.txt") -> -1 getpathtype("...\Тестовый файл Ёжик.txt") -> 0 rename(...) -> -1 remove(...) -> file still existsdir() can find the entry, but the returned Cyrillic filename is corrupted, for example:
[�������� ���� ����.txt]instead of the real filename.
I also verified direxists() and chdir() independently using the Windows Unicode API.
I created the test directory using CreateDirectoryW, then checked it with GetFileAttributesW. Windows correctly reported that the directory exists:
WinAPI: 1but Ring returned:
direxists(): 0For chdir(), the directory was also created and verified through WinAPI, but Ring did not change into it.
I tested a workaround using ring-cffi and the Windows Unicode API:
FindFirstFileW FindNextFileW GetFileAttributesW CreateDirectoryW RemoveDirectoryW DeleteFileW MoveFileExWwith wstring() and wtoString() conversions.
This works correctly with Cyrillic paths.
So it seems that some Ring file-system functions already use a Unicode-safe implementation, while others still use a Windows path handling method that does not correctly support UTF-8/Cyrillic paths.
A particularly clear comparison is:
fexists(path) -> works remove(path) -> fails read(path) -> works getfilesize(path) -> failsThis suggests that the issue is not with Ring strings themselves, but with the Windows implementation of specific file-system functions.
It may be worth checking whether the affected functions can internally use the corresponding wide-character Windows APIs (...W) and UTF-8 <-> UTF-16 conversion consistently.
I understand the idea of keeping the standard file functions simple and recommending libraries like RingQt/QFile for advanced features.
However, I think this solution is not optimal for Windows users. File system operations are a basic part of the language, and users usually expect functions like rename(), remove(), dir(), chdir() and getfilesize() to work correctly with normal Windows paths, including Cyrillic names.
Using RingQt only for Unicode file paths introduces a much larger dependency for a very basic feature. It also means that simple file operations require a completely different API instead of the standard Ring functions.
A possible solution could be implementing the Windows file functions internally using the Unicode WinAPI (...W functions):
FindFirstFileW / FindNextFileW
CreateFileW
DeleteFileW
MoveFileW
GetFileAttributesW
CreateDirectoryW
with UTF-8 ↔ UTF-16 conversion.
This would keep the existing Ring API unchanged:
rename(oldPath, newPath) remove(filePath) dir(folderPath)but make it work correctly with Unicode paths on Windows.
The performance impact should be very small because these operations are already dominated by Windows file system calls, while the added UTF-8/UTF-16 conversion is only a small overhead.
I think this would make Ring much more natural to use on Windows, especially for users working with non-English languages.