When I write patches touching the loader code (including process and thread initialization and startup), it would be useful to know the overall plans for that area. Generally I'm asking about ntdll.
What is the team's overall direction for that area of code? Is it as simple as "it just has to work"? Are there things about how it works that aren't expressed in code but have to be preserved? Or do you have plans for how you're intending to change it in the future?
Thanks, Jefferson
Am 02.09.2020 um 13:29 schrieb Jefferson Carpenter jeffersoncarpenter2@gmail.com:
What is the team's overall direction for that area of code? Is it as simple as "it just has to work"? Are there things about how it works that aren't expressed in code but have to be preserved? Or do you have plans for how you're intending to change it in the future?
It is complicated and always evolving. The ntdll tests certainly capture a lot of requirements, but not everything. What's making matters more complicated is that DRM and anti-cheat systems hook into ever-lower levels of ntdll, and we have to do our best to replicate how things work on Windows.
What is it that you are trying to do in the loader code?
On 9/2/2020 11:04 AM, Stefan Dösinger wrote:
Am 02.09.2020 um 13:29 schrieb Jefferson Carpenter jeffersoncarpenter2@gmail.com:
What is the team's overall direction for that area of code? Is it as simple as "it just has to work"? Are there things about how it works that aren't expressed in code but have to be preserved? Or do you have plans for how you're intending to change it in the future?
It is complicated and always evolving. The ntdll tests certainly capture a lot of requirements, but not everything. What's making matters more complicated is that DRM and anti-cheat systems hook into ever-lower levels of ntdll, and we have to do our best to replicate how things work on Windows.
What is it that you are trying to do in the loader code?
Well, right now I have bugs 49755, 49754, and 49495 open indicating valgrind warnings in the ntdll code. I recently submitted "[PATCH] ntdll: Decouple pthread stack and win32 stack." to try to fix the last one, but it was rejected for good reasons.
It's good to know you have pretty thorough test coverage.
Those bugs might be closed without needing to be patched if the warnings are all false positives. However as I look into matters I might come across some useful patches. I just want to submit worthwhile patches that won't break anything.
-Jefferson
-
Jefferson Carpenter -
Stefan Dösinger