XP DOS communicate via parallel printer port?

[Chris Holbrook]

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?

[Marco Pontello]

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!

[Chris Holbrook]

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.

[Eros Olmi]

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

[Chris Holbrook]

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?

[Eros Olmi]

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:

• ReadConsoleOutput: http://msdn.microsoft.com/en-us/libr...65(VS.85).aspx
• ReadConsoleOutputAttribute http://msdn.microsoft.com/en-us/libr...68(VS.85).aspx
• ReadConsoleOutputCharacter http://msdn.microsoft.com/en-us/libr...69(VS.85).aspx

To read console Data from your DOS application, it depends what compiler you used, so I cannot help on this.

Eros

[Paul Dixon]

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

http://www.powerbasic.com/support/pbforums/showthread.php?t=11194

Paul.

[Michael Mattias]

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.

[Chris Holbrook]

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.

[Paul Dixon]

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.

[Mike Stefanik]

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.

[Chris Holbrook]

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!

[Chris Holbrook]

OK, now I can see attachconsole - ignore previous.

[Eros Olmi]

Hi Chris,

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

Another way to get handle is something like:

 
      '---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

[Chris Holbrook]

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...

[Michael Mattias]

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.

[Chris Holbrook]

"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?"

[Michael Mattias]

>"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

[Paul Purvis]

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.

[Michael Mattias]

Lots of activity in a thread which started out asking for but one (1) lonely little byte.......