Put path and name variables in lm_module_t (and maybe lm_process_t)

[rdbo]

To avoid calling LM_GetModulePath(Ex) and LM_GetModuleName(Ex) all the time, why not just make a variable inside the lm_module_t of size LM_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:

typedef struct {
        lm_address_t base;
        lm_size_t    size;
        lm_address_t end;
        lm_tchar_t   path[LM_PATH_MAX];
        lm_tchar_t  *name;
} lm_module_t;

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.

[rdbo]

After doing this, I could remove LM_GetModulePath(Ex) and LM_GetModuleName(Ex), since that information will always be present in the module.

[rdbo]

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;

[rdbo]

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.

[rdbo]

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.

[rdbo]

Done for lm_module_t: 30ada7cade137c8cf1a1a89529a4ac476ef996e6

[rdbo]

Done for lm_process_t: 4fe50e5ac81fe7ba28208fdc6c91cda3d7cca1a7