If a name contains values beyond ASCII — technically out of spec
I'm not sure what spec it's referring to, but this is normal and expected for files in non-English systems.
Such tools often incorrectly assume UTF-8, which is what motivated this article.
Those tools are likely to be from the *nix world, where UTF-8 is far more common for the multibyte encoding --- but even there, you can have different codepages; and I have worked on Linux systems using CP1252 and 932 before.
The description of import directories[1,2] in the PE/COFF spec explicitly (if somewhat glibly) restricts imported DLLs to being referenced using ASCII only:
> Name RVA - The address of an ASCII string that contains the name of the DLL.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... (current, unversioned)
[2] https://github.com/tpn/pdfs/blob/master/Microsoft%20Portable... §6.4.1 (version 6.0, 1999)
I've read my share of MS docs and I do not recall ever seeing this to be the case. Like the parent says, I've seen "ANSI" used to refer to that, not ASCII. Do you have any examples of where they say "ASCII" where the intention is obviously something broader than 0-127? It makes me wonder how I've missed this if that's the case.
In MS output in my experience consistently means standard 7-bit ASCII.
Things they routinely do oddly are using ANSI to specifically refer to the WIN1252 code page (a superset of ISO8859-1 otherwise referred to as CP1252) when the institute of that name did not define nor dictate user of the codepage, and including (or requiring for correct interpretation) the BOM sequence in UTF-8 encodings when the standard allows recommends against a BOM in this context.
And clearly those things are why there is C:\ProgramData\(that's under 8+3 characters!) since late XP era - even "C:\Program\ Files\" must have been too much sometimes, and having that folder is a useful harm reduction; developer response to app not working under Program Files is to make random top level directories under C:\, not taking time to clear dech tebts.
#define X(s) #s
#define S(s) X(s) cat > a.c
#define X(s) #s
#define S(s) X(s)
char *f(void) return { S(A); }
^D
cc -E a.c
char *f(void) return { "A"; }
cc -DA=B -E a.c
char *f(void) return { "B"; }
M(foo)
M(bar)
void print_foo(void) { puts("foo"); }
voir print_bar(void) { puts("bar"); }Ah, the poor man's introspection and reflection with C macros.
shudder
#define F 42
#define X(s) #s
X(5) // Expands to "5" (as a string literal)
X(F) // Expands to "F" not "42"
#define F 42
#define X(s) #s
#define S(s) X(s)
S(5) // "5" as expected
S(F) // "42" because S(F) expands to X(42) expands to "42"“I tried the beta and it couldn’t install successfully if I set my regional options to en-AU.”
“Umm… that’s just a cosmetic issue.”
“It’s a hypervisor kernel, it is going to host tens of thousands of our most critical applications and it crashes if I change one of only three things it asks during setup. My confidence is not super high right now.”
Etc…
I got the impression that Microsoft is used to selling to PHBs based on the look of shock on the guy’s face when I told him that I not only installed the product, but benchmarked it too for good measure.
We've had fine-grained control over this for ages, apps can handle it fine, just let us get it the way we want it.
You can even use emoji as date separators if you please.
However, for the newfangled "apps", they take the regional settings entirely based off your default keyboard layout!
But even then it didn't work to simply have English locale and Norwegian and US keyboard layouts under it. I can't recall what they messed up right now, but I fought Windows 11 for quite some time.
Finally settled on English locale with US keyboard layout, and Norwegian locale with Norwegian keyboard layout, which mostly works in terms of keyboard layout, but now my Weather app is showing Fahrenheit instead of Celsius, despite my regional settings being Norwegian.
Like, how hard can it be to just not fuck it up? They had it working fine for decades!
“I tried the beta and it couldn’t complete the installer if I set my regional options to en-AU.”
“Umm… that’s just a cosmetic issue.”
“It’s a hypervisor kernel, it is going to host tens of thousands of our most critical applications and it crashes if I change one of only three things it asks during setup. My confidence is not super high right now.”
"Well, it said it is beta, didn't it? The quality of the installer of a BETA hasn't anything to do with the quality of hypervisor itself. "
I also managed to crash or lock it up several times, I just mentioned the keyboard thing as an insane bug. What possible dependency could a stripped down kernel with hardly any user space have on a keyboard layout that’s identical! It is different from en-US in name only.
It’s not about the specifics of the issue, but about the overall impression of sloppiness. They didn’t make a hypervisor that’s purpose-designed for the requirements, they just stripped down Windows and deleted stuff haphazardly so that they were missing the keyboard but still had the installer option.
For reference, I did run it at scale a few years later and my misgivings were confirmed… and then some. It was much less stable than ESXi and the cluster operations were a disaster. Read only operations could cause deadlocks that only a full cluster reboot could resolve. In-place upgrades weren’t available for several major versions! Meanwhile ESXi clusters could be live-upgraded including disk format changes!
After enough decades of experience you get a sixth sense for these things. A single sentence or just one word can trigger an alarm bell in your brain.
[1]: The classic example being Chris Sawyer writing nearly all of Rollercoaster Tycoon in x86 assembly but requiring just enough C for the system calls.
You don't need C/C++ to call a function from a DLL, but it makes things easier, especially for more complex APIs like DirectX.
This isn’t true. The Win32 API is C-based. You can call a C-based API from hand-written assembly just fine. You just have to understand the ABI calling convention so you know how to do it. You can also write some C code to call the API and then get the C compiler to output assembly and then you can copy/paste the relevant portion into your hand-written assembly
> The classic example being Chris Sawyer writing nearly all of Rollercoaster Tycoon in x86 assembly but requiring just enough C for the system calls.
I don’t think he had to do it that way. Maybe he just decided that was the path of least resistance for him.
Ultimately, he has to have assembly call C at some point, since his own assembly code has to call his C function which calls the Win32 API (technically not system calls, as other commenters have pointed out). Maybe, given the Win32 API involves some rather complex data structures, numerous constant definitions, various helper macros, etc, he may have just found it easier to use some of that stuff from C instead of trying to replicate the complexity in hand-written assembly, or having to translate all the C header definitions he needed into corresponding assembler macros
> I don’t think he had to do it that way. Maybe he just decided that was the path of least resistance for him.
From the Chris Sawyer himself[0]:
What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX.
bits 64
default rel
segment .data
msg db "Hello world!", 0xd, 0xa, 0
segment .text
global main
extern ExitProcess
extern printf
main:
push rbp
mov rbp, rsp
sub rsp, 32
lea rcx, [msg]
call printf
xor rax, rax
call ExitProcess
nasm -f win64 -o hello_world.obj hello_world.asm
link hello_world.obj /subsystem:console /entry:main /out:hello_world_basic.exe