• Jay Jacobson (13/13) Jan 12 2007 I've been working with the example from this location:
• Jay Jacobson (10/31) Jan 14 2007 I was tinkering with this some more this morning and located and fixed

Jay Jacobson <jjjacobson gmail.com> writes:

I've been working with the example from this location:
http://www.dsource.org/projects/tutorials/wiki/RegistryEnumerationExample

It is obvious from that example that there is some kind of issue with the
module. However, I've put a simple test app together based on that code which
appears to show some form of what looks like stack corruption going on around
that module. I was able to generate an uncorrupted file by going within the
module (std.windows.registry) for the output.

There are three files created by the test app (dumpuninstall.d):
Installed.txt - which is corrupt
Installed2.txt - which is not corrupt
Installed3.txt - which is corrupt, but which is basically on the receiving end
of a trivial return from where Installed2.txt is created within the module.

You can comment and uncomment some trivial code and change what the corruption
looks like (within the modified registry2.d file).

The same registry values always appear to be corrupted. I haven't seen a
definite reason for why that is. Perhaps it has something to do with the number
of characters ran through the interface or possibly some DWORD reads (though
that isn't consistent in all cases).

I've gotten what I need with the uncorrupted Installed2.txt. I am posting this
here so that perhaps, the use of the interface as it is intended might be
enabled by someone with more D experience. 

I've only been working with D for a few days, but I'm really liking it.
Thanks for the effort,
Jay

Jay Jacobson <jjjacobson gmail.com> writes:

I was tinkering with this some more this morning and located and fixed
two bugs in std.windows.registry.

The first was on line 691 and had to do with setting the cbData value to be the
size of a DWORD 8. This lead to the odd problem pointed at in the previous
post. This caused all string registry values with a size less than 8 to become
corrupted because the fall-through test of "too small a buffer" was skipped. In
the case of a string, you can't know what the size is in advance without first
calling the function to obtain the correct size to allocate. The subsequent
call then works (the fall-through test).

Unfortunately, the one liner fix caused the DWORD registry entries to not be
read correctly which lead to the addition of the case statement to
appropriately set the "data" variable ptr (might be a better way to do this).

Additionally, I found that the EXPAND_SZ method was not stripping a trailing
NULL from the ExpandEnvironmentStringsA call. 

With the attached changes, the std.windows.registry module passes the "works
for me" test... without needing any of the "strip nulls" logic as in the wiki
example... YMMV

By the way, Scite made seeing these errors really easy in the output file.

Thanks,
Jay

Jay Jacobson Wrote:

 I've been working with the example from this location:
 http://www.dsource.org/projects/tutorials/wiki/RegistryEnumerationExample
 
 It is obvious from that example that there is some kind of issue with the
module. However, I've put a simple test app together based on that code which
appears to show some form of what looks like stack corruption going on around
that module. I was able to generate an uncorrupted file by going within the
module (std.windows.registry) for the output.
 
 There are three files created by the test app (dumpuninstall.d):
 Installed.txt - which is corrupt
 Installed2.txt - which is not corrupt
 Installed3.txt - which is corrupt, but which is basically on the receiving end
of a trivial return from where Installed2.txt is created within the module.
 
 You can comment and uncomment some trivial code and change what the corruption
looks like (within the modified registry2.d file).
 
 The same registry values always appear to be corrupted. I haven't seen a
definite reason for why that is. Perhaps it has something to do with the number
of characters ran through the interface or possibly some DWORD reads (though
that isn't consistent in all cases).
 
 I've gotten what I need with the uncorrupted Installed2.txt. I am posting this
here so that perhaps, the use of the interface as it is intended might be
enabled by someone with more D experience. 
 
 I've only been working with D for a few days, but I'm really liking it.
 Thanks for the effort,
 Jay