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?

use old includes

what a nightmare, i have stopped upgrading since 1.54 because of the include files discompatibility

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.

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.

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.



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.

Perhaps you forgot to "return" from a previous "proc"...

No, the only other proc is WindowProc and it has a return.

Comrade,

Thanks for all of your help.

I now have it working as follows:



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.