If the bit-wise manipulation of the parallel port is exposed as some kind of interface under Win9x,
Yes. It's exposed by enabling access to all io ports by default.
we can probably do better than inb() / outb().
You can't do any better than that. If an application does inb()/outb(), the ioperm method is the only one that makes sense (when you run things on ia32).
Advantages of using ppdev over simple inb() / outb() are:
should support [*] cross-architecture (arm, alpha, powerpc, ...)
That'd be good for winelib only or wine-with-emulator (bochs? qemu?).
should support [*] some esoteric devices (USB-parallel converters, ...)
At a huge performance penalty ;)
The overhead in doing a syscall isn't significant as any outb() operation takes ~1us anyway
AFAIK, the overhead stems from the fact that instead of a machine instruction you have to: - process an exception in the kernel, which then signals SIGSEGV to the process - invoke the signal handler - determine what's up and disassemble the instruction at CS:EIP - invoke a function/syscall based on the disassembled instruction
If this isn't dog slow, I don't know what is. I wasn't entirely clear, the syscall is the least of our worries in fact :)
I suspect most programs designed to work under Win98 just hit the hardware, so obtaining permissions (doing ioperm() as root, for example) should work. If we have some mechanism for catching the program doing either inb() or outb(), then we could provide a better implement via the ppdev interface.
At the cost of slowing things down. For devices that bit bang data (like programmers), this makes things unacceptably slow.
I believe (from limited exposure) that under Win2k, accessing the parallel port is "more difficult". Applications may use some kind of .sys driver to expose a bit-wise interface to the parallel port, which may be part of some "standard". I guess this could be implemented using ppdev by some enthusiastic person.
Yep, that's another story entirely.
Cheers, Kuba