Parallel Port in XP

Code:

---

#include<iostream.h>
#include<conio.h>
#include<dos.h>
void left();
void right();
int main()
{
clrscr();
int i;
        for(i=1;i<=10;i++)
        {
        left();
        right();
        }
getch();
outportb(0x378,0);
return(0);
}

void left()
{
outportb(0x378,1);
delay(25);
outportb(0x378,2);
delay(25);
outportb(0x378,4);
delay(25);
outportb(0x378,8);
delay(25);
outportb(0x378,16);
delay(25);
outportb(0x378,32);
delay(25);
outportb(0x378,64);
delay(25);
outportb(0x378,128);
delay(25);
outportb(0x378,0);
}

void right()
{
outportb(0x378,128);
delay(25);
outportb(0x378,64);
delay(25);
outportb(0x378,32);
delay(25);
outportb(0x378,16);
delay(25);
outportb(0x378,8);
delay(25);
outportb(0x378,4);
delay(25);
outportb(0x378,2);
delay(25);
outportb(0x378,1);
delay(25);
outportb(0x378,0);
}

---

This code works fine when I run it under Turbo C 3.0, but when I run the EXE in Windows, nothing happens.
I am using LEDs to monitor the parallel port and they go on and off when using TC but not in XP.
Even tried Compatibility modes in XP, nogo.

The basic problem is your fossil compiler on your nice new operating system.

Would you buy a Ferrari, then rip the engine out only to replace it with a steam engine? Because in computing terms, that's what you've just done.

Get a modern compiler, one which is suited to your OS.
http://www.cprogramming.com/compilers.html

It's a bit more than that. torq3ue is trying to access the parallel port directly, and windows XP (as does the whole NT family) is specifically designed to prevent user programs from accessing hardware directly. In practice, to do what he wants, it is necessary to use a dedicated device driver or to use less direct means of interacting with the parallel port.

I think what grumpy is saying is right, because I have ported the same code to VB 6 and that too could not play around with the port without inpout32.dll.

Now a program called parmon which basically monitors the parallel port does let you do all this direct in XP.

The weird part is that when the code is run in TC it works fine, but the EXE is what has issues running.

That's because your program isn't actually being executed. It's being specially emulated, giving the illusion that it is running all nice and naturally. When you get into emulation, your mileage may vary.

The guy that wrote parmon.... He's explained this already in greater detail than we have, and he's written a system driver that enables you to do close-to-real-time processing of the IO ports:

http://geekhideout.com/iodll.shtml

As part of his warning, though:

Quote:

---

Before moving on, it is probably prudent to mention that the technique employed in IO.DLL for releasing the ports to the application level isn't, strictly speaking, the proper way to do things. The proper way is to have a virtual device driver for Windows 95/98 and a kernel mode driver for Windows NT/2000/XP.

---

Nevertheless, this is probably better to use than emulating a DOS program.

At least you can ditch Turbo C and get a real compiler that is made for your OS.

What should we do if we want output on 10 bits? This program is for 8 bit. This means this program will glow only 8 LED's. What should we do if we want to glow 10 LEDs. I hvae used demux on D-9 of the parallel port.
Help.

You contribute to your own thread -> http://cboard.cprogramming.com/c-pro...llel-port.html
Rather than digging up someone else's old thread.