VS2010 debugging with command-line arguments - visual-studio-2010

I've set the command line args for my app in the project properties -> debugging -> command arguments section.
If I run the program from command line directly I do:
progname arg1 arg2
So I've set the command line arguments in VS to
arg1 arg2,
as described here.
But, the program doesn't seem to run the same way as in running it from command line. The arguments are text files, and in the command line it can load those text files correctly, in VS2010 it doesn't somehow. Any ideas why?
Edit: update/clarification of post:
I am not getting any exceptions.
I may have oversimplified the problem too much in my explanation. I'm not actually loading text files, I'm loading a physics engine, which should be determined at runtime, so I need command line arguments.
The code used for loading the physics engine, on a high level, is:
if ( argc > 2 )
{
#ifndef PAL_STATIC
PF->LoadPALfromDLL();
#endif
//DebugBreak(); // for debugging ;)
PF->SelectEngine(argv[1]);
if (!pp) {
#ifdef _WIN32
MessageBox(NULL,L"Could not start physics!",L"Error",MB_OK);
/* ^ This is the error I am getting, i.e. pp is NULL,
so "PF->SelectEngine(argv[1]);" is not loading engine correctly */
#else
printf("Could not start physics engine %s!\n",argv[1]);
#endif
return -1;
}
I am using Bullet, which is run like this:
progname.exe arg1 arg2,
arg1 is the physics engine name and arg2 is a physics file to load, but it hangs on arg1.
The specific way I invoke this on the command line is:
progname.exe Bullet filename.
If i do this on command line it works, but if I pass these arguments to the debugger, I get a problem saying could not load physics engine.
This may be a result of the internals of the physics engine loader, which is from another source, but my guess is that this should work the same way whether I pass these arguments in the command line or in the debugger settings of VS.
I will look into the UAC settings and see what they say.

As it says in : https://msdn.microsoft.com/en-us/library/17w5ykft.aspx, you can try adding a backslash to every "\" character, to escape them inside the path. For example :
Before : "C:\somewhere\someplace\physics_engine"
After : "C:\\somewhere\\someplace\\physics_engine"

Related

Why does this command crash cmd?

I came across a mind-blowing weird script that crashes the console:
set "h=/?" & call [if | for | rem] %%h%%
IF, FOR and REM aren't normal internal commands.
They use an own special parser, which possibly caused some interception errors so it crashed.
#jeb pointed out CALL doesn't execute the following special characters, but instead convert them into a "token" (version dependent):
& returns /
&& returns 1
| returns 2
|| returns 0
/? returns <
# returns +
#() returns ;
#if a==a : returns ,
#for %a in () do : returns +
#rem : returns -
However, even though they have unique parsers, it still doesn't explain why they all crash. So I did some testing:
Remove call
C:\>set "h=/?" & for %h%
%%h%% was unexpected at this time.
Change the command to something else. (I tried all other internal commands, none works)
Seperate two commands:
C:\>set "h=/?"
C:\>call for %%h%%
--FOR help message--
Add #
C:\>set "h=/?" & call for #%%h%%
CRASH!!!
Surround the scriptblock by ()
C:\>set "h=/?" & call for (%%h%%)
CRASH!!!
Summary of question:
What role does call play?
What caused the parser to crash?
The CALL is necessary to start a second round of the parser.
But there is a small bug (or more), in that phase it's not possible to execute any of the special commands or using &, |, &&, ||, redirection or command blocks.
The cause seems to be, that the parser build internally a token graph, replacing the special things into some kind of token values.
But with CALL the executer doesn't know anymore how to handle them.
This code tries to execute a batch file, named 3.bat !!!
(The name can be different, depending on the windows version)
set "cmd=(a) & (b)"
call %%cmd%%
But in your sample, the help function is triggered on a non executable token.
That seems to be the final death trigger for the executer to be completely out of sanity.
Summary of Research:
Calling linefeeds \n or FOR, IF & REM's help function crashes cmd, exiting with ERRORLEVEL -1073741819 aka 0xC0000005, which indicates an access violation error.
First, the cmd parser tries to start werfault to terminate the process.
If you prematurely terminate werfault, an error message will appear!
Access violation error:
The instruction at 0x00007FF7F18E937B referenced memory at 0x0000000000000070. The memory could not be read.
It is conjectured that if, for and rem uses special parsers, but when the help function is triggered by call, a non-command token is returned, which crashes the cmd parser.
Sources:
Why I can't CALL "IF" and "FOR" neither in batch nor in the cmd?
CALL me, or better avoid call
Limit CMD processing to internal commands, safer and faster?

How to workaround doskey's special character, like $L

I got a useful tip from this post: https://stackoverflow.com/a/374363/151453 , but plagued by doskey's special characters.
(env: Windows 7 and Windows XP)
Using Visual C++ command line, we have env-vars INCLUDE and LIB. So with this doskey macro,
doskey whichinclude=for %i in ($1) do #echo.%~$INCLUDE:i
we can easily findout which .h is found first in which INCLUDE directory, really convenient.
However, this trick fails for LIB. I just CANNOT simply code a macro like:
doskey whichlib=for %i in ($1) do #echo.%~$LIB:i
Call whichlib winsock32.lib, it spouts The system cannot find the file specified.
I launch Procmon to know what happens, it reveals:
So I realize $L has special meaning for doskey, it is replaced with current drive letter when run.
Try double dollar( #echo.%~$$LIB:i ), still not working, Procmon report CMD accessing C:\echo .
Counld someone kindly help me out?
My doskey book mark: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/doskey.mspx?mfr=true
I agree with Michael Burr's comment - you may be better off with a batch file. I generally do not use DOSKEY macros because they do not work within batch files, so it seems kind of pointless. In my mind, if a command works on the command line, it should also work within a batch file.
But... it is possible to do what you want :)
The $ only has special meaning if it is followed by a character that has special meaning to DOSKEY. The $L is interpreted as the < character (input redirection). The MS documentation implies that $$L should give a $L literal, but the documentation is not correct, as you have discovered.
The DOSKEY $ substitution happens before the normal command line parsing. The trick to embed a literal $L in your macro definition is to put an intervening character between $ and L that is not treated as special by DOSKEY, but that disappears during the normal command line parsing - The ^ works perfectly. $^ has no special meaning to DOSKEY, and ^L simply becomes L during command line parsing.
You can list the definition of your DOSKEY macros by using DOSKEY /M.
The full definition you require is whichlib=for %i in ($1) do #echo(%~$^LIB:i.
The ^ must be escaped when you define the macro. So the complete line to define the macro becomes:
doskey whichlib=for %i in ($1) do #echo(%~$^^LIB:i

Nemiver - Unable to direct standard input

I like the idea of nemiver, but i can't get this basic function of nemiver to work: redirect standard input to program. so as my program needs file input instead of manual input, it usually takes the form:
./program < list.txt
but apparently, nemiver does not recognize this simple redirection. and thinks "<" and "list.txt" as separate arguments. this frustrates me greatly. is there a solution to this? Thank you guys so much!
If you just want to do a postmortem analysis (and don't need to single-step), you can load a crash-dump (core) file which can be generated under any kind of pipelining/redirection scenario.
( ulimit -c unlimited && ./yourapp <in.txt >out.txt ) || nemiver --load-core=core ./yourapp
This only launches the debugger if a crash or assert occurs.
As a quick-and-dirty solution, you can add something like the following at the beginning of main()...
{
// programmatically redirect stdio
const char * stdin_filename="input.txt", * stdout_filename="output.txt";
assert( dup2(open(stdin_filename ,O_RDONLY),0) != -1 );
assert( dup2(open(stdout_filename,O_WRONLY),1) != -1 );
asm(" int3"); // optional breakpoint -- kills program when not debugging
}
Just make sure that you disable this when not debugging (since presumably you want to use the normal method of redirection in that case).
You also need the following...
#include <unistd.h>
#include <fcntl.h>

Inno Setup IDE and ISCC/ISPP passing define

I would like to use both the InnoIDE and ISCC/ISPP, the difference being that I would like to pass in a parameter, which will override a #define in the script.
In the command line I can pass /Dmyarg=myvalue. That is the same as #define myarg myvalue in the script.
Sadly, the script takes precedence over the command line value. I know, as I tried. I can obviously comment out the #define in the script and the command line define will work, however then I will not be able to use the IDE to build.
Is it possible to set a #define inside InnoIDE somewhere for the project or is there some means to have the command line #define take precedence?
In your script, do something like this:
#ifndef myarg
# define myarg "mydefault"
#endif
Now, if you compile in the IDE or if you use the command line without specifying /Dmyarg="something", then it will use the default specified in the script. Otherwise, if you do specify something on the command line then it will use that instead.

Build events not honoring multiple command-line arguments

I have the following as my post-build event in a C# .NET 4.0 project in Visual Studio 2010:
call "$(SolutionDir)Publish\Publish.exe" "$(TargetDir)" "\\lithium\c\Photon"
call "$(SolutionDir)RemoteControl\RemoteControl.exe" start
The problem is that when Publish.exe is executed, there is only one command line argument being passed, which contains the following value:
C:\Users\...\bin\Release" \\lithium\c\Photon
note: I replaced some folders with an ellipsis, otherwise this is the exact value
For whatever reason, it's combining the two arguments into one, and parsing the quotes very strangely. I've been debugging this for awhile, and I've tried it without the call, with a relative directory to Publish.exe, with something as simple as call "$(SolutionDir)Publish\Publish.exe" hello world and it's always smashed into a single argument. This leads me to believe that it's not some quotation tomfoolery.
If I run this exact same program from the prompt, it works flawlessly. Someone, please help me cut through this madness.
While working on another project, I actually managed to replicate your problem. I was passing multiple args to a powershell script and found that they were being treated as a single argument. Googling found this link
http://davidfrette.wordpress.com/2011/01/20/creating-powershell-pre-build-and-post-build-events-for-visual-studio-projects/
Which has the solution of putting a space at the end of the first parameter i.e. in your example it would be
call "$(SolutionDir)Publish\Publish.exe" "$(TargetDir) " "\\lithium\c\Photon"
This worked for me so hopefully it will fix your problem.
If you have more than 2 args then you would need to add a space at the end of each except for the last one.
HTH
I hit the same problem - if the argument expands out to something which ends in a backslash, I think the second quote is being escaped and treated as a quote character within the first argument.
Using "$(OutDir)\" worked for me.
I'm not getting this behaviour at all.
I created a post-build event of
call "$(SolutionDir)test.cmd" "$(SolutionDir)a.txt" "$(SolutionDir)b.txt"
Where test.cmd contains:
if '%1' == '' GOTO END
notepad.exe %1
if '%2' == '' GOTO END
notepad.exe %2
:END
a.txt & b.txt just have "This is File A" & "This is File B"
When I do the build, Notepad fires up with a.txt, and when I close it then Notepad fires up with b.txt.
So the parameters are definitely being sent separately for me.
Can you try this same test to see what behaviour you get?

Resources