Monday, August 14, 2006

So what is a "thunk"?

What is a thunk?

This question was posed to me recently by a fellow programmer at work. He expected that I would know, since I have been in the industry for a while, but though the term was familiar I had to admit I didn't know what it meant. He went on to explain that a thunk was that bit of code which redirected a function call from the standard address in memory to a "thunk handler" which did whatever business it wanted to do and then returned control of execution back to the original target address.

Looking things up, this seems to be not quite the case. Or at least, this definition of a thunk seems to leave out the main use it has been put to which is to (apparently ) redirect code properly when moving between 32-bit and 16-bit libraries, ala the PC programming world circa Windows 3.1 (early 1990).

So what are the "official" defintions? Wikipedia has a great page, as usual. The official Wikipedia blurb on a thunk is:

  • a mapping of machine data from one system-specific form to another, usually for compatibility reasons. For example, running a 16-bit program on a 32-bit operating system may require a thunk from 16-bit addresses to 32-bit. Thunk in this sense may also refer to mappings from one calling convention to another or from one version of a library to another. This meaning is similar to the first—the "delayed computation" can be thought of as the "update" from the old format to the new.

PCMagazine's Encyclopedia has a different definition:

  • In a PC, to execute the instructions required to switch between segmented addressing of memory and flat addressing. A thunk typically occurs when a 16-bit application is running in a 32-bit address space, and its 16-bit segmented address must be converted into a full 32-bit flat address. On the other hand, if a 32-bit program calls a 16-bit DLL, then the thunk is in the opposite direction: from 32 bit to 16 bit.
WikiDictionary has this to say:

  • (computing) a mapping of machine data from one system-specific form to another, usually for compatibility reasons, such as from 16-bit addresses to 32-bit to allow a 16-bit program to run on a 32-bit operating system

No comments: