Joined: 16 Jun 2003
Location: Kraków, Poland
Since Cancel means TerminateThread(), it could be so (though the window of opportunity is not so wide, you have to be [un]lucky enough).
Yes, it's exactly like that. It may be possible to fix this by modifying the code of "open", "create" and "close" in the fasm's interface API, so that they keep track of the handles and the main thread can then clean it up.
TerminateThread should never be used anywhere.
Actually, in the case of fasm's thread, its only weak spots are the file access and allocation of main memory block. If some kind of mutex was introduced to prevent thread termination in these few vulnerable places, all the rest of fasm's code is safe to be terminated at any moment, simply because it uses no external functions and operates within its own data structures that are re-created from scratch inside that single memory block each time the thread is started, overwriting any possible leftover from the previous thread executions.
I did not put any safeties into those few weak spots simply because I belittled the chances of actually hitting the mark and landing in one of them when pressing "Cancel".
I don't know if this is related, but I once had a consistent problem with "Error: Write Failed" when I was on Win 8 and using multiple version of FASMW and even FASM. I had to wait for almost a minute to enable me to run my code after the "write failed" compilation. The workaround;
1. Compatibility: Lowered to WinXP SP 2
2. Enabled write/disk cache on the disk. Can't remember the exact steps but it was something on the Disk property's Policy.
Problems gone. I think this has nothing to do with FASM.
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