Name forwarded parameters in Storm, zlib, window and server connection helpers
Ghidra v1799 · 2663303
Each parameter reaches a named callee parameter unchanged, and I checked the pushes and registers against the callee's signature in the machine code. Names follow the callee, with three exceptions: nMsg on WndProcC because the checks have no u prefix for the callee's uMsg, nLen2 on ZLIB_Adler32Combine32 because a single 32-bit length is sign-extended into the callee's Lo and Hi, and bSeekOptimization on SFILE_InitializeFileSystem because its callee's own plate shows the value is a boolean gate (gbSFileSeekOptimization), so the stale chosen name dwThrottleDelay on that callee is not copied.
Changes 20, applied together
Rename variable
win 0x00406870 EDXnamedwParam→bSeekOptimizationRename variable
win 0x0047fbf0 ECXnamenParam→nSizeRename variable
win 0x00420cf0 Stack[0x8]namenParam1→nMsgRename variable
win 0x00420cf0 Stack[0xc]namenParam2→nWParamRename variable
win 0x00425700 Stack[0x8]namenParam2→nBitLengthRename variable
win 0x00424f50 Stack[0xc]namenParam→nExponentRename variable
win 0x0052cc10 ECXnamenParam→nClientIdRename variable
win 0x0052c8e0 ECXnamenParam→nClientIdRename variable
win 0x0051e440 Stack[0x8]namedwParam→nNumberOfBytesToWriteRename variable
win 0x0042b990 ECXnamenParam3→nAdler1Rename variable
win 0x0042b990 EDXnamenParam2→nAdler2Rename variable
win 0x0042b990 Stack[0x4]namenParam1→nLen2Rename variable
win 0x0042b9b0 ECXnamenParam3→nAdler1Rename variable
win 0x0042b9b0 EDXnamenParam4→nAdler2Rename variable
win 0x0042b9b0 Stack[0x4]namenParam1→nLen2LoRename variable
win 0x0042b9b0 Stack[0x8]namenParam2→nLen2HiRename variable
win 0x0042dbc0 ECXnamenParam1→dwCrcRename variable
win 0x0042dbc0 EDXnamenParam2→dwFinalXorRename variable
win 0x0042dbe0 ECXnamenParam1→dwCrcRename variable
win 0x0042dbe0 EDXnamenParam2→dwFinalXor