Re: [PATCH v3 0/4] MR3423: Iphlpapi: Implement NotifyAddrChange (part 1 of 2)

[Paul Gofman (＠gofman)]

On Thu Jul 27 20:38:34 2023 +0000, Zebediah Figura wrote:
> > Beyond the test included in the patches, I did roughly the following:
> > ptr = VirtualAlloc(NULL 4096 \* 2, PAGE_NOACCESS); VirtualProtect(ptr,
> > 4096, PAGE_READWRITE); params = ptr + 4096 - sizeof(\*params). And used
> > that pointer. So far it doesn't access it beyond the end of accessible
> > memory (that succeeds).
> > Ah yes, that definitely sounds convincing to me :-)
> > It might happen that with some other values for unknown parameter it
> > is using more data from the structure, but IMO exploring more details
> > about those parameters, in the absence of any known app which uses those
> > functions, looks like a waste of time to me. It is relatively easy here
> > with nsi and was already explored for other functions so I didn't want
> > to break this tradition in nsi, but in general it seems impractical to
> > me to spend huge amount of time reversing the exact parameters of the
> > undocumented functions which nothing is using directly. Not feasible for
> > implementing larger APIs and the benefit is not obvious. And once
> > something is using directly in a way we don't support we can rather
> > easily look how and test with those parameters.
> > Sure. I don't think we necessarily need to figure out the unknown
> > parameter, or spend too much effort on reverse-engineering undocumented
> > things in general, or closely matching undocumented APIs.
> > I only get nervous about the prospect of implementing undocumented APIs
> > that are incorrect in ways that would be subtle or hard to debug—wrong
> > number of parameters, wrong struct sizes, and so on. To a degree, the
> > fact that an application even uses such APIs means that it's a first
> > place to look when debugging, but that's not exactly the kind of thing
> > that's trivial to notice.
> > I could possibly add a fixme for nonzero unk parameter?
> > That sounds like a unilaterally good idea to me, at least.
> > Now when this patchset is split in two this first part has only a stub FIXME there anyway; I will update the second part with the specific fixme for unknown parameter.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/3423#note_40573