So Unix did it, for various reasons, including speed & size.
And it persists to this day. OK.
And in order for MS to (better) interact with a "Unix subsystem", it they needs to play along.
And (programing) languages may use it to differentiate various constructs being used.
And an end user may use it.
Say a lowercase name is intended to be a program, & an uppercase name is intended to be the data portion for said program.
So the program is named, "data", & the associated program data is named, "DATA".
So you can look down a directory listing & see & understand that data belongs to DATA.
But then you could (case insensitive) DaTa.prog belongs dAtA.dat.
And you can look down a directory listing & know that caseinsensitive(name.prog) belongs to caseinsensite(name.dat).
Or, we could have /prog/data & /data/data, knowing that programs are in /prog/ & data files are in /data/.
Wonderful (yet again).
Other then forcing something like that, for whatever easons, I've yet to come across a compelling reason for case sensitivity.
, creates an .ini file, named (guess what) ShowTx.ini.
And I can look in a directory & see showtx.exe & showtx.ini & can assume that they go together.
But, the beta version of ShowTx.exe now also creates a new file, IgnoreSectionMarkers.ini.
So I write the guy & say:
No big deal, but...
As it is, I tend to keep smaller, generally stand-alone utilities, in a /BIN/ directory.
Helps that if there is an associated .ini, that its' name relates to the .exe.
In this case, IgnoreSectionMarkers.ini.
No big deal, but maybe if it were something like ShowTx_IgnoreSectionMarkers.ini,
(He didn't like the idea, BTW, which is OK too.
Also note that I tend to create directories, capitalized. I think there is an unwritten rule that you must do that; probably in the K&R how to create an OS manual.)
Now, if he could only rely on case sensitivity, that would make things much better
So... use case?