flat assembler
Message board for the users of flat assembler.

Index > Windows > CreateThread and Proc

Author
Thread Post new topic Reply to topic
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
In my last post concerning includes, I was having a problem with endp etc.

Comrade helped me out and I thought everything was working. I made some test programs and everything worked.

Today, I am still having problems with some aspect of CreateThread or includes or the assembler itself.

Code:
; LN:91 CREATETASK CommTask
invoke CreateThread,0,0,CommTask,0,0,STATUS
mov [!CommTask],eax
.
.
.
proc CommTask,STATUS
enter
push esp
; LN:174 BEGIN LOOP
_Lbl42:
; LN:175 GOSUB GetData
call GetData
; LN:176 END LOOP
jmp _Lbl42
_Lbl43:
; LN:177 END TASK
pop esp
return
    


The CreateThread is the last thing in the window's create event.

The other code is at the very bottom of my code. It works as shown, but if I move the bottom part anywhere else or embed the subroutine (GetData) within the thread procedure, I get compile errors on known good lines of code. The same lines of code that work fine as presented here.

The rule seems to be that if I can get it to assemble, it will run as expected.

BTW, almost forgot, I'm using version 1.56. I also tried 1.64 with no difference.
Post 27 Dec 2005, 07:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system
revolution
I think you need to post a compilable subsection of your code here. That makes it easier for others to help you. Try to reduce it to just the parts that you are having the trouble with then show the working vs non-working code sets so we can compare and see what is going wrong.
Post 27 Dec 2005, 08:37
View user's profile Send private message Visit poster's website Reply with quote
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
revolution,

I will try to do that. Please keep in mind that this is compiler gerated code which carries a lot of code that has nothing to do with the problem. I will either pare back a compiled file or, alternatively make a hand generated pgm that will demonstrate the problem. Either will take some time.

With that said, I would think that someone could tell me if the proc in my post has correct ot incorrect framing, and why moving the frame around should have any affect.

I think we are going to find out that there is an error in my framing or that there is an assembler bug.

Thanks,

Mike
Post 27 Dec 2005, 21:21
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
Quote:

invoke CreateThread,0,0,CommTask,0,0,STATUS
mov [!CommTask],eax

What is the ! doing in your mov? Looks odd are you NOTing the memory address of the proc and then mov the ThreadHandle (in EAX) into that NOTed address? or is the ! meaningless, in which case your overwriting the ENTER instruction in your thread proc with EAX?

Why is STATUS being used as a parameter for your thread proc and the parameter for the CreateThread function to return the threadID? If you want your thread proc to know its thread ID then pass the memory address to STATUS in the correct arg of CreateThread.

Also, in your thread proc you have an ENTER opcode but you have no LEAVE opcode before the return statement.
Why even bother using the PROC macro at all?

More context (what your trying to accomplish) is need to fix your problem.
Post 28 Dec 2005, 00:24
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
r22,

The ! is used because it is an acceptable char in a symbol name in fasm, but not to my compiler users. I allows the compiler to generate priviledged names. In fasm ! has nothing to do wit NOT, that is the c language.

STATUS is a compiler variable set to the result of many (usually I/O) operations so that the user can see status.

My usage of STATUS in the CreateThread is merely to allow the user to store away the ID if he wishes to. You will notice that the compiler stores away the handle for its own <later> use. There is nothing incorrect about this at all.

Quote:

Also, in your thread proc you have an ENTER opcode but you have no LEAVE opcode before the return statement.
Why even bother using the PROC macro at all?


This is where someone may be able to help me. If you look at the earlier thread I mentioned, Comrade and I were trying to figure out what was nedded here and what the macros were doing.
Post 28 Dec 2005, 00:39
View user's profile Send private message Reply with quote
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
r22,

Quote:

Also, in your thread proc you have an ENTER opcode but you have no LEAVE opcode before the return statement.
Why even bother using the PROC macro at all?


I think there is a lot of wisdom in this statement!

I changed the proc to look like this:

[code]
CommTask:
push esp
; LN:174 BEGIN LOOP
_Lbl42:
; LN:175 GOSUB GetData
call GetData
; LN:176 END LOOP
jmp _Lbl42
_Lbl43:
; LN:177 END TASK
pop esp
ret

Now it assembles fine under all of the conditions that it previously failed.

I think maybe I should adjust the stack at the beginning to throw away the incoming arg? Is this correct.

I think what it would be helpful if someone would describe all these framing macros.

Another way of asking this is: if my pgm works fine without all these framing macros, why use them?

Thanks,

Mike
Post 28 Dec 2005, 01:50
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.