Why prevInstance exists in WinMain and wWinMain if it is always NULL

Since I'm new, this can be a very simple question. I run DirectX 11, and when creating my first application, wWinMain was used, and looking for the difference between WinMain and wWinMain, I came across this prevInstance parameter.

prevInstance is always null according to MSDN, and since it is always null why it exists (since it is logical to think that the creators did not provide a useless parameter). And (quoting from the book),

if you need a way to determine if the previous instance of the application was already running, the documentation recommends creating a unique mutex using CreateMutex. Although there will be a mutex, the CreateMutex function will return ERROR_ALREADY_EXISTS.

What is a mutex and how to use it (a good enough link). And it seems like a method is needed to find if another instance of the application exists, prevInstance should have a pointer or a reference to it, which, apparently, is not the case, since it is null. Why is this and what is the role of prevInstance?

+7
source share
2 answers

Raymond Chen’s blog is almost entirely devoted to discussing the Windows API aspects that are β€œweird” today. And, fortunately, he has a blog post that answers this exact question:

In 16-bit Windows, the GetInstanceData function has appeared. This function took the HINSTANCE, pointer, length, and copied memory from this instance to your current instance. (This is a kind of 16-bit equivalent to ReadProcessMemory, with the restriction that the second and third parameters must be the same.)

...

This was the reason for the hPrevInstance parameter for WinMain. If hPrevInstance was not NULL, then this was an instance of the handle to the copy of the program that is already running. You can use GetInstanceData to copy data from it, get out of the ground faster. For example, you can copy the handle of the main window from the previous copy so that you can communicate with it.

Whether hPrevInstance was NULL or did not tell you if you were the first copy of the program. On 16-bit Windows, only the first instance of the program registered its classes; the second and subsequent instances continued to use the classes registered in the first case. (Indeed, if they try, registration will fail because the class already exists.) Therefore, all 16-bit Windows programs skipped the class registration procedure if hPrevInstance was non-NULL.

The people who developed Win32 turned out to be a bit fixed when it came time for the WinMain port: what to pass for hPrevInstance? the entire module / instance did not exist at all in Win32, and separate address spaces mean that programs that skip reinitialization in the second case will no longer work. So, Win32 always skips NULL, forcing all programs to believe that they are the first.

Of course, now that hPrevInstance today is not related to the Windows API, with the exception of compatibility reasons, MSDN recommends using mutexes to detect previous instances of the application.

Mutex means "mutual exclusion." You can refer to the MSDN documentation for CreateMutex() . There are many examples of using mutexes to discover previous instances of applications such as this one . The main idea is to create a mutex with a unique name that you came up with, and then try to create this named mutex. If CreateMutex() failed with ERROR_ALREADY_EXISTS , you know that an instance of your application is already running.

+15
source

The prev parameter is present for 16-bit Windows compatibility. I think this was indicated in the MSDN link for WinMain, at least it was before.

+1
source

All Articles