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.
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.
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.
Sure beats reinventing the wheel or copy-pasting code across projects as I often do for this kind of thing.
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.
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.
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
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
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.
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?
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
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
Well, I only convert once to obj... so speed is not factor. Size was never factor for me. But that's just me :)
comrade, you heretic! Such a tool should of course be written in raw octal, with SSE2 optimizations! :rolleyes:
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...
Let us not start war here :)
Faster and smaller is better than bigger and slower, but not much argument today :)
Faster and smaller is better than bigger and slower, but not much argument today :)
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 ^_^
its f0dder vs lingo, ****hu
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
". 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
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 :)
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 :)
be nice people :)
lingo you would need quotes for "files with spaces in or the occassional weird char?.no"
lingo you would need quotes for "files with spaces in or the occassional weird char?.no"
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
"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
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 :)
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
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
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)