On 8/15/20 5:43 AM, Rémi Bernon wrote:
On 2020-08-15 09:39, Stefan Dösinger wrote:
Am 15.08.2020 um 01:44 schrieb Myah Caron qsniyg@protonmail.com:
Sorry I'm a bit new so I'm not quite sure what the rules are regarding TRACEs, but would adding a TRACE here be an issue? I think it might be helpful for future debugging if there are any other issues with it.
Those 'rules' are somewhat inconsistent. I would say adding a TRACE here is a good idea, but not strictly necessary.
A lot of functions in kernel32/kernelbase and ntdll have no TRACEs because they show up in a +relay log. But since I am used to COM interfaces in d3d which don't show up in relay logs (+relay injects code into DLL exports, and COM interfaces aren't PE exports) I am very used to +ddraw showing me all ddraw calls, so at times I am confused when +winmm doesn't show half the winmm calls.
Also, +relay doesn't work with some DRMs, so IMHO adding TRACE messages is always useful unless there's a performance penalty or too much verbosity.
For instance I would say ntdll could use more TRACE but it may be subjective so I've always kept these patches local.
The lack of traces in kernel32/ntdll is often an annoyance. +relay is often just not an option, due to slowness or excessive output size.
With regard to timeGetTime(), though, and time functions in general, I think it is likely better not to trace it. They may be called many times per second.