developer.* Blogs - Run DOS Commands from .NET with Free msDOScommand Class - Comments

printing from DOS software to modern (non-dotmatrix) printers

Guest — Thu, 01 Feb 2007 10:51:32 -0800

Can you help me find out how to print from DOS software to inkjet type modern printers rather than to just the old Epson compatible dot matrix type printers. I have some DOS programs that I use a lot but would like to have the capability of obtaining the Epson fonting on the newer printers.

Thank you for any information or help you can give me.

Bernie Tonroy

Are you using msdosCommand?

Edward G Nilges — Mon, 09 Oct 2006 22:50:53 -0700

That's the free software on this site which handles many of the problems, and comes with documentation about handling other problems.

Here's what I think your problem may be...

Just running shell() in a different thread is NOT the answer.

This is because the new thread is accessing system files through the pseudo-DOS interface completely outside of .Net.

Meanwhile, other .Net threads are doing the same thing.

This creates collisions, possibly deadlocks.

My software at least tries to address the problem that exists when you use a safe-appearing legacy library function like shell() in Visual Basic, which runs well under .Net, but contains "gotchas" both as regards internationalization and here, the system facilities that are issued when you issue a batch command through shell.

The basic problem: when you issue any VB library command that violates thread safety, YOU are thread unsafe and YOUR program will "seem to work" at first, but then crash or hang, usually when you are proudly demonstrating your work to the boss from hell, who would like to fire you.

shell() is completely thread unsafe because in the batch command, it can do ANYTHING. This is an instance of the paradox of computing "power": you are empowered to mess up.

Not only are other threads in your application constantly interacting with the Windows file system, other applications on your system are doing the same.

msdosCommand cannot fully address all these problems. Instead, it provides a primitive framework in which to create the batch file and make sure it runs through to completion.

The contents of the batch file can still be dangerous. They can erase the user's hard disk, for starters.

It looks like you are doing it "your" way, therefore my advice is to do it "my" way.

Download the msdosCommand software, read the documentation, drink the Kool Aid and use the class.

running dos command in vb.net

Thomas — Mon, 09 Oct 2006 07:45:34 -0700

hai Edward i have a doubt like i amtrying to run a batch file in vb.net but its not working ,created a new thread to run this (basically i was using Shell to do tht).Only for the application am running its not working but if i create a new application and try the same its working .any idea why it doesn't work in one and work in the other.Is it that the main thread is restricting other threads not to function properly.after running the application it shows the dos screen but doesn't perform the function properly....please let me know if you have experienced anything similar
Regards
Thomas

Ping away

Edward G Nilges — Wed, 16 Aug 2006 01:29:39 -0700

I wrote msdosCommand because "they" (the suits) expect us to monitor the network in a sort of perverted vigil, watching it all night long. This is silly. You should be able to issue pings and other commands from a monitor, go home and go to bed.

When my wife was suffering from postpartum depression, I had to drag my butt down to Tulsa, Oklahoma, essentially to babysit a network so one suit could say to another that they had a passel of "experts" on the case.

One has better things to do, and msdosCommand was written so you can do them safely, whence its timeout controls and so on.

Check out Dan Read's discussion of error handling and don't stop learning new things.

msdosCommand

Edward G Nilges — Tue, 15 Aug 2006 15:35:19 -0700

Glad you found it. Sure you are not a programmer? I won't be working on new releases, probably, having a number of higher-priority projects to hand. But let me know if you have any specific comments or change requests.

New Version of msdoscommand vb.net

Kerry — Tue, 15 Aug 2006 10:59:09 -0700

Just curious as the comment dates are over a year old. Will there ever be a "new version" or have you moved on to other things?

Thank you for what you have done. I am NOT a programmer. I "cut-n-paste" together samples, examples, and freebies to make my .net code do what I need for monitoring my network. None of it was possible before I found the msdoscommand class.

Thanks.

vb.net help

R.devaraj — Fri, 14 Jul 2006 23:00:45 -0700

Hi sir,

how to run a ms dos batch work file in vb.net code.

ex: if create a .txt fiel by using stream write how to give the print command in dos print. please help me sir.

thanking you

Converting msDOSCommand to Visual Basic Express

Edward G Nilges — Sat, 03 Jun 2006 22:20:49 -0700

msDOSCommand converts to Visual Basic Express easily. VB Express is a free VB.Net but unlike the older Learning editions, more full-featured.

The VB Express compiler, when used to compile the source code of msDOSCommand as downloaded from Developer Dot Star, emits more than a hundred warnings and three errors.

The warnings all have to do with local variables declared, mostly in utilities.vb, but not used, and local variables declared without explicit assignment of a starter value that are then used as reference parameters.

I agree with Microsoft in the latter case that it is poor practice to declare a variable without assigning it and then pass it by reference.

The errors are in one case statement in datatype_() in utilities where a case statement checks an object for number values, and, it is easily fixed: go to datatype_() and find Select Case objValue: change this to Select Case CType(objValue, integer).

New vers with asynch commands will NOT be available in a day or

Edward G Nilges — Wed, 09 Nov 2005 02:41:09 -0800

so. I have gotten sidetracked with some deeper issues.

I will endeavor in future to do a better job of making and keeping committments. My apologies if you were waiting for this new version.

Consider changing the source code yourself if you need this feature.

Again: my apologies.

Thanks, Steve!

Edward G Nilges — Mon, 31 Oct 2005 23:39:25 -0800

Interesting point (that in XP you can redirect stderr). It confirms that MS-DOS still exists, exists in multiple versions, and is being evolved by a group of gnomes and elves at Microsoft.

I see them in my mind's eye, happy and contented at having a secure job but in a corner of the lunchroom muttering darkly about what new features they can sneak in.

Having a permanent job maintaining old software leading to a cozy retirement is for me the road not taken. I was maintaining a compiler but when I ran out of work like an idiot I looked for another job.

I am working on a new version with a script language but this has diverted me into a Garden of Forking Paths in which I'd like to follow up on some issues with the Build Your Own compiler, which will power the script language. I will incorporate stderr redirect.

Great to hear that my code is useful as always.

Justa suggestion

Steve — Mon, 31 Oct 2005 18:03:50 -0800

I really like your work. It is impressive. I made a small change that helped me alot. For example if the command was "net" with no options, the user would get nothing back. It is helpful to get error message. In windows XP you can redirect stderr, unlike previous other Windows OSes. So I modified line 2433 to add the stderr redirection:

strCommands &= " > " & enquote(strOutputId) & " 2<&1"

I have not tested yet but it oughta work. I will probably also add a conditional test to determine the OS so it only applies the 2

Ethical considerations re msdosCommand

Edward G Nilges — Tue, 25 Oct 2005 01:27:57 -0700

The current version can issue pathological commands, as I have said. Moreover, the version I am working on has the capability of behaving as did one of the first computer virus, the unix self-replicating virus that was created by Robert Tappan Morris of Cornell University in 1987.

Now, the source code could itself undertake to scan commands for safety, and it could also limit the number of threads in the new version.

But, this would be a misallocation of my time.

This is because I would code the checks perforce as clearly as any other code, having a prior committment to transparency, therefore, the checks could be removed given that the source is distributed.

The fact is that shell() already exists, and that Microsoft is responsible for the relative lack of security that is created by a failure to acknowledge, properly, the existence of MS-DOS (for example, one searches in vain for a BNF definition of a Windows file that is not violated with impunity by third parties that use "invalid" identifiers to encode and international software, and I had to devise a minimal BNF in fileFinder).

Now, it SOUNDS pretty sleazy to say "not my responsibility". But this is because the fashion today is Zero Tolerance and Personal Responsibility as a sort of pose.

Again: all this code allows you to do is issue shell() safely. It merely replicates some features already available in .Net shell but in a more transparent and OO fashion.

New version will be available in a day or so

Edward G Nilges — Tue, 25 Oct 2005 01:18:17 -0700

I am working on a new version of this code. It allows the user to prefix any MS-DOS command with a semicolon. The effect is that the command is issued with no wait as is the default behavior.

If a semicolon precedes any command in the Command batch of 0..n newline-separated MS-DOS commands, then that command is used to create a new instance of the msdosCommand class running a new thread, running the doCommand() method already available.

I added this because in an MS-DOS command script, I wanted to serenade myself with the French and the Dutch national anthems, which involved calling Windows Media Player as a command line. There is no need to "wait" because of course WMP creates a Windows application.

Of course, the true destination is an msdosCommand class which supports a Turing-complete programming language in its Command script, but this awaits some further work on the fileFinder for finding frigging files in the f*d up environment of Windows!

I will upload the new version of msdosCommand in a day or so with semicolon-prefixed asynchronous commands.

Many thanks to Daniel Read for his assistance on these posts.

Run DOS Commands from .NET with Free msDOScommand Class

Edward G Nilges — Mon, 24 Oct 2005 06:32:46 -0700

The msDOScommand class, written in Visual Basic.Net, executes MS-DOS commands and provides both status and results.