On 11/4/21 4:31 AM, Alexandre Julliard wrote:
Zebediah Figura zfigura@codeweavers.com writes:
@@ -3394,7 +3394,7 @@ typedef void (CALLBACK *PLDR_DLL_NOTIFICATION_FUNCTION)(ULONG, LDR_DLL_NOTIFICAT
/* these ones is Wine specific */ #define LDR_DONT_RESOLVE_REFS 0x40000000 -#define LDR_WINE_INTERNAL 0x80000000 +#define LDR_WINE_BUILTIN 0x80000000
That doesn't seem necessary.
No, it's not necessary. The idea is that LDR_WINE_INTERNAL is somewhat ambiguous, especially if we're introducing a second sense in which a module can be internally marked, and I wanted to clarify it.
I suppose that it's less ambiguous to one who is familiar with the loader code, though. I'll resend the series without this patch.
Zebediah Figura zfigura@codeweavers.com writes:
On 11/4/21 4:31 AM, Alexandre Julliard wrote:
Zebediah Figura zfigura@codeweavers.com writes:
@@ -3394,7 +3394,7 @@ typedef void (CALLBACK *PLDR_DLL_NOTIFICATION_FUNCTION)(ULONG, LDR_DLL_NOTIFICAT /* these ones is Wine specific */ #define LDR_DONT_RESOLVE_REFS 0x40000000 -#define LDR_WINE_INTERNAL 0x80000000 +#define LDR_WINE_BUILTIN 0x80000000
That doesn't seem necessary.
No, it's not necessary. The idea is that LDR_WINE_INTERNAL is somewhat ambiguous, especially if we're introducing a second sense in which a module can be internally marked, and I wanted to clarify it.
Actually I'm not convinced we need a second name here. It seems to me that the "system" flag can be a purely ntdll-internal thing that doesn't have to be exposed in the LDR data.
Arguably the system modules themselves should not be exposed in the process module list, but that may be more complicated...
On 11/4/21 2:28 PM, Alexandre Julliard wrote:
Zebediah Figura zfigura@codeweavers.com writes:
On 11/4/21 4:31 AM, Alexandre Julliard wrote:
Zebediah Figura zfigura@codeweavers.com writes:
@@ -3394,7 +3394,7 @@ typedef void (CALLBACK *PLDR_DLL_NOTIFICATION_FUNCTION)(ULONG, LDR_DLL_NOTIFICAT /* these ones is Wine specific */ #define LDR_DONT_RESOLVE_REFS 0x40000000 -#define LDR_WINE_INTERNAL 0x80000000 +#define LDR_WINE_BUILTIN 0x80000000
That doesn't seem necessary.
No, it's not necessary. The idea is that LDR_WINE_INTERNAL is somewhat ambiguous, especially if we're introducing a second sense in which a module can be internally marked, and I wanted to clarify it.
Actually I'm not convinced we need a second name here. It seems to me that the "system" flag can be a purely ntdll-internal thing that doesn't have to be exposed in the LDR data.
Arguably the system modules themselves should not be exposed in the process module list, but that may be more complicated...
Indeed, it could be made a separate field in WINE_MODREF. I assumed that the best thing to do would be to stash it in the flags field, alongside LDR_DONT_RESOLVE_REFS which also isn't used outside of ntdll, but maybe that one deserves to be changed too.