Another problem with Windows

Recently I am reading ipset'sCodeIpset implements an IP address set operation, which is a subset of Netfilter operations in Linux. ipset plays a role in netfilter. Its logic is simple, basically pureAlgorithmThe kernel debugging is rarely involved, so I want to study it in detail. Because the working machine is windows, I have to copy the compressed package to Windows, decompress it with WinRAR, decompress it, and start to read the code, no match registration is found. It is reasonable to say that each matching operation should have a match function. ipset obviously needs its own match function, but I didn't find it, so I began to doubt my eyes, does ipset use a magic way to define a match? I don't think the source code Author can be bored to this point...
After a long time, I clicked the ipset compressed package and found that there were two ipt_set.c files, ipt_set.c and ipt_set.c. So I suddenly realized that Windows is case insensitive, ipt_set.c and ipt_set.c are the same files, so they will overwrite each other during decompression, and thus lose one. This is the root cause. After finding this, I cursed God, A group of Windows enthusiasts have been challenged. They say that the ipset author should not name the file like this... I just want to ask, is a and a in the real world the same? Even in the original computer code, is the and A of ASCII a number? If Windows dominates the world, should Microsoft define a and a as the same? In fact, Microsoft also has two sets of standards. In a Windows File System, a and a are no different, but in its API or anything else, even Microsoft must follow international standards, at least follows ASCII and Unicode