APIs like rack::asset::plugin have type std::string. The documentation says on windows some items which require a UTF16 string require you to call rack::string::UTF8ToUTF16 which returns a std::wstring and the rack code has, in a few places, a call to that and then a call to .c_str() (notably not.wc_str()) before a load. For instance here’s some code on how to set up an archive from src/system.cpp
// Open file
#if defined ARCH_WIN
r = archive_write_open_filename_w(a, string::UTF8toUTF16(archivePath).c_str());
r = archive_write_open_filename(a, archivePath.c_str());
butSvg::load has signature const std::string & and all through the rack code the calls to Svg::load use the output of rack::asset::system directly. So I am presuming that somehow nvgSvgParse has been patched like fopen has
Is there a definitive set of APIs which require you to call UTF8toUFT16? My understanding was it was
Any filesystem API which takes a char * requires the conversion on windows, as above
Any rack API which takes a std::string does not (and cannot since UTF16 returns a std::wstring)
That makes me think that, in the Surge XT case, our call to json_load_file probably needs an ifdef and protection but our call to loadSvg does not. Explicitly this code:
so it clearly expects a UTF8 path inbound (and uses ghc filesystem, which is a sub in for std::filesystem that we also have used in surge). So as long as you aren’t doing any math on your string you should be fine since it’s all UTF-8 up to that api point as far as I can see. Maybe?
again like I said I don’t have a bootable windows box to test on right now.
Assuming this name is spelled correctly (which seems likely), and assuming you or the user didn’t mangle the log output in a text editor, and assuming that the users´ home directory is actually C:\Users\Aurélien\ on disk, then comparing with the original log output you presented in the top post:
True, and I adhere to the same from bitter experience. But for normal users they often don’t have a choice, and/or don’t know the ramifications when they innocently type in their actual name in their language. It should be reasonable to assume that “things just work”, except they don’t of course, and that’s just another reason that people (rightly) distrust IT. Heck, in my bitter old days as a programmer now, I have come to largely shy away from “smart things”, and generally prefer low tech whenever possible. Sigh…
Not related to anything I’ve done with rack, but I did once have VSCode decompose some unicode into precursor characters so that some literal unicode strings HAD to be expressed as unicode code numbers.
Quick update – A reinstall of Windows 10 solved the user’s issues, but I didn’t glean much new information from his message. I also haven’t run tests (as suggested by Squinky and Baconpaul) myself yet and hope to do that soon.
After a complete reinstallation of Windows 10, VCV works like a charm, and your plugins too
I strongly suspect the default “Document” folder, because I met similar problems with a VST, which couldn’t display the built-in presets stored in that “Document” folder.
Well good thing is I found one spot in surge where we might have an issue which I’ve fixed. It’s just that user skin preferences may not be saved with unicode user names, nothing fatal but definitely that review of my code made me fix one spot.
The was a time a while back where a user was getting some very odd behaviour with the display of MindMeld modules.
He reported it to us on a Sunday morning and Marc and I spent a good part of our Sunday (around 4 or 5 hours) investigating…
It eventually transpired that he had a Cyrillic username or some such and right at the end he told us none of his other Rack plugins were displaying properly either… so it was never a MindMeld issue in the first place. And he had already reported the issue to VCV the day before in regards to Fundamental modules… it was a bug in Rack.