Weird Code Problem

[Zen]

So,...I've been coding what is essentially an update to Japheth's COMView,...everything is going well,...it's a bit tedious,...
Anyway,...I made a typographical error in my code,...and, I'm not sure what is really happening,...
I found and corrected the errors (and the program works fine),...but, I don't understand why the code was executing the way it was,...
Here's the background: I'm enumerating all the CLSID SubKeys in the Registry (HKEY_CLASSES_ROOT),...and,...I'm then adding a number of strings to a ListView control. It's a HUGE, long, looping code segment,...but, I got it working OK,...
The main thing is getting the path to the InprocServer32, in readable format,...that I do simply by checking for a REG_EXPAND_SZ type when calling RegQueryInfoKey and then RegEnumValue. This is all straightforward (and, pretty boring, really).
Typically,...I use a number of .IF/.ENDIF blocks to check values and then jump to the appropriate code block (ExpandEnvironmentStrings and GetLongPathName, as necessary).

...And,...finally,...here's the problem:   

Code Select Expand

ChckExpnd:    ;   
     .IF TypeDatValue==REG_EXPAND_SZ    ;    (defined in windows.inc) 
     JMP ExpndEnvrnStr
     .ELSEIF TypeDatValue==REG_SZ
     JMP ChckShrtPth
     .ENDIF

ChckShrtPth:    ;   
      invoke CheckTilde, ADDR ValueData
      .IF eax==9    ;    Code returned if tilde is found.   
      JMP GetLongPath
      .ELSEIF eax==0    ;    Returns zero if string completely scanned and no tilde is found.   
      JMP AddItemLstVw
      .ENDIF


The above is the code with the errors corrected,...this works as expected,...but,...originally, the code looked like this:

Code Select Expand

ChckExpnd:    ;   
     .IF TypeDatValue--REG_EXPAND_SZ    ;    (defined in windows.inc) 
     JMP ExpndEnvrnStr
     .ELSEIF TypeDatValue--REG_SZ
     JMP ChckShrtPth
     .ENDIF

ChckShrtPth:    ;   
      invoke CheckTilde, ADDR ValueData    ;    This routine scans the string for a tilde.   
      .IF eax==9    ;    Code returned if tilde is found.   
      JMP GetLongPath
      .ELSEIF eax==0    ;    Returns zero if string completely scanned and no tilde is found.   
      JMP AddItemLstVw
      .ENDIF

You will notice that in the above code block (there are several typos), the == operator is replaced with a -- operator, in several locations...
.IF TypeDatValue--REG_EXPAND_SZ
,...and,...
.ELSEIF TypeDatValue--REG_SZ

Incredibly,...this code compiled,...and,...partially worked,...
The first JMP instruction: JMP ExpndEnvrnStr actually worked, and jumped to a code block that expanded the path string containing Environmental variables,...
But,...the second JMP instruction: JMP ChckShrtPth never executed,...
I couldn't figure it out,...but, noticed the typos,...and corrected them,...and the entire routine now works correctly,...

SO,...how did those two typos effect my code, exactly,...???
Is this some inexplicable quantum mechanics effect,...or,...is there some bizarre voodoo hidden somewhere in HUTCH's MASM QuickEditor ???

[rrr314159]

SO,...how did those two typos effect my code, exactly,...???

- With a little experimentation, it appears that "TypeDatValue--REG_EXPAND_SZ" always returns TRUE (nonzero). This seems a bug in the "HLL" stuff, (.IF etc), else an "undocumented feature". Or else, for all I know, maybe it's a documented feature! That's why I still avoid these constructs, stuff like that keeps happening. Does anyone know where they are thoroughly documented?

- Anyway, that explains why always takes the first branch. BTW I could be wrong require rather more experimentation to be sure

Is this some inexplicable quantum mechanics effect,...

- very likely

or,...is there some bizarre voodoo hidden somewhere in HUTCH's MASM QuickEditor ???

- Well of course there is, I thought everyone knew that

[hutch--]

While I confess that the guts of QE are not suitable for human consumption, the only remapping that occurs is in replacing tabs with spaces as no-one was ever consistent in the way they alternated between tabs and the space bar. Apart from that it is a pure[tm] ASCII editor with no technicolor, auto complete, UN_intellisense or hand holding. Now while the guts of the editor is not fit for human consumption, the guts of the two scripting languages are true nightmares, the programmable menus are like picking fly specs out of pepper.

It always made me laugh to see how long it took other editors to come up with either selection of global replace, QE had it in 1997. Sequential replace was for Word Processors, not programming editors.

[rrr314159]

Don't be modest about the voodoo, everybody knows what "wickedly crafted" refers to. Always wanted to ask, how does it feel to bite the head off a live chicken, while simultaneously selecting "Console Assemble & Link"?

[hutch--]

Depends on if the feathers get caught in your teeth.

[habran]

There is no "woodoo" in this it is just taken as .if ((TypeDatValue)  -  (-REG_EXPAND_SZ)) ;)

[rrr314159]

There is no "woodoo" in this it is just taken as .if ((TypeDatValue)  -  (-REG_EXPAND_SZ)) ;)

- Of course. I should have thought of that. :icon_rolleyes: Thanks habran!

Depends on if the feathers get caught in your teeth.

- Of course. I should have thought of that. :icon_rolleyes: Thanks hutch!

[Zen]

Hey,...you guys are wickedly FUNNY,...Thanks,...I think I got the idea (thanks, HABRAN, that actually makes perfect sense),...
...This experience has given me a fabulous idea, though,...I'll start working on a 'voodoo' Quick Editor Plug-In,...forthwith,...could be my best idea ever,...

[hutch--]

 

I would be careful about going the voodoo path, voodoo is inherently dumb where "wickedly crafted" is diabolical, something like Merlin the magician on steroids.  :P

[Zen]

:icon_eek:...Ah,...yeah,...good point,...
OK,...maybe it'll be DEEP Voodoo,...(with Machiavellian AI),...