OK, Wots, uh, the deal?
As some of you may know, I'm and 'old-skool' ASM coder who's just now learning this Win32 stuff... I was using TASM 5.0 until about a week ago when I finally got MASM32 downloaded. Most of the TASM code I was working on was sound, and it worked fine, but alas, TASM has no support and no future.
After assembling my test prog under MASM, it appears to not work. I have 'prettied-up' the source to a more MASM-like syntax (although I know it's not necessary, is does make it more readable). It took me a fair amount of time to figure out what was wrong. My registry-writes were failing. In fact, a call to RegSetValueEx would crash my debugger.
Finally figured out that my registry-writes were crashing because RegOpenKeyEx was failing. Didn't know exactly why, so I stepped through the old TASM version and the MASM32 version simultaneously in side-by-side debug windows.
Here it is:
HKEY_ALL_ACCESS under TASM assembled to 000F003F(h), yet under MASM it's 001F003F(h). The TASM version works, the MASM version crashes. I've fixed it with the handy-dandy hex editor, but still...
Any ideas on why it's different?? Does 001F003F(h) only fail on NT? I don't have a Win9x box here to check it on. I don't understand... If anyone has any explanation for this, I'd love to hear it because this has been driving me nuts.
Thanks,
Q
Sounds like a problem with the definition in the masm32 includes.
Somebody should look into this. For now, you could change the
definition yourself, if that really *is* the problem.
Check the post previous posts on the registry...
Icz has explained it (and I don't want to steal
his thunder :) )
Basically its NT/2K enforcing rules properly,
but 9x letting things go.
I think the post is called something like
"Registry mis-behaving on Win2k" or some such...
Registry Misbehaviour ( w2k )
Mirno
This message was edited by Mirno, on 2/20/2001 10:12:48 AM
I recall having that problem on NT also. At the time I just reduced
my calls to KEY_WRITE and KEY_READ. But I do think there is a problem
with the KEY_ALL_ACCES equate. It should be F003Fh but equates to 1F003Fh.
I glanced at the windows.inc and the definition seemed to be OK.
But it sure seems like the AND NOT SYNCRONIZE is not happening.
Am I brain dead or is this an equate problem ?
duh, I was pulling in windows.inc 1.18.
Q, double check what version you are including.
I don't know which version it was fixed in, but 1.18 had an
operator precedence issue with KEY_ALL_ACCESS that sounds
very much like what you describe.