Announcement

Collapse
No announcement yet.

XP DOS communicate via parallel printer port?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • XP DOS communicate via parallel printer port?

    I'm probably about eight years late with this idea, but could an XP application read a byte of data from a parallel printer port? That was put there by, say a DOS application?

  • #2
    Sure. Total Commander for example do it for his "LapLink like" module, that let you transfer files to/from a slave DOS machine on witch you run a small server program.

    Bye!
    -- The universe tends toward maximum irony. Don't push it.

    File Extension Seeker - Metasearch engine for file extensions / file types
    Online TrID file identifier | TrIDLib - Identify thousands of file formats

    Comment


    • #3
      Originally posted by Marco Pontello View Post
      to/from a slave DOS machine on witch you run a small server program.
      Mm. I was thinking of both applications running on the same PC.

      Comment


      • #4
        Chris,

        I do not know what you are trying to do but it seems similar a problem I've faced for some old DOS applications in need to get data from a 32Bit application.

        We have solved the problem using a 32Bit PowerBasic Console application that comunicates with DOS application reading/writing data at line 24 of the console screen with a foreground color equal to background (so user do not see anything).

        When DOS application needs to talk with 32Bit application, it writes on line 24 the command, that run the 32Bit process and waith for sync command. 32bit application reads data from line 24, executes the relevant invoked commands and reply again on line 24 (we use black on black color).
        We used a 78 bytes of buffer data. Last 2 bytes (79/80) are used for in sync flags.

        If the 2 process has to exchange not big amount of data, this can be a possible methods (this was our case).
        With big amount of data, it can be too slow.

        Hope this can help.
        Eros
        Last edited by Eros Olmi; 3 Jul 2008, 04:40 PM.
        thinBasic programming language
        Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

        Comment


        • #5
          Originally posted by Eros Olmi View Post
          We have solved the problem using a 32Bit PowerBasic Console application that comunicates with DOS application reading/writing data at line 24 of the console screen with a foreground color equal to background (so user do not see anything).
          Eros, that is very encouraging. I did try to read the screen of the console application (not a PB app), but my windows skills were not sufficient. In your system, do you rely upon the DOS app being PB or could any console screen be scraped by your method?

          Comment


          • #6
            Our DOS applications are writtent in CBasic, a very very old Basic from Digital. Our 32Bit applications are written into PowerBasic Console.
            We have sources of both so we can change and recompile them all.

            I think any application able to read Console screen data as ascii chars can use this method. It is like using a file to exchange data but video, in our case, was simpler.


            To read console data from 32Bit console applications you can use the following Windows API:To read console Data from your DOS application, it depends what compiler you used, so I cannot help on this.

            Eros
            Last edited by Eros Olmi; 3 Jul 2008, 06:05 PM.
            thinBasic programming language
            Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

            Comment


            • #7
              Chris,
              you can read/write to I/O ports from XP using this:

              http://www.powerbasic.com/support/pb...ad.php?t=11194

              Paul.
              Last edited by Paul Dixon; 3 Jul 2008, 05:00 PM.

              Comment


              • #8
                Does XP program just need to READ a small amount of data provided by the DOS program?

                If so, you could SHELL the 32-bit program from your MS-DOS program and put the data on the command-line.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  Does XP program just need to READ a small amount of data provided by the DOS program?
                  Sort of Client/server situation, the wider the pipe the better.

                  Comment


                  • #10
                    Chris,
                    open a file and write stuff to it in DOS which can be read back in XP. In practice you'll just be reading from the cached version of the file most of the time so it'll be faster than you might expect.

                    Paul.

                    Comment


                    • #11
                      Originally posted by Paul Dixon View Post
                      Chris,
                      open a file and write stuff to it in DOS which can be read back in XP. In practice you'll just be reading from the cached version of the file most of the time so it'll be faster than you might expect.
                      I would go with what Paul says here. Keep it simple and use files, since you're going to be working out of the cache most of the time anyway. If it's very small amounts of data, then heck, you could actually encode it as part of the filename itself and not even worry about storing any data. You'd be limited to 8.3 filenames on the DOS end of things, but if it's just passing a couple of bytes around, that'd be sufficient.
                      Mike Stefanik
                      sockettools.com

                      Comment


                      • #12
                        Originally posted by Eros Olmi View Post
                        To read console data from 32Bit console applications you can use the following Windows API...
                        First I need a console handle, so I get the pid of the console process - no problem. Now to connect the PB Win app to the console - I use attachconsole - am I right? but Attachconsole is not to be found! I'm running XP SP2 so _WIN32_WINNT must be 0x0501 already. Looking at prior versions of Kernel32.dll on my PC, there's no attachconsole in them, either!

                        Comment


                        • #13
                          OK, now I can see attachconsole - ignore previous.

                          Comment


                          • #14
                            Hi Chris,

                            attention: attachconsole is only available under WinXP/Vista/2003/2008 OSs.

                            Another way to get handle is something like:

                            Code:
                             
                                  '---Get handles to STDIN and STDOUT
                                  AllocConsole()
                                  ghStdin =  GetStdHandle(%STD_INPUT_HANDLE)
                                  ghStdout = GetStdHandle(%STD_OUTPUT_HANDLE)
                            If 32Bit application is executed from a DOS application, a Console window is already allocated, so the 32Bit application will use the same Console as the DOS process.

                            Hope this helps.
                            Ciao
                            Eros
                            thinBasic programming language
                            Win10 64bit - 8GB Ram - i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

                            Comment


                            • #15
                              Originally posted by Eros Olmi View Post
                              If 32Bit application is executed from a DOS application, a Console window is already allocated, so the 32Bit application will use the same Console as the DOS process.
                              That's good to know, thanks!
                              My problem was, well, me.
                              Code posted to Source Code Forum - you may recognise some of it...

                              Comment


                              • #16
                                What a marketing opportunity!

                                "Why don't we replace that old, obsolete, hard-to-maintain MS-DOS program with a nice new Windows-based program?"

                                BIAS ALERTS:
                                A. I have had some BAD experiences with "screen scraping" applications (none of which I created).
                                B. This is how I put food on the table.
                                Michael Mattias
                                Tal Systems (retired)
                                Port Washington WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  Originally posted by Michael Mattias View Post
                                  "Why don't we replace that old, obsolete, hard-to-maintain MS-DOS program with a nice new Windows-based program?"
                                  or even
                                  "Why don't we let that old MSDOS program interrogate our database?"

                                  Comment


                                  • #18
                                    >"Why don't we let that old MSDOS program interrogate our database?"

                                    Because we don't do MS-DOS anymore, that's why. Hell, we barely 'do' Windows/9x anymore.

                                    But FWIW and if "you" are not "we" ....

                                    If using compilers which support MS-DOS interrupts (PB/MS-DOS) and Windows API calls (PB/CC or PB/Windows) as well as STDOUT/STDIN (eg the same compilers), you can redirect the STDOUT and STDIN of the both programs to files and end up with a client-server application between an MS-DOS and a Windows program, in which the files used serve as the communications channel.

                                    Just a little something to think about........for those who do "do MS-DOS."


                                    MCM
                                    Michael Mattias
                                    Tal Systems (retired)
                                    Port Washington WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      if you do not have any control over the msdos program and the information is placed on the screen in formated output and the screen is not scrolling, you can use powerbasic for dos and write a trs program to read the screen.

                                      i wrote a program to do this after there is no keyboard input for something like 2 seconds.


                                      does the data only go one direction.
                                      if you are trying to read printer output and just capture the output there are ways to do that.
                                      p purvis

                                      Comment


                                      • #20
                                        Lots of activity in a thread which started out asking for but one (1) lonely little byte.......
                                        Michael Mattias
                                        Tal Systems (retired)
                                        Port Washington WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X