This code was likely written in a mixture of C and assembly during the DR5 era, and of course would be optimised for slow hardware; this may be the reason why it is written in a peculiar way.
To first understand how it is written, we must understand how the Atom APIs in Windows are constructed.
The developer-facing public APIs are ADDATOM, FINDATOM et al. There is a DELATOM function, but for some reason it is not declared as public for developers. FINDATOM takes one parameter and declares one local variable (a byte) - I haven't looked as to what they are, but 1.0x final takes one - a long pointer to the string you are attempting to search for, and returns the atom. DR5 probably works similarly
All of these are essentially trivial functions:
For some unknown reason (likely optimisation or C/assembly mixture), instead of using parameters, LOOKUPATOM takes a "command id" for the action that it will take. 0 = find atom, 1 = add atom, and 2 = delete atom. This is kind of bizarre behaviour, as parameters are used for FINDATOM.
Code: Select all
DELATOM proc far mov bl, 2 jmp short LOOKUPATOM public ADDATOM ADDATOM proc far mov bl, 1 jmp short LOOKUPATOM FINDATOM var_3 = byte ptr -3 arg_0 = dword ptr 6 mov bl, 0
Furthermore, FINDATOM doesn't call LOOKUPATOM. Code execution literally runs into LOOKUPATOM, as LOOKUPATOM is the next code after FINDATOM. All FINDATOM does is force the command ID to 0.
It's pretty odd behaviour, and a demonstration of the extreme efforts that were dedicated towards weird micro-optimisations back in the mid 80s.