Harnessing the Power of DOS

[kazar]

It's a fact - APIs have replaced many of the DOS Functions, and yet there are still people who consider dos a powerful tool, after all .net provides the ability to make console applications.

So, i created a simple way, without messing around with console opening and manipulation, of sending and recieving the results of DOS commands in VB6.

Sending a DOS Command:

Now for most vb programmers, sending a command to DOS is easy as pie. However, if you want to receive a command from DOS, you need to wait for the command to finish executing, right? So i use this code to send a command to DOS and wait for it to finish. Some of it can be found on MSDN btw.

Option Explicit
Private Type STARTUPINFO
      cb As Long
      lpReserved As String
      lpDesktop As String
      lpTitle As String
      dwX As Long
      dwY As Long
      dwXSize As Long
      dwYSize As Long
      dwXCountChars As Long
      dwYCountChars As Long
      dwFillAttribute As Long
      dwFlags As Long
      wShowWindow As Integer
      cbReserved2 As Integer
      lpReserved2 As Long
      hStdInput As Long
      hStdOutput As Long
      hStdError As Long
   End Type
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
   Private Type PROCESS_INFORMATION
      hProcess As Long
      hThread As Long
      dwProcessID As Long
      dwThreadID As Long
   End Type
Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long
   Private Declare Function WaitForSingleObject Lib "kernel32" (ByVal _
      hHandle As Long, ByVal dwMilliseconds As Long) As Long
 
   Private Declare Function CreateProcessA Lib "kernel32" (ByVal _
      lpApplicationName As String, ByVal lpCommandLine As String, ByVal _
      lpProcessAttributes As Long, ByVal lpThreadAttributes As Long, _
      ByVal bInheritHandles As Long, ByVal dwCreationFlags As Long, _
      ByVal lpEnvironment As Long, ByVal lpCurrentDirectory As String, _
      lpStartupInfo As STARTUPINFO, lpProcessInformation As _
      PROCESS_INFORMATION) As Long
 
   Private Declare Function CloseHandle Lib "kernel32" _
      (ByVal hObject As Long) As Long
 
   Private Declare Function GetExitCodeProcess Lib "kernel32" _
      (ByVal hProcess As Long, lpExitCode As Long) As Long
 
   Private Const NORMAL_PRIORITY_CLASS = &H20&
   Private Const INFINITE = -1& 
 
   Public Function ExecCmd(cmdline$)
      Dim proc As PROCESS_INFORMATION
      Dim start As STARTUPINFO
 
      ' Initialize the STARTUPINFO structure:
      start.cb = Len(start)
 
      ' Start the shelled application:
      ret& = CreateProcessA(vbNullString, cmdline$, 0&, 0&, 1&, _
         NORMAL_PRIORITY_CLASS, 0&, vbNullString, start, proc)
       DoEvents
        Dim sysbuffer As String
        Dim sysbuffersize As Long
         GetSystemDirectory sysbuffer, sysbuffersize
 
      ' Wait for the shelled application to finish:
         ret& = WaitForSingleObject(proc.hProcess, INFINITE)
         Call GetExitCodeProcess(proc.hProcess, ret&)
         Call CloseHandle(proc.hThread)
         Call CloseHandle(proc.hProcess)
         ExecCmd = ret&
 
   End Function
 
Function SendDOSCommand(command as string, destlog as string)
 
'i know that using bat files is a strange way to do it, but i find it works better
 
     Open "C:\Dosemu.bat" for output as #1
              Print #1, command + " > " + destlog
 
'the  > destlog part is the key to the whole thing, since it forces dos to copy it's results to the specifyed file
 
     Close
 
 
 ExecCmd ("C:\dosemu.bat")
'this line waits for the command to finish executing
Kill ("C:\dosemu.bat")
'and this gets rid of the temp bat file
 
End Function

So thats that for sending commands, now for retrieving them. In the code above, the dos results have been saved to a file, called destlog.

To get them back is simple. Just Read the File! Create a textbox and call it dosbox, with multiline enabled.

Sub getdosresults(doslog as string)
 
Open doslog For Input As #1
    On Error GoTo skipfile
        Do
        Input #1, buffer
        dosbox.Text = dosbox.Text + buffer + vbCrLf
     'this line gets each line from the file and adds a next line character
        Loop
        
skipfile:
Close
 
End Sub

[szlamany]

Being able to create command line .BAT files to do things like FTP files and copy/rename/post-process them is a requirement of today's programming world.

Being able to schedule these jobs to run at certains times, unattended, is also a part of today's programming world...

With that said, DOS command line seems to have a place.

[kazar]

You know that, I know that, but i have met a worrying amount of people who think otherwise, i'm afraid.

[iPrank]

Let them think that way.
If you know DOS very well, you'll be always one step ahed.

There are some things that aren't possible from windows (atleast not easily), but they are just a child's play in DOS.

[kazar]

Very true, personally, i always found the tracert command really useful, along with ipconfig, and netstat.

Any favourite commands?

[iPrank]

***tree C:\*.* /y

[kazar]

Perhaps there should be a batch section on the forum...?

[si_the_geek]

There arent enough questions asked to justify a separate forum... we have other forums where they can be asked (and have been answered).

[RobDog888]

Checkout Joacim Anderssons FAQ thread on redirecting the DOS command window information.

http://www.vbforums.com/showthread.php?t=364219

There is always a need for DOS in programming, its just knowing when and where to apply it. This is what sets a good programmer above other programmers.

[RhinoBull]

Don't care much about what everybody else sais but for me and most of my colleagues DOS is still the KING of all programming!

[Joacim Andersson]

On the question if DOS have a place in todays programming world, I had to answer No! DOS is dead and has been so for many years now. What you guys are talking about, and what the question should be is if there is a place for console based application in todays programming world, and on that question I would have said Yes of course it has!

On my WinXP computer I don't have DOS. The console window is not DOS. All "DOS commands" are Win32 console commands. The Windows console is also much more powerful than DOS ever was. The command line limit is about 8KB instead of 260 character. You can combine several commands on the same line by using the & character, for example:

cd \ & dir

It has *true* support for long filenames. A Win32 console application has access to the Win API even though there is no use for any of the GDI functions. Console applications, like all other Win32 applications, runs in there own virtual memory space and as such have 2GB of memory to play with (compared to 640 for a DOS app)... the list goes on...

So don't confuse DOS with the Windows console because they are not the same thing even though the name of many commands are the same.

[RhinoBull]

...So don't confuse DOS with the Windows console because they are not the same thing even though the name of many commands are the same.

Indeed Mr Professor.

[ssampson]

Personally - I miss 'edlin'...

[Datacide]

DOS, the ultimate hacking tool...

I'll never give up my DOS knowledge and hope they continue to support it. It's so easy to create a .BAT file and gain access to things your
not supposed too

[Joacim Andersson]

What is it that a BAT file can give you access to that you're not supposed to? Absolutly nothing... What can a batch file do that you can't do with the WSH? Nothing! How much more access do you have to the OS from the WSH compared to a batch file? A whole lot. And it's still not DOS unless you're running a 10 year old version of Windows.

[Datacide]

Well when your at place where it's secured up and stuff and everythings removed from the start menu (like at the library). I just make a batch file in notepad and gain access to DOS.

[Joacim Andersson]

If it's secure you will not be able to save and run a BAT file (if you could you could just as well create a script file and use WSH instead) and can everyone please stop calling the Windows command line for DOS

[szlamany]

What is WSH?

[RhinoBull]

In our world is stands for "Windows Script Host" but it could also be "Water, Sanitation and Health", etc ...

[szlamany]

So it's just another way to execute a .BAT file?

How do you get to WSH?

[RhinoBull]

It's available since Win98:

Windows Script Host

[MartinLiss]

Moved.

[RhinoBull]

... and can everyone please stop calling the Windows command line for DOS

Joacim,
I do share your sentiments but you need not to scream - lots of people (and small businesses) are still running off Win 95 (and even Win 3.1) platform so they do have a DOS despite the fact that it's (DOS that is) dead.
Although it is 2006 and Windows Vista in on the way those win95 users are pretty happy campers so we must respect as well.
Having said that I gues DOS isn't quite dead yet. Also, majority of "old-timers" refer to "command-line" as "DOS" and that's the end of it.

Best regards.

[k1ll3rdr4g0n]

On the question if DOS have a place in todays programming world, I had to answer No! DOS is dead and has been so for many years now. What you guys are talking about, and what the question should be is if there is a place for console based application in todays programming world, and on that question I would have said Yes of course it has!

On my WinXP computer I don't have DOS. The console window is not DOS. All "DOS commands" are Win32 console commands. The Windows console is also much more powerful than DOS ever was. The command line limit is about 8KB instead of 260 character. You can combine several commands on the same line by using the & character, for example:

cd \ & dir

It has *true* support for long filenames. A Win32 console application has access to the Win API even though there is no use for any of the GDI functions. Console applications, like all other Win32 applications, runs in there own virtual memory space and as such have 2GB of memory to play with (compared to 640 for a DOS app)... the list goes on...

So don't confuse DOS with the Windows console because they are not the same thing even though the name of many commands are the same.

If DOS is truly dead they why does Microsoft still include command.com in Windows XP?
So if command.com is DOS then you still have it on your computer silly pants.
Don't even try and say command.com isn't DOS when the first lines that come up say:

Microsoft<R> Windows DOS
<C>Copyright Microsoft Corp 1990-2001

(Btw, you do have DOS on your computer still, I'm running XP Pro.)
I doubt DOS will ever go away (in fact DOS emulators will make sure of that, DOSBox being one of them). So many (great) legacy programs depend on DOS and old console commands, so I doubt Microsoft will ever get rid of it entirely.

-rant rant-
Thats my rant. Enjoy

[szlamany]

I've got customers that create .BAT files for all kinds of purposes. Archiving files - moving backups from server to server...

Running complex FTP operations - ones that require those ugly little "command-line" variables for date-stamping the filename...

They can run these .BAT files from a desktop scheduler or even from the SQL Server Agent - they are rather general purpose.

Are you all saying there is a better, newer, cleaner way to be doing this type of "operations" functionality?

I'm not saying from VB - not from a coders perspective - but from the IT-staff at a shop - production type people.

[RhinoBull]

...Are you all saying there is a better, newer, cleaner way to be doing this type of "operations" functionality?...

There are quite of few superb enterprize schedulers like Tivoli's Maestro (they probably have something new by now but what I knew as Maestro was extraordinary product).

[Joacim Andersson]

Joacim,
I do share your sentiments but you need not to scream - lots of people (and small businesses) are still running off Win 95 (and even Win 3.1) [...]
Having said that I gues DOS isn't quite dead yet. Also, majority of "old-timers" refer to "command-line" as "DOS" and that's the end of it.

When did I scream? The fact that some companies might still run Windows 3.1 doesn't mean that DOS has a place in todays programming world, and that was the question that was asked.

Also that DOS emulators exists doesn't mean squat either, Windows itself can emulate DOS pretty well too. But if you all say that DOS still have a place in todays programming world may I then ask when you last wrote a program for DOS? Writing a BAT file is not the same thing as writing a DOS program, you can run BAT files using Windows command line tool, which means that your running a Windows batch file and not a DOS program.

That some people refers to the command line as DOS doesn't make it DOS, and this was my whole point, you should call things by their right names to avoid confusion.

There's a huge difference between the Windows command line interpreter and DOS. Even when you run Command.com on WinXP it still uses Windows disk operations when you look at the file system, which means that you're not running DOS, you might call it a DOS command line emulator if you wish, but an emulator is not DOS.

I might be able to dress up and disguise myself as Bill Gates, but that doesn't make me into Bill Gates does it? I just emulate him.

I use BAT files as well sometimes, but (again) a BAT file is not (necessarily) the same as a DOS program, and running a BAT file on my WinXP computer doesn't mean that DOS suddenly gets installed and I then switch operating system.

[gigemboy]

If DOS is truly dead they why does Microsoft still include command.com in Windows XP?
So if command.com is DOS then you still have it on your computer silly pants.

(Btw, you do have DOS on your computer still, I'm running XP Pro.)

No you dont "silly pants". What you see looks like DOS but it isnt. Its the command interpreter (cmd.exe), that was made to look similar for a reason (to make you think you are still working in DOS, when you actually aren't, which worked in your case )

The command prompt is run from its own window by invoking the Windows XP command interpreter that is provided by the file cmd.exe located in the folder \Windows\System32\. (The old DOS command interpreter is command.com.) If you look in this folder you may also see several files that look suspiciously like some of the old DOS files. They are, however, different 32-bit versions with many new features.

http://commandwindows.com/command1.htm

[iPrank]

Yes. WinMe/2K/XP/2003 doesn't have a 'true' DOS mode.
That's why I always keep a Win98 partition.

[RhinoBull]

When did I scream? The fact that some companies might still run Windows 3.1 doesn't mean that DOS has a place in todays programming world, and that was the question that was asked.

Also that DOS emulators exists doesn't mean squat either, Windows itself can emulate DOS pretty well too. But if you all say that DOS still have a place in todays programming world may I then ask when you last wrote a program for DOS? Writing a BAT file is not the same thing as writing a DOS program, you can run BAT files using Windows command line tool, which means that your running a Windows batch file and not a DOS program.

That some people refers to the command line as DOS doesn't make it DOS, and this was my whole point, you should call things by their right names to avoid confusion.

There's a huge difference between the Windows command line interpreter and DOS. Even when you run Command.com on WinXP it still uses Windows disk operations when you look at the file system, which means that you're not running DOS, you might call it a DOS command line emulator if you wish, but an emulator is not DOS.

I might be able to dress up and disguise myself as Bill Gates, but that doesn't make me into Bill Gates does it? I just emulate him.

I use BAT files as well sometimes, but (again) a BAT file is not (necessarily) the same as a DOS program, and running a BAT file on my WinXP computer doesn't mean that DOS suddenly gets installed and I then switch operating system.

That's so like Joacim: an article when few words could be enough...

[Joacim Andersson]

That's so like Joacim: an article when few words could be enough...

If that was true there wouldn't be 30+ posts in this thread

Besides it looks like everyone here thinks that DOS was equal to command.com which is wrong. Command.com was simply the command line interpreter of DOS, which was the user interface of DOS and not the operating system. You could easily replace command.com with another interpreter in the same way that you can replace the explorer.exe shell in Windows with another shell. Replacing the shell doesn't mean you're not running Windows though.

[szlamany]

This thread has really got some legs!

But I'm still confused...

Either the poll is poorly worded or the replies are simply all over the place.

I thought the thread topic was related to creating a .BAT file to perform system operation tasks - file copies, FTP's - renames - run an .EXE - that type of stuff. That is what CMD (or COMMAND or DOS) means to me. It certainly doesn't bring to mind the old Win 3.1 where you booted to C:\ and were lucky if you had a PCShell-type GUI to work with...

We do a lot of operational tasks with the SQL AGENT - but we always fall back on the agent running a "step" that is actually a .BAT file - since we can get so much more done without requiring a "programmers" mind. I come from a mainframe world (VAX/VMS) where creating BATCH COMMAND file scripts is a large part of your world.

My customers could always ask me to write a "down-and-dirty" VB program to perform a file copy or SHELL and FTP or whatever - but that's not cost effective.

[Joacim Andersson]

I agree that the poll is badly named, and this was my point in the first place. It doesn't really have anything to do with the ShellAndWait code that was posted. Batch files are however an essential tool but before MS released WSH you could only use the old DOS-style BAT files for this purpose or get a third party tool. Today writing a simple VBScript file (or JScript or any other script language supported by the WSH) is a better choice. A BAT file is great if you want to copy a few files or run a command line tool of some sort (like FTP.EXE) but what if you need your batch job to update the Registry or send an e-mail when a certain condition is met? Or maybe you need to run some overnight printing job...

[k1ll3rdr4g0n]

No you dont "silly pants". What you see looks like DOS but it isnt. Its the command interpreter (cmd.exe), that was made to look similar for a reason (to make you think you are still working in DOS, when you actually aren't, which worked in your case )

http://commandwindows.com/command1.htm

The command prompt is run from its own window by invoking the Windows XP command interpreter that is provided by the file cmd.exe located in the folder \Windows\System32\. (The old DOS command interpreter is command.com.) If you look in this folder you may also see several files that look suspiciously like some of the old DOS files. They are, however, different 32-bit versions with many new features.

Read it more carefully, I wasn't talking about cmd.exe the command interperter, I was talking about command.com the DOS prompt. Go back to the old days, if you have a game like Duke Nukem 3D, and exit and especially if you booted from a book disk and had a disk in that didn't have commmand.com (like a normal boot disk would have) it would complain about it not being avaiable. And it wouldn't let you do anything until you told it where it was located.

http://en.wikipedia.org/wiki/Command.com

COMMAND.COM is the name for the default operating system shell (or command line interpreter) for DOS

So its basically both. Or I don't know anymore.
Could we at least agree that command.com is more suited for really old DOS programs? Such as Duke Nukem 3D, Heretic (I can only think of games right now ).

[Joacim Andersson]

Duke Nukem 3D doesn't use Command.com.

[RhinoBull]

Duke Nukem 3D doesn't use Command.com.

But recommended way to play was "pure DOS boot"...

[Joacim Andersson]

But recommended way to play was "pure DOS boot"...

Yes, but that doesn't mean it used command.com. When you run DOS the first thing that is loaded is IO.SYS followed by MSDOS.SYS and last the command line interpreter command.com was loaded. Command.com was however loaded at the very top of the memory area and was allowed to be overwritten by an application that needed that memory. So a DOS application never really used command.com, which was most often unloaded when another program was launched. When you exited that program command.com was loaded again from disk. This was the reason the disk you used to boot the computer with had to be inserted again if it was removed while running another application.

[RhinoBull]

Yes, but that doesn't mean it used command.com. ...

Oh, yes yes yes... It (game's name) just brought some memory back from about 10 years ago so I commented on it...

[MartinLiss]

Does this thread have a point any more?

[Joacim Andersson]

Does this thread have a point any more?

Yeah I think the point now is that DOS games are old . The fact that nobody writes any DOS games anymore is another evidence that DOS is dead . LOL!!!