Huw Davies huw@codeweavers.com wrote:
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec index 3c25286..224e6ae 100644 --- a/dlls/kernel32/kernel32.spec +++ b/dlls/kernel32/kernel32.spec
...
+@ stdcall DeleteProcThreadAttributeList(ptr)
...
+@ stdcall InitializeProcThreadAttributeList(ptr long long ptr)
...
+@ stdcall UpdateProcThreadAttribute(ptr long long ptr long ptr ptr)
UMS (User Mode Scheduler) stuff should be implemented in ntdll and kernel32 APIs should be either forwards or thin wrappers around the ntdll exports. So, to avoid duplicate efforts this all from the start needs to be implemeted in ntdll.
So which ntdll functions are you suggesting they forward to?
I can't find ntdll exports for managing thread attribute lists, but on the other hand NtCreateThreadEx isn't documented either, and it's not clear how the UMS thread attributes are passed (if any) to it. Perhaps thread attributes are a kernel32 side only thing, and they have no equavalent on the real (ntdll) UMS side, in that case perhaps there is no point in implementing them without understanding how they are supposed to be used.
I do understand how they are supposed to be used. The attribute list is part of the STARTUPINFOEX structure that can be passed to CreateProcess. The app I’m looking at uses it to pass a list of handles that in wants the child process to inherit.
Thanks for the clarification, that means that the attribute lists are not a UMS centric thing after all.
I think you have got a bit distracted by the UMS stuff.
That looks like the case, yes. Thanks again.