Hi,
On Mon, Jul 12, 2004 at 07:53:33AM +1000, by way of Troy Rollo troy@corvu.com.au wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
_w95_dump_dke has code in it that processes sibling keys in the registry recursively. This results in a stack blowout for large registries (in my case in the Software\CLASSES key).
Ah, someone else also discovered it. Yep, also Software\CLASSES.
It's trivial to stop the stack blowing out by changing this not to be recursive, but processing siblings recursively is such an unusual thing to do that I suspect it must have been done for a reason. Attached is the way I've "fixed" it, but this causes the keys to be output in the opposite order to the way they are output with the CVS code.
Same here. I intended to fix it, but at the same time I suspected that there is a reason for this to be done recursively.
Is there a reason this needs to be done in the order the CVS code is doing it?
- entry sort order? - coolness? ;) (ok, forget it, it's not cool...)
This came up on LinuxTag, and we asked Marcus Meissner (who also visited us there :) about some specifics, but of course he doesn't remember much after almost a decade ;-) I think what one should do is testing it with a *small* Win9x registry (well, at least small enough to not crash...) and comparing the result with recursive and non-recursive code.
The beginning of that function also does some suspicious root key check which isn't particularly helpful for recursive call performance... (would be useful to get that re-coded away somehow when going for a more iterative approach).
How to proceed? Anyway, this cries for a fix, since probably many Win9x installations are affected.
Greetings,
Andreas Mohr