Hi,

I have a little problem with this code:

.386
.model flat,stdcall
option casemap:none

include win32.inc
include user32.inc
include kernel32.inc
;includes .. all ok
includelib import32.lib


.data

explorer db "C:\explorer.exe",0

.code

Start:

;calls to messagebox,createprocess:all ok

call open_program,OFFSET explorer
call ExitProcess,0

open_program PROC NEAR STDCALL, svPath:DWORD

;====> TASM VERSION CRASHES HERE:MASM VERSION WORKS
call MessageBox,0,,0,MB_OK

ret
open_program endp

end Start

******************

The messageboxa call crashes the program, i don't know why tasm-compiled binary can't access the argument, it should do.I compiled the code under masm and the executable works OK.

No link and compiler parameters for TASM.

I see in many source codes that i can access function arguments using their name, but in this case it doesn't work. :cry: How can i access the function's argument then? Using ebp?
Posted on 2004-08-29 20:49:20 by giacos
use so,

open_program PROC NEAR, svPath:DWORD
Posted on 2004-08-29 21:42:01 by cakmak
still crashing ..
Posted on 2004-08-30 06:44:21 by giacos
I'm new to ASM my self and am not familiar with TASM, but in NASM saying tells the assembler to access the value at the memory location of svPath, whereas the MessageBoxA wants a pointer to the memory location, not the value. I'm not sure how you do it in TASM (possibly with OFFSET svPath?), but in NASM you would just remove the brackets.
Posted on 2004-08-30 10:01:21 by ben
with or without brackets and offset i still get a crash :(
Posted on 2004-08-30 10:04:50 by giacos
Can post a binary?
Posted on 2004-08-30 10:08:14 by roticv
i included source file and binary in the attachment .. tasm has really strange behaviour, i wrote some new lines and now it doesn't crash but it shows strange strings :?
Posted on 2004-08-30 10:12:40 by giacos
Can't run OllyDbg, can't use masm or fasm or goasm or... ? :)
Posted on 2004-08-30 10:12:54 by f0dder
Can't run OllyDbg, can't use masm or fasm or goasm or... ?


If i'm here maybe i need some help to fix the problem :)

I debug many times using olly and it seems tasm assembles incorrectly, jnz instead of jmp and similar :? I'd prefer to use tasm instead of masm (micro$oft CRAP :twisted: ).nasm naaah..

:roll:
Posted on 2004-08-30 10:25:11 by giacos
I think this is a pretty good example that it's tasm, not masm, that is crap :rolleyes: - the code is simple and straightforward, and yet tasm manages to screw it up (and my oh my, it uses ENTER to do a strack frame? Icky.)

Of course it's your choice, but tasm is old and defunct, and there are better assemblers available (and yes, masm is one of them.)
Posted on 2004-08-30 10:33:58 by f0dder
I'd prefer not to use masm because it's a microsoft product, and i don't like them.This is because i define crap all they do. :lol:

However i think one can say that tasm is one of the better assemblers, this is the impression i got browsing various forums and sites.
Posted on 2004-08-30 10:38:34 by giacos

I'd prefer not to use masm because it's a microsoft product, and i don't like them.This is because i define crap all they do.

Isn't that a bit silly? Visual C++ is one of the best x86 compilers, visual studio is a nice IDE, The NT flavours of windows are pretty stable and high-performing (even XP is okay with SP2 and all the fisher-price turned off), etc...


However i think one can say that tasm is one of the better assemblers, this is the impression i got browsing various forums and sites.

Let's see - TASM is commercial (last time I looked, it wasn't included in FreeCommandLineTools), while MASM can be obtained for free (and legally). TASM uses OMF object files, while the defacto standard on win32 is COFF. TASM has even more quirks than masm (and that's a big uh-oh ;) ). I don't know if borland has upgraded it, but last time I looked SSE/SSE2 (heck, even MMX) required use of funky user macros, rather than having built-in support. And considering your own statement, I debug many times using olly and it seems tasm assembles incorrectly, jnz instead of jmp and similar, how can you say tasm is a better product than masm? :)

If you really are that opposed to Microsoft, either go Linux, or look at GoAsm, FASM, or perhaps RosAsm...
Posted on 2004-08-30 10:52:11 by f0dder
Isn't that a bit silly? Visual C++ is one of the best x86 compilers, visual studio is a nice IDE, The NT flavours of windows are pretty stable and high-performing (even XP is okay with SP2 and all the fisher-price turned off), etc...


Ok i admit it:i was provoking you with masm, since your attitude is a bit aggressive and one-sided in my opinion.I only asked a question ! But now let's be serious.

I'm not an expert, as i said, about ASM and assemblers, however i read many nice things about TASM.So i decided to go for it.Now i'm going to switch to MASM or NASM since TASM shows this "strange behaviours".I'm going to check out nasm also.

I use visual c++ and i have to agree with you, nice compiler and nice ide.

Ok let's end this, no rancour for me.
Posted on 2004-08-30 11:02:19 by giacos

since your attitude is a bit aggressive and one-sided in my opinion.

I offer you my humble apologies :)

I just get annoyed when people hold on to old stuff without any reasonable explanation, and I'm tired of Microsoft-bashing that isn't reasonable (I'm all for bashing their business model though, that really sucks. But some of their products are quality products.)

There's multiple assemblers you should check out. You could probably call NASM and FASM "brothers", their syntax and ideals are pretty close. NASM seems a bit stagnant though, while FASM is under (very) active development. FASM is also pretty fast, and has pretty powerful macro features. It's a very good assembler if you need to do "funky stuff", and it's speed makes it well suited for use in, say, a compiler system.

MASM is the defacto assembler for the win32 platform, that alone makes it worth looking at it. It has some quirks, but it works pretty well for application development and is easy to use for application development (and it has nice STRUCt and PROCedure support).

GoASM is interesting because of it's unicode support and the way it handles imports (no import libraries, you can call directly - powerful ordinal support as well). I haven't played with GoASM yet, but it's on my todo list.

RosASM... well, it's radically different, and I'm not too fond of it for various reasons - but give it a shot and see if you like it.

There's at least a couple of other assemblers under development too, but I have no experience with them whatsoever, so I can't recommend either for or against them.
Posted on 2004-08-30 11:18:48 by f0dder
I offer you my humble apologies

I just get annoyed when people hold on to old stuff without any reasonable explanation, and I'm tired of Microsoft-bashing that isn't reasonable (I'm all for bashing their business model though, that really sucks. But some of their products are quality products.)

There's multiple assemblers you should check out. You could probably call NASM and FASM "brothers", their syntax and ideals are pretty close. NASM seems a bit stagnant though, while FASM is under (very) active development. FASM is also pretty fast, and has pretty powerful macro features. It's a very good assembler if you need to do "funky stuff", and it's speed makes it well suited for use in, say, a compiler system.

MASM is the defacto assembler for the win32 platform, that alone makes it worth looking at it. It has some quirks, but it works pretty well for application development and is easy to use for application development (and it has nice STRUCt and PROCedure support).

GoASM is interesting because of it's unicode support and the way it handles imports (no import libraries, you can call directly - powerful ordinal support as well). I haven't played with GoASM yet, but it's on my todo list.

RosASM... well, it's radically different, and I'm not too fond of it for various reasons - but give it a shot and see if you like it.

There's at least a couple of other assemblers under development too, but I have no experience with them whatsoever, so I can't recommend either for or against them.


apologies accepted, no problem :)

I agree with you about Microsoft, bad marketing strategies and business model, but they also develop some really nice apps.

Oh and thx for the advice, i'll check out.
Posted on 2004-08-30 11:47:56 by giacos
giacos,

Remove the NEAR STDCALL statement from your procedure definition and your example will be assembled fine.

Also, you can consider using MS link instead of tlink. Microsoft's linker is able to convert OMF object code to COFF, plus it creates smaller executables compared to the minimum 4Kb standard of tlink. Here, the only trick with the MS linker is to use special import libraries which contains non-decorated API function names. My tool dll2lib creates these import libraries directlt from DLLs.
You need to have ml.exe and Polink.exe at c:\masm32\bin to run dll2lib.
The attachment contains your example linked with MS link, also I included the import libs.

You have another alternative to link Tasm object files, the linker from Digital Mars, a powerfull OMF linker. Plus, with some linker tricks, you can even link Tasm object code with GoLink or Polink. To see some examples, have a look at:

Creating import libs to use Fasm/GoAsm/Tasm with MS Link
http://www.asmcommunity.net/board/viewtopic.php?t=13805

PS : Polink is Pelle's linker coming also with the latest masm32 package.
Posted on 2004-08-30 13:16:28 by Vortex
giacos,

your program is crashing becoz the MessageBox() is accessing not the first param of the function, but the second!! (that dont exists)

becoz this it get a pointer inside to kernel, and show trash in MessageBox().

i dont have the includes you use, so i can confirm that, but you should try to use that as proc header:

show_message PROC
ARG svString:DWORD

and access svString using [], as is the correct way :wink:

also, you dont need NEAR and STDCALL in proc definition, coz you already defined STDCALL in model directive, and near dont make much sense in flat model too

ancev

ps: and, f0dder... a assembler is as good as the man behind it 8) and, moreover, they dont make difference at all after the first 6 months. after you learn, coding using a assembler or other is matter of minutes
Posted on 2004-08-30 14:01:39 by ancev
Vortex, big thanks! I changed NEAR STDCALL and the example works well.

answered
Posted on 2004-08-30 14:02:28 by giacos
ancev, now it works with or without the brackets,since i'm in masm mode.

The only problem was NEAR STDCALL, if i remove it the code works perfectly.

Is there a difference between this:

show_message PROC
ARG svString:DWORD

and this:

show_message PROC , svString:DWORD

?

If i like to access arguments manually, i'm going to do:

mov eax,
mov ecx
Posted on 2004-08-30 14:08:23 by giacos
giacos,

both way of proc are the same, i guess. i like more using ARG keyword, coz i make a block of them and LOCAL directives, and know all my stack acess at a glance

ancev

ps: if you will access your params manually, then use direct access, and free EBP to others uses :wink:
Posted on 2004-08-30 14:15:30 by ancev