Greetings coders!,
Recently there have been several threads regarding commandline parsing. So,
I decided to dust off a library I developed: GetCLArgs is a commandline parser
library supporting both single and double quoted command line arguments.
Posted on 2004-02-19 22:11:21 by Poimander
I sometimes still add commandline args to my win32 apps so thanks, I'll probably use this at some point :)
Sure beats reinventing the wheel or copy-pasting code across projects as I often do for this kind of thing.
Posted on 2004-02-19 22:17:26 by Homer
I think most people have some home-brewed code for handling command line arguments :) .. here is my brew in case it's of use to anybody (posted a couple of years ago):

http://www.asmcommunity.net/board/showthread.php?threadid=7464

The only interesting thing about it is that it can handle simple command line switches too.
Posted on 2004-02-20 02:26:52 by Jibz
I prefer more "professional" command line parsers (for instance LINK.EXE)
with keys as a /Fn: c:\Myprogs\Myfilename.asm
and without quotes, double quotes, etc...(why to write more?!..)
I coded similar in my program Bin2Obj.zip:
http://www.asmcommunity.net/board/attachment.php?postid=118516

Regards,
Lingo
Posted on 2004-02-20 10:20:53 by lingo12
Well. this is only the first release so functionality isn't quite where I think it could be yet, but stay tuned for any future improvements.
Posted on 2004-02-20 22:13:55 by Poimander

I prefer more "professional" command line parsers (for instance LINK.EXE)
with keys as a /Fn: c:\Myprogs\Myfilename.asm
and without quotes, double quotes, etc...(why to write more?!..)
I coded similar in my program Bin2Obj.zip:
http://www.asmcommunity.net/board/attachment.php?postid=118516

Regards,
Lingo


didn't f0dder make bin2o?
Posted on 2004-02-20 22:26:59 by comrade
didn't f0dder make bin2o?

f0dder's bin2o is bigger and slower
without source code
http://www.asmcommunity.net/board/showthread.php?threadid=3722


My bin2obj is faster and smaller,
with source code,
because it is in assembly...
http://www.asmcommunity.net/board/showthread.php?threadid=14699&perpage=15&pagenumber=2


Regards,
Lingo
Posted on 2004-02-21 00:53:05 by lingo12
Well, I only convert once to obj... so speed is not factor. Size was never factor for me. But that's just me :)
Posted on 2004-02-21 11:31:01 by comrade
comrade, you heretic! Such a tool should of course be written in raw octal, with SSE2 optimizations! :rolleyes:
Posted on 2004-02-21 11:46:20 by f0dder

My bin2obj is faster and smaller,
with source code,
because it is in assembly...

I don't see how your tool automatically becomes faster and smaller because it was coded in assembly?
Such assumptions usually lead to 'tools' that are inherently bad designed and slow. The size is also usually non-optimal.
Not to say anything about your Bin2Obj tool...
Posted on 2004-02-21 12:01:51 by death
Let us not start war here :)
Faster and smaller is better than bigger and slower, but not much argument today :)
Posted on 2004-02-21 14:55:39 by comrade
true, true. I stopped working on bin2o when it met my requirements, anyway. There's a lot of room for improvement, like accepting textfile list instead of cmdline arguments, adding a symbol with the size of the data, etc. But who cares, it works fine ^_^
Posted on 2004-02-21 15:16:42 by f0dder
its f0dder vs lingo, ****hu
Posted on 2004-02-21 16:52:32 by comrade
comrade,

". so speed is not factor. Size was never factor for me. "

I'm wondering what your assembly life without factors is, hence you are not a factor too because of that...

"but not much argument today"

The arguments are in my shared source code



death,

"I don't see how your tool automatically becomes faster and smaller because it was coded in assembly?"

I assume you are blind for assembly C++ moron (as f0dder) because:

"it was coded in assembly BY ME"
and I shared my source code...
and if you can read assembly....
and if you red and understood the A. Fog's book...
and if you can use his methodology like me...

Ooops, you can see how I use A. Fog's methodology here:
http://www.asmcommunity.net/board/showthread.php?threadid=4358&perpage=15&pagenumber=2


"Such assumptions usually lead to 'tools' that are inherently bad designed and slow.
The size is also usually non-optimal."


What is this? Emotional and powerless HLL blab, blah, bla..
Where is your "faster" and "optimal" assembly code?
Don't forget you are just a blind moron


Not to say anything about your Bin2Obj tool.."

I'm not wondering why...he, he


Regards,
Lingo
Posted on 2004-02-21 17:04:05 by lingo12
Lingo, peace with you.

My tool is indeed "bigger" and "slower", but at 4kb and "the blink of an eye", I don't think anybody cares. Most of us would rather optimize stuff that matters :)
Posted on 2004-02-21 17:10:59 by f0dder
be nice people :)

lingo you would need quotes for "files with spaces in or the occassional weird char?.no"
Posted on 2004-02-21 17:15:30 by Hiroshimator
f0dder,

"Most of us would ... optimize stuff..."

I believe you can do that with C/C++ compiler's optimize keys ONLY....



Hiro,

"lingo you would need quotes for "files with spaces in or the occasional weird char?. No"

No, of course
It is as Link.exe ; we can write whatever between two keys or
between key and last zero

Regards,
Lingo
Posted on 2004-02-21 17:51:13 by lingo12

I believe you can do that with C/C++ compiler's optimize keys ONLY....

Well, that's not true. It's been a while since I wrote anything that needed optimization, though. And even when I write 'intensive' stuff, I prototype it in C, play with different algorithms, etc - then I decide whether or not to write assembly implementations.

Also, I'm not going to claim I'm a better asm optimizer than you are, that would be silly. I can get my stuff running decently at my target platforms, this is what matters to me. I'd rather focus on program design, security issues, extendability than writing the fastest possible wndproc handler :)
Posted on 2004-02-21 18:04:48 by f0dder
Lingo,

I downloaded your bin2obj and it seems to work fine. Where I have the problem is I don't have any info on how to access the data that is enclosed in the obj file.

This is the command line I ran.

bin2obj /fi:testfile.txt /fo:test.obj /id:mytest

I have tried declaring "mytest" as PUBLIC but when I try to load the address with code like,

mov eax, offset mytest

I get errors like,

: error A2006: undefined symbol : mytest

Could you let me know how it is supposed to be used ?

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-21 18:43:39 by hutch--
hutch, masm by default wants names prefixed with underscores - so use /id:_mytest on the bin2obj commandline and you'll be fine. Otherwise, figure out how to make masm generate non-underscore-prefixed EXTRN references for data (perhaps by defining the data as a proc with syscall calling convention, heh)
Posted on 2004-02-21 19:02:24 by f0dder