LPT I/O Port Access in Vista [modified]
-
I used to use the LPT port in a program in Windows XP. In order to get access to the port, I used TotalIO. Now I am using Windows Vista 32-bit, but I can't get TotalIO to work. It says the service is loaded successfully, but I still do not get access to the x86 assembly in and out instructions. I still get the priveledged instruction error. I have even tried running as Admininstrator with XP compatibility. Has anyone had any success with getting port access in Vista that has any tips? Please note: I want to avoid using inpout32.dll; although if it is the only option I will. The reason is, in my experience, TotalIO is MUCH MUCH faster than inpout32.dll.
modified on Thursday, February 7, 2008 9:03 PM
It seems strange that it worked on XP: the
inandoutinstructions are privileged in XP too and so can only be executed from kernel mode (i.e. by drivers, for example.)Steve
-
It seems strange that it worked on XP: the
inandoutinstructions are privileged in XP too and so can only be executed from kernel mode (i.e. by drivers, for example.)Steve
Stephen Hewitt wrote:
It seems strange that it worked on XP: the in and out instructions are privileged in XP too
that is why he is using TOTALIO, a driver which changes the priviledge bit to give direct access to hw port to the application.
-
I used to use the LPT port in a program in Windows XP. In order to get access to the port, I used TotalIO. Now I am using Windows Vista 32-bit, but I can't get TotalIO to work. It says the service is loaded successfully, but I still do not get access to the x86 assembly in and out instructions. I still get the priveledged instruction error. I have even tried running as Admininstrator with XP compatibility. Has anyone had any success with getting port access in Vista that has any tips? Please note: I want to avoid using inpout32.dll; although if it is the only option I will. The reason is, in my experience, TotalIO is MUCH MUCH faster than inpout32.dll.
modified on Thursday, February 7, 2008 9:03 PM
-
Stephen Hewitt wrote:
It seems strange that it worked on XP: the in and out instructions are privileged in XP too
that is why he is using TOTALIO, a driver which changes the priviledge bit to give direct access to hw port to the application.
I found a post about TOTALIO: TOTALIO is indeed quite a dangerous program, giving nearly total port I/O access (up to port about port 0xf00) to every program in the system (including any old DOS program which, as Luke mentions, could easily trash your system), and I never intended it to be used in practice (I have never found a need for it, personally). GIVEIO (also available in the same ZIP file) is slightly less dangerous in that it limits I/O access to only those processes that request it. I would prefer it above TOTALIO.[^] I would assume the driver is not compatible with Vista, which is probably a good thing.
Steve
-
I found a post about TOTALIO: TOTALIO is indeed quite a dangerous program, giving nearly total port I/O access (up to port about port 0xf00) to every program in the system (including any old DOS program which, as Luke mentions, could easily trash your system), and I never intended it to be used in practice (I have never found a need for it, personally). GIVEIO (also available in the same ZIP file) is slightly less dangerous in that it limits I/O access to only those processes that request it. I would prefer it above TOTALIO.[^] I would assume the driver is not compatible with Vista, which is probably a good thing.
Steve
Stephen Hewitt wrote:
I would assume the driver is not compatible with Vista,
I too.
-
Stephen Hewitt wrote:
I would assume the driver is not compatible with Vista,
I too.
Using such a driver is reckless, to say the least. It affects every process running on the system. This means that a badly written process (perhaps not even the one that installed the driver) can trash the system instead of just terminating with an exception, and Microsoft would probably cop the blame!
Steve
-
Using such a driver is reckless, to say the least. It affects every process running on the system. This means that a badly written process (perhaps not even the one that installed the driver) can trash the system instead of just terminating with an exception, and Microsoft would probably cop the blame!
Steve
Stephen Hewitt wrote:
and Microsoft would probably cop the blame!
How so? If they would refrain from promising infinite compatibility, no one would come to blame them when there is none. MacOS has changed its API (and broke compatibility) two times now. Linux constantly changes its internal APIs and drop outdated ones (SysFS, still remembered?). Yet both are on the rise, while MS declines...
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency" -
Using such a driver is reckless, to say the least. It affects every process running on the system. This means that a badly written process (perhaps not even the one that installed the driver) can trash the system instead of just terminating with an exception, and Microsoft would probably cop the blame!
Steve
Yes, obviously.
x87Bliss wrote:
in my experience, TotalIO is MUCH MUCH faster than inpout32.dll.
I think this is because direct execution of instruction rather than deep path to kernel mode driver like inpout32.dll. I would suggest that he can increase the performance by decreasing the number of calls through inpout32.dll (buffered commands), if the frequency of the call is high. inpout32.dll source is available for him to experiment on.
-
Yes, obviously.
x87Bliss wrote:
in my experience, TotalIO is MUCH MUCH faster than inpout32.dll.
I think this is because direct execution of instruction rather than deep path to kernel mode driver like inpout32.dll. I would suggest that he can increase the performance by decreasing the number of calls through inpout32.dll (buffered commands), if the frequency of the call is high. inpout32.dll source is available for him to experiment on.
Thank you all for your info and security concerns. This is just a personal program, I am not designing it for public release. I only allow TotalIO to run during the timeframe that I need it. I will have to give GiveIO a try, since that should be much more secure, thanks for that tip. And Steve's info on the allowed port range also clears it up: "up to about 0xf00". As my LPT port is on port 0xCD00 - thanks to the add-on card. It's no wonder TotalIO "isn't doing it's job" if you will. Again, thank you all. TotalIO's failure, and your comments, is like a wake-up call to stop doing the I/O the quick and dirty way.
-
Stephen Hewitt wrote:
and Microsoft would probably cop the blame!
How so? If they would refrain from promising infinite compatibility, no one would come to blame them when there is none. MacOS has changed its API (and broke compatibility) two times now. Linux constantly changes its internal APIs and drop outdated ones (SysFS, still remembered?). Yet both are on the rise, while MS declines...
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"jhwurmbach wrote:
How so?
Because in modern operating systems user programs can’t directly access the hardware of the machine, this is the job of a device driver. TOTALIO gives user programs access to the
inandoutinstructions; any user program. This means that installing TOTALIO allows a badly written application to crash the whole system instead of just crashing itself. This is obviously the kind of thing that needs to be stopped. When a user’s computer blue screens Microsoft will cop the blame when the fault really lies with the software that installed TOTALIO.Steve