I realized I have a design problem.

I have existing console mode applications, e.g. hexdump.

I don't really want to change them, but I can rebuild them
all if required, with some minor technical change in the
executable, so long as they still function as console mode
programs that work with msvcrt.dll on win95, win 10, win 11 etc.

The problem is that in the win32s environment (which exists
on Windows 3.11 and potentially modern OS/2), the msvcrt.dll
that I provide (aka PDPCLIB), can be freely changed for the
Win32s environment, but currently the DLL entry point is
DllMainCRTStartup (and that is still the case in win32s), but
I somehow need some parameters from Windows:

int WINAPI WinMain(IN HINSTANCE inst,
IN HINSTANCE previnst,
IN LPSTR cmd,
IN int cmdshow)

I am only using "inst" and "cmdshow" in my (sample) code.

So if DllMainCRTStartup is called (it looks like that is an
arbitrary name I can change), but what is not arbitrary is
that Windows will call it with:

BOOL __stdcall _DllMainCRTStartup(HINSTANCE hinstDll,
DWORD fdwReason,
LPVOID lpvReserved)

So how am I supposed to get access to "inst" and "cmdshow"
so that I can start doing graphics for something that
otherwise looks like a console mode application (hexdump.exe
certainly is, but I do have flexibility over whether msvcrt.dll is
considered something different)?

Thanks. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Jul 2023 19:35:42 -0700 (PDT), Paul Edwards wrote:

I realized I have a design problem.

I have existing console mode applications, e.g. hexdump.

I don't really want to change them, but I can rebuild them
all if required, with some minor technical change in the
executable, so long as they still function as console mode
programs that work with msvcrt.dll on win95, win 10, win 11 etc.

The problem is that in the win32s environment (which exists
on Windows 3.11 and potentially modern OS/2), the msvcrt.dll
that I provide (aka PDPCLIB), can be freely changed for the
Win32s environment, but currently the DLL entry point is
DllMainCRTStartup (and that is still the case in win32s), but
I somehow need some parameters from Windows:

int WINAPI WinMain(IN HINSTANCE inst,
IN HINSTANCE previnst,
IN LPSTR cmd,
IN int cmdshow)

I am only using "inst" and "cmdshow" in my (sample) code.

So if DllMainCRTStartup is called (it looks like that is an
arbitrary name I can change), but what is not arbitrary is
that Windows will call it with:

BOOL __stdcall _DllMainCRTStartup(HINSTANCE hinstDll,
DWORD fdwReason,
LPVOID lpvReserved)

So how am I supposed to get access to "inst" and "cmdshow"
so that I can start doing graphics for something that
otherwise looks like a console mode application (hexdump.exe
certainly is, but I do have flexibility over whether msvcrt.dll is
considered something different)?

Thanks. Paul.

You'd have to "walk" back the stack to get to WinMain's arguments.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 22, 2023 at 11:17:54 AM UTC+8, JJ wrote:

BOOL __stdcall _DllMainCRTStartup(HINSTANCE hinstDll,
DWORD fdwReason,
LPVOID lpvReserved)

So how am I supposed to get access to "inst" and "cmdshow"
so that I can start doing graphics for something that
otherwise looks like a console mode application (hexdump.exe
certainly is, but I do have flexibility over whether msvcrt.dll is considered something different)?

You'd have to "walk" back the stack to get to WinMain's arguments.

Ok, thanks, I'll see what I can do.

I have committed the raw proposed code:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/makefile.wcs

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/win32s.c

but now need to glue it together as you indicated above.

BFN. Paul.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)