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
Posted on 2002-08-16 11:07:00 by shafieian
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...
Posted on 2002-08-16 11:19:51 by JimmyClif
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
Posted on 2002-08-16 12:24:41 by 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.
Posted on 2002-08-16 12:43:42 by Homer
masm32.lib has some nice functions which make commandline handling easy.
Posted on 2002-08-16 14:13:19 by bazik
And what is so useful about this utility? :)
Posted on 2002-08-16 15:37:05 by f0dder

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.)
Posted on 2002-08-16 17:00:30 by bazik
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
Posted on 2002-08-17 11:15:37 by shafieian
>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
Posted on 2002-08-17 16:54:23 by 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.
Posted on 2002-08-18 11:04:43 by Pone
szQuoteString db 022h,0

invoke InString,
2,
ADDR szRawSource,
ADDR szQuoteString
.if eax > 0 ;found second quote mark.
.endif

Enjoy your work, P1
Posted on 2002-08-18 11:08:39 by Pone

>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?
Posted on 2002-08-18 11:44:04 by shafieian
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
Posted on 2002-08-19 08:15:55 by 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
Posted on 2002-08-19 09:13:54 by hutch--
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:


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
Posted on 2002-08-22 08:31:42 by Marwin