DOS, create pipe for stdin/stdout of command.com(or 4dos.com) in C or Batch? The 2019 Stack Overflow Developer Survey Results Are InDOS, create pipe for stdin/stdout of command.com(or 4dos.com) in C or Batch?How does the command.com shell work with MS-DOS?VT52 emulation for MS-DOS?Does ancient UNIX create a new shell process for each terminal?Which tools were used to create the C language?What are these tiny TSRs doing?An old DOS application that allowed to create cards, posters, invitations, etcHow do I create a boot menu to select between Windows and DOS?How do I compile C code with the IRIX X Window System?Gotek drives for MS-DOS (plus few more constraints)Alternatives for TurboVision on DOS

Where to refill my bottle in India?

What does Linus Torvalds mean when he says that Git "never ever" tracks a file?

How to save as into a customized destination on macOS?

Why is the maximum length of OpenWrt’s root password 8 characters?

Is flight data recorder erased after every flight?

Why didn't the Event Horizon Telescope team mention Sagittarius A*?

Worn-tile Scrabble

Can you compress metal and what would be the consequences?

Delete all lines which don't have n characters before delimiter

The difference between dialogue marks

Falsification in Math vs Science

Button changing it's text & action. Good or terrible?

Which Sci-Fi work first showed weapon of galactic-scale mass destruction?

"as much details as you can remember"

Is bread bad for ducks?

Apparent duplicates between Haynes service instructions and MOT

Why do we hear so much about the Trump administration deciding to impose and then remove tariffs?

Are there any other methods to apply to solving simultaneous equations?

For what reasons would an animal species NOT cross a *horizontal* land bridge?

Is this app Icon Browser Safe/Legit?

Deal with toxic manager when you can't quit

What could be the right powersource for 15 seconds lifespan disposable giant chainsaw?

Origin of "cooter" meaning "vagina"

What did it mean to "align" a radio?



DOS, create pipe for stdin/stdout of command.com(or 4dos.com) in C or Batch?



The 2019 Stack Overflow Developer Survey Results Are InDOS, create pipe for stdin/stdout of command.com(or 4dos.com) in C or Batch?How does the command.com shell work with MS-DOS?VT52 emulation for MS-DOS?Does ancient UNIX create a new shell process for each terminal?Which tools were used to create the C language?What are these tiny TSRs doing?An old DOS application that allowed to create cards, posters, invitations, etcHow do I create a boot menu to select between Windows and DOS?How do I compile C code with the IRIX X Window System?Gotek drives for MS-DOS (plus few more constraints)Alternatives for TurboVision on DOS










9















I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?



For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.



Can anyone tell me how to to this? Preferably in C or Batch.



Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?










share|improve this question









New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

    – RichF
    Apr 7 at 12:48











  • I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

    – RichF
    Apr 7 at 13:13












  • One way to circumvent this, for the skinning part at least, may be the use of a device driver.

    – Raffzahn
    Apr 7 at 14:11






  • 1





    @RichF PowerShell is certainly not POSIX-compatible in any way.

    – Michael Homer
    Apr 7 at 18:44











  • @MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

    – RichF
    Apr 7 at 19:46
















9















I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?



For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.



Can anyone tell me how to to this? Preferably in C or Batch.



Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?










share|improve this question









New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

    – RichF
    Apr 7 at 12:48











  • I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

    – RichF
    Apr 7 at 13:13












  • One way to circumvent this, for the skinning part at least, may be the use of a device driver.

    – Raffzahn
    Apr 7 at 14:11






  • 1





    @RichF PowerShell is certainly not POSIX-compatible in any way.

    – Michael Homer
    Apr 7 at 18:44











  • @MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

    – RichF
    Apr 7 at 19:46














9












9








9


1






I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?



For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.



Can anyone tell me how to to this? Preferably in C or Batch.



Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?










share|improve this question









New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?



For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.



Can anyone tell me how to to this? Preferably in C or Batch.



Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?







ms-dos c shell






share|improve this question









New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Apr 7 at 9:12







Dacobi













New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Apr 7 at 9:04









DacobiDacobi

704




704




New contributor




Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Dacobi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

    – RichF
    Apr 7 at 12:48











  • I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

    – RichF
    Apr 7 at 13:13












  • One way to circumvent this, for the skinning part at least, may be the use of a device driver.

    – Raffzahn
    Apr 7 at 14:11






  • 1





    @RichF PowerShell is certainly not POSIX-compatible in any way.

    – Michael Homer
    Apr 7 at 18:44











  • @MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

    – RichF
    Apr 7 at 19:46


















  • Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

    – RichF
    Apr 7 at 12:48











  • I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

    – RichF
    Apr 7 at 13:13












  • One way to circumvent this, for the skinning part at least, may be the use of a device driver.

    – Raffzahn
    Apr 7 at 14:11






  • 1





    @RichF PowerShell is certainly not POSIX-compatible in any way.

    – Michael Homer
    Apr 7 at 18:44











  • @MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

    – RichF
    Apr 7 at 19:46

















Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

– RichF
Apr 7 at 12:48





Are you aware of the Cygwin project ( cygwin.com ) ? It provides Windows the infrastructure compile and run many GNU programs. Included is a terminal program which has many POSIX features. See also: stackoverflow.com/questions/12468913

– RichF
Apr 7 at 12:48













I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

– RichF
Apr 7 at 13:13






I know you are working on a retro project, but if working on a modern Windows system there is powershell.exe. I believe it is fully POSIX compatible and comes with the OS. It is obviously not a retro tool, though.

– RichF
Apr 7 at 13:13














One way to circumvent this, for the skinning part at least, may be the use of a device driver.

– Raffzahn
Apr 7 at 14:11





One way to circumvent this, for the skinning part at least, may be the use of a device driver.

– Raffzahn
Apr 7 at 14:11




1




1





@RichF PowerShell is certainly not POSIX-compatible in any way.

– Michael Homer
Apr 7 at 18:44





@RichF PowerShell is certainly not POSIX-compatible in any way.

– Michael Homer
Apr 7 at 18:44













@MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

– RichF
Apr 7 at 19:46






@MichaelHomer Sorry. I should have been suspicious of the wording at en.wikipedia.org/wiki/PowerShell It says, "PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2 Korn shell." I've never actually used it. Thank you for correction. // They have the Command Prompt to be "DOS"; why not make the other shell POSIX?

– RichF
Apr 7 at 19:46











3 Answers
3






active

oldest

votes


















15














MS-DOS doesn't support pipes like Unix does - It does support input and output redirection through its command line processor COMMAND.COM, but that's a different thing.



If you're fine with pure I/O redirection, you should be able to do that using the system() function in C, by providing a command line that has the output redirection (<, >, |) included. Opposed to Unix, you will, however, not be able to have the "piped together" commands run in parallel, but rather only sequentially (which isn't quite what you need to scrape the console of an interactive program) - MS-DOS is not a multitasking system.






share|improve this answer

























  • Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

    – Dacobi
    Apr 7 at 9:45






  • 3





    Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

    – tofro
    Apr 7 at 10:17







  • 1





    @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

    – Raffzahn
    Apr 7 at 13:25






  • 1





    @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

    – tofro
    Apr 7 at 18:40






  • 2





    @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

    – DarkDust
    Apr 7 at 18:44


















15














It seams as if you imply that DOS is kind of an unixoide OS, which it isn't. While Microsoft's goal with MS-DOS 2.0 was to move it toward Unix like operations, for compatibility with Xenix, it never went all the way. Not in internal workings nor API or shell. MS-DOS is a single user, single program OS - with a few 'handmade' exceptions like TSR.




For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.




UNISTD is a POSIX definition. DOS isn't a POSIX system. POSIX definitions where made years after DOS got unix alike features.



DOS only implements STDIN/OUT/ERR. They are made as simple file handles (0,1,2) to be read from/writen to and inherited from the parent program.




Can anyone tell me how to to this? Preferably in C or Batch.




Just use redirection one the command line in the usual way via </|/>




Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




You might get a hard time, as DOS can only run a single program at a time. Without two concurrent processes it's just not possible to transfer data between them.



chaining two programs in



Workings of Rediection in DOS



DOS implements pipeing (redirection to a program) as an application of redirection to files.



When pipeing is used, all output of the first program to STDOUT gets written into a temporary file until the program terminates. Then the next program gets started (after the first is unloaded) and the file written is assigned to STDIN. Then the program terminates, the (input) File gets deleted.



In other words a command line like



TREE C: /F | FIND /I ".COM" | SORT 


to display all .COM files with their path on drive C works in sequential steps like this:



TREE C: /F >tempfile1
FIND /I ".COM" <tempfile1 >tempfile2
DEL tempfile1
SORT <tempfile2
DEL tempfile2


From a user perspective the result is the same, but inenr workings are complete different (*1)



So unless you spread your programs across multiple DOS machines, you can't come close to Unix behaviour (*2).





I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?




See, that's the true lesson of retrocomputing: these old machines and OSes were not the same as today, just in small, slow and with blocky graphics, they where different. And not just between today and back then, but as well between different manufactures and even machines. Backporting ideas isn't about finding the same function, but to work from a complete different angle.



Discovering unknown space with different laws of physic :))




Now, having said all of this and taking the assumption of adding bells and whistles to STDOUT), a clean way to do this would be writing a character driver and assign them as STDIN/OUT when starting command.com. If the driver is (for example) named skinner.dev and the resulting device would be SKINNER, then config.sys needs to contain these two lines (*3):



DEVICE=C:DRIVERSKINNER.DEV
SHELL=C:COMMAND.COM SKINNER


And from there on, all output to STDOUT is delivered thru your driver - unless redirected that is. Now you may add any kind of framing skins or whatsoever. Keep in mind that the application might not be aware of and for example still assume a 24x80 screen, even if you took some characters off for a beautiful frame. Similar any output bypassing STDOUT, like when using BIOS calls or direkt screen manipulation, may show up at the wrong place (*4). Last but not least, every program opening CON on its own will as well bypass your driver.



A few points to think about may be:



  • Don't forget to make the driver as well handling read requests, as Command.Com requires both ways to go thru the same device.


  • You may as well try to replace the build-in CON driver(*5), this means setting the CON bit in the device attributes word as well as replacing/capturing INT 29h, as DOS does handle CON a bit different. (*6)


  • Adding I/O-Control support would support a clean interface to set the workings during runtime (changing colours or whatsoever it does) with a configuration command supplied by you.


  • Do your users a favour and use Assembly - at least for the driver.


Device drivers can be a lot of fun and are usually way less complicated to write then people tend to assume.



Caveat: Some mechanics only work with DOS 3.1 and higher even though already defined before. This goes especially for monitoring open/close calls.




*1 - Now, when devices are used as targets of a redirection, access is immediate and concurrent. Just they can only be source or destination.



*2 - And even then you may need some file server allowing read while write and plunge in a zillion FLUSH calls to make each output seen.



*3 - For test purpose it may be more appropriate to only load the driver and use redirected STDIN/OUT only via a sub-shell.



*4 - Some of this may be captured by the driver due manipulation of BIOS data and alike - but that will as well lead to a slow creep into machine and OS dependence while at the same time bloating code ever more.



*5 - This would remove some of the possible ways to screw up things for child processes in complex scenarios involving sub-shells as well as redirections with the explicit use of CON. On the down side, you'd have to rewrite all of it's functionality - hopefully compatible with ANSI.SYS which already is one.



*6 - Which BTW would be the better way (when going this route) - get the source for some ANSI.SYS compatible driver like NANSI.SYS and tweek it to support your additional functionality - more work than writing your own, but for sure a great drop in by naming it ANSI.SYS and copying it onto any machine available - not other change needed.






share|improve this answer
































    0















    Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




    If are experienced in assembly language, you may do the following:



    You can run the "Skin" program and replace the int 21h vector by your own one. In your own vector you process all int 21h requests that are related to the console.



    If some function is not handled by your handler, you use a jmp far instruction to jump to the original interrupt handler. Many DOS device drivers used this method to add additional functionality to a DOS or BIOS interrupt.



    You may also call the original int 21h interrupt using pushf followed by call far to the original handler's address.



    In addition to functions accessing the console, you would have to handle dup, dup2 and close in your int 21h handler to track which file handles correspond to the console.



    Unfortunately, many programs directly access BIOS interrupts int 10h (screen) or int 16h (keyboard). To support such programs, you would have to do the same with these two interrupt handlers.



    There were also a lot of programs directly accessing the hardware (e.g. the screen memory at 0B8000h). Unfortunately, before the 80386 there was no method to "skin" such programs. This is why there was no console window in Windows 3.x running in 286 mode but you could only run MS-DOS programs in full screen mode.



    (And the method used by 32-bit OSs is anything but easy to implement.)






    share|improve this answer























      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "648"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      noCode: true, onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );






      Dacobi is a new contributor. Be nice, and check out our Code of Conduct.









      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9609%2fdos-create-pipe-for-stdin-stdout-of-command-comor-4dos-com-in-c-or-batch%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      15














      MS-DOS doesn't support pipes like Unix does - It does support input and output redirection through its command line processor COMMAND.COM, but that's a different thing.



      If you're fine with pure I/O redirection, you should be able to do that using the system() function in C, by providing a command line that has the output redirection (<, >, |) included. Opposed to Unix, you will, however, not be able to have the "piped together" commands run in parallel, but rather only sequentially (which isn't quite what you need to scrape the console of an interactive program) - MS-DOS is not a multitasking system.






      share|improve this answer

























      • Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

        – Dacobi
        Apr 7 at 9:45






      • 3





        Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

        – tofro
        Apr 7 at 10:17







      • 1





        @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

        – Raffzahn
        Apr 7 at 13:25






      • 1





        @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

        – tofro
        Apr 7 at 18:40






      • 2





        @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

        – DarkDust
        Apr 7 at 18:44















      15














      MS-DOS doesn't support pipes like Unix does - It does support input and output redirection through its command line processor COMMAND.COM, but that's a different thing.



      If you're fine with pure I/O redirection, you should be able to do that using the system() function in C, by providing a command line that has the output redirection (<, >, |) included. Opposed to Unix, you will, however, not be able to have the "piped together" commands run in parallel, but rather only sequentially (which isn't quite what you need to scrape the console of an interactive program) - MS-DOS is not a multitasking system.






      share|improve this answer

























      • Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

        – Dacobi
        Apr 7 at 9:45






      • 3





        Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

        – tofro
        Apr 7 at 10:17







      • 1





        @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

        – Raffzahn
        Apr 7 at 13:25






      • 1





        @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

        – tofro
        Apr 7 at 18:40






      • 2





        @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

        – DarkDust
        Apr 7 at 18:44













      15












      15








      15







      MS-DOS doesn't support pipes like Unix does - It does support input and output redirection through its command line processor COMMAND.COM, but that's a different thing.



      If you're fine with pure I/O redirection, you should be able to do that using the system() function in C, by providing a command line that has the output redirection (<, >, |) included. Opposed to Unix, you will, however, not be able to have the "piped together" commands run in parallel, but rather only sequentially (which isn't quite what you need to scrape the console of an interactive program) - MS-DOS is not a multitasking system.






      share|improve this answer















      MS-DOS doesn't support pipes like Unix does - It does support input and output redirection through its command line processor COMMAND.COM, but that's a different thing.



      If you're fine with pure I/O redirection, you should be able to do that using the system() function in C, by providing a command line that has the output redirection (<, >, |) included. Opposed to Unix, you will, however, not be able to have the "piped together" commands run in parallel, but rather only sequentially (which isn't quite what you need to scrape the console of an interactive program) - MS-DOS is not a multitasking system.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Apr 7 at 10:44

























      answered Apr 7 at 9:18









      tofrotofro

      16.6k33493




      16.6k33493












      • Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

        – Dacobi
        Apr 7 at 9:45






      • 3





        Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

        – tofro
        Apr 7 at 10:17







      • 1





        @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

        – Raffzahn
        Apr 7 at 13:25






      • 1





        @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

        – tofro
        Apr 7 at 18:40






      • 2





        @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

        – DarkDust
        Apr 7 at 18:44

















      • Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

        – Dacobi
        Apr 7 at 9:45






      • 3





        Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

        – tofro
        Apr 7 at 10:17







      • 1





        @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

        – Raffzahn
        Apr 7 at 13:25






      • 1





        @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

        – tofro
        Apr 7 at 18:40






      • 2





        @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

        – DarkDust
        Apr 7 at 18:44
















      Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

      – Dacobi
      Apr 7 at 9:45





      Ok. The reason I asked was that I just had a long conversation with a guy on another forum, who said that people used to make CLI overlays to command.com, etc back in the day. But this doesn't seem possible with what you just said.

      – Dacobi
      Apr 7 at 9:45




      3




      3





      Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

      – tofro
      Apr 7 at 10:17






      Well, you can, with using pure I/O redirection and quite a bit of ado (and people really did that): COMMAND.COM is just (nearly) a program like everything else in MS-DOS. If you do a system ("COMMAND.COM DIR>C:TMPDIR.TXT") and later parse dir.txt, you might be able to achieve what you are looking for. But you obviously need to implement any command you want to support by a separate system call. And that obviously won't work well with interactive commands.

      – tofro
      Apr 7 at 10:17





      1




      1





      @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

      – Raffzahn
      Apr 7 at 13:25





      @Dacobi Since programms can have child programs, these can act as new shell (CLI) for the user and thus replacing Command.com for most parts (or even be started instead) - still, they can't change the nature of the OS. So what's possible or not will be different from what you'd know from a Unix-alike system. Starting with the problem that DOS programs often not write their output STDOUT, but use means of BIOS or direct screen manipulation.

      – Raffzahn
      Apr 7 at 13:25




      1




      1





      @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

      – tofro
      Apr 7 at 18:40





      @DarkDust yes. But TSRs wouldn’t exactly fit the concept of pipes. TSRs didn’t have OS mechanisms to communicate to applications

      – tofro
      Apr 7 at 18:40




      2




      2





      @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

      – DarkDust
      Apr 7 at 18:44





      @tofro: You're right, but I was referring to OPs remark about some guy saying "people used to make CLI overlays to command.com" .

      – DarkDust
      Apr 7 at 18:44











      15














      It seams as if you imply that DOS is kind of an unixoide OS, which it isn't. While Microsoft's goal with MS-DOS 2.0 was to move it toward Unix like operations, for compatibility with Xenix, it never went all the way. Not in internal workings nor API or shell. MS-DOS is a single user, single program OS - with a few 'handmade' exceptions like TSR.




      For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.




      UNISTD is a POSIX definition. DOS isn't a POSIX system. POSIX definitions where made years after DOS got unix alike features.



      DOS only implements STDIN/OUT/ERR. They are made as simple file handles (0,1,2) to be read from/writen to and inherited from the parent program.




      Can anyone tell me how to to this? Preferably in C or Batch.




      Just use redirection one the command line in the usual way via </|/>




      Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




      You might get a hard time, as DOS can only run a single program at a time. Without two concurrent processes it's just not possible to transfer data between them.



      chaining two programs in



      Workings of Rediection in DOS



      DOS implements pipeing (redirection to a program) as an application of redirection to files.



      When pipeing is used, all output of the first program to STDOUT gets written into a temporary file until the program terminates. Then the next program gets started (after the first is unloaded) and the file written is assigned to STDIN. Then the program terminates, the (input) File gets deleted.



      In other words a command line like



      TREE C: /F | FIND /I ".COM" | SORT 


      to display all .COM files with their path on drive C works in sequential steps like this:



      TREE C: /F >tempfile1
      FIND /I ".COM" <tempfile1 >tempfile2
      DEL tempfile1
      SORT <tempfile2
      DEL tempfile2


      From a user perspective the result is the same, but inenr workings are complete different (*1)



      So unless you spread your programs across multiple DOS machines, you can't come close to Unix behaviour (*2).





      I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?




      See, that's the true lesson of retrocomputing: these old machines and OSes were not the same as today, just in small, slow and with blocky graphics, they where different. And not just between today and back then, but as well between different manufactures and even machines. Backporting ideas isn't about finding the same function, but to work from a complete different angle.



      Discovering unknown space with different laws of physic :))




      Now, having said all of this and taking the assumption of adding bells and whistles to STDOUT), a clean way to do this would be writing a character driver and assign them as STDIN/OUT when starting command.com. If the driver is (for example) named skinner.dev and the resulting device would be SKINNER, then config.sys needs to contain these two lines (*3):



      DEVICE=C:DRIVERSKINNER.DEV
      SHELL=C:COMMAND.COM SKINNER


      And from there on, all output to STDOUT is delivered thru your driver - unless redirected that is. Now you may add any kind of framing skins or whatsoever. Keep in mind that the application might not be aware of and for example still assume a 24x80 screen, even if you took some characters off for a beautiful frame. Similar any output bypassing STDOUT, like when using BIOS calls or direkt screen manipulation, may show up at the wrong place (*4). Last but not least, every program opening CON on its own will as well bypass your driver.



      A few points to think about may be:



      • Don't forget to make the driver as well handling read requests, as Command.Com requires both ways to go thru the same device.


      • You may as well try to replace the build-in CON driver(*5), this means setting the CON bit in the device attributes word as well as replacing/capturing INT 29h, as DOS does handle CON a bit different. (*6)


      • Adding I/O-Control support would support a clean interface to set the workings during runtime (changing colours or whatsoever it does) with a configuration command supplied by you.


      • Do your users a favour and use Assembly - at least for the driver.


      Device drivers can be a lot of fun and are usually way less complicated to write then people tend to assume.



      Caveat: Some mechanics only work with DOS 3.1 and higher even though already defined before. This goes especially for monitoring open/close calls.




      *1 - Now, when devices are used as targets of a redirection, access is immediate and concurrent. Just they can only be source or destination.



      *2 - And even then you may need some file server allowing read while write and plunge in a zillion FLUSH calls to make each output seen.



      *3 - For test purpose it may be more appropriate to only load the driver and use redirected STDIN/OUT only via a sub-shell.



      *4 - Some of this may be captured by the driver due manipulation of BIOS data and alike - but that will as well lead to a slow creep into machine and OS dependence while at the same time bloating code ever more.



      *5 - This would remove some of the possible ways to screw up things for child processes in complex scenarios involving sub-shells as well as redirections with the explicit use of CON. On the down side, you'd have to rewrite all of it's functionality - hopefully compatible with ANSI.SYS which already is one.



      *6 - Which BTW would be the better way (when going this route) - get the source for some ANSI.SYS compatible driver like NANSI.SYS and tweek it to support your additional functionality - more work than writing your own, but for sure a great drop in by naming it ANSI.SYS and copying it onto any machine available - not other change needed.






      share|improve this answer





























        15














        It seams as if you imply that DOS is kind of an unixoide OS, which it isn't. While Microsoft's goal with MS-DOS 2.0 was to move it toward Unix like operations, for compatibility with Xenix, it never went all the way. Not in internal workings nor API or shell. MS-DOS is a single user, single program OS - with a few 'handmade' exceptions like TSR.




        For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.




        UNISTD is a POSIX definition. DOS isn't a POSIX system. POSIX definitions where made years after DOS got unix alike features.



        DOS only implements STDIN/OUT/ERR. They are made as simple file handles (0,1,2) to be read from/writen to and inherited from the parent program.




        Can anyone tell me how to to this? Preferably in C or Batch.




        Just use redirection one the command line in the usual way via </|/>




        Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




        You might get a hard time, as DOS can only run a single program at a time. Without two concurrent processes it's just not possible to transfer data between them.



        chaining two programs in



        Workings of Rediection in DOS



        DOS implements pipeing (redirection to a program) as an application of redirection to files.



        When pipeing is used, all output of the first program to STDOUT gets written into a temporary file until the program terminates. Then the next program gets started (after the first is unloaded) and the file written is assigned to STDIN. Then the program terminates, the (input) File gets deleted.



        In other words a command line like



        TREE C: /F | FIND /I ".COM" | SORT 


        to display all .COM files with their path on drive C works in sequential steps like this:



        TREE C: /F >tempfile1
        FIND /I ".COM" <tempfile1 >tempfile2
        DEL tempfile1
        SORT <tempfile2
        DEL tempfile2


        From a user perspective the result is the same, but inenr workings are complete different (*1)



        So unless you spread your programs across multiple DOS machines, you can't come close to Unix behaviour (*2).





        I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?




        See, that's the true lesson of retrocomputing: these old machines and OSes were not the same as today, just in small, slow and with blocky graphics, they where different. And not just between today and back then, but as well between different manufactures and even machines. Backporting ideas isn't about finding the same function, but to work from a complete different angle.



        Discovering unknown space with different laws of physic :))




        Now, having said all of this and taking the assumption of adding bells and whistles to STDOUT), a clean way to do this would be writing a character driver and assign them as STDIN/OUT when starting command.com. If the driver is (for example) named skinner.dev and the resulting device would be SKINNER, then config.sys needs to contain these two lines (*3):



        DEVICE=C:DRIVERSKINNER.DEV
        SHELL=C:COMMAND.COM SKINNER


        And from there on, all output to STDOUT is delivered thru your driver - unless redirected that is. Now you may add any kind of framing skins or whatsoever. Keep in mind that the application might not be aware of and for example still assume a 24x80 screen, even if you took some characters off for a beautiful frame. Similar any output bypassing STDOUT, like when using BIOS calls or direkt screen manipulation, may show up at the wrong place (*4). Last but not least, every program opening CON on its own will as well bypass your driver.



        A few points to think about may be:



        • Don't forget to make the driver as well handling read requests, as Command.Com requires both ways to go thru the same device.


        • You may as well try to replace the build-in CON driver(*5), this means setting the CON bit in the device attributes word as well as replacing/capturing INT 29h, as DOS does handle CON a bit different. (*6)


        • Adding I/O-Control support would support a clean interface to set the workings during runtime (changing colours or whatsoever it does) with a configuration command supplied by you.


        • Do your users a favour and use Assembly - at least for the driver.


        Device drivers can be a lot of fun and are usually way less complicated to write then people tend to assume.



        Caveat: Some mechanics only work with DOS 3.1 and higher even though already defined before. This goes especially for monitoring open/close calls.




        *1 - Now, when devices are used as targets of a redirection, access is immediate and concurrent. Just they can only be source or destination.



        *2 - And even then you may need some file server allowing read while write and plunge in a zillion FLUSH calls to make each output seen.



        *3 - For test purpose it may be more appropriate to only load the driver and use redirected STDIN/OUT only via a sub-shell.



        *4 - Some of this may be captured by the driver due manipulation of BIOS data and alike - but that will as well lead to a slow creep into machine and OS dependence while at the same time bloating code ever more.



        *5 - This would remove some of the possible ways to screw up things for child processes in complex scenarios involving sub-shells as well as redirections with the explicit use of CON. On the down side, you'd have to rewrite all of it's functionality - hopefully compatible with ANSI.SYS which already is one.



        *6 - Which BTW would be the better way (when going this route) - get the source for some ANSI.SYS compatible driver like NANSI.SYS and tweek it to support your additional functionality - more work than writing your own, but for sure a great drop in by naming it ANSI.SYS and copying it onto any machine available - not other change needed.






        share|improve this answer



























          15












          15








          15







          It seams as if you imply that DOS is kind of an unixoide OS, which it isn't. While Microsoft's goal with MS-DOS 2.0 was to move it toward Unix like operations, for compatibility with Xenix, it never went all the way. Not in internal workings nor API or shell. MS-DOS is a single user, single program OS - with a few 'handmade' exceptions like TSR.




          For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.




          UNISTD is a POSIX definition. DOS isn't a POSIX system. POSIX definitions where made years after DOS got unix alike features.



          DOS only implements STDIN/OUT/ERR. They are made as simple file handles (0,1,2) to be read from/writen to and inherited from the parent program.




          Can anyone tell me how to to this? Preferably in C or Batch.




          Just use redirection one the command line in the usual way via </|/>




          Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




          You might get a hard time, as DOS can only run a single program at a time. Without two concurrent processes it's just not possible to transfer data between them.



          chaining two programs in



          Workings of Rediection in DOS



          DOS implements pipeing (redirection to a program) as an application of redirection to files.



          When pipeing is used, all output of the first program to STDOUT gets written into a temporary file until the program terminates. Then the next program gets started (after the first is unloaded) and the file written is assigned to STDIN. Then the program terminates, the (input) File gets deleted.



          In other words a command line like



          TREE C: /F | FIND /I ".COM" | SORT 


          to display all .COM files with their path on drive C works in sequential steps like this:



          TREE C: /F >tempfile1
          FIND /I ".COM" <tempfile1 >tempfile2
          DEL tempfile1
          SORT <tempfile2
          DEL tempfile2


          From a user perspective the result is the same, but inenr workings are complete different (*1)



          So unless you spread your programs across multiple DOS machines, you can't come close to Unix behaviour (*2).





          I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?




          See, that's the true lesson of retrocomputing: these old machines and OSes were not the same as today, just in small, slow and with blocky graphics, they where different. And not just between today and back then, but as well between different manufactures and even machines. Backporting ideas isn't about finding the same function, but to work from a complete different angle.



          Discovering unknown space with different laws of physic :))




          Now, having said all of this and taking the assumption of adding bells and whistles to STDOUT), a clean way to do this would be writing a character driver and assign them as STDIN/OUT when starting command.com. If the driver is (for example) named skinner.dev and the resulting device would be SKINNER, then config.sys needs to contain these two lines (*3):



          DEVICE=C:DRIVERSKINNER.DEV
          SHELL=C:COMMAND.COM SKINNER


          And from there on, all output to STDOUT is delivered thru your driver - unless redirected that is. Now you may add any kind of framing skins or whatsoever. Keep in mind that the application might not be aware of and for example still assume a 24x80 screen, even if you took some characters off for a beautiful frame. Similar any output bypassing STDOUT, like when using BIOS calls or direkt screen manipulation, may show up at the wrong place (*4). Last but not least, every program opening CON on its own will as well bypass your driver.



          A few points to think about may be:



          • Don't forget to make the driver as well handling read requests, as Command.Com requires both ways to go thru the same device.


          • You may as well try to replace the build-in CON driver(*5), this means setting the CON bit in the device attributes word as well as replacing/capturing INT 29h, as DOS does handle CON a bit different. (*6)


          • Adding I/O-Control support would support a clean interface to set the workings during runtime (changing colours or whatsoever it does) with a configuration command supplied by you.


          • Do your users a favour and use Assembly - at least for the driver.


          Device drivers can be a lot of fun and are usually way less complicated to write then people tend to assume.



          Caveat: Some mechanics only work with DOS 3.1 and higher even though already defined before. This goes especially for monitoring open/close calls.




          *1 - Now, when devices are used as targets of a redirection, access is immediate and concurrent. Just they can only be source or destination.



          *2 - And even then you may need some file server allowing read while write and plunge in a zillion FLUSH calls to make each output seen.



          *3 - For test purpose it may be more appropriate to only load the driver and use redirected STDIN/OUT only via a sub-shell.



          *4 - Some of this may be captured by the driver due manipulation of BIOS data and alike - but that will as well lead to a slow creep into machine and OS dependence while at the same time bloating code ever more.



          *5 - This would remove some of the possible ways to screw up things for child processes in complex scenarios involving sub-shells as well as redirections with the explicit use of CON. On the down side, you'd have to rewrite all of it's functionality - hopefully compatible with ANSI.SYS which already is one.



          *6 - Which BTW would be the better way (when going this route) - get the source for some ANSI.SYS compatible driver like NANSI.SYS and tweek it to support your additional functionality - more work than writing your own, but for sure a great drop in by naming it ANSI.SYS and copying it onto any machine available - not other change needed.






          share|improve this answer















          It seams as if you imply that DOS is kind of an unixoide OS, which it isn't. While Microsoft's goal with MS-DOS 2.0 was to move it toward Unix like operations, for compatibility with Xenix, it never went all the way. Not in internal workings nor API or shell. MS-DOS is a single user, single program OS - with a few 'handmade' exceptions like TSR.




          For instance the pipe() command from unistd.h isn't present in BorlandC, which I'm using.




          UNISTD is a POSIX definition. DOS isn't a POSIX system. POSIX definitions where made years after DOS got unix alike features.



          DOS only implements STDIN/OUT/ERR. They are made as simple file handles (0,1,2) to be read from/writen to and inherited from the parent program.




          Can anyone tell me how to to this? Preferably in C or Batch.




          Just use redirection one the command line in the usual way via </|/>




          Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




          You might get a hard time, as DOS can only run a single program at a time. Without two concurrent processes it's just not possible to transfer data between them.



          chaining two programs in



          Workings of Rediection in DOS



          DOS implements pipeing (redirection to a program) as an application of redirection to files.



          When pipeing is used, all output of the first program to STDOUT gets written into a temporary file until the program terminates. Then the next program gets started (after the first is unloaded) and the file written is assigned to STDIN. Then the program terminates, the (input) File gets deleted.



          In other words a command line like



          TREE C: /F | FIND /I ".COM" | SORT 


          to display all .COM files with their path on drive C works in sequential steps like this:



          TREE C: /F >tempfile1
          FIND /I ".COM" <tempfile1 >tempfile2
          DEL tempfile1
          SORT <tempfile2
          DEL tempfile2


          From a user perspective the result is the same, but inenr workings are complete different (*1)



          So unless you spread your programs across multiple DOS machines, you can't come close to Unix behaviour (*2).





          I'm working on a retro project and was trying to create a pipe of stdin/out/err in DOS, but I can't find any functions to to this?




          See, that's the true lesson of retrocomputing: these old machines and OSes were not the same as today, just in small, slow and with blocky graphics, they where different. And not just between today and back then, but as well between different manufactures and even machines. Backporting ideas isn't about finding the same function, but to work from a complete different angle.



          Discovering unknown space with different laws of physic :))




          Now, having said all of this and taking the assumption of adding bells and whistles to STDOUT), a clean way to do this would be writing a character driver and assign them as STDIN/OUT when starting command.com. If the driver is (for example) named skinner.dev and the resulting device would be SKINNER, then config.sys needs to contain these two lines (*3):



          DEVICE=C:DRIVERSKINNER.DEV
          SHELL=C:COMMAND.COM SKINNER


          And from there on, all output to STDOUT is delivered thru your driver - unless redirected that is. Now you may add any kind of framing skins or whatsoever. Keep in mind that the application might not be aware of and for example still assume a 24x80 screen, even if you took some characters off for a beautiful frame. Similar any output bypassing STDOUT, like when using BIOS calls or direkt screen manipulation, may show up at the wrong place (*4). Last but not least, every program opening CON on its own will as well bypass your driver.



          A few points to think about may be:



          • Don't forget to make the driver as well handling read requests, as Command.Com requires both ways to go thru the same device.


          • You may as well try to replace the build-in CON driver(*5), this means setting the CON bit in the device attributes word as well as replacing/capturing INT 29h, as DOS does handle CON a bit different. (*6)


          • Adding I/O-Control support would support a clean interface to set the workings during runtime (changing colours or whatsoever it does) with a configuration command supplied by you.


          • Do your users a favour and use Assembly - at least for the driver.


          Device drivers can be a lot of fun and are usually way less complicated to write then people tend to assume.



          Caveat: Some mechanics only work with DOS 3.1 and higher even though already defined before. This goes especially for monitoring open/close calls.




          *1 - Now, when devices are used as targets of a redirection, access is immediate and concurrent. Just they can only be source or destination.



          *2 - And even then you may need some file server allowing read while write and plunge in a zillion FLUSH calls to make each output seen.



          *3 - For test purpose it may be more appropriate to only load the driver and use redirected STDIN/OUT only via a sub-shell.



          *4 - Some of this may be captured by the driver due manipulation of BIOS data and alike - but that will as well lead to a slow creep into machine and OS dependence while at the same time bloating code ever more.



          *5 - This would remove some of the possible ways to screw up things for child processes in complex scenarios involving sub-shells as well as redirections with the explicit use of CON. On the down side, you'd have to rewrite all of it's functionality - hopefully compatible with ANSI.SYS which already is one.



          *6 - Which BTW would be the better way (when going this route) - get the source for some ANSI.SYS compatible driver like NANSI.SYS and tweek it to support your additional functionality - more work than writing your own, but for sure a great drop in by naming it ANSI.SYS and copying it onto any machine available - not other change needed.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 2 days ago

























          answered Apr 7 at 9:44









          RaffzahnRaffzahn

          55.8k6136225




          55.8k6136225





















              0















              Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




              If are experienced in assembly language, you may do the following:



              You can run the "Skin" program and replace the int 21h vector by your own one. In your own vector you process all int 21h requests that are related to the console.



              If some function is not handled by your handler, you use a jmp far instruction to jump to the original interrupt handler. Many DOS device drivers used this method to add additional functionality to a DOS or BIOS interrupt.



              You may also call the original int 21h interrupt using pushf followed by call far to the original handler's address.



              In addition to functions accessing the console, you would have to handle dup, dup2 and close in your int 21h handler to track which file handles correspond to the console.



              Unfortunately, many programs directly access BIOS interrupts int 10h (screen) or int 16h (keyboard). To support such programs, you would have to do the same with these two interrupt handlers.



              There were also a lot of programs directly accessing the hardware (e.g. the screen memory at 0B8000h). Unfortunately, before the 80386 there was no method to "skin" such programs. This is why there was no console window in Windows 3.x running in 286 mode but you could only run MS-DOS programs in full screen mode.



              (And the method used by 32-bit OSs is anything but easy to implement.)






              share|improve this answer



























                0















                Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




                If are experienced in assembly language, you may do the following:



                You can run the "Skin" program and replace the int 21h vector by your own one. In your own vector you process all int 21h requests that are related to the console.



                If some function is not handled by your handler, you use a jmp far instruction to jump to the original interrupt handler. Many DOS device drivers used this method to add additional functionality to a DOS or BIOS interrupt.



                You may also call the original int 21h interrupt using pushf followed by call far to the original handler's address.



                In addition to functions accessing the console, you would have to handle dup, dup2 and close in your int 21h handler to track which file handles correspond to the console.



                Unfortunately, many programs directly access BIOS interrupts int 10h (screen) or int 16h (keyboard). To support such programs, you would have to do the same with these two interrupt handlers.



                There were also a lot of programs directly accessing the hardware (e.g. the screen memory at 0B8000h). Unfortunately, before the 80386 there was no method to "skin" such programs. This is why there was no console window in Windows 3.x running in 286 mode but you could only run MS-DOS programs in full screen mode.



                (And the method used by 32-bit OSs is anything but easy to implement.)






                share|improve this answer

























                  0












                  0








                  0








                  Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




                  If are experienced in assembly language, you may do the following:



                  You can run the "Skin" program and replace the int 21h vector by your own one. In your own vector you process all int 21h requests that are related to the console.



                  If some function is not handled by your handler, you use a jmp far instruction to jump to the original interrupt handler. Many DOS device drivers used this method to add additional functionality to a DOS or BIOS interrupt.



                  You may also call the original int 21h interrupt using pushf followed by call far to the original handler's address.



                  In addition to functions accessing the console, you would have to handle dup, dup2 and close in your int 21h handler to track which file handles correspond to the console.



                  Unfortunately, many programs directly access BIOS interrupts int 10h (screen) or int 16h (keyboard). To support such programs, you would have to do the same with these two interrupt handlers.



                  There were also a lot of programs directly accessing the hardware (e.g. the screen memory at 0B8000h). Unfortunately, before the 80386 there was no method to "skin" such programs. This is why there was no console window in Windows 3.x running in 286 mode but you could only run MS-DOS programs in full screen mode.



                  (And the method used by 32-bit OSs is anything but easy to implement.)






                  share|improve this answer














                  Also, how to pipe stdin/out from the current shell (command.com or 4dos.com) in order to "Skin" the console?




                  If are experienced in assembly language, you may do the following:



                  You can run the "Skin" program and replace the int 21h vector by your own one. In your own vector you process all int 21h requests that are related to the console.



                  If some function is not handled by your handler, you use a jmp far instruction to jump to the original interrupt handler. Many DOS device drivers used this method to add additional functionality to a DOS or BIOS interrupt.



                  You may also call the original int 21h interrupt using pushf followed by call far to the original handler's address.



                  In addition to functions accessing the console, you would have to handle dup, dup2 and close in your int 21h handler to track which file handles correspond to the console.



                  Unfortunately, many programs directly access BIOS interrupts int 10h (screen) or int 16h (keyboard). To support such programs, you would have to do the same with these two interrupt handlers.



                  There were also a lot of programs directly accessing the hardware (e.g. the screen memory at 0B8000h). Unfortunately, before the 80386 there was no method to "skin" such programs. This is why there was no console window in Windows 3.x running in 286 mode but you could only run MS-DOS programs in full screen mode.



                  (And the method used by 32-bit OSs is anything but easy to implement.)







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 2 days ago









                  Martin RosenauMartin Rosenau

                  662127




                  662127




















                      Dacobi is a new contributor. Be nice, and check out our Code of Conduct.









                      draft saved

                      draft discarded


















                      Dacobi is a new contributor. Be nice, and check out our Code of Conduct.












                      Dacobi is a new contributor. Be nice, and check out our Code of Conduct.











                      Dacobi is a new contributor. Be nice, and check out our Code of Conduct.














                      Thanks for contributing an answer to Retrocomputing Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9609%2fdos-create-pipe-for-stdin-stdout-of-command-comor-4dos-com-in-c-or-batch%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Sum ergo cogito? 1 nng

                      三茅街道4182Guuntc Dn precexpngmageondP