Parameters Only Sometimes Necessary: The Tale of LOOKUPATOM in Windows 1.0 DR5

[winnt32]

LOOKUPATOM is the internal function used in Windows 1.0 KERNEL.EXE for adding and deleting atoms. These are not atomic operations; the Atom Manager is one of the oldest APIs still extant in Windows and is akin to string caching - it was originally designed so that programs did not continually have to load strings from slow disk. An atom is an individual string

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:

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

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.

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.