That's a different thing, actually. There are two distinctions here:
- Win16/win32 programs in PE object files which could be:
-- Console subsystem, where they'd have a stdin and stdout and all that, take a char* argv, their entry point was main(), etc. and if run directly would open a console window, and if run from a console would block the console with their own execution.
-- Windows subsystem, where they would have the more elaborate entry point (WinMain), could get unicode argv, etc. If run directly they would not spawn a console, and if run from a command line would appear to return immediately.
- DOS EXE files, which could obviously only be 'console' and only had one entry point.
PE executables (of either sort) had a stub DOS exe at their header that would print that message.
As another post pointed out, nothing was actually stopping you from using the gui windows apis from a console app, incidentally. It wasn't done very often though.
- Win16/win32 programs in PE object files which could be: -- Console subsystem, where they'd have a stdin and stdout and all that, take a char* argv, their entry point was main(), etc. and if run directly would open a console window, and if run from a console would block the console with their own execution. -- Windows subsystem, where they would have the more elaborate entry point (WinMain), could get unicode argv, etc. If run directly they would not spawn a console, and if run from a command line would appear to return immediately. - DOS EXE files, which could obviously only be 'console' and only had one entry point.
PE executables (of either sort) had a stub DOS exe at their header that would print that message.
As another post pointed out, nothing was actually stopping you from using the gui windows apis from a console app, incidentally. It wasn't done very often though.