If you

look through old code,
you see a lot of
redundant function pointer casts.
(If you're writing new code,
you should get rid of as many function pointer casts as possible,
because

a function pointer cast is a bug waiting to happen.)
Why does old code have so many redundant function pointer casts?

Because back in the old days, they weren't redundant.

In the days of 16-bit Windows,
function prologues were required to take very specific forms
in order to make

stack walking work,
and stack walking was necessary in order to simulate an MMU
on a CPU that didn't have one.

Another rule for prologues has to do with state management.
The full prologue for a far function looks like this:

    mov     ax, ds

    nop

    inc     bp

    push    bp

    mov     bp, sp

    push    ds

    mov     ds, ax

Before we can dig into those instructions, we need to know a bit about
how code segments worked in real-mode 16-bit Windows.
In real-mode 16-bit Windows, there was a single address space for all applications
because the CPU had no concept of per-process address spaces.
The kernel simulated separate address spaces by managing instances.
The instance (represented by an instance handle)
specified the location of the data segment the code should operate on.
If you have two copies of a program running,
the code is shared, but each program has its own data.
The instance handle tells you where that data is.

And the instance handle is kept in the ds register.

Therefore, it is essential that every function have its ds
register set to the instance handle that describes where the code
should find its data.
You can think of it as a "global this pointer for the process."

Okay, so let's look at the function prologue again.
First, it copies ds to ax via a two-byte
mov ax, ds instruction.
Then there is a nop.
This pads the prologue size to three bytes.

The next four instructions build the stack frame:
The inc bp

marks the stack frame as a far frame.
The push bp and mov bp, sp
build the bp chain.
And
the
push ds saves the original ds register,

which also provides breathing room for
return address patching.

And then we move ax back into ds.
The instance handle just took a little tour of the ax
register and then returned back home.
What was the point of that?

Recall that in 16-bit Windows,

every far function called from another segment was listed
in the module's Entry Table.

When a far function is placed in the exported function table,
the loader patches the first three bytes of the function
to three nop instructions.
Non-exported functions remain unchanged.
This means that non-exported functions do the redundant
ds rigamarole.
It's a little extra work, but it's ultimately harmless.

The effect of patching out the initial mov ax, ds
is that the function ends up doing this:

• Build a far stack frame,
  which includes saving the original ds.
  
• Set ds to whatever was passed in the ax register.
  

The second step means that the code, when it executes,
operates on the data associated with the handle passed in the ax
register.

Okay, great, but this means that you can't call an exported function
directly,
because it will set the ds register to whatever
value is passed in the ax register.
Since the ax register is not part of the calling convention,
its value is garbage.

But that's okay.
We made things worse so we can make them better.

The Make­Proc­Instance function
creates a stub function that loads the ax register
with the instance handle you provide,
and then jumps to the function you provide.
Really.
That's all it did.
(When you're done, you call Free­Proc­Instance
to free the memory back to the system.)

This stub function was known as
a procedure instance thunk,
or a proc instance for short.
Hence the name Make­Proc­Instance.

Okay, finally the punch line.
The Make­Proc­Instance function didn't care
what kind of function pointer you passed it.
Whatever you passed in, it returned the same kind of pointer back out,
because all the stub did was twiddle the ax register
and then jump to the real function.
The parameters on the stack didn't change,
the cleanup convention didn't change,
nothing else changed.

The Make­Proc­Instance function was
declared as returning a FARPROC,
which is a typedef for a far function that takes no parameters
and returns nothing.
The parameters and return value are irrelevant;
it just had to be something.

But what this means is that when you take your function,
like a window enumeration callback,
and create a procedure instance for it,
the thing you get back has been type-erased to a generic
function pointer.
To make it useful again, you need to cast it back to what it
was originally.

For example, if what you passed was a WNDENUMPROC,
then you need to cast the procedure instance back to a
WNDENUMPROC.
If you passed a TIMERPROC, then you need to cast
the procedure instance back to a TIMERPROC.
You could anachronistically express this as

template

auto MakeProcInstanceT(R (FAR *func)(Args...), HINSTANCE inst)

{

  return (decltype(func))MakeProcInstance((FARPROC)func, inst);

}

Of course, you didn't have this fancy template deduction
in 1983-era C,
so you had to cast the return value manually.

And that brings us to today.
Even though
Make­Proc­Instance has been obsolete
for decades,
some people imprinted on the
"gotta cast your function pointers to get them to compile"
pattern,
either because they wrote code when the cast was required
and fell into the habit, or
or (more likely) they learned from code that was written
by someone who inherited this habit from somebody else.
And yes, this inherited folk wisdom

can even be found in MSDN.

The redundant function pointer cast is now a type of folklore,
passed down from developer to developer,
even though it's no longer needed
and in fact

will mask problems
caused by mismatched prototypes.