this small utility and found that data is received and sent correctly.
Given the way the parallel port works I really doubt your testing is sufficient. There is much more to interacting with a parallel port than just writing data to its output register (which is all your code does) or reading from the input register. Are you aware, for example, that there are at least five distinct operating modes for parallel ports, and that older ports do not support all modes?
Because of that, just throwing data at the output register of the parallel port (as you are doing) will not reliably work. There is also interaction with the operating system and other installed drivers to consider.
I'm not familiar with the utility you are using, but would bet that (on commencement) it places the port into some known state. If it is a good windows citizen, it would clean up after itself (i.e. remember the initial settings it detected, and restore them as it exits). That would explain why you can do what you want with the utility, but not with your code. It is, more than likely, your code (and assumptions it makes) that is the problem.
As I said before, you need to read up on the parallel port itself. All your code is doing is throwing data to the output register of the port. Depending on the type of parallel port, and the state it is in, your data may simply be ignored by the port. That means, it will not be passed onto your device or circuit.
Well I need to work in Byte mode. I have not yet connected my actual device to the port but I have used a test circuit consist of LEDs to check whether the port is working or not. And by "data is not written on the port" I mean to say that circuit is not detecting the change in signals.
Come back to the working mode. I need to work in Byte mode. I have searched on internet "how to set parallel port mode in C/C++" but found no use full result regarding my problem. Secondly, this is previously discussed that the program is working properly on win Xp with out setting or changing the operation mode. But (if this is really the reason) why win & is waiting for me to change the operation mode before running my program?
You're asking the wrong question.
The windows NT family of operating systems (NT/2000/XP/win 7) specifically prevent direct access to the parallel port, by design. You are using a third-party DLL, which installs a kernel-mode driver, in order to explicitly bypass design features of the operating system, and access the parallel port in a manner that the operating system cannot control. The folks who designed your operating system had no knowledge of the particular needs of your program.
Why, given that you are going out of your way to bypass the operating system, would you expect that the operating system would ensure that the parallel port is kept in some state or mode that ensures your program would work?
I gave links in previous posts to information on programming the parallel port. Granted, those links do not provide cookbook recipes of "do this to place the port in byte mode", but the information is there if you take the trouble to seek it. I'm not aware of any guides to programming the parallel port that provide simple cookbook recipes. Which is usually a hint that experts do not consider parallel port programming to be difficult enough to warrant writing "parallel ports for dummies" guides.
This sounds to me that I should skip chasing parallel port and should look for a third party ware that enables me to communicate with my device since I do not have this much which allows me to first study a whole book on parallel port programming then writing a simple code that would send a single byte of data to my device.
That's a matter of perspective, I guess. It strikes me that you want canned solutions without effort.
To find a "third party ware" to do what you want, you'll need to go through a process of testing any you find. But, yeah, I suppose you might consider that less complicated than reading documentation, and implementing your own solution.
Yes. You are right. Even if I dont want a canned solution then again I do not want to waste time reading documentations and learning something which one would rarely need in life. Most of the guys at my academy also have "advised" me not to go behind something which do not exist in the modern world any more (almost all the mother board's manufacturer's are not providing parallel port any more), therefore I should achieve my target by using some "USB to parallel port converter" or some sort of USB supported Micro Controllers.