• Please review our updated Terms and Rules here

Why wasn't there a win16 console application?

Microsoft called the facility "QuickWin", while Borland had their own called "EasyWin" (which I used a ton in school). They both did the same thing, created a GUI window and outputted text from your console applications. Luckily Microsoft realized how stupid this was and allowed for native Win32 console applications despite Windows NT being a fully graphical OS.
 
Windows 2 supported TopView applications which could have met that console need. Few designed for TopView. A handful of developers took advantage of the hooks provided in Windows to communicate within a DOS session. All the rest designed for DOS and left it to MS to make a DOS session that handled things.

Look at the multi-tasking DOS 4 or TopView design documentation. There is a lot of work to be part of a cooperative multitasking system but the program doesn't gain much from the user perspective. It took newer OSes to offer enough benefit to make up for all the work creating a new application.
 
Having been required to straddle the boundary between real-mode DOS and Windows 16, there are probably some good reasons otherwise. Memory management back then was a mess. There were "DOS extenders", then DPMI servicers. Recalling that 16-bit Windows could run in several modes only complicated things. It really wasn't until the 386 and V86 mode that a console-mode Windows application became practical. Trying to do it on an 80286 was fraught with hazards.

OS/2 had a more interesting approach--a "bound" executable that included both PM and real-mode (DOS) versions of the executable. Depending on which mode the system was running in, the appropriate binary was loaded.
 
Nothing prevented a Windows developer from binding a DOS version of their application instead of the standard WINSTUB. Indeed, MS even put out an MSKB note on the subject. https://jeffpar.github.io/kbarchive/kb/011/Q11591/ I expect that the reviews would have been hostile to the larger file size that would entail. The reviews of the various bound OS/2 applications were negative.
 
Indeed, we did just that. Real-mode device processing was handled through a TSR interfaced via the multiplex interrupt. There was also a Win16 DLL to do the same thing and a VxD interface to do likewise for 32 bits. (remember thunking?)

Back in the early days of Win30, one invoked a VxD by a registered (by Microsoft) number. Ours was 0x3218, obtained via CompuServe's Microsoft account.

All of which I'd like to forget.
 
And, since Windows 2.x you could also use the Winoldap interface to control the menu of an MS-DOS program running in a window (using a PIF file) by wrapping it in a Windows shell program.
Your programs (Windows and7or MS-DOS) could also use the clipboard to exchange data between MS-DOS and Windows applications.

I am still astonished how few programmers used these options to improve their MS-DOS programs and cooperation with Windows. I believe Microsoft Word for MS-DOS used the clipboard.

Martin
 
alank2 said:
Was it because DOS applications already existed?
Click to expand...
According to the "New Old Thing" (post), 16-bit Windows simply did not have a console subsystem - that was introduced in Windows 95.

In Real (8086) or Standard (286) mode, text-mode applications are run in DOS. Windows removes itself mostly from memory and the application takes over. For such applications, there is no Windows to communicate with. Therefore, console applications are simply not possible.

In Extended (386) mode, Windows acts as a proper hypervisor and creates a DOS virtual machine for text-mode applications. These are mostly isolated from the system. So text-mode applications can't really do much more than DOS applications can, and Windows applications cannot communicate with them, either.

The only exception I know of is IPCONFIG.EXE shipped with Microsoft TCP/IP-32b. But this is less of a console application and more of a DOS program knowing how to punch through a special hole in the hypervisor. This is possible because the TCP/IP stack only works in Extended mode anyway.
 
The situation was a bit strange under Win 3.1. You could launch 32-bit DOS (DPMI) programs from a DOS window. You could run Win32 GUI programs using win32s. But if you tried to run a Win32 console program from the DOS window you'd just get the stub message. I remember having an Unrar program which was a Win32 console app, and I could run it under Win 3.1 but only by typing the command line into the Program Manager's 'run' box to launch it blindly. No output would be shown, but if I typed out the command correctly I would nevertheless get some files extracted from a RAR.
 
You must log in or register to reply here.
Back
Top