flat assembler
Message board for the users of flat assembler.

Index > Windows > New Includes

Author
Thread Post new topic Reply to topic
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
I was trying to use CreateThread, and found out that endp is missing from my macro includes. I am using version 1.56 with some older include files.

I tried to use the new includes from version 1.56 and now it doesn't like my WindowProc line.

What gives?
Post 25 Dec 2005, 05:03
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
use old includes

what a nightmare, i have stopped upgrading since 1.54 because of the include files discompatibility
Post 25 Dec 2005, 05:24
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
msmith



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

I think that's good advice becuase I'm using FASM for a backend to my compiler, so I don't need or use all of the features anyway.

Can you tell me how to "frame" a thread proc without the endp macro (since I can't use it)?

BTW I've been building tube amplifiers and using a lot of Russian tubes (valves). The Svetlana and Sovtek products are very good.
Post 25 Dec 2005, 05:52
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
With old macros, you use the "return" macro in place of "endp".

This macro will generate a proper retn instruction, after removing the stackframe created by the "proc" macro.

I am glad you support the work of the proletariat.
Post 25 Dec 2005, 06:43
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
I tried using the return macro.

Now it fails on: je __MovArgSpace which is about 10 instructions down the line.

This instruction is part of a routine which has been running for years.

If I remove the CreateThread and the following code it assembles ok.

Code:
proc th1,STATUS
push esp
inc [x]
pop esp
return
    


As you can see, I just wanted to test threads by incrementing x and looking at the value of x elsewhere in a timer callback event.

Any ideas?

BTW if I remove the code above, but not the CreateThread, then the CreateThread line fails. I didn't know that fasm examined the args of an invoke.
Post 25 Dec 2005, 07:08
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
Perhaps you forgot to "return" from a previous "proc"...
Post 25 Dec 2005, 07:29
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
msmith



Joined: 22 Jun 2003
Posts: 40
Location: Missouri
msmith
No, the only other proc is WindowProc and it has a return.
Post 25 Dec 2005, 07:49
View user's profile Send private message Reply with quote
msmith



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

Thanks for all of your help.

I now have it working as follows:

Code:
proc th1,STATUS
enter
push esp
lp1:
inc [x]
jmp lp1
pop esp
return
    


If this code comes before the CreateThread, I get an error. If it comes later, all is well. This not only assembles ok, it works.

This is my first try at threads, so I have a lot to learn. Before I added the jmp lp1 instruction, x only counted to 1. So it looks like if the thread proc finishes, control never goes back to the thread.

As mentioned in an earlier post, a timer callback routine reports the value of x. Using the code above, it counts like crazy!

One of the first uses for this will be a routine to check the status of 16-32 comm ports and receive data from them. I don't like the way Overlapped I/O works, so this is a good alternative for me.

It is really a shame that MS took out the WM_COMMNOTIFY message and added the ugly overlapped scheme to replace it.

The way I wrote my serial communications routines, I assumed that there would be an event message to show UART activity. Well, there was, but MS removed it. I don't see why they couldn't have left it in when they added the overlapped functions.
Post 25 Dec 2005, 20:18
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.

Powered by rwasa.