ZenHAX

sir aluigi, everything works fine in QuickBMS (at least i can't see any problem in current beta until now)
i think updating userDefineLang.xml of Notepad++ is needed
and i am pretty sure there is many useful things in QuickBMS that not included in quickbms.txt
i hope you have good time, thank you

one of the things that QuickBMS can do is handling c strings and replacing forbidden characters and good handling of output file name

two things really needed
1)make an option to dissable all c-string errors (for example: when we want to use a wrong escape. and that option should replace 0x0D and 0x0A with a tag like <bms_tag=break> if we want to disable c-string error and use single line string)
2) using open FDSE NAME 2 not working if NAME have a forbidden chatacter (in this case, NAME string is "star*file.bin", but "*" replaced to "_" in exporting, and problem is that can't open exported file with open command based on exported NAME string)
open FDSE NAME 2
but it just trying to open "star*file.bin" instead of "star_file.bin"

1) I don't think I can implement any alternative encoding/method because it would take time and effort. And the lack of standards doesn't help. I'm sure we already discussed about it.

2) You can't use the * character on most filesystems. It's used as wildcard interpreted by console and terminals.
https://en.wikipedia.org/wiki/Filename# ... imitations

1) then i will keep to the current standard, thank you. but if you get free time, please think about xml slog, sir aluigi. because xml is easy to detecting errors, and it can be multi line and people can add id and label to their localization strings

2) i attached a open_naming.zip, and there is a file.bms in it that checks if a file exist or not before extraction
real file name is *my_file*.star in file.bin, and since it has forbidden character, then QuickBMS turn it to "_", but when i want to try open a forbidden named file with OPEN command, it's trying to open it with real forbidden name instead of fixed name with "_" chars

2) Interesting, I will check it.

ok I double checked.
The filename is passed as-is to the _wfopen and fopen API.
I also checked the unicode name and it's just intact.

The different behavior between input and output is due to security and "cleaning" reasons, the former needs maximum freedom for which no filters are applied while the latter must be filtered and limited.

So it's all ok.

New beta out.
There was a lame bug recently introduced in unzip_dynamic/zlib_noerror/deflate_noerror that returned an error.
I also added support for the dictionary in that same code since it costed me nothing.
Now tcc supports 64bit (long long) variables.