Why is the Windows cmd.exe limited to 80 characters wide? - cmd

I love stretching my terminal on unix. What is the history or reason behind windows lame command line?

It isn't. You can right click the title bar, select properties, and in the "Layout" tab alter the screen buffer size (line width and scrollback) and the window size (viewport size). If you started cmd from a shortcut, you can save these settings for future sessions.

If you are mouse-phobic you can also just type this inside the cmd window:
mode <cols>,<lines>
mode 80,25
mode 120,50
etc.

It's not limited.
Run cmd.exe
Click on the icon in the upper left hand of the screen.
Select Properties
Select the Layout tab.
Set the buffer and window widths to whatever you like.
Click OK
Select Save Properties for future...
Click OK.
You might want to check out Console. It's an open source app that lets you run multiple shells in a tabbed environment. You can also set the alpha-transparency of the shells.

RE: Because MS value "backwards compatibility" over a lot of things and in this case I suspect it's a misplaced belief that it will somehow unnerve people if they don't have their standard 80 wide window.
The backwards compatibility works pretty terribly, though. I don't imagine Microsoft was pretty thorough about their implementation of it, and I do believe Microsoft is the poster boy for making sure newer versions won't work on older versions. A lot doesn't work properly under COMMAND.COM, which considerably sabotages the usefulness it possesses, not to mention that you have to enter DOSONLY to make some programs run properly, plus Microsoft has been removing useful commands. Honestly, I can't imagine Microsoft holds "backwards compatibility" in much of a high regard.
Furthermore, I think the real reason why the line length is at a standard of 80 columns is because most command-line programs, etc. operate under the assumption that the user is capped at an 80 column prompt, meaning that increasing the width can cause formatting errors or worse possibly break programs altogether.
As jmucchiello mentioned, MODE will work fine for resizing the window if you feel like it.
Configures system devices.
Serial port: MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
[to=on|off] [xon=on|off] [odsr=on|off]
[octs=on|off] [dtr=on|off|hs]
[rts=on|off|hs|tg] [idsr=on|off]
Device Status: MODE [device] [/STATUS]
Redirect printing: MODE LPTn[:]=COMm[:]
Select code page: MODE CON[:] CP SELECT=yyy
Code page status: MODE CON[:] CP [/STATUS]
Display mode: MODE CON[:] [COLS=c] [LINES=n]
Typematic rate: MODE CON[:] [RATE=r DELAY=d]
If you have DOSONLY enabled on your CONFIG.NT, however, when you open COMMAND.COM, it will inherit a proper DOS-style line resolution from cmd.exe, but you cannot invoke MODE from inside COMMAND.COM. If you wish to resize inside COMMAND.COM, you will have to use 16-bit assembly instructions, like so:
80x50 Line Resolution (No framebuffer, no SVGA, virtually universally supported.)
DEBUG
A100
MOV AX,1112
INT 10
INT 20
G
Q
132x60 Line Resolution (No framebuffer, requires SVGA. Won't work on ATI gfx cards, usually works on nVidia gfx cards, afaict always works on Intel integrated gfx cards.)
DEBUG
A100
MOV AX,4F02
MOV BX,010C
INT 10
INT 20
G
Q
If you enter this on your COMMAND.COM, it will give you the specified resolution. (Warning: If your monitor is ancient enough not to support the mode, you might wind up destroying it. Side-note: If you can run Windows, your monitor should be fine. Disclaimer: Emphasis on should, and you've been warned, so it's not my problem if your monitor fries. ;-) However, if you use this without DOSONLY enabled, COMMAND.COM will resize back to its previous size as soon as the application (in this case, unless you wrote it to a file and executed that, DEBUG) exits.
Alternatively, you could use FreeDOS's MODE.COM, which will run properly under COMMAND.COM set to DOSONLY. You can either pull it from the disk image at the official website (freedos.org) or get it at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/mode/2005/.
New FreeDOS MODE by Eric Auer 2003-2005. License: GPL. (version 12may2005)
MODE [device] [/STA[TUS]] (show status of one or all devices)
MODE LPTn[:] cols[,[lines][,retry]] (cols or cpi, 6/8 lpi, retry p or n)
MODE LPTn[:] [COLS=...] [LINES=...] [RETRY=...] (retry: p infinite / n none)
MODE LPTn[:]=[COMn[:]|NUL] (redirect printer data to serial port or NUL)
MODE COMn[:] baud,parity,data,stop,retry (empty values allowed)
MODE COMn[:] [BAUD[HARD]=...] [PARITY=...] [DATA=...] [STOP=...] [RETRY=...]
Baud can be abbreviated to unique prefix, parity can be o/e/n/s/m, the
latter 2 mean space/mark, data can be 5..8, stop 1..2. Retry is IGNORED!
PLANNED: Retry b/e/r -> busy/error/ready if busy, p/n infinite/no retry.
MODE CON[:] [CP|CODEPAGE] [/STA[TUS]] (FreeDOS DISPLAY must be loaded)
MODE CON[:] [CP|CODEPAGE] REF[RESH] (needs DISPLAY)
MODE CON[:] [CP|CODEPAGE] SEL[ECT]=number (needs DISPLAY)
MODE CON[:] [CP|CODEPAGE] PREP[ARE]=((codepage) filename) (needs DISPLAY)
Use PREP=((,cp2,cp3,,cp5) ...) to prep codepages in other buffers.
MODE [40|80|BW40|BW80|CO40|CO80|MONO][,rows] (rows can be 25, 28, 43 or 50)
Use 8, 14 or 16 as 'rows' value if you only want to change the font.
MODE [CO40|CO80|...],[R|L][,T] (shift CGA left/right, T is interactive mode)
MODE CON[:] [NUMLOCK|CAPSLOCK|SCROLLLOCK|SWITCHAR]=value
Value can be: + or - for the locks or a character for switchar.
MODE CON[:] [COLS=...] [LINES=...] (possible values depend on your hardware)
MODE CON[:] [RATE=...] [DELAY=...] (default rate 20, default delay 1)
Rate can be 1..32 for 2..30 char/sec, delay can be 1..4 for 1/4..4/4 sec.
For the same reasons as with the ASM code I provided, unless you execute it in COMMAND.COM with DOSONLY added to your CONFIG.NT file, the window will immediately rebound to its previous size once MODE.COM exits.
Lastly, as others have stated, it is also possible to modify these settings simply by right clicking on the command prompt's title bar, and modifying Properties -> Layout. Similarly, you can set the resolution for any shortcuts to CMD.EXE and batch files (Right click the shortcut -> Properties -> Layout). This only works for CMD.EXE, however, not COMMAND.COM.

A simple command to fix the window size that I use all the time:
wmic
It will open the Windows Management Instrumentation Command-line and remove the size limits.
Then just close it with Ctrl+C.

I don't know the history behind it, but this wishlist item from the author of PuTTy is an interesting post that explains the technical hurdles involved with any type of cmd.exe replacement that isn't lame:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-command-prompt.html
You don't mention that you're looking for a replacement, but if so you might also check out some of the cmd.exe replacements like Console 2 or JP Software's Take Command etc. I've also had some good experiences with PuTTy-Cyg which lets you use PuTTy as a cygwin shell.

While the width is not limited as other answers show, I've always found it strange that one can drag and resize the height with the mouse, but not the width.
I think the default 80 character width is related to compatibility with old programs that assume the terminal won't be more than 80 characters wide. I don't think this has been a realistic reason for a decade or so, though.

As others have pointed out, it's not limited to 80 characters wide, but my guess as to why it defaults to 80 characters would be that it's left over from the DOS days where CRT displays were 80 characters wide.
See also

You could also use a different terminal application, such as Console2, which allows you to resize the window all you want (among other things, such as transparency, and the ability to use any font you'd like). It's a great application, I've switched to it and now I only use cmd.exe when I absolutely have to.

Since it will scroll left to right as well as up and down, the very first thing I do on a system is define my width as 180 and save it. That's generally enough so that stack traces don't have to wrap for the most part, but not so much that you are waisting a ton of space.
While you're at it, set the vertical size (scrollback buffer) to all 9's. You'll be glad you did some day.

Because MS value "backwards compatibility" over a lot of things and in this case I suspect it's a misplaced belief that it will somehow unnerve people if they don't have their standard 80 wide window.
Of course it could be that it was programmed for a fixed 80 chars width when that was pretty much universal, and the additional property settings were a bit of a hack.

It IS limited. Check it out. (I mean window size NOT buffer)
You will find that the maximum width you can set is limited but varies according to your screen resolution. If your resolution is set to 1024 x 768 you will find that you can only get to 128 on the command prompt width. 128/1024=.125
you will find that ratio to be consistent across the board. I have an RDP session running at 2000x768 (across two of my three monitors) and get a max width of 250.
Now, that actaully turns out to be a little bigger than your actaul monitor size but I have three monitors all running individual desktops. (so in essence, 3 1024x768 resolutions) and if I want to do something SO SIMPLE as stretch a command prompt across 2 or more monitors, I CAN'T. (I want to when doing things with very long paths (diruse.exe/etc.)...
-c

This isn't closed. So it should be noted that Windows Terminal is now is changing all of this:
https://github.com/microsoft/terminal
https://www.theverge.com/2020/1/9/21059316/microsoft-windows-terminal-crt-effects-retro-search-tabs-features
https://devblogs.microsoft.com/commandline/windows-command-line-backgrounder/
https://github.com/microsoft/terminal/blob/master/doc/terminal-v1-roadmap.md
https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab

Because improving the usability and functionality of anything that Unix/GNU-like development requires will undermine Windows as a commercial platform for Microsoft's partners. Preventing this means other large companies' products for developers, such as improved terminals, and other general third party products, like word processors, video players etc. aren't competing with existing Unix/GNU software. Without this, Windows wouldn't be a profitable platform, and Microsoft would lose its desktop monopoly.
This is why the terminal sucks, there's no POSIX API, no C99 support in MSVC and the list goes on. To clarify, common Unix/GNU technologies and development are intentionally unsupported so that large commercial software houses don't have to compete with them.

Related

Using ncurses in c language

I'm using ncurses in one of my application in unix server.
My application is in such a way that it displays different set of information.
So I have created different pads to display each content.
Is there a way to use scroll option for these pads at a stretch?
As of now ncurses is limited to screen size, if I have display 3 or more pads at the same time it is not possible because it exceeds the screen size.
Is there any way to do to implement scroll using ncurses in this scenario?
ncurses (any curses library) supports overlapping windows. You do not have to tile (subdivide) the screen.
If you design your program to allow the user to select different views of the data, you can have multiple windows on the screen which use most of it.
For instance, the dialog program in this screenshot is showing overlapping windows (using touchwin and wrefresh). The tab character makes it switch focus to the next window:

How to stop Explorer starting my application maximized?

Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.

Can a window be resized past the screen size/offscreen?

My purpose is to size a window to a width/height greater than the size of my physical screen programmatically under Win32. How can I do this?
On my systems it seems the maximum size of a given window is bound by the size of my screen whether programmatically or whether sizing manually by dragging the sizing cursor.
I have tried programmatically with SetWindowPos() and MoveWindow() and both cap the size of the target window. Oddly I know some people do not have this 'cap' so I wonder whether this is perhaps due to some OS setting (registry). Does anyone know something about this? Or perhaps some way to workaround it?
// Edit: new developments
I am testing on Windows XP and Windows 7. The graphics cards I'm using are a NVIDIA Quadro NVS 290 (256MB) and a Geforce 9800GT (1GB). After further investigation it looks like Windows is intercepting the message and fiddling with the parameters. For example, if you call SetWindowPos to make a target 2000x2000 it will only receive a WM_SIZE for the capped x/y.
Implement a message handler for WM_GETMINMAXINFO to stop Windows from applying the sane default behavior:
case WM_GETMINMAXINFO: {
DefWindowProc(hWnd, message, wParam, lParam);
MINMAXINFO* pmmi = (MINMAXINFO*)lParam;
pmmi->ptMaxTrackSize.x = 2000;
pmmi->ptMaxTrackSize.y = 2000;
return 0;
}
Windows with a thick frame (to allow user resize) are restricted from growing larger than the desktop.
Try SetWindowLong() clearing the THICKFRAME (0x40000) flag.
The following should allow programatic sizing, but the user will lose the ability to resize. If you add the Thickframe back after sizing, the user can resize, but when he does so the window will immediately shrink back to the desktop limited size.
The following is from some csharp code that also removes all borders, caption, etc:
WS style = (WS)GetWindowLong(ptr, GWL_STYLE);
style = style & ~WS.BORDER & ~WS.ThickFrame & ~WS.SYSMENU & ~WS.CAPTION | WS.POPUP;
SetWindowLong(ptr, GWL_STYLE, (int)style);
A good tool to play with window settings is uuSpy.
It's like Microsoft Spy++, but allows you to modify settings like THICKFRAME.
Yes, windows can be larger than the screen (or even the sum of all your monitors). Windows can also be positioned off-screen (which some applications do as a hack to hide while remaining active).
Perhaps the Windows 7 desktop manager is kicking in and trying to "dock" those windows to the edges of your screen for you.
You might try using the slightly lower-level API SetWindowPos, which gives you control over notifications, z-order, and other stuff.
You can get a window to be larger in resolution (and even way way larger) than your screen, using the 'Infinte Screen" software:
http://ynea.futureware.at/cgi-bin/infinite_screen.pl
Here's how to use it:
Download it, run it.
In the Oversize tab, choose the Windows you want to enlarge.
Give it the Width and Height you want. Done!
Just in case you need a large screenshot (that's how I ended up here):
If you want to get a screenshot of the window, you've got a screenshot option in the same Oversize tab. (Because screenshots are normally no bigger than the screen size, even if the window is larger). Another (and better) way to screenshot the window is using Greenshot, as you can save them in .tiff and directly watching the window.

Unknown extended window style values from GetWindowLong and GetWindowInfo

I am calling querying the extended window styles of a window using the GetWindowLog property and it is returning values in many cases that are not documented in msdn.
Particularly 0x00000800L and 0x00000100L or a combination of the two. Does anyone have information about these values, or a more complete list than what is documented on the msdn site?
I ran across this thread while looking for an answer to why this value changes when Microsoft Word "disappears" a window. I maintain an app that tracks the HWND values in order to do application sharing. This works well, but Microsoft Office applications often handle these in unusual ways. In this particular case, I found that if you do the following in Microsoft Word 2013:
Open two new documents in separate windows.
Save the HWND values for both windows.
Close one of the two windows.
Both HWND values will, when interrogated with the IsWindow, IsVisible, etc Windows functions, appear to be normal, still visible, etc. There's no way I can find to tell that one of the windows has been closed -- except this undocumented dwExStyle value. 0x800 will be 'on' in the window that's still visible, and 'off' in the window that isn't visible any more.
(BTW, I know you're not "supposed" to save HWND values this way -- but try tracking windows for sharing without saving this value -- not so easy!)
Since 0x00000100L is listed right on the Extended Window Styles page it is a little unclear to me if you mean the normal or extended style so I'll describe both.
Style:
Dialog & old (user32) controls
0xFFFF for control/dialog specific styles
Common control:
0x00FF is generally used by the shared common control styles (CCS_NORESIZE, CCS_TOP etc)
0xFF00 for control specific styles, for a toolbar you would have TBSTYLE_LIST, TBSTYLE_TRANSPARENT etc
ExStyle:
0x00000100L=WS_EX_WINDOWEDGE
0x00000800L=Don't know, undocumented flag maybe (Edit: ReactOS has/had 0x00000800 as WS_EX_MAKEVISIBLEWHENUNGHOSTED, that does not mean that it has the same meaning on windows since ReactOS is not 100% compatible with windows)
Jeremy, this is just a bug of GetWindowInfo (for any OS after Win98: 2k, XP, Vista, Win7).
see http://rsdn.ru/forum/winapi/3362548.all.aspx ("WINDOWINFO.dwExStyle error")
try small tester therefrom: http://files.rsdn.ru/42164/wi_exstyle.zip
kero

Is there anything like Winsplit Revolution for Mac OS X?

Is there anything like Winsplit Revolution for Mac OS X?
Try these:
Zooom/2 ($15) has been my favorite since I installed it. Fast, flexible, and minimizes the number of key combinations I need to remember
Divvy ($15) might soon replace Zoom/2 for me. It's closer to Winsplit. You can arrange windows on a grid, define your own grid arrangements, and define your own shortcuts. It also minimizes the number of keystroke combinations you need to remember. BONUS: There are Mac and Windows versions, which means if you use both platforms you can use the same window management method across all your machines.
Breeze ($8) makes it easy to make windows fullscreen, split left, or split right. It also lets you save screen states (generic) and for specific apps.
Moom ($5) is a more recent entry. It supports both keyboard shortcuts and mouse shortcuts. For the mouse shortcuts, moving the cursor over the greeen zoom button displays a popup list of different layout options: full screen, left/right half, top/bottom half, or any of the corners.
SizeUp ($10) mimics various aspects of WinSplit functionality, but it relies on many keystroke combinations that take time to learn. The advantage is quickly moving windows. The drawback is that it uses up a lot of global keyboard shortcuts, and there are so many I couldn't remember them all.
Cinch ($7) is a mouse-driven app by the makers of SizeUp. Drag your window to various hot zones on the screen edges and the window will "cinch" to that edge and resize to fill half the screen. Similar to the built-in resizing feature in Windows 7.
MercuryMover ($20) is quite powerful and offers fine-grained control. However, there are a lot of different key combinations and, overall, I didn't find it as easy to learn or as elegant as WinSplit. I uninstalled it almost immediately. It struck me as powerful, but inefficient and unwieldy.
The DIY approach (free) mentioned in another post is to combine some applescripts and bind them to quicksilver triggers. I haven't tried this. But it is a free solution.
I found the weak window management one of the hardest things to cope with when I started using a Mac.
Why go beyond spaces and expose?
Winsplit significantly adds to what spaces and expose can do. I didn't understand the appeal until I actually used it. Before that, I thought virtual desktops (ie, like spaces) was enough. Now I consider it must-have functionality, especially on large monitors and multi-mon setups.
On my Windows machine running 3 monitors, I would rank the importance of these different apps in the following order:
Winsplit-like window rearranging
Spaces-like virtual desktops
Expose-like application switching
On my MacBook, I've learned to approach it the other way.
Expose-like application switching
Winsplit-like window rearranging
Spaces-like virtual desktops
From the Winsplit website I understand more or less the functionality; in the past I actually used to have my window manager (Waimea) configured to do exactly that in linux.
You may try using Quicksilver to trigger one of a custom set of applescripts; each applescript would resize and move the currently focused window to a predefined location.
See this macosxhints post for inspiration...
ShiftIt is a free option. Assignable hotkeys to resize to different portions of the screen (Left, Right, Top, Bottom, Top Left, Top Right, Bottom Left, Bottom Right, Full Screen and Center with current size)
Link to ShiftIt on github
Just click on the big download button towards the right of the screen.
Spectacle is a good option, its free and open source. And easy to use with keyboard shortcut :
Windows can be moved to a number of predefined regions of the screen:
Move to the left half ⌥⌘←
Move to the right half ⌥⌘→
Move to the top half ⌥⌘↑
Move to the bottom half ⌥⌘↓
Move to the upper left ⌃⌘←
Move to the lower left ⌃⇧⌘←
Move to the upper right ⌃⌘→
Move to the lower right — ⌃⇧⌘→
Another question on StackOverflow adresses the same issue
https://stackoverflow.com/questions/276760/tiling-window-manager-for-os-x
One answer provided links to an app called TwoUP. It's free, and does the job on OSX!
Thanks to Dong Hoon's answer, I have developed a hybrid solution. Using the AppleScript Editor, you can create scripts to resize the current window, like this:
tell application "System Events"
set _everyProcess to every process
repeat with n from 1 to count of _everyProcess
set _frontMost to frontmost of item n of _everyProcess
if _frontMost is true then set _frontMostApp to process n
end repeat
set _windowOne to window 1 of _frontMostApp
set position of _windowOne to {5, 0}
set size of _windowOne to {1150, 735}
end tell
such a script will work on a 13" MacBook. Using subtle variations of this script saved to /Users/[YourUserNameHere]/Library/Scripts, you can have configure the AppleScript Editor to show itself in the menu bar, where it will allow you to select a script to run.
Using several different scripts, I'm able to resize and reposition any window with only two clicks.
Hope this helps.
It looks like TwoUp is dead, but here are some other options:
Cinch ($7) is like Aero Snap for Mac.
Breeze ($8) allows you to save window states and restore them like a template to another window.
Divvy ($14) shows a grid on the screen where you can select boxes to indicate how you want the window to fill your screen.
I haven't used Winsplit, so I don't know how it compares, but an app I developed, Optimal Layout, offers very flexible window tiling, as well as moving and resizing from the keyboard:
http://most-advantageous.com/optimal-layout/
You can also try Arrange application which features resize and reposition with keyboard shortcuts, on screen menu and by dragging window.
You should also try out secondbar. gives you an extra menubar at the second display + re-arrange options. See this link.
You can even try SplitScreenapp.com. It allows you to resize Mac Windows in many ways including full split, half split, drag and snap, etc.
I doubt it. Between Spaces and Expose, there's not much need for a third-party app to help manage multiple windows.

Resources