I dream that someday I can cut and paste from the command prompt. I mean, I'm really happy that Microsoft is actually making improvements to parts of windows that have been needlessly awkward for decades.
So the question you're asking is a bit moot, in a way, considering that the answer is yes, because that's exactly the way it is. It cannot be any other way, as far as I can see.
Maybe the rest of the dialog controls are all fixed dimensions and non-autosizable.
Still, that seems like the kind of thing you could unleash a platoon of interns on and modernize, though.
That's exactly the problem. Raw Win32 doesn't really have provisions for layouting containers and auto-resize behaviour. So you'd essentially have to handle WM_SIZE and reposition/resize all controls in the dialog. Such code is cumbersome to write, awkward to change and annoying to debug/test (e.g. you still need to check that you don't change something to negative sizes and/or constrain the window dimensions appropriately). And in the end you have a few hundred lines of code that are intricately linked to the current dialog layout and, in part, even replicate the layout. So you cannot even easily change the layout anymore. This is quite a bit of a cost associated with that.
Inventing layout containers on the Win32 side seems a pointless idea as well, considering that nearly no one except Microsoft actually uses the API at that level, so improvements here have little benefit for lots of work. Most people most likely use wrappers around it that offer such things (e.g. Windows Forms), or things that take care of their own rendering and offer layout containers (WPF, Swing, GTK, Qt, ...).
So I guess if MS offered the usual layout mechanisms in Win32 people would just shrug and ask »Why? I already have those things in the toolkit I use. Can't they devote development resources to actually important things?«.
[1] "One of the top requested changes we’ve received over the years is to have quick-edit mode enabled by default. Tada!"
[2] http://blogs.msdn.com/b/oldnewthing/archive/2007/09/13/48861...
Like an hour instead of few minutes.
I remember also, that coworkers had the same issue. One of them left work once, leaving a long process running. He came back the next day and it hadn't finish yet. He was ready to file a bug report somewhere, when we found out...
If you click on the command prompt with the QuickEdit mode turned on, in a "wrong way", the underlying process will be frozen. It's because the input and output streams are blocked indefinitely, until you finish your selection and the content gets copied to the clipboard.
So, why would you want to click on it? There is a common pattern people use for long running scripts: they push the window somewhere in the background, but leave a little space you can click on, so that you can view it very quickly.
The "wrong way" of clicking is when you do click-drag instead of a point click. It goes automatically into the QuickEdit mode freezing everything underneath it.
Also, seriously, is there a way to get the console to reliably remember the size and layout settings between launches? At least half the time I launch something with a console window, it's smashed into a 80x25 window, with the ridiculously low 300 line scroll history.
For the command window size and scrollback buffer, I've always had good luck - in Windows 10 and older versions - by setting the options in the Layout tab of the command prompt property pages. I also use the Font tab to select Consolas.
It is true that some programs that open their own command window don't follow these settings, but I usually open cmd.exe and go from there.
For window size that's been easy to fix since forever. Just click the upper left corner icon and select either properties or defaults. Properties changes the settings for the shortcut if it was launched from one, defaults changes the settings for all cmd windows. In addition to window size and selection mode you can change the font and colors and whatnot.