Discussion:
console calling graphics
(too old to reply)
Paul Edwards
2023-07-22 02:35:42 UTC
Permalink
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.
JJ
2023-07-22 03:17:51 UTC
Permalink
Post by Paul Edwards
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
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
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.
Paul Edwards
2023-07-22 03:42:04 UTC
Permalink
Post by JJ
Post by Paul Edwards
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.

Loading...