I am not an expert in WMI, but the issue is not that of C++ but your use of the wmic commands. You should first check the actual syntax of the commands you are trying to use. Then run them in a command window to find out the actual correct usage. I tried them both and got the following:
C:\Users\rjmac\source\repos>wmic bootconfig get description
C:\Users\rjmac\source\repos>wmic diskdrive where DeviceID=\\.\PHYSICALDRIVE0
Node - RJM-INSPIRON15
Description = Invalid query
So I tried this to find out what options are available with the diskdrive sub-command:
C:\Users\rjmac\source\repos>wmic diskdrive -?
DISKDRIVE - Physical disk drive management.
HINT: BNF for Alias usage.
(<alias> [WMIObject] | <alias> [<path where>] | [<alias>] <path where>) [<verb clause>].
DISKDRIVE ASSOC [<format specifier>]
DISKDRIVE CREATE <assign list>
DISKDRIVE GET [<property list>] [<get switches>]
DISKDRIVE LIST [<list format>] [<list switches>]
The final one allows you to check the options for the command.
So the error message "Description = Invalid query" is telling you that the command is in error, and you need to find out what the correct format is.
Yes you always need to escape backslashes in C/C++, as the backslash itself is the escape character. It's also interesting that you need to escape them when using the string in a command window. Glad you found the answer.
diskdrive where DeviceID='\\\\.\\PHYSICALDRIVE0'produces a result that can be parsed.
In C/C++, each of those backslashes needs to be escaped (with a backslash).
The real problem is that people can say anything like that with at straight face: Sure, that which semantically '\\.\' is already escaped in one level, but certain conditions that are too difficult to explain means that every one of those six backslashes - semantically, they are only three - must be escaped to make the three of them into twelve escaped-escaped backslashes ..."
This is the kind of stuff that makes me sigh, "Sorry, workmates: We failed. This just doesn't work."
Even programmers have difficulties handling it (at least in counting the number of slashes when the debugger displays the string as \\\\\\\\.\\\\devicename). When we say 'OK with us!', the next step is that we expect non-IT users to accept something like that.
Really, it is like saying that 'In tttthis systtttem you have to repeatttt every tttt four ttttimes, because tttthatttt is tttthe way tttthe systtttem is builtttt!'
I am not a super-expert with macros (in my C# programming I have never used it). I do not immediately see how I can write a macro so that I can write file names in their 'true' form, without any escaping of backslashes (or for that sake, spaces, different quotes and other other characters requiring quoting in a *nix file system context.
If you can show me how a macro to achieve that might look like, I would be grateful.
The problem goes back to the first days of MS-DOS, when they chose the backslash for the path separator, rather than the forward slash used by UNIX. Microsoft could have addressed this when they created the first version of Windows, but obviously no one thought it important.
The problem goes back to the first days of MS-DOS, when they chose the backslash for the path separator,
Apparently IBM is responsible for that decision. But there are other factors. The following is surprisingly detailed. Even comments at end are interesting. Goes sideways with charset discussion but that also is historically interesting.
Microsoft could have addressed this when they created the first version of Windows, but obviously no one thought it important.
Huh? There were quite a few versions of windows which ran on DOS. Not with it or instead of it. DOS provided the file system not Windows. DOS was directly accessible. So they would have needed to change DOS.
If they had changed it with Win 95 (perhaps the first possible) it would have made it incompatible with a lot of third party software that ran fine on Win 95.
I always was happy that DOS/Windows chose the backwards slash. Ideally, the separator should be a character that is never used in plain text so it could be used in a file name. Forward slash is often used in text, in several different ways: As an either/or. For fractions, 1/2. At least in Norwegian (but I believe it holds for a number of other languages as well) in commonly used abbreviations, A/S is an 'Ltd.' company. (Today some companies have dropped the slash, but several thousand A/S-es still have 'A/S' in their official name.)
The same goes for the full stop between the file name and the extension. Lunix handles this by not splitting into name.ext. DOS/Windows mostly determines or identifies the extension from context, but there are still cases of ambiguity where a non-overloaded character code was used as a separator.
The problem with both \ and . is significantly reduced in a GUI environment where you point and select, rather that typing the full path. A file name being edited in an entry file dedicated to a file name also handles spaces without requiring quoting\escaping.
Holding up *nix file naming rules as some sort of ideal, "Why would anyone ever dream of doing anything differently??", is in my eyes rather crazy. It satisfied engineers of the 1960s and 70s, by not everyday, non-technical users of the 2020s. Not by far!
CP could make it a requirement that with any request for having someone doing your homework for you, the name and email of the professor must be specified, so we know where to go to obtain more details about the task.