All you have to do to get a USEFUL LITTLE utility for FREE is to tell me why the following code doesn't work.
The problem zone is passing it command line parameters.(No need to mention that this is just a test code. The real one is useful indeed.)
.386
.model flat, stdcall
option casemap :none
include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\kernel32.inc
include \MASM32\INCLUDE\shell32.inc
include \masm32\include\user32.inc
include \MASM32\INCLUDE\masm32.inc
includelib \MASM32\LIB\kernel32.lib
includelib \MASM32\LIB\shell32.lib
includelib \MASM32\LIB\masm32.lib
includelib \masm32\lib\user32.lib
.data
open db "open",0
scan db "C:\SCANDISK.LOG",0
video db "C:\VIDEOROM.BIN",0
.data?
commandline dd ?
.code
start:
invoke GetCommandLine
mov commandline,eax
.if commandline == s
jmp scanx
.elseif commandline == v
jmp videox
.endif
videox:
invoke ShellExecute,0,ADDR open,ADDR video,NULL,NULL,SW_SHOWNORMAL
jmp exit
scanx:
invoke ShellExecute,0,ADDR open,ADDR scan,NULL,NULL,SW_SHOWNORMAL
jmp exit
exit:
invoke ExitProcess,NULL
end start
The problem zone is passing it command line parameters.(No need to mention that this is just a test code. The real one is useful indeed.)
.386
.model flat, stdcall
option casemap :none
include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\kernel32.inc
include \MASM32\INCLUDE\shell32.inc
include \masm32\include\user32.inc
include \MASM32\INCLUDE\masm32.inc
includelib \MASM32\LIB\kernel32.lib
includelib \MASM32\LIB\shell32.lib
includelib \MASM32\LIB\masm32.lib
includelib \masm32\lib\user32.lib
.data
open db "open",0
scan db "C:\SCANDISK.LOG",0
video db "C:\VIDEOROM.BIN",0
.data?
commandline dd ?
.code
start:
invoke GetCommandLine
mov commandline,eax
.if commandline == s
jmp scanx
.elseif commandline == v
jmp videox
.endif
videox:
invoke ShellExecute,0,ADDR open,ADDR video,NULL,NULL,SW_SHOWNORMAL
jmp exit
scanx:
invoke ShellExecute,0,ADDR open,ADDR scan,NULL,NULL,SW_SHOWNORMAL
jmp exit
exit:
invoke ExitProcess,NULL
end start
Maybe:
mov commandLine,eax
.if byte ptr =="s"
do stuff
.elseif byte ptr =="v"
do other stuff
.else
do some more other stuff
.endif
I guess GetCommandLine is returning a pointer for the commandline...
mov commandLine,eax
.if byte ptr =="s"
do stuff
.elseif byte ptr =="v"
do other stuff
.else
do some more other stuff
.endif
I guess GetCommandLine is returning a pointer for the commandline...
I believe this is your problem:
GetCommandLine returns a pointer to the full command line... not to the arguments. Ex. if I launch notepad to read test.txt the command line will be
"C:\windows\notepad.exe test.txt"
so the first byte will be "C" i.e., the drive letter from where the application was launched and not the "t" from "test.txt" parameter.
--Chorus
GetCommandLine returns a pointer to the full command line... not to the arguments. Ex. if I launch notepad to read test.txt the command line will be
"C:\windows\notepad.exe test.txt"
so the first byte will be "C" i.e., the drive letter from where the application was launched and not the "t" from "test.txt" parameter.
--Chorus
Absolutely correct, on all counts.
CommandLine is the address of a string, ie a pointer to the string, and not the string itself, and the string is indeed an absolute path including the exe name.
Make your parameters begin with a "trigger" character which isn't part of regular filenames, like "^", then u can easily find them in the string without complex parsing.
CommandLine is the address of a string, ie a pointer to the string, and not the string itself, and the string is indeed an absolute path including the exe name.
Make your parameters begin with a "trigger" character which isn't part of regular filenames, like "^", then u can easily find them in the string without complex parsing.
masm32.lib has some nice functions which make commandline handling easy.
And what is so useful about this utility? :)
And what is so useful about this utility? :)
>(No need to mention that this is just a test code. The real one is useful indeed.)
Thanks folks
I found the solution to my question. The fight however goes on.
.code
start:
invoke main
invoke ExitProcess,0
main proc
LOCAL clbuffer[128]:byte
invoke GetCL,1,ADDR clbuffer
.if clbuffer == "j"
invoke stuff
.elseif clbuffer== "s"
invoke other stuff
.endif
I found the solution to my question. The fight however goes on.
.code
start:
invoke main
invoke ExitProcess,0
main proc
LOCAL clbuffer[128]:byte
invoke GetCL,1,ADDR clbuffer
.if clbuffer == "j"
invoke stuff
.elseif clbuffer== "s"
invoke other stuff
.endif
>The fight however goes on.
Maybe you could be more specific...
From what I'm seeing, you could have a problem with the case of the character (upper or lower), but you'll have to give more information than you have.
--Chorus
Maybe you could be more specific...
From what I'm seeing, you could have a problem with the case of the character (upper or lower), but you'll have to give more information than you have.
--Chorus
That's not how it shows up on W98 for me.
From a shortcut program line, C:\Masm32\RunFrom\RunFrom.exe -V produces on a commandline, "C:\Masm32\RunFrom\RunFrom.exe" -V ; Note that the exefilepath is quoted with the appended parameters outside the quotes. That's why I search for a quote and a space together to find the beginning of the parameters.
The same thing happens when you generate a shortcut for the exefile and put it on your SendTo menu. But the filepath for the parameter file name is the shorten 'GetShortPathName' format.
Enjoy your work, P1
PS: Chorus, the test.exe shows up outside the quotes as the full path in the 'GetShortPathName' format.
From a shortcut program line, C:\Masm32\RunFrom\RunFrom.exe -V produces on a commandline, "C:\Masm32\RunFrom\RunFrom.exe" -V ; Note that the exefilepath is quoted with the appended parameters outside the quotes. That's why I search for a quote and a space together to find the beginning of the parameters.
The same thing happens when you generate a shortcut for the exefile and put it on your SendTo menu. But the filepath for the parameter file name is the shorten 'GetShortPathName' format.
Enjoy your work, P1
PS: Chorus, the test.exe shows up outside the quotes as the full path in the 'GetShortPathName' format.
szQuoteString db 022h,0
invoke InString,
2,
ADDR szRawSource,
ADDR szQuoteString
.if eax > 0 ;found second quote mark.
.endif
Enjoy your work, P1
invoke InString,
2,
ADDR szRawSource,
ADDR szQuoteString
.if eax > 0 ;found second quote mark.
.endif
Enjoy your work, P1
>The fight however goes on.
Maybe you could be more specific...
From what I'm seeing, you could have a problem with the case of the character (upper or lower), but you'll have to give more information than you have.
--Chorus
As far as I can tell characters are automatically translated into upper case in low level programming, so that the lower you program the higher will be the results.
Was I specific enough?
P1, you're right. Sometimes the command line will show up with a quotation mark -- but certainly not always. I find it'll usually be there if the executable path is a long file name ex. if run from My Documents where the quotations indicate that the spaces are part of the path.
To solve this I always do a test on the first character to see if is a quotation or not, then I go find the first argument accordingly (which will either occur after the first space, or after the first quotation-space pair).
As far as I can tell characters are automatically translated into upper case in low level programming, so that the lower you program the higher will be the results.
The first part of this sentence seems to imply that because you program in Assembly language, all your characters are made into upper case. This is by no means true. If it were, you wouldn't be able to output any text but capital letters. Maybe I misunderstand you...
Also, I'm not sure how the second half of the sentence follows from the first. And I don't know what you are talking about when you say "results". The only result of concern here is the comparison of a byte with a letter from what I can tell by your code.
What I wanted to know was if your *new* problem is still the *old* problem. When you test against "j" or "s" are you getting one of these values? Or are you getting something else, like "J" or "S" or "m" or whatever? Is stuff being invoked? or other stuff? Maybe you're programming on a MacIntosh? What I'm getting at is that without any specifics, who knows why your code doesn't work.
--Chorus
To solve this I always do a test on the first character to see if is a quotation or not, then I go find the first argument accordingly (which will either occur after the first space, or after the first quotation-space pair).
As far as I can tell characters are automatically translated into upper case in low level programming, so that the lower you program the higher will be the results.
The first part of this sentence seems to imply that because you program in Assembly language, all your characters are made into upper case. This is by no means true. If it were, you wouldn't be able to output any text but capital letters. Maybe I misunderstand you...
Also, I'm not sure how the second half of the sentence follows from the first. And I don't know what you are talking about when you say "results". The only result of concern here is the comparison of a byte with a letter from what I can tell by your code.
What I wanted to know was if your *new* problem is still the *old* problem. When you test against "j" or "s" are you getting one of these values? Or are you getting something else, like "J" or "S" or "m" or whatever? Is stuff being invoked? or other stuff? Maybe you're programming on a MacIntosh? What I'm getting at is that without any specifics, who knows why your code doesn't work.
--Chorus
The command line that is passed to a program from the operating system varies depending on where it is from. Command.com, Winfile, Explorer etc ... and it varies from version to version of Windows.
I have tried with the algos in the MASM32 lib to handle most combinations of quoted or unquoted parameters but it seems that there are still combinations that it will fail on.
Usuaqlly long file names or paths must be enclosed in quotes but sometimes the command line is enclosed in quotes even if it is a short name.
Regards,
hutch@movsd.com
I have tried with the algos in the MASM32 lib to handle most combinations of quoted or unquoted parameters but it seems that there are still combinations that it will fail on.
Usuaqlly long file names or paths must be enclosed in quotes but sometimes the command line is enclosed in quotes even if it is a short name.
Regards,
hutch@movsd.com
Hello,
I've just another question to handling commandlines. My program passes a commandline to a .BAT file. All works fine, but when the parameters are longer than 85 byte, the filename is about 60 byte long. If the parameter is longer than mentioned the .BAT file isn't started. You can only read following:
It's only the same as if you've choosen to run the dos prompt. Is there any limitation to the lenght of a commandline. (I'm using ShellExecute to run the BAT-file)
:( Marwin
I've just another question to handling commandlines. My program passes a commandline to a .BAT file. All works fine, but when the parameters are longer than 85 byte, the filename is about 60 byte long. If the parameter is longer than mentioned the .BAT file isn't started. You can only read following:
Microsoft(R) Windows 98
(C)Copyright Microsoft Corp 1981-1999.
C:\WINDOWS>
It's only the same as if you've choosen to run the dos prompt. Is there any limitation to the lenght of a commandline. (I'm using ShellExecute to run the BAT-file)
:( Marwin