I know that the command line in windows is not really DOS. So here are some questions that this fact leads to. Is MS-DOS a true form of DOS? How does one get to a true DOS shell, MS-DOS or otherwise? What are some specific advantages to one or the other?(command line and DOS)
Windows command line vs. MS-DOS
Started by AIGuy, Oct 25 2010 06:39 PM
10 replies to this topic
#1
Posted 25 October 2010 - 06:39 PM
|
|
|
#2
Posted 25 October 2010 - 07:56 PM
AIGuy said:
Is MS-DOS a true form of DOS?
Quote
How does one get to a true DOS shell, MS-DOS or otherwise?
An alternative is to run Windows 98 or older, which runs MS DOS under the hood.
Quote
What are some specific advantages to one or the other?(command line and DOS)
Root Beer == System Administrator's Beer
Download the new operating system programming kit! (some assembly required)
Download the new operating system programming kit! (some assembly required)
#3
Posted 26 October 2010 - 01:45 PM
Guest said:
The command line in Windows is more modern and integrated with the rest of the operating system. The problem with it is that it uses a mediocre DOS emulator to run DOS programs. The advantage to actual DOS is that it can run programs made for DOS in a native environment, improving speed and compatibility.
Not to mention the Windows command line no longer lets you go full-screen, or even make the cmd window wider. Why Microsoft has (seemingly deliberately) introduced this limitation is beyond me.
Programming is a journey, not a destination.
#4
Posted 26 October 2010 - 02:24 PM
DarkLordofthePenguins said:
Not to mention the Windows command line no longer lets you go full-screen, or even make the cmd window wider. Why Microsoft has (seemingly deliberately) introduced this limitation is beyond me.
Way back when computer terminals displayed characters in columns, and the standard column width for IBM-era computers were 80 columns. This was transposed for legacy reasons into the Windows command line console, so MS-DOS legacy programs would not break graphically (i.e. assembly buffered line positions assumed column 80 as end of line)
Be sure to read the updated FAQ! || Health is achieved through the same 10,000 steps.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
#5
Posted 26 October 2010 - 02:57 PM
Nullw0rm said:
Way back when computer terminals displayed characters in columns, and the standard column width for IBM-era computers were 80 columns. This was transposed for legacy reasons into the Windows command line console, so MS-DOS legacy programs would not break graphically (i.e. assembly buffered line positions assumed column 80 as end of line)
That still doesn't explain why the DOS prompt has no fullscreen mode. I've played games full screen in DOSBox and the graphics don't get broken.
Programming is a journey, not a destination.
#6
Posted 26 October 2010 - 05:22 PM
DarkLordofthePenguins said:
That still doesn't explain why the DOS prompt has no fullscreen mode. I've played games full screen in DOSBox and the graphics don't get broken.
Be sure to read the updated FAQ! || Health is achieved through the same 10,000 steps.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
#7
Posted 26 October 2010 - 05:25 PM
I think what he's saying is, why can't it just stretch?
#8
Posted 26 October 2010 - 05:39 PM
It is not defined in the dos.sys driver to go more than 80 columns.
Be sure to read the updated FAQ! || Health is achieved through the same 10,000 steps.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
If a suggested code/method fails, informing us is less important than telling us why or what errors occurred.
#9
Posted 26 October 2010 - 05:51 PM
My main problem is when it comes to programs like Vim and MySQL where text can potentially take up many columns. If I'm using Vim in a cmd window and it's got five levels of indentation in places, then half the cmd window is blank and I only see small snippets of code at a time. In MySQL, I often have tables that when printed can be over 100 characters wide. It's more convenient not to have an 80-column limit. PowerShell doesn't have a limit if I recall correctly, but I can't use Vim in that because the blue background makes it impossible to read blue text, and for some reason I can't change the text and background color in PowerShell like I can in the DOS prompt, not with the same command anyway.
Programming is a journey, not a destination.
#10
Posted 26 October 2010 - 06:33 PM
Quote
It is not defined in the dos.sys driver to go more than 80 columns.
Ok, so that's not what he meant. What I meant was why can't you stretch the columns too?
#11
Posted 27 October 2010 - 07:12 AM
You can change the width of the cmd screen in windows by right-clicking the title bar ->properties.
In the properties window you go to the Layout tab and set the window size.
In the properties window you go to the Layout tab and set the window size.


Sign In
Create Account


Back to top









