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.