Closed rdbo closed 1 year ago
After doing this, I could remove LM_GetModulePath(Ex)
and LM_GetModuleName(Ex)
, since that information will always be present in the module.
Maybe the same should be done with lm_process_t
.
In the previous commits, I got rid of it in order to interact solely with lm_pid_t
. I did that so you could avoid opening/closing process handles.
But the new lm_process_t
struct wouldn't have to be opened and closed, it would just contain information about the process. Something like this:
typedef struct {
lm_pid_t pid;
lm_pid_t ppid;
lm_size_t bits;
lm_tchar_t path[LM_PATH_MAX];
lm_tchar_t *name;
} lm_process_t;
In order to do this, some process APIs will have to be reduced to take only a PID as parameter (like LM_GetModulePathEx
) because those functions will be called to initialize process itself. If they take a process and a process needs that function to initialize, it will cause an infinite loop.
In order to do this, some process APIs will have to be reduced to take only a PID as parameter (like
LM_GetModulePathEx
) because those functions will be called to initialize process itself. If they take a process and a process needs that function to initialize, it will cause an infinite loop.
I just found out that the Windows API structure PROCESSENTRY32
already stores the executable path. Which means there really is no need to port LM_GetModulePathEx
to some sort of PID system. On Linux, I can use readlink
on /proc/<pid>/exe
.
Done for lm_module_t
: 30ada7cade137c8cf1a1a89529a4ac476ef996e6
Done for lm_process_t
: 4fe50e5ac81fe7ba28208fdc6c91cda3d7cca1a7
To avoid calling
LM_GetModulePath(Ex)
andLM_GetModuleName(Ex)
all the time, why not just make a variable inside thelm_module_t
of sizeLM_PATH_MAX
that will store the path of the module, and another variable that will point to the filename of the path? Something like this:One concern I have about this is that LM_PATH_MAX may be a little too large and occupy a big space in the stack. To mitigate this, I would set it to a constant value that I know won't be a big worry, like 1024 or 4096, and make it not OS-dependent. After all, how many module paths are longer than 1024 chars or even 4096? None that I've seen.