I might be wrong but seems to me like what you want to do is get the window so you can output some text like debuging info, just like you would use printf, or cout, am I right?
if I am, then all you have to do is create a new empty console project, and add your windows code file (IE they use Winmain and the messaje pump, and all that) compile, and when you run your app it will come up with a console of its own that will show all the printf and cout messages you put inside the code.
there is a way to do it with the command line feed to the linker, but I dont know what it is, /windows perhaps?
I think you can set it on a DEF file, like a subsystem variable or something like that.

felisandria, the Win32 console is no more an "emulator of the old DOS system" than Linux's terminal is. Stop denying that Win32 has a console subsystem in addition to its GUI subsystem—it does. And console apps are identical to GUI apps with one difference: their entry point is main rather than WinMain. That's the only disparity.

If you want the console for outputtting text, I'd suggest making your app a Win32 GUI app, then use AllocConsole to create a console belonging to your app. You can use, say, printf, and that text will appear in your created console. When you're done with the console, call FreeConsole. This is the method I used in my current project.

Edited by - merlin9x9 on August 1, 2001 5:53:57 PM

I didn''t say that it WAS the old DOS system. I said it EMULATED the old DOS system.

Obviously it''s not the old DOS system. It just allows you to use basically all of the old DOS commands, as well as interpreting scripts and creating an area in which you can run text-base programs... all of which DOS used to do. Does it have ties to Win32? Yeah, duh, it has to, how else would it display. But, just as we have emulators that act like the old nintendo, amiga, etc systems (though they are not, actually, the old nintento, amiga, etc systems), we have a console that acts like the old DOS system (which Linux does not. You do not use DOS commands in Linux. Well, not if you want to get anything done, anyway). Which, I believe, is the definition of "emulator".

-fel

I never said you said it was DOS. I know better than to accuse you of that because we've been through this battle before.

It doesn't emulate DOS, either. The fact that DOS had a command-line interface is completely irrelevant and no more than a coincidence. As a matter of fact, you could have replaced DOS's interface (command.com by default) with anything, so that DOS could have had a completely different interface.

DOS was an operating system, not an interface. This is why I keep comparing the Linux terminal to Win32's console.

Windows is an operating system, and it happens to support two separate interfaces: the console, and the GUI.

If you're going to argue that commands like DIR and COPY are DOS commands, yes, they were. But, coincidentally, they're also OS/2 commands. Does that mean that OS/2 is DOS or that OS/2's command prompt is DOS? Does that mean that any OS that happens to have commands similar to DOS's must have some ties to DOS? Of course not. The argument is the same with Windows (Win32 implementations). The commands in OS/2 and Windows were modeled after the DOS commands, but are indeed different imlementations (which is why they're not use the same and why they behave somewhat differently). I could continue your argument by pointing out that the command CD on Linux or other Unix system—since it was a command in DOS—must be an emulation of the corresponding DOS command which, of course, is complete rubbish.

If the Windows console is an emulation of DOS, why doesn't it or any other part of Windows spawn a Virtual DOS Machine (a DOS emulator) at any time except for when you try to run a DOS or Win16 app? Why? Because it's not a DOS emulator, and because it has nothing to do with DOS.

The Windows console has nothing to do with DOS.


By the way, thank you for being a good sport and not, say, deleting my posts.

Edited by - merlin9x9 on August 2, 2001 1:37:58 PM

This time I side with felisandria, full circle.

quote:

---

Original post by merlin9x9
felisandria, the Win32 console is no more an "emulator of the old DOS system" than Linux's terminal is. Stop denying that Win32 has a console subsystem in addition to its GUI subsystem—it does. And console apps are identical to GUI apps with one difference: their entry point is main rather than WinMain . That's the only disparity.

---

God, if you're going to get this nitpicky, then you should know that there's no entry point difference, either. That's set by the compiler.

quote:

---

It doesn't emulate DOS, either. The fact that DOS had a command-line interface is completely irrelevant and no more than a coincidence. As a matter of fact, you could have replaced DOS's interface (command.com by default) with anything, so that DOS could have had a completely different interface.

---

That is exactly where you are wrong. The console subsystem was designed - built - as a DOS emulator. Long before there was Win32, there was Win 3.1. And in Win 3.1, there was no "virtual machine" as far as that went. There was simply a redirection of console output to the CONSOLE WINDOW in windowed mode.

"Console" originally refers to the character-mode input system, not to the user interface.

quote:

---

If you're going to argue that commands like DIR and COPY are DOS commands, yes, they were. But, coincidentally, they're also OS/2 commands. Does that mean that OS/2 is DOS or that OS/2's command prompt is DOS? Does that mean that any OS that happens to have commands similar to DOS's must have some ties to DOS? Of course not. The argument is the same with Windows (Win32 implementations). The commands in OS/2 and Windows were modeled after the DOS commands, but are indeed different imlementations (which is why they're not use the same and why they behave somewhat differently). I could continue your argument by pointing out that the command CD on Linux or other Unix system—since it was a command in DOS—must be an emulation of the corresponding DOS command which, of course, is complete rubbish.

---

Why are we talking about commands? As you noted yourself, command.com is a user interface. So is Cmd.exe on Windows NT. The argument isn't about the UI, it's about the input methods. Text-based console programs run in the console window.

Are you trying to argue that the console can be used by Win32 and hence is not a DOS emulator? Felisandria already said the "old DOS system". You interpreted it as "the old DOS user interface". I, however, choose to interpret it as "the old DOS input system." See where I'm leading?

quote:

---

If the Windows console is an emulation of DOS, why doesn't it or any other part of Windows spawn a Virtual DOS Machine (a DOS emulator) at any time except for when you try to run a DOS or Win16 app? Why? Because it's not a DOS emulator, and because it has nothing to do with DOS.

---

You're misinterpreting the word "emulation". Believe it or not, the MSVCRT.dll file "emulates" the old CRT. When porting to Win32 they had to throw out many old interrupt calls for file and console functions and replace them with Windows API calls. Just because the underlying *implementation* is changed doesn't mean the *interface* (and this time I do mean the programming interface) has to change. Your specific definition of a "machine emulator" is overshadowed by the general definition of an emulator, which is (or should be), the duplication of functionality.

quote:

---

By the way, thank you for being a good sport and not, say, deleting my posts.

---

Brilliant way of making a professional argument personal. Not relevant to the argument, if I may say so myself.

Edited by - GayleSaver on August 2, 2001 12:51:52 AM

quote:

---

That is exactly where you are wrong. The console subsystem was designed - built - as a DOS emulator. Long before there was Win32, there was Win 3.1. And in Win 3.1, there was no "virtual machine" as far as that went. There was simply a redirection of console output to the CONSOLE WINDOW in windowed mode.

---

In no way have you proven that the console subsystem was intended to "emulate" DOS—nor have I disproven it, clearly.

Regardless, neither of us can really say for sure whether Microsoft created the Console subsytem in order to reproduce DOS. I don''t think they did. The console was a convenient way to display output during, say, the NT boot process before any of the GUI loads.

quote:

---

"Console" originally refers to the character-mode input system, not to the user interface.

---

If it''s an input system, it is an interface for the user to give input, and it happens to give output. Therefore, it is a user interface just as much as the GUI is.

quote:

---

Why are we talking about commands? As you noted yourself, command.com is a user interface. So is Cmd.exe on Windows NT. The argument isn''t about the UI, it''s about the input methods. Text-based console programs run in the console window.

---

Admittedly, I''d misinterpreted fel''s argument as saying that because commands that happen to be almost identical to DOS ones exist in Windows, it must be a DOS emulator or otherwise have ties to DOS. However, fel''s argument did call them DOS commands, and I think that''s not quite correct, since you could call that same command set OS/2 commands, and you could call a small subset Unix commands.

You could argue that they were commands, but because they''re now in Windows, they are now Windows commands; this is reinforced by the realization that they don''t behave identically to their DOS counterparts.

quote:

---

You''re misinterpreting the word "emulation". Believe it or not, the MSVCRT.dll file "emulates" the old CRT.

---

And I think that you''re using the word "emulation" a bit too generally. It''s very flexible, to the point that you could eventually say that everything emulates something else.

If I''m not mistaken MSVCRT stands for Microsoft Visual C[++] Runtime Library. For ANSI compliance, it must support—among other things—the console input and output functions. And it does, just like every other platform, and they all treat them in their own special way, but generally doing the same thing.

quote:

---

Are you trying to argue that the console can be used by Win32 and hence is not a DOS emulator? Felisandria already said the "old DOS system". You interpreted it as "the old DOS user interface". I, however, choose to interpret it as "the old DOS input system." See where I''m leading

---

(Just to make sure that we''re not just clashing over definitions, I consider the "console" to refer to the place where you input commands and receive their output. "Console mode" is when the current user interface is through a console; this is equivalent to "command-line interface.")

Interpreting it as "the old DOS input system" is flawed. Command-line interfaces were never unique to DOS, so you could call it "the old Unix input system" for example, and be equally correct, since Unix has a console. But I think that since a lot of us grew up with DOS and its transition to Windows standing on top of it, we''re used to associating command-line interfaces with DOS. The main problem with this association is that we see kids around here all the time calling "Win32 console apps" "DOS apps."

Command-line interfaces (console) aren''t DOS; they''re interfaces. And they appear in many other systems. So, if they appear in other systems, how could you say that the Windows console is an emulation of the DOS interface? Well, I suppose you can, but if you do, you should also acknowledge that you can call it an emulation of the old (and current) Unix interface. And you can call it (etc.) of the old (and current) OS/2 interface. You can say these things because they all have consoles. Since you can say all of those things, saying Windows'' console is (etc.) of the DOS interface (as opposed to Unix or OS/2) is an arbitrary choice. Right? <shrugs>

So why not just call it a console that is exactly that? Yes, the sentences, "it emulates the DOS interface," and "it looks like the DOS interface" are essentially equivalent in most people''s dialects. But I think that the former ties one thing to the other as though they were identical.

Anyway, I suppose it''s not worth arguing any further because I''ll go on just calling it the console and considering it to have nothing intrinsically to do with anything else, and you and most everyone else will go around calling it DOS or being a DOS interface emulation. And I guess that''s fine in the grand scheme of things...

...but I think it''s almost as bad as comparing OpenGL and DirectX (you know...OpenGL == one 3D API versus DirectX == set of APIs), which we also see around here a lot...

But, to each his/her own.

Let me define a few words first so that we are on the same level ,

console application
1. A program that runs from the operating system''s command line, in character-mode, rather than from a graphical user interface. 2. a character-mode application that uses a console window for its input and output. If necessary, the operating system creates a new console window that exists until the application terminates.
console window
A window that allows user input and displays output for a console application.

[fact]
Dos and console applications , run in a v86 mode a virtual machine which provides registers, instructions, and 1-megabyte address space that real-mode applications are designed to use,address space, I/O port space, interrupt-vector table ROM BIOS, MS-DOS, device drivers, and TSRs to the address space of the virtual machine so that the application has access to MS-DOS system functions and ROM BIOS routines.

V86 supports the complete set of MS-DOS system functions and interrupts and provides extensions that permit MS-DOS – based applications to take advantage of features such as long filenames, and exclusive volume locking.
[/fact]

Doesnt that sound like a dos emulator ?

Console apps have all the access to win32 stuff as a GUI app, and has 32 bit addressing, which DOS did not have (unless using an extender such as DOS4GW). So while a console app emulates the functionality of DOS, it does not emulate DOS itself.

quote:

---

So while a console app emulates the functionality of DOS, it does not emulate DOS itself.

---

Let me use smaller words .

Console applications do not emulate dos , but they run in a Dos virtual machine , however , the console subsytem(which is a part of windows) emulates dos.

quote:

---

Emulator.
Main Entry: em·u·la·tor
Pronunciation: ''em-y&-"lA-t&r
Function: noun
Date: 1589
1 : one that emulates
2 : hardware or software that permits programs written for one computer to be run on another usually newer computer.

---

Thats arccoding to webster.

quote:

---

Console applications do not emulate dos , but they run in a Dos virtual machine

---

This is absolutely not true.

If you all are convinced that you''re right, then a little experiment shouldn''t hurt.

Here''s what you''ll need:
1. NT-based incarnation of Windows (this is to be considered "true" Windows)
2. A Win32 console application that does more than just exit immediately. If you''ve got a Win32 compiler handy, just make something like this:

#include <iostream>void main() {int x; cin >> x;}

3. A genuine 16-bit DOS application.
4. (Optional) A Win16 [GUI] application.

Here''s the procedure:
1. Open the Task Manager, and switch to the Processes tab
2. Make sure a VDM instance isn''t already running (it''ll be listed as ntvdm.exe in Task Manager)
3. Run the Win32 console app, waiting for Task Manager to refresh (by the default setting it should take no more than a second); you''ll note that the VDM process (ntvdm.exe) does not appear in Task Manager for the duration of the app''s execution
4. Close the Win32 console app.
(Optional steps)
5. Follow step 3 with the Win16 app; you''ll note that this time a VDM instance does appear.
6. Close the Win16 app.
7. Follow step 3 again with the 16-bit DOS app; you''ll note that, as in step 5, a VDM is spawned

Conclusions:
- Windows NT has no ties to DOS. Win32 has no inherent ties to DOS (as does Win16). Therefore, a VDM must be spawned when DOS support is required.
- A Win32 console app has no dependency on DOS whatsoever. If it did, NT would have to spawn a VDM process in which to run it. The testing shows that this simply doesn''t happen.
- Since the original Windows (and the Win16) API was intended to work on top of DOS, a Win16 app requires DOS to run, explaining why a VDM is spawned when one is run.
- As expected, a DOS app will require a VDM.