How to change Screen buffer size in Windows Command Prompt from batch script

I know you can do right click properties ->layout and there change it manually.

But how would you go about changing it from a Windows batch script?

I know you can change size of it from script using something like this

MODE CON: COLS=90 LINES=10

But how can you change buffer size?

The script will run for a while and sometimes before failing and exiting it takes some time, so I need larger buffer.

I was just searching for an answer to this exact question, come to find out the command itself adjusts the buffer!

mode con:cols=140 lines=70

The lines=70 part actually adjusts the Height in the 'Screen Buffer Size' setting, NOT the Height in the 'Window Size' setting.

Easily proven by running the command with a setting for 'lines=2500' (or whatever buffer you want) and then check the 'Properties' of the window, you'll see that indeed the buffer is now set to 2500.

My batch script ends up looking like this:

@echo off
cmd "mode con:cols=140 lines=2500"

I was just giving a try for max lines on windows 7 i can set using mode con command and found it to be 32766 2^15-2 and you can set it with following command

mode con lines=32766

although you can set screen buffer size from the GUI too, but the max you can get is 9999.

mode con lines=32766

sets the buffer, but also increases the window height to full screen, which is ugly.

You can change the settings directly in the registry :

:: escape the environment variable in the key name
set mySysRoot=%%SystemRoot%%

:: 655294544 equals 9999 lines in the GUI
reg.exe add "HKCU\Console\%mySysRoot%_system32_cmd.exe" /v ScreenBufferSize /t REG_DWORD /d 655294544 /f

:: We also need to change the Window Height, 3276880 = 50 lines
reg.exe add "HKCU\Console\%mySysRoot%_system32_cmd.exe" /v WindowSize /t REG_DWORD /d 3276880 /f

The next cmd.exe you start has the increase buffer.

So this doesn't work for the cmd.exe you are already in, but just use this in a pre-batch.cmd which than calls your main script.

Below is a very simple VB.NET program that will do what you want.

It will set the buffer to 100 chars wide by 1000 chars high. It then sets the width of the window to match the buffer size.

Module ConsoleBuffer
  Sub Main()
    Console.WindowWidth = 100
    Console.BufferWidth = 100
    Console.BufferHeight = 1000
  End Sub
End Module

UPDATE

I modified the code to first set Console.WindowWidth and then set Console.BufferWidth because if you try to set Console.BufferWidth to a value less than the current Console.WindowWidth the program will throw an exception.

This is only a sample...you should add code to handle command line parameters and error handling.

There's a solution at https://stackoverflow.com/questions/13311924/cmd-set-buffer-height-independently-of-window-height effectively employing a powershell command executed from the batch script. This solution let me resize the scrollback buffer in the existing batch script window independently of the window size, exactly what the OP was asking for.

Caveat: It seems to make the script forget variables (or at least it did with my script), so I recommend calling the command only at the beginning and / or end of your script, or otherwise where you don't depend on a session local variable.

Here's what I did in case someone finds it useful (I used a lot of things according to the rest of the answers in this thread):

First I adjusted the layout settings as needed. This changes the window size immediately so it was easier to set the exact size that I wanted. By the way I didn't know that I can also have visible width smaller than width buffer. This was nice since I usually hate a long line to be wrapped.

Then after clicking ok, I opened regedit.exe and went to "HKEY_CURRENT_USER\Console". There is a new child entry there "%SystemRoot%_system32_cmd.exe". I right clicked on that and selected Export:

I saved this as "cmd_settings.reg". Then I created a batch script that imports those settings, invokes my original batch script (name batch_script.bat) and then deletes what I imported in order for the command line window to return to default settings:

regedit /s cmd_settings.reg
start /wait batch_script.bat
reg delete "HKEY_CURRENT_USER\Console\%%SystemRoot%%_system32_cmd.exe" /f

This is a sample batch that could be invoked ("batch_script.bat"):

@echo off
echo test!
pause
exit

Don't forget the exit command at the end of your script if you want the reg delete line to run after the script execution.

There is no "DOS command prompt". DOS fully died with Windows ME (7/11/2006). It's simply called the Command Prompt on Windows NT (which is NT, 2K, XP, Vista, 7).

There is no way to alter the screen buffer through built-in cmd.exe commands. It can be altered through Console API Functions, so you might be able to create a utility to modify it. I've never tried this myself.

Another suggestion would be to redirect output to both a file and to the screen so that you have a "hard copy" of it. Windows does not have a TEE command like Unix, but someone has remedied that.

I created the following utility to set the console size and scroll buffers.

I compiled it using DEV C++ (http://www.bloodshed.net/devcpp.html).

An executable is included in https://sourceforge.net/projects/wa2l-wintools/.

#include <iostream>
#include <windows.h> 

using namespace std;


// SetWindow(Width,Height,WidthBuffer,HeightBuffer) -- set console size and buffer dimensions
//
void SetWindow(int Width, int Height, int WidthBuffer, int HeightBuffer) { 
    _COORD coord; 
    coord.X = WidthBuffer; 
    coord.Y = HeightBuffer; 

    _SMALL_RECT Rect; 
    Rect.Top = 0; 
    Rect.Left = 0; 
    Rect.Bottom = Height - 1; 
    Rect.Right = Width - 1; 

    HANDLE Handle = GetStdHandle(STD_OUTPUT_HANDLE);      // Get Handle 
    SetConsoleScreenBufferSize(Handle, coord);            // Set Buffer Size 
    SetConsoleWindowInfo(Handle, TRUE, &Rect);            // Set Window Size 
}  // SetWindow



// main(Width,Height,WidthBuffer,HeightBuffer) -- main
//
int main(int argc, char *argv[]) {     
    int width = 80;
    int height = 25;
    int wbuffer = width + 200;
    int hbuffer = height + 1000;
      
    if ( argc == 5 ){
        width = atoi(argv[1]);
        height = atoi(argv[2]);
        wbuffer = atoi(argv[3]);
        hbuffer = atoi(argv[4]);
    } else if ( argc > 1 ) {
        cout << "Usage: " << argv[0] << " [ width height bufferwidth bufferheight ]" << endl << endl;
        cout << "  Where" << endl;
        cout << "    width            console width" << endl;
        cout << "    height           console height" << endl;
        cout << "    bufferwidth      scroll buffer width" << endl;
        cout << "    bufferheight     scroll buffer height" << endl;
        return 4;
    }    

    SetWindow(width,height,wbuffer,hbuffer);
    return 0;
} 

If anyone is still wondering, on the newer versions of windows you can use powershell:

powershell.exe -command "& {$pshost = Get-Host;$pswindow = $pshost.UI.RawUI;$newsize = $pswindow.BufferSize;$newsize.height = 150;$pswindow.buffersize = $newsize;}"

You can change the buffer size of cmd by clicking the icon at top left corner -->properties --> layout --> screen buffer size.
you can even change it with cmd command

mode con:cols=100 lines=60
Upto lines = 58 the height of the cmd window changes ..
After lines value of 58 the buffer size of the cmd changes...

I know the question is 9 years old, but maybe for someone it will be interested furthermore. According to the question, to change the buffer size only, it can be used Powershell. The shortest command with Powershell is:

powershell -command "&{(get-host).ui.rawui.buffersize=@{width=155;height=999};}"

Replace the values of width and height with your wanted values.

But supposedly the reason of your question is to modify the size of command line window without reducing of the buffer size. For that you can use the following command:

start /b powershell -command "&{$w=(get-host).ui.rawui;$w.buffersize=@{width=177;height=999};$w.windowsize=@{width=155;height=55};}"

There you can modify the size of buffer and window independly. To avoid an error message, consider that the values of buffersize must be bigger or equal to the values of windowsize.

Additional implemented is the start /b command. The Powershell command sometimes takes a few seconds to execute. With this additional command, Powershell runs parallel and does not significantly delay the processing of the following commands.

I have found a way to resize the buffer size without influencing the window size. It works thanks to a flaw in how batch works but it gets the job done.

mode 648 78 >nul 2>nul

How does it work? There is a syntax error in this command, it should be "mode 648, 78". Because of how batch works, the buffer size will first be resized to 648 and then the window resize will come but it will never finish, because of the syntax error. Voila, buffer size is adjusted and the window size stays the same. This produces an ugly error so to get rid of it just add the ">nul 2>nul" and you're done.

I'm expanding upon a comment that I posted here as most people won't notice the comment.

https://lifeboat.com/programs/console.exe is a compiled version of the Visual Basic program described at https://stackoverflow.com/a/4694566/1752929. My version simply sets the buffer height to 32766 which is the maximum buffer height available. It does not adjust anything else. If there is a lot of demand, I could create a more flexible program but generally you can just set other variables in your shortcut layout tab.

Following is the target I use in my shortcut where I wish to start in the f directory. (I have to set the directory this way as Windows won't let you set it any other way if you wish to run the command prompt as administrator.)

C:\Windows\System32\cmd.exe /k "console & cd /d c:\f"

As a workaround, you may use...

Windows Powershell ISE

As the Powershell script editor does not seems to have a buffer limitation in its read-eval-print-loop part (the "blue" part). And with Powershell you may execute DOS commands as well.

PS. I understand this answer is a bit aside the original question, however I believe it is good to mention as it is a good workaround.