#### Archived

This topic is now archived and is closed to further replies.

# HWND of console

This topic is 6045 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Is there any way to get the HWND of a win32 console window?

##### Share on other sites
The console window was never really meant to be "known about" by the program running in it. It''s basically an emulator of the old DOS system. I suppose that it''s theoretically possible to query the system and find the process to pull out the HWND, but I really can''t see why you''d ever want to do that.

What exactly are you trying to accomplish?

-fel

##### Share on other sites
Actually, you should create a normal Win32 Application project (if you''re using MSVC) and set up your own console window. i remember seeing it in the MSDN sample application for __beginthread and __endthread. It''s way more powerful and flexible. I''m too far away from my own computer to provide more info and too lazy to check MSDN online.

GetStdHandle()

##### Share on other sites
Im trying to use DirectX with a console window. I found a function for getting the HWND but it only works with Windows 2000. Is there a way to do it that would work on most versions of windows?

##### Share on other sites
You should probably be using a Win32 application rather than a console then, you''re going to be needing a lot more control than a console is capable of giving you.

The console is more or less meant for text-based programs that don''t require any windows support.

-fel

##### Share on other sites
Use SetConsoleTitle() to make the title (temporarily) something wierd, then use FindWindow() to get the HWND, then set it back.

##### Share on other sites
It doesn''t really matter if your application is a console application or a windows application. If it''s a conolse application, you can still call all the regular windows functions (CreateWindow, et al) and a windows application can still use a console (but it just has to call AllocConsole() first).

The onle difference between the two is the entry point. A console application''s entry point is main() and a windows'' one is WinMain().

War Worlds - A 3D Real-Time Strategy game in development.

##### Share on other sites
Incidentally, the console is a kernel object and is not owned by your application, so there may be a restriction on what you can do with the window, or else you could mess up the kernel.

##### Share on other sites
quote:
Original post by GayleSaver
Incidentally, the console is a kernel object and is not owned by your application, so there may be a restriction on what you can do with the window, or else you could mess up the kernel.

If you try to mess with the console it might work on 9x but it''ll most likely crash in windows NT/2000. Stick to Win32 Applications, unless you''re using glut(which, since you said you''re using dx, is very unlikely).

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
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

##### Share on other sites
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

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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 ?

##### Share on other sites
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.

##### Share on other sites

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.

##### Share on other sites
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 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.

##### Share on other sites
Are we talking causative factors here? No doubt, the console subsystem was built to emulate DOS and in general be as close to character-mode (DOS or otherwise) as possible. Microsoft would not build a Unix or Linux emulator, they would (did) build a DOS emulator.

As for console applications - no, they''re not DOS emulators, of course. They run in Win32 and simply use the console for output. However, to the user, they behave like character-mode programs.

And that''s what most of us really care about, isn''t it? The console applications are full fledged win32 applications, but we''re not talking about them; we''re talking about the subsystem and its cause. Its cause was to
a) ALlow old DOS programs to be run, and, consequently,
b) Allow programmers to make character-mode programs under Win32.

I suspect the only reason Microsoft decided to allow the public to access the console subsystem in Win32 was because they really didn''t want to throw out all that old code that called printf and scanf and the rest of the console functions to do its work.

To back me up here, Win 3.1 didn''t expose its console system...I don''t believe.

##### Share on other sites
Since you haven't argued against my "experiment," I assume that you believe it.

quote:

...the console subsystem was built to emulate DOS and in general be as close to character-mode (DOS or otherwise) as possible.

You acknowledge the "otherwise" bit, then. You should also acknowledge that OS/2's console is equally similar to DOS as Windows'. And since the Win32 implementations of Windows came after OS/2 (in fact NT was originally going to be another version of OS/2), why don't you (not the generic "you") call it an OS/2 emulator? I believe that since character mode is not inherent to DOS, just call it character-mode or the console or whatever else, rather than saying it's a x emulator, where x is whatever it happens to look like; this is particularly pertinent when many things happen to look like x.

I don't think you could call Windows' (or OS/2's) console an emulation of DOS any more than you can call Quake x's console an emulation of DOS.

Certainly what "most of us really care about" is that they're character-mode programs. But I feel it's harmful to associate them with DOS in any way because it allows most people to equate "console" with "DOS" in their heads, and clearly there is no unique correlation along those lines.

So, I think it's best just to call it the console. Forget DOS or OS/2 or whatever else it happens to look like. It's a console.

It's like how we shouldn't call sugary carbonated beverages originally derived from an African nut by the name "Coke." They are "colas," since some colas are Pepsi and some actually are Coke and some are RC, and some are that horrible crap you get at Sam's or Wal-Mart.

So, it's a console.

Edited by - merlin9x9 on August 3, 2001 12:53:44 PM

##### Share on other sites
By the way, if I''m not mistaken, Windows 3.x and earlier didn''t have a console subsystem at all. Back in those days, since DOS was always there, I imagine that they decided that there was no point to re-implementing what was already there. So, if you wanted character-mode, you either did it in your GUI yourself, or make an actual DOS app.

##### Share on other sites
So we''re arguing about names, not origins?

And yes, Win 3.1 did have a console subsystem and a VM. In fact, Win16''s console was a redirection of the DOS console. As far as I remember.
I could be entirely wrong!

##### Share on other sites
quote:

So we're arguing about names, not origins?

Does it matter?
It's sort of both, isn't it?

Either way, I say that we should all just call it the console. If you want to talk about origins and argue that the Windows console exists to cater to something from DOS, then you could also argue the same thing about DOS with respect to CP/M or OS/2. All three have similar consoles and very similar commands. OS/2 evolved from DOS, and Win32 evolved from OS/2. So, since this is Win32 we're talking about, how come we're not saying that the Windows console is an emulation of OS/2? Why? Because, I think we're used to understanding that OS/2 is its own operating system. But we're still programmed to think that Windows and DOS are inseperable, so as soon as we see something that's DOS-like, we call it DOS or say it's like DOS. Again, console were never unique to DOS, or OS/2, or Unix, or Quake. A console is just a console, just in the same way that a GUI is a GUI (and not an emulation of a Macintosh, or GEM, or OS/2 Presentation Manager, or that original Xerox prototype).

It's just a console.

quote:

And yes, Win 3.1 did have a console subsystem and a VM. In fact, Win16's console was a redirection of the DOS console. As far as I remember.
I could be entirely wrong!

And you might be right, too. Well, if Windows API functions such as AllocConsole and GetConsoleScreenBufferInfo existed in Win16, then there must have been a console subsystem to some extent. However, I don't know how long those functions have been around—my guess is that they were introduced with Win32.

Edited by - merlin9x9 on August 3, 2001 4:55:04 PM