Odd issue with the SHELL command running OSCDIMG.EXE utility

[hanness]

I have an odd issue running a command from SHELL.

In my program, I am running many different commands via SHELL. I have no problem with any of them, except for the Microsoft OSCDIMG.EXE utility which I am using to build an ISO image.

As an example, I store the command that I am about to run in a variable called Cmd$ and then run it like this:

SHELL Cmd$

The contents of Cmd$ are:

"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\oscdimg.exe" -m -o -u2 -udfver102 -l"Win10" -bootdata:2#p0,e,b"f:\boot\etfsboot.com"#pEF,e,b"f:\efi\microsoft\boot\efisys.bin" "f:" "c:\users\hanness\desktop\Win10.iso"

When run, I get the following error:

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

Some things to note here:

1) My QB64 Program is being run elevated. If I take that EXACT SAME command and run it from an elevated command prompt, it runs flawlessly.

2) This one is very interesting to me: If I output Cmd$ to a file called TEMP.BAT and then do a SHELL "TEMP.BAT" it works fine. Why???

Example:

OPEN "TEMP.BAT" FOR OUTPUT AS #1
PRINT #1, "@echo off"
PRINT #1, Cmd$ ' Note that Cmd$ holds the same command that fails when run as SHELL Cmd$
CLOSE #1
SHELL "TEMP.BAT"



64-Bit vs 32-Bit

This smells and feels like another problem I ran into. Bear with me because this can be a little confusing...

I had this exact same problem with the DISM command and it turned out that the problem was related to 32-bit code running 64-bit utilities. In that instance, I was running QB64 32-Bit and was calling %windir%\System32\DISM.EXE from a SHELL command. It turns out that when you are running a 32-bit program and you reference System32, Windows automatically redirects that to %windir%\SysWOW64. System32 holds 64-bit applications on Windows 64-bit, and SysWOW64 holds the 32-bit programs, so when you run a 32-bit app it redirects you to SysWOW64 so that the 32-bit app is called. The problem is that there is no 32-bit version of DISM.EXE and so you get an error. The workaround is to replace "System32" with "Sysnative", which is a virtual directory. This results in the 64-bit version being run from your 32-bit app. Note also that if you run QB64 64-Bit you won't encounter this issue because you now have a 64-bit program calling another 64-bit application.

Forward to today...

I am now running 64-Bit QB64 on a computer running 64-bit Windows 10. Note too that in my command the path to the OSCDIMG.EXE specifically references "\amd64\Oscdimg\oscdimg.exe", so I know I'm running the 64-bit version of OSCDIMG.EXE.

I have the workaround of outputting the command to a batch file and then running that batch file as noted above, but this is still bugging me. I would just be curious to know if anyone has any thoughts on what might be happening here.

[FellippeHeitor]

Try wrapping the first part (the actual command) in a pair of CHR$(34).

If it still doesn't work, try beginning the command with cmd /c.

[hanness]

I appreciate the suggestions.

Note that the first part of the command (the path up to and including the .exe) is already enclosed in CHR$(34)'s.

Also, the cmd /c yields the exact same results.

This is nothing critical since I have a perfectly working workaround, it's move just curiosity  to understand what it is that is happening here.

It just seems odd that running the command directly fails, but put the 100% exact same command in a batch file and call the batch file and it works flawlessly.

[Pete]

Fell is spot on abut the quotes. What QB64 SHELL commands don't get is spaces. Enclose any folder / file name that contain a space or spaces in quotes and that solves the problem.

Be sure to use the _dontwait statement with it, if you don't want your program to wait for the shelled program to finish. For instance, if you use SHELL "Notepad" in Windows, Notepad will open but control won't be returned to your QB64 program until you close Notepad. To get around that, SHELL _DONTWAIT "Notepad" Also, use _HIDE in conjunction with _DONTWAIT to hide the console window. _HIDE can be used by itself, of course.

Pete

[Raven_Singularity]

To be clear, the issue is the space between the "Program" and "Files", but as you already have quotes around it, not sure why it's treating it that way.

Are you sure they are regular quotes, and not "fancy quotes"?

[Pete]

It's making quotes with CHR$(34) that is requited. For instance, I have 7-zip installed in my program files folder, so...

SHELL _HIDE "c:\program files\7-zip\7zfm.exe" ' THIS WON'T WORK.

SHELL _HIDE "c:\" + CHR$(34) + "program files" + CHR$(34) + "\7-zip\7zfm.exe" ' THIS WILL WORK.

Pete

[hanness]

I understand the concern over the quotes and I can assure you with 100% certainty that I am doing exactly as requested = enclosing the path and executable name in CHR$(34)'s.

Again, note too that the exact same string, character for character,  is identical to what is being run from the "temp.bat" file and what I am running manually, both of which work fine.

When I get back in front of my other system I will grab the original code and paste it in here. Actually I may try to simplify it because I build that command line from a lot of other pieces of information which would mean several hundred lines of code to get the full context. I'll see if I can create a simplified example that behaves exactly the same.

Thanks for all the suggestions thus far.

[hanness]

Apologies in advance for the rough look of this post. I tried to use the "Insert QB64 code with syntax highlighting" but it's not working for me.

Below is a simplified example illustrating in complete the issue that I am encountering.

Explanation of Program

This program takes all files and subfolders in a given folder, creates an ISO image file using the Microsoft OSCDIMG.EXE utility, and places a copy of those files and folders in it at a destination chosen by the user.

In this sample, I have hard coded the variables in lines 30-32 rather asking for any input. Modify these as you see fit.

This program requires that the "Deployment Tools" portion of the Windows ADK be installed. It should be run with QB64 64-bit since I am specifically calling the 64-bit version of OSCDIMG.

The entire command to be run is contained in the variable called Cmd$.

When I perform a Shell Cmd$, the result is a failure. Put the contents of Cmd$ in a file called "TEMP.BAT" and then SHELL "TEMP.BAT" and it runs flawlessly.

The actual code:

Code: QB64: [Select]

1. $CONSOLE:ONLY
2. _DEST _CONSOLE
3. OPTION BASE 1
4.  
5. ' **************************
6. ' * Declare variables here *
7. ' **************************
8.  
9. DIM DestinationPathAndFileName AS STRING
10. DIM SourcePath AS STRING
11. DIM VolumeName AS STRING
12.  
13.  
14.  
15. ' INSTRUCTIONS: This sample code will require that the Windows ADK be installed in the default location. Note that only
16. ' the "Deployment Tools" option from the ADK needs to be installed.
17. '
18. ' Modify the variables below as follows:
19. '
20. ' SourcePath$ - Point to a location containing files that you want to place into an ISO image. Any files will do.
21. ' DestinationPathAndFileName$ - This is the full path and filename of the ISO image that is to be created.
22. ' VolumeName$ - This is the Volume Name that will be displayed when the ISO image is mounted in Windows or on the
23. '               media when burned. An empty string is valid and denotes no volume name or label.
24.  
25.  
26.  
27. ' Initialize variables. Note that in my real code, these variables are populated from various other pieces
28. ' of information. I'm simply plugging in sample values here to demostrate the issue.
29.  
30. SourcePath$ = "D:\My folder with test data"
31. DestinationPathAndFileName$ = "D:\Test File.iso"
32. VolumeName$ = "This is the image vol name"
33.  
34.  
35. ' Build the command that needs to be run to create the ISO image.
36.  
37. Cmd$ = CHR$(34) + "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\oscdimg.exe" + CHR$(34) + " " + "-o -m -h -k -u2 -udfver102 -l" + CHR$(34) + VolumeName$ + CHR$(34) + " " + CHR$(34) + SourcePath$ + CHR$(34) + " " + CHR$(34) + DestinationPathAndFileName$ + CHR$(34)
38.  
39. PRINT "Command to be run:"
40. PRINT Cmd$
41. PRINT
42. SHELL "pause"
43.  
44.  
45.  
46. ' The line following these comments is what actually executes the command  and fails.
47.  
48. SHELL Cmd$
49. PRINT
50. PRINT "We are pausing at this point so that the output can be viewed. We will then continue"
51. PRINT "after the user presses any key."
52. PRINT
53. SHELL "pause"
54.  
55. ' Next, note that we are taking the exact same command contained in Cmd$ and putting it in a batch file.
56. ' We then execute that batch file. This exact same command executes successfully now.
57.  
58. OPEN "TEMP.BAT" FOR OUTPUT AS #1
59. PRINT #1, "@echo off"
60. PRINT #1, Cmd$
61. CLOSE #1
62. SHELL "TEMP.BAT"
63. PRINT
64. PRINT "Once again, we pause so that the user can view the output and continue after the user presses any key."
65. PRINT
66. SHELL "pause"
67.  
68. ' We no longer need the batch file that was created above, so we are now deleting it
69.  
70. IF _FILEEXISTS("TEMP.BAT") THEN
71.     KILL "TEMP.BAT"
72. END IF
73.  
74. SYSTEM

Sample output:

Command to be run:
"C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\oscdimg.exe" -o -m -h -k -u2 -udfver102 -l"This is the image vol name" "D:\My folder with test data" "D:\Test File.iso"

Press any key to continue . . .
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

We are pausing at this point so that the output can be viewed. We will then continue
after the user presses any key.

Press any key to continue . . .

OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Copyright (C) Microsoft, 1993-2012. All rights reserved.
Licensed only for producing Microsoft authorized content.


Scanning source tree
Scanning source tree complete (3 files in 1 directories)

Computing directory information complete

Image file is 538673152 bytes (before optimization)

Writing 3 files in 1 directories to D:\Test File.iso

100% complete

Storage optimization saved 0 files, 0 bytes (1% of image)

After optimization, image file is 538669056 bytes
Space saved because of embedding, sparseness or optimization = 0

Done.

Once again, we pause so that the user can view the output and continue after the user presses any key.

Press any key to continue . . .

Explanation of output:

When you view the output, you will see that I first simply print the value of Cmd$ to the screen to show the exact command to be run.
The program pauses until a key is hit and then the command is run and fails.
Once again we pause.
The same exact command (still the contents of Cmd$) is output to a file called TEMP.BAT and we then SHELL "TEMP.BAT". From the output you can readily see that this now works flawlessly for some reason.

[FellippeHeitor]

I insist on my initial "extra quotes" instruction:

Code: QB64: [Select]

1. SHELL CHR$(34) + Cmd$ + CHR$(34)

[hanness]

Fellippe,

You were absolutely right. Running it as you suggested worked.

Any chance you can help me understand why this works? I dismissed the suggestion the first time because I didn't understand that you meant to enclose THE ENTIRE STRING quotes. I had thought that I was doing what you suggested by enclosing the path and exe in double quotes. Apologies for the misunderstanding.

So the resulting command is now like this:

""C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg\oscdimg.exe" -o -m -h -k -u2 -udfver102 -l"This is the image vol name" "D:\My folder with test data" "D:\Test File.iso""

Note the double-double quotes at the start and end.

I guess the part I'm having difficulty wrapping my head around is the fact that my program is over 3,000 lines of code consisting of MANY shell commands and this is literally the only one that I need to do this with.  It also befuddles me that running the command contained in Cmd$ without enclosing it in another set of CHR$(34)'s works when calling it in a batch file.

I also just want to say a great big thank you for all your help. I know that I've posted several questions here lately, but I honestly try my best to resolve issues on my own before posting here. I'm very thankful for all who have assisted and put up with all my questions :-).

[FellippeHeitor]

I dismissed the suggestion the first time because I didn't understand that you meant to enclose THE ENTIRE STRING quotes.

You did understand correctly the first time, I was only talking about the first part of the command indeed, but after the discussion went on it occurred to me that enclosing it all would somehow work. Glad it did.

Now as to why... good question.

[Raven_Singularity]

Requiring the entire command be within quotes makes no sense.  It should either require quotes around path/file names containing spaces, or nothing.  Internally it should add the quotes around the entire command line if that strange requirement exists.

[hanness]

LOL. Fair enough. I will remember the symptom and keep this trick in mind.

BTW, in the meantime I tried one more test:

If you simply run the command "OSCDIMG.EXE" with no parameters, it displays help on the syntax for the app. If I remove the parameters from my code and just shorten the command to omit all those parameters the command is executed properly and it displays the syntax help, without the need to wrap it in CHR$(34)'s. It must be some quirk of that command.

In any case, thanks once again. The help is greatly appreciated!