I'm responding to both your comments to me in one place. My memory here is fuzzy, especially of 16-bit Windows (which I did use, but I was a child at the time). But, from what I can gather, there is an important difference between 16-bit and 32-bit Windows programs.
In 16-bit land, WinMain is an application entrypoint, and launching an already-open application again causes its WinMain to be invoked with hPrevInstance set to a non-NULL value. Here, the distinction between "process" and "application" was nonexistent/irrelevant.
In 32-bit land, WinMain is a process entrypoint, hPrevInstance is always NULL, and launching an already-open application again causes a new process to be spawned by the O/S. If the application wasn't coded for explicit coordination (using O/S-level mutexes or IPC mechanisms), then two or more running copies of the same application are not aware of each other, do not share any resources, and for a long time were not treated as a single "application" by the operating system.
In 16-bit land, WinMain is an application entrypoint, and launching an already-open application again causes its WinMain to be invoked with hPrevInstance set to a non-NULL value. Here, the distinction between "process" and "application" was nonexistent/irrelevant.
In 32-bit land, WinMain is a process entrypoint, hPrevInstance is always NULL, and launching an already-open application again causes a new process to be spawned by the O/S. If the application wasn't coded for explicit coordination (using O/S-level mutexes or IPC mechanisms), then two or more running copies of the same application are not aware of each other, do not share any resources, and for a long time were not treated as a single "application" by the operating system.