Thank you Bill Gates, he said sarcastically
Tom Vrankar
I'm developing some application-specific test instrumentation that is
controlled by a PC's parallel port. I'm currently writing the control
software in PythonDX. Besides Python being a very easy language to work in,
PythonDX offers the familiar "peek" and "inportb" and "outportb" extension
functions to directly access the parallel port hardware under Win3.1 and
Win95.
Now I want to be able to move the control software to a WinNT4 platform. I
have just discovered something called the Hardware Abstraction Layer which
prevents apps from directly accessing any hardware. I know nothing more
about the HAL than how to spell it. What is the new way to directly access
the port hardware? I don't want to access a printer, I want to manipulate
each bit in the 25-pin D connector individually. Can I do this with any of
the existing Python extensions for Windows? After some initialization
overhead, will this new way be as fast as mapping outportbs? Will this new
way work on both Win95 and WinNT4 or do I have to maintain multiple versions
of the resulting code?
Thanks for any tips or pointers to FAQs.
twv@
--
---------------------------------
Tom Vrankar
twv at ici.net
http://www.ici.net/customers/twv/
Rhode Island, USA
Scott C. Zimmerman
Tom Vrankar wrote:
>
<snip Python info>
> Now I want to be able to move the control software to a WinNT4 platform. I
> have just discovered something called the Hardware Abstraction Layer which
> prevents apps from directly accessing any hardware. I know nothing more
> about the HAL than how to spell it. What is the new way to directly access
> the port hardware? I don't want to access a printer, I want to manipulate
HAL is there precisely to keep you from accessing the hardware
directly. As part of NT's crash-resistant architecture, any apps must
be able to talk to HAL in order to reach the hardware. This is why
DOS-based games like Doom 2 and Duke Nukem 3-D will not run under NT:
they try to access the hardware directly, then HAL steps in and you get
error messages like "sound card not installed" and such. It's still
there, but HAL prevents the app from seeing it. I'm afraid I can't help
you with your Python-specific questions, though. HTH.
Scott
scott(a)earth.nexus.net
Craig P Earls
n...@spam.net (Tom Vrankar) writes:
> Now I want to be able to move the control software to a WinNT4 platform. I
> have just discovered something called the Hardware Abstraction Layer which
> prevents apps from directly accessing any hardware. I know nothing more
> about the HAL than how to spell it. What is the new way to directly access
> the port hardware?
To directly access hardware in NT, or Linux (or any other real
operating system for that matter (DOS and Win 95 barely qualify) you
must write a kernel level device driver. This is difficult.
Why?
The primary purpose of an operating system is broker hardware access,
i.e. share the processor, to keep programs from trying to use the same
serial port at the same time, etc. The Hardware Abstraction Layer does
just that: Abstracts the hardware to insulate programs from each other
and hardware changes.
I am certain somebody understands this better than I, you should
search for information on NT device drivers.
--
----------------------------------------------------------------------
Craig P Earls cpe...@ziplink.net
LT US Navy, MIT Aero/Astro Engineering cpe...@mit.edu
----------------------------------------------------------------------
Josef Dalcolmo
Tom Vrankar wrote:
>
> I'm developing some application-specific test instrumentation that is
> controlled by a PC's parallel port. I'm currently writing the control
> software in PythonDX. Besides Python being a very easy language to
You might want to look at Sam Rushing's calldll module (available from
http://www.nightmare.com/). This is primarily designed to let you call
arbitrary DLL's, but it also includes peek/poke style functionality.
In addition, if you've already done it in C, you can put that code
into a DLL and call it via calldll. That way you don't run into the
hassles of writing a full python extension (not that it's really that
hard).
-Chris
Above is a snippet I took the liberty to copy a while ago from this
newsgroup. I haven't tried the calldll module yet, and since I need
Python for similar things, and have also to move to NT, I am interested
in the outcome. Please let me know if it works for you.
--
Josef Dalcolmo, ESAT/ACCA Laboratory, K.U. Leuven,
Kardinaal Mercierlaan 94, B-3001 Heverlee, Belgium
dave porter
You might want to read up on operating systems theory.
Operating systems often have a goal of providing
robust and secure operation. To do this, it is generally
considered necessary to prevent unprivileged code from
fooling directly with hardware (otherwise you end
up with all the robustness of Windows 3.1).
In other words, a "protected mode" operating system is
supposed to do some protecting!
This is nothing to do with the HAL. It is a mere matter
of sensible operating system design.
The HAL is there for a different reason altogether. It allows
suitably privileged code (i.e., kernel device drivers) to
be written in a platform-independent way. For example, if
you're writing a driver for a particular PCI card, then
you shouldn't have to kow whether it's on an Intel x86-based
machine, a MIPS machine, an Alpha machine, or whatever.
The HAL is what allows that to be true.
dave
--
For email, please remove the 'w' from my address. Sorry.
Tom Vrankar <n...@spam.net> wrote in article <6d5ea0$d88$1...@bashir.ici.net>...
> I'm developing some application-specific test instrumentation that is
> controlled by a PC's parallel port. I'm currently writing the control
> software in PythonDX. Besides Python being a very easy language to work
in,
> PythonDX offers the familiar "peek" and "inportb" and "outportb"
extension
> functions to directly access the parallel port hardware under Win3.1 and
> Win95.
>
> Now I want to be able to move the control software to a WinNT4 platform.
I
> have just discovered something called the Hardware Abstraction Layer
which
> prevents apps from directly accessing any hardware. I know nothing more
> about the HAL than how to spell it. What is the new way to directly
access
> the port hardware? I don't want to access a printer, I want to manipulate
Scott Campbell
Tom,
Get this book,
http://www.amazon.com/exec/obidos/quicksearch-query/8679-0132161-941241
The Windows Nt Device Driver Book : A Guide for Programmers
by Art Baker
List: $44.95
Our Price: $35.96
You Save: $8.99 (20%)
Availability: This title usually ships within 24 hours.
Bk&Disk Edition
Paperback, 500 pages
Published by Prentice Hall Computer Books
Publication date: January 1, 1997
Dimensions (in inches): 9.27 x 7.09 x .90
ISBN: 0131844741
It has a section with a prewritten device driver for the parallel
port. The program is on th disk that comes with the book.
Good luck.
Scott Campbell
Tom Vrankar wrote:
> I'm developing some application-specific test instrumentation that is
> controlled by a PC's parallel port. I'm currently writing the control
> software in PythonDX. Besides Python being a very easy language to work in,
> PythonDX offers the familiar "peek" and "inportb" and "outportb" extension
> functions to directly access the parallel port hardware under Win3.1 and
> Win95.
>
> Now I want to be able to move the control software to a WinNT4 platform. I
> have just discovered something called the Hardware Abstraction Layer which
> prevents apps from directly accessing any hardware. I know nothing more
> about the HAL than how to spell it. What is the new way to directly access
> the port hardware? I don't want to access a printer, I want to manipulate
> each bit in the 25-pin D connector individually. Can I do this with any of
> the existing Python extensions for Windows? After some initialization
> overhead, will this new way be as fast as mapping outportbs? Will this new
> way work on both Win95 and WinNT4 or do I have to maintain multiple versions
> of the resulting code?
>
> Thanks for any tips or pointers to FAQs.
Roger J.Hamlett
In article: <6d5ea0$d88$1...@bashir.ici.net> n...@spam.net (Tom Vrankar)
writes:
This has nothing to do with the HAL, but is fundamental to such an
OS, which prevents any application from having access at such a level
to I/O ports, which could do all sorts of damage to the system.
However _provided_ you know what you are doing, there is a 'virtual'
port driver that will allow you such access. Do a web search for
'tinyport', which should find the driver.
Best Wishes
--
--------------------------------------------------------------------
| EMail ro...@ttelmah.demon.co.uk http://www.ttelmah.demon.co.uk/ |
| A beard! A beard! cried Fly Nicholas.'By God, that's a good one!'|
| (Chaucer) |
Rodrigo Ventura
Craig P Earls wrote:
> To directly access hardware in NT, or Linux (or any other real
> operating system for that matter (DOS and Win 95 barely qualify) you
> must write a kernel level device driver. This is difficult.
NOT TRUE! (I agree that DOS and Win 95 barely qualify to OS, though)
In Linux, there are the ioperm() and the stronger iopl() syscalls that
allow a user program to access the hardware directly. No need to write
kernel code! ioperm() unprotects ranges of IO port addresses, while
iopl() just opens everything. Of course, you'll need root permissions
(or setuid flag) in order to do this.
Regards,
--
*** Rodrigo Martins de Matos Ventura, alias <Yoda>
*** yo...@isr.ist.utl.pt, http://www.isr.ist.utl.pt/~yoda
*** Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, Portugal
*** PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A