CMD window does not return to it's original size after MODE command

You can use cmdow (http://www.commandline.co.uk) to resize the cmd window from commandline. There is no direct way to revert the window settings, so this is the "smoothest" solution.

"Basically, I want to be able change CMD to a scrolless 25-lined window at the start of the batch file, and then restore it back to a scrollable 300-line window before exiting the batch file"

Why? Bill.

That's something I asked myself several times reading this question ...

Hiya guys.... First of all, thank you for your participation. Let me answer your question (Bill and Qlemo)...

I'm writing a series of batch files with embedded assembler routines (I know.... batch files.... embedded assembler. I've heard all the jokes). The embedded routines just means the user does not have to rely on external third-party commands. These batch files will run in a COMMAND box as well as a CMD box under XP. To ensure the display is consistent, I want to set CMD's window to the same size as COMMAND's window during execution then reset it to how the user had it prior to running the batch file (out of courtesy of course). I acknowledge some people will might run these batch file in a COMMAND box while others might run them in a CMD box. Basically, it's just a case of maintaining consistency.

That's why I don't want CMD's Window_Size to default to 40 lines when reseting CMD's Screen_Buffer.Height.

Bill, that's great advice and something I did not take into consideration. The assembler routines consist mostly of standard DOS INT calls. Currently, I don't have access to a 64-bit PC.

So my proposal would work. You know yourself how to read out the windows settings of the cmd box out of registry, I assume, and you can then reset the windows size to those values with cmdow.
Further I suppose you won't use
start /w command ASMprg.com > c:\output.txt
type c:\output.txt
to have the command window separated.

BTW: 499 points? Is it 500 minus daylight saving?

Qlemo
Hmmmm..... just wanted to break the mold.

I've struggled to keep up with EE lately as my PC has been down but I'm back now so I'll be looking at my replies in due course.

Gentlemen

None of the comments are particularly helpful. I am however, exploring whether this behaviour is due to writing 16-bit code / 32-bit code instead of Win32 code.


abqBill

>> "are these assembler programs MS-DOS programs? If so, this is likely why the screen is resizing"
   FINDSTR.EXE is a DOS program but that doesn't effect the appearance of a DOS window

>> "be aware that such scripts will fail on 64-bit Windows"
   Good advice.

>> "I recommend finding Win32 versions"
   Still exploring whether Win32 code is the answer to this problem

Much Googling has not helped either. I have also bought no less than 6 (used) books on assembler - again, nothing mentioned there.

There are two issues here:

1) Why does only certain code (or COM and EXE programs) effect a DOS window
2) When the DOS window's LINES= setting is restored, why does it effect the size of the window

Strange, I'm about to pose this (2nd) question to MS and see if there is a work-around

I agree nothing mentioned really solves the problem. And about the last sentence - ask them why they didn't allow for visual size and buffer size to be set independently.

Actually, that's an interesting comment because, the two settings which you would think effect the window's appearance are:

   ScreenBufferSize.Height
   WindowSize.Height

and you would think using MODE CON LINES=300 would only affect the ScreenBufferSize.Height.

Let's face it, there's no way in a billion years XP is going to expand the window size to 300 lines so why expand it at all.

I requested a ScreenBufferSize.Heught of 300 bu XP epands the DOS winfow to 40,It doesn't make sense.

Furthermore, there's a separate setting for WindowsSize.Height - so setting the buffersize should not strictly affect the WindowSize.

It just doesn't make sense.

Thank you for clarifying that AbqBill, that's the sort of reply that leads me closer and closer to arriving at a logical conclusion.

Please do not reply to this as there is no need to...unless you can add something not already mentioned.

Okay, I accept 16-bit DOS applications running on a 32-bit machine is going to run under 'emulation' but this does not explain why the ODS box does not return to it's original physical size afterwards.

Nevertheless, we're almost there.