format pe gui
include 'win32ax.inc'
entry start

section '.data' data readable writeable
fileName db 'E:\text.exe',0
hFile dd ?

section '.code' code readable executable
start:
invoke CreateFileA,fileName,GENERIC_READ or GENERIC_WRITE ,\
FILE_SHARE_WRITE,\
NULL,OPEN_EXISTING,0,0
cmp eax,INVALID_HANDLE_VALUE
jz lppt

lppt:
ret


section '.import' import data readable
library kernel32,'kernel32.dll'
include 'api\kernel32.inc'    

GENERIC_READ or GENERIC_WRITE    

invoke  CreateFileA,fileName,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL    

invoke  CreateFileA,fileName,GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL    

Also use invoke ExitProcess,0 instead of ret

In Windows Super Sky 9 not calling ExitProcess could left the process in zombie state? Razz (don't remember if this state is implemented on Windows)

This pratical consideration should answer at all, until you can prove the opposite case.

Tomasz: Windows internals are not documented by MS - you aren't told if the main thread is created with CreateThread, CreateRemoteThread, ZwCreateThread, or something completely different. You're relying on the documentation of user-mode CreateThread. I don't have the DDK documentation handy right now, so I can't look up ZwCreateThread, but you can be pretty sure it doesn't lead to the same KERNEL32.DLL code that CreateThread does

DWORD WINAPI ThreadProc(
  __in  LPVOID lpParameter
);    

If one of the terminated threads in the process holds a lock and the DLL detach code in one of the loaded DLLs attempts to acquire the same lock, then calling ExitProcess results in a deadlock. In contrast, if a process terminates by calling TerminateProcess, the DLLs that the process is attached to are not notified of the process termination. Therefore, if you do not know the state of all threads in your process, it is better to call TerminateProcess than ExitProcess. Note that returning from the main function of an application results in a call to ExitProcess.

CreateProcess=CreateThread?

What I mean is that you rely on the fact that you can return from ThreadProc, but since the entry point is NOT documented as ThreadProc, how do you conclude that RET will be always safe?

And another problem, doing just RET will be equivalent to ExitProcess, TerminateProcess or neither of both?

the only logical conclusion is that every thread should be ThreadProc-like

How Processes are Terminated

A process executes until one of the following events occurs:

* Any thread of the process calls the ExitProcess function. Note that some implementation of the C run-time library (CRT) call ExitProcess if the primary thread of the process returns.
* The last thread of the process terminates.
* Any thread calls the TerminateProcess function with a handle to the process.
* For console processes, the default console control handler calls ExitProcess when the console receives a CTRL+C or CTRL+BREAK signal.
* The user shuts down the system or logs off.