Small Unicode/UTF-8 issue

46 views
Skip to first unread message

Igor S

unread,
Oct 1, 2026, 10:47:38 AM (9 days ago) Oct 1
to The Ring Programming Language

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.


Igor S

unread,
Oct 1, 2026, 1:54:24 PM (9 days ago) Oct 1
to The Ring Programming Language

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 exists

dir() 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: 1

but Ring returned:

direxists(): 0

For 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 MoveFileExW

with 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) -> fails

This 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.



четверг, 1 октября 2026 г. в 17:47:38 UTC+3, Igor S:

Mahmoud Fayed

unread,
Oct 1, 2026, 2:38:05 PM (9 days ago) Oct 1
to The Ring Programming Language
Hello

>> "I thought this might be useful to report because the issue seems quite localized and may be relatively easy to fix."

Thanks for the report :D

>> "However, these functions failed with the same kind of Cyrillic paths:"

The standard functions are not designed to support such a feature
You could try a library/extension like QFile from RingQt: RingQt Classes Reference — Ring 1.27.0 documentation

Greetings,
Mahmoud

Igor S

unread,
Oct 2, 2026, 1:53:41 AM (9 days ago) Oct 2
to The Ring Programming Language

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.



четверг, 1 октября 2026 г. в 21:38:05 UTC+3, Mahmoud Fayed:

Mahmoud Fayed

unread,
Oct 2, 2026, 5:58:49 AM (9 days ago) Oct 2
to The Ring Programming Language
Hello

>> "I understand the idea of keeping the standard file functions simple and recommending libraries like RingQt/QFile for advanced features."

The Idea in standard Ring functions provided by Ring VM directly is to treat (ANSI C) as the platform (not operating system like Windows/Linux/macOS/etc.)
So, functions that uses specific code for specific operating system (is very limited when this is very necessary)

>> "Also, loading a Ring source file with a Cyrillic filename works correctly:"

Because Syntax flexibility (changing keywords to non-English words) is a core feature in Ring
We supported source code files with non-English words

>> "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."

>> "A possible solution could be implementing the Windows file functions internally using the Unicode WinAPI (...W functions)"

Thanks for your suggestions, I will think about this in the future if I need this in my apps.
For now, this should be fixed through a library/extension by interested contributors (For my apps, I just use RingQt).

In Ring we can create extensions (In C/C++) that wraps standard Ring functions which is written in C

Example:

# Using _std_dir() as original dir() function
RingVM_TranslateCFunction("dir","_std_dir")

# Defining a function called Dir() in Ring code that replace original Dir() function which is written in C
func dir cFolder
    ? "Wrapping standard dir() function"
    if isWindows()
         # Call a new function that provides the features that you want 
    else
        # calling original dir() function
         _std_dir(cFolder) 
    ok

This way you can create a new library that replace standard function and add any features you want/need

Greetings,
Mahmoud

Reply all
Reply to author
Forward
0 new messages