Announcement

Collapse
No announcement yet.

parallel port monitor?

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

    parallel port monitor?

    I need a software that can give me info what program DOS is outputting data to a parallel port by flagging the LPT# address. Not the one that monitors the parallel port itself.

    It is like IP scanner.

    Problem is I have a program brundle, one works well with 2 printers but one other program for printing from the database that was created by first program is squirting data steam into ether-space and is "waiting for a ACK from printer or spooler" and doesn't appear on XP spool monitor.

    For this reason I need to track down the "ghost" port address that program is sending data to that doesn't exist so I can redirect it to correct port. That where I need a program to report to me what this program is doing during the "printing".
    The brundle of this two programs with database does not have provision for changing the port settings. Unfortunely and it is important.

    Tried google and could not find what I'm looking for.

    HELP!

    Cheers, Wizard

    #2
    Re: parallel port monitor?

    The program is a Dos program or a Windows one? If it's a Dos one, it may pool directly the printer and wait for a reply from it (an ACKnowledge command); a Windows one should send all data through the Windows spooler but there are [dreadful] exceptions.

    I don't know if such a lpt tester does exist so I suggest an alternative approach: remap a LPT port to a network device with "NET USE LPTx \\SERVER\PRINTER", being LPTx the port you want to redirect and \\SERVER\PRINTER the path (SERVER is your computer's name and PRINTER the printer's one). Ancient Dos program should look for LPT1 and LPT2 only (IBM PCs and XTs could address only two parallel ports) while newer Dos programs (for 286, 386 and above) can look up to 4 ports and Windows ones are without explicit limits (they can send data to any port, such as FILE or USBx), though 4 addressable ports are the most common limit. Try remapping LPT1 first: if it doesn't work, then remove the remapping and try with LPT2, then LPT3 etc. Moreover, the program can print to a serial port instead to a parallel one so try remapping all COM[1-4] ports if the 4 LPT aren't enough. Eventually you should identify the port the program uses.
    Note: remapping port[s] physically present on the computer (such as LPT1) is tricky because you need Administrative privileges.

    Zandrax
    Last edited by zandrax; 11-25-2008, 04:14 PM.
    Have an happy life.

    Comment


      #3
      Re: parallel port monitor?

      Thanks for the reply, I figured that out that thing, will try to find a solution for once and all, because I recalled looong ago about the bios call and banging on the hardware directly (NO NO!! finger wagging.).

      I tested on a spare printer and the old server (98 and the software) that I took out offline awhile ago due to corruptions to database) to see if windows's spooler appear when this retarded program prints. Nothing on spooler and printer a-churning. Aha, banging on the hardware. :P Funny, the 2 out of 3 programs we use works except the one was different in programming. So I added the start link to the alterative program so we can keep going.

      Yes, I said DOS programs.

      I'll use the NET USE.... method and see.

      I wish the hardware designer of this wonderful 1x PCI-E 2x parallel ports adapter card wrote and designed that adapter better even it works via software emulation but make it better that it can fool the hardware-twiddling programs.

      Cheers, Wizard

      Comment


        #4
        Re: parallel port monitor?

        That's a tough one to answer... I did a lot of copy protection cracking in the DOS days, by writing an ASM routine that intercepted various interrupt vectors.

        This concept will work to intercept Int17 calls to the parallel ports. But... most DOS programs bypassed the BIOS call due to awful performance, and wrote directly to port 378, etc. Nothing comes to mind for a software intercept of I/O ports. A bus analyzer would do the trick. Think of it as a Sniffer on the bus that is filtered to watch for the port addresses you are interested in.

        All the above is geeky stuff, and not really a fix. The redirection idea is probably the first choice. After that, perhaps running the DOS application in a virtual machine might work... ?

        Comment

        Working...
        X