locked
How do I create a C++ command line program that works in MS-DOS mode? RRS feed

  • 질문

  • I wish to use VS2008 to create a C++ program that will run in DOS mode without giving me that message "This program cannot be run in DOS mode."  I've searched VS2008 help and the web, but to no avail.  I'm not talking about a DOS command prompt window running under Windows XP, but a true DOS mode command prompt.

    I've already written the app which reads and writes files, and it works fine in VS2008 debug.  But on the target computer running a flavor of DOS, it barfs with that message.

     

    2011년 8월 31일 수요일 오후 6:13

답변

  • @TCMullet --

    A DOS program and a Win32 app are really very different beasts.  It isn't simply a matter of adding in a bunch of windows stuff. 

    For example a DOS program runs in X86 real mode with segmented memory addressing and the pantheon of memory models.  A Win32 app runs in protected x86 mode with flat memory addressing.  A DOS program accesses the display either via BIOS calls or direct memory writes.  A Win32 program uses an API provided by Windows (Direct hardware access is strictly forbidden in Win32 land).  These examples are just the tip of the iceberg.

    IIRC, Win9x did not have a proper console, so if you are targeting a Win9x DOS box, you might need to try something extremely old.  On the other hand you could write a basic Win32 app that consists of a window and a child edit control that fills that window and just put your output there.  Then your app would work in both Win9x and WinNT based systems.  You would still need to find an old version of Visual Studio to do the work.  I think Visual C++ 6.0 was the last to target Win9x (possibly 7.0 and 7.1 did as well, I am sure that subsequent versions do not).  But lots of people still use Visual C++ 6 (even though that is ancient as well)

    • 답변으로 표시됨 Rob Pan 2011년 9월 7일 수요일 오전 3:08
    2011년 8월 31일 수요일 오후 8:23
  • > Oh, I've always felt it'd be good to write console programs, utilities and such.  I just never had the need since my Clipper '87 days in the early 90s.  And now that I need to, it's unexpectedly very hard. 

    So you don't want to write any DOS program at all. Either google for data recovery software (which usually runs on some version of Linux) or find a data recovery specialist (yes, very costly). Otherwise you risk losing your precious files forever. Imagine that you aren't the first person on the Earth having this problem, some good tools do already exist.  Going for DOS is just another mistake.

    Good luck,

    -- pa

    • 답변으로 표시됨 Rob Pan 2011년 9월 7일 수요일 오전 3:08
    2011년 8월 31일 수요일 오후 11:30
  • I found that DJGCC blew up because, while the comments *said* "C/C++", it turns out it only works with C and I was feeding it C++ code.

    But I did find a solution to the problem of writing C for Dos.  It's an amazing C/C++ compiler with *way* too much documentation (not that that's bad), and it's free:

    WATCOM.   Amazing!  Can compile to DOS-32 bit *or* DOS-16 bit (and others) easily with simple changes to the command line by which you compile and link.  The executable ran on the Dos machine just fine.

    Had other problems, leading me to realize that a C++ program was not the answer.  I'm presently in day 6 of a very long run of "ddrescue" running under a live-CD of Knoppix, a flavor of Linux.  Runs only from the CD and I have the bad drive and a good drive bigger than the bad drive.  Ddrescue smartly identifies pockets of good and bad sectors, and has more success in getting to the bad sectors than other things.  Oh I learned before this that both of my MFTs are sufficiently corrupt that they cannot be rebuilt.  But a solution may possibly work IF I can clone the drive to a good physical drive first.  This is days away, as it can take a LONG time to do it's thing.

    The C++ program was behaving strangely for reasons unknown.  My program was to copy blocks (I picked 512 bytes/block) from a source file to a file on a good drive.  When it hit a bad sector (as detected by "ferror()"), it was to write out binary zeros to the destination instead of aborting.  Each read of the input file was preceded by a "seek", and I'd seek to each new source record after processing the previous.  (The source program worked fine in VS, and on the target machine with a good file.)  The funny thing was that neither the seek nor it's subsequent "read" EVER had an "ferror()" when hitting a known bad spot in the file.  So my zeros logic never was invoked.  BUT, somehow DOS returned zeros as a successfully read buffer starting at a spot in the file where I knew from prior salvage attempts that the good data should stop.  I guess somehow "dos" (NTFSforDOS) was failing to trigger the "ferror()" flag.  Mystery still unsolved.

    Sorry I didn't report this earlier.  I didn't realize there was some kind of deadline for "mark as answer".

    • 답변으로 표시됨 TCmullet 2011년 9월 7일 수요일 오전 3:32
    2011년 9월 7일 수요일 오전 3:32

모든 응답

  • I don't think it's possible to create MS DOS programs with Visual Studio.  You may want to check out something like DJGPP: http://www.delorie.com/djgpp/
    James A. Chappell
    2011년 8월 31일 수요일 오후 6:45
  • 2011년 8월 31일 수요일 오후 6:54
  • Thanks to both of you.  I am starting the very messy process of digging into DJGPP now.  But I am sorely temted to fear that I will run into obstacles that I can't figure out.

    I can't understand why VS would not be capable of doing this.  I thought it was supposed to be able to do EVERYTHING.  (Everything within the realm of MS os's that is, which DOS *is*.  I find all the hundreds of switches in VS2008 (whether for C# or C++) to be very overwhelming.  You'd think with all those zillion options, there'd be some to implement DOS mode programming (or compilation, I should say).

    Btw, while it took me a few days to write my C++ program, I suspect it may take much longer than that to get it up on DJGPP.  We'll see.


    2011년 8월 31일 수요일 오후 7:03
  • Well, keep in mind that DOS predates Win16 (which is also no longer supported).  DOS uses an entirely different memory model than Win32/Win64 and would be a huge maintenance burden in the compiler for a group of users that is probably about 0.1% of the total Visual Studio user base.  I am not particularly surprised that DOS support has been removed.

    I assume you are referring to a true DOS program and not a Win32 console app.  You might try to see if you can find an ancient version of Microsoft C++ compiler (one that predates Visual Studio)

    2011년 8월 31일 수요일 오후 7:07
  • I think so.  My Win32 console app gives the "This program cannot be run in DOS mode" message when run at the DOS prompt of the target system, who's "ver" says "Windows Millennium [Version 4.90.3000]

    I'm almost crying already when I try to decipher even how to download DJGPP.  But as best I can tell, it IS capable of running the app in DOS mode.

    To my way of thinking, all programs should run in DOS mode if excess stuff is left out.  You'd have to ADD stuff to make it work in Windows.  But I'm just a dumb unemployed ex-COBOL programmer; what do *I* know?  (I do know a lot of VS-C# now, though.)

     

    2011년 8월 31일 수요일 오후 7:18
  • You may want to look around for some older versions of Turbo C++ if DJGPP doesn't work for you.
    James A. Chappell
    2011년 8월 31일 수요일 오후 7:43
  • May be Digital Mars compiler will be easier to use: http://www.digitalmars.com/ctg/ctg.html.

    The comparison of compilers for DOS is here:  http://stackoverflow.com/questions/2066863/compiling-a-program-to-run-in-dos-mode

    2011년 8월 31일 수요일 오후 7:55
  • Visual C++ 1.52 can compile 16 bit programs, and is still available to MSDN subscribers. But I'm not sure VC++ 1.52 can run under XP, it is a 18 year old program!

    I'm just curious: what is your "target system" and why do you want to write 16-bit code?

     

    2011년 8월 31일 수요일 오후 8:13
  • Thanks!  I wondered what happened to the Zortech/Symantec tools: http://en.wikipedia.org/wiki/Digital_Mars
    James A. Chappell
    2011년 8월 31일 수요일 오후 8:15
  • One could run an older version of Windows in a VM if 1.52 won't run on XP...
    James A. Chappell
    2011년 8월 31일 수요일 오후 8:16
  • @TCMullet --

    A DOS program and a Win32 app are really very different beasts.  It isn't simply a matter of adding in a bunch of windows stuff. 

    For example a DOS program runs in X86 real mode with segmented memory addressing and the pantheon of memory models.  A Win32 app runs in protected x86 mode with flat memory addressing.  A DOS program accesses the display either via BIOS calls or direct memory writes.  A Win32 program uses an API provided by Windows (Direct hardware access is strictly forbidden in Win32 land).  These examples are just the tip of the iceberg.

    IIRC, Win9x did not have a proper console, so if you are targeting a Win9x DOS box, you might need to try something extremely old.  On the other hand you could write a basic Win32 app that consists of a window and a child edit control that fills that window and just put your output there.  Then your app would work in both Win9x and WinNT based systems.  You would still need to find an old version of Visual Studio to do the work.  I think Visual C++ 6.0 was the last to target Win9x (possibly 7.0 and 7.1 did as well, I am sure that subsequent versions do not).  But lots of people still use Visual C++ 6 (even though that is ancient as well)

    • 답변으로 표시됨 Rob Pan 2011년 9월 7일 수요일 오전 3:08
    2011년 8월 31일 수요일 오후 8:23
  • Pierre,

    I don't want to write 16-bit code.  I want to write whatever it takes to run under DOS.  I'm in the midst of a personal disaster recovery.  I have a very sick (SMART-triggered) 750GB SATA drive with 200GB of big files on it that I greatly desire to copy off.  So far, using NTFS Reader, I've been able to copy many of them.  But for all the files that have bad sectors in the middle of them, the copy process stops at the first bad sector.  I'm writing (or have written) my first C++ program (after taking 1 course in C++ 2 years ago and forgetting it all) to copy each readable block to a target file (on a good drive) and for blocks not readable, substitute binary zeros for the unreadable block. (This will work well for my purposes.)

    I can presently only get to my drives files 2 ways:  (And I just found out the reason is my MFT is corrupted and may not be correctable. Apparently either the original or the mirror is worse.).  NTFS-Reader, which allows me to copy the files as I've described but doesn't allow access to the drive after I exit it.  And NTFS-Boot-disk, which will let me see the files in 8.3 format and copy to and from.  So I embarked on a project to (re)learn enough C++ in VS2008 to write a command line program to run at the Win ME Dos prompt provided by NTFS-Boot-disk.

    I have many GB of data salvagable from the middle of many 2GB files on that bad drive.  The drive is under warranty, but obviously not the data.

    So now you know.   Stupid me for trusting data to this sick drive.

    Oh, I've always felt it'd be good to write console programs, utilities and such.  I just never had the need since my Clipper '87 days in the early 90s.  And now that I need to, it's unexpectedly very hard.  Easier to write a GUI app in C#.  But can't do any of that when I'm stuck w/nothing but a dos prompt to run SOMETHING that might salvage the data.

     

    2011년 8월 31일 수요일 오후 8:27
  • SimonRev,

    Are you saying that if I had VS6, I could create my program??  Can VS6 be installed and run concurrently on a PC that also has VS2008??  If so, I'm in luck, as I do have VS6, which I used for awhile long ago (and numerous PCs ago).  I didn't throw it out, so can I safely install it on my XP machine which also has VS2008?

    2011년 8월 31일 수요일 오후 8:30
  • > Either google for data recovery software (which usually runs on some version of Linux) or find a data recovery specialist (yes, very costly).

    I have no Linux experience (but I realize I might not need much, assuming any Linux recovery software will extract from NTFS).  And specialists are 4 digits, and I have NO money.

    > Otherwise you risk losing your precious files forever.

    I'm willing to lose a small percentage of each file, no matter where in the file the lost piece or pieces are.

    > Imagine that you aren't the first person on the Earth having this problem, some good tools do already exist.

    Yes, and I've already scoured the free ones.

    > Going for DOS is just another mistake.

    It's not my fault that what's out there has a DOS prompt.  And it shouldn't be rocket science to write a dinky little program to do file access.  Heck, while I was driving home, I got to thinking GWBASIC might work.  Obviously it's a DOS program, and I'm not worried about speed.  (The task is mostly I/O bound anyway.)  But I'll give Dev-C++ a try first.  DJGCC blew up on the 1st try of my app, asking me to make a bug report.  But as to your comment, EVERY computer should be allowed to write software for, IMHO.

    I was hoping to hear back from Simon about VC6.  I was starting to install my very old (and very little used) VS6/VC6, when part way thru I searched a bit more, finding evidence that even VC6 can't create DOS mode programs.  Unless further wisdom comes from you kind folks, I'll try Dev, then GW.

    2011년 9월 1일 목요일 오전 2:07
  • No, I said you could use VC6 to write a Win32 program for Win9x and WinNT/XP/etc.  (Specifically, at the time I had no idea what you were trying to accomplish.  If it was merely to output some data, an editbox in a window would suffice and not need a console)

    I suspect, as a previous poster mentioned, it was roughly Microsoft C++ 1.52 was the last time you could write a true DOS program.

     

    2011년 9월 1일 목요일 오후 3:58
  • I found that DJGCC blew up because, while the comments *said* "C/C++", it turns out it only works with C and I was feeding it C++ code.

    But I did find a solution to the problem of writing C for Dos.  It's an amazing C/C++ compiler with *way* too much documentation (not that that's bad), and it's free:

    WATCOM.   Amazing!  Can compile to DOS-32 bit *or* DOS-16 bit (and others) easily with simple changes to the command line by which you compile and link.  The executable ran on the Dos machine just fine.

    Had other problems, leading me to realize that a C++ program was not the answer.  I'm presently in day 6 of a very long run of "ddrescue" running under a live-CD of Knoppix, a flavor of Linux.  Runs only from the CD and I have the bad drive and a good drive bigger than the bad drive.  Ddrescue smartly identifies pockets of good and bad sectors, and has more success in getting to the bad sectors than other things.  Oh I learned before this that both of my MFTs are sufficiently corrupt that they cannot be rebuilt.  But a solution may possibly work IF I can clone the drive to a good physical drive first.  This is days away, as it can take a LONG time to do it's thing.

    The C++ program was behaving strangely for reasons unknown.  My program was to copy blocks (I picked 512 bytes/block) from a source file to a file on a good drive.  When it hit a bad sector (as detected by "ferror()"), it was to write out binary zeros to the destination instead of aborting.  Each read of the input file was preceded by a "seek", and I'd seek to each new source record after processing the previous.  (The source program worked fine in VS, and on the target machine with a good file.)  The funny thing was that neither the seek nor it's subsequent "read" EVER had an "ferror()" when hitting a known bad spot in the file.  So my zeros logic never was invoked.  BUT, somehow DOS returned zeros as a successfully read buffer starting at a spot in the file where I knew from prior salvage attempts that the good data should stop.  I guess somehow "dos" (NTFSforDOS) was failing to trigger the "ferror()" flag.  Mystery still unsolved.

    Sorry I didn't report this earlier.  I didn't realize there was some kind of deadline for "mark as answer".

    • 답변으로 표시됨 TCmullet 2011년 9월 7일 수요일 오전 3:32
    2011년 9월 7일 수요일 오전 3:32