Hi, On Mon, Jul 12, 2004 at 07:53:33AM +1000, by way of Troy Rollo <[EMAIL PROTECTED]> 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
