Hi Holly, there's no UI to do this yet, as you found out.
By default, you don't need to do any config, at least on Linux. COM1 defaults to /dev/ttyS0, COM2 to /dev/ttyS1, and so on. LPT1 defaults to /dev/lp0.. you get the idea.
If you want to change it, you can create a link in .wine/dosdevices from, say, com1 to the device you want it to use. So if for example you wanted com1 to be /dev/cua0, you should have this in dosdevices: lrwxrwxrwx 1 juan juan 9 Oct 4 08:15 com1 -> /dev/cua0
Hope that helps, --Juan
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Juan Lang wrote:
Hi Holly, there's no UI to do this yet, as you found out.
By default, you don't need to do any config, at least on Linux. COM1 defaults to /dev/ttyS0, COM2 to /dev/ttyS1, and so on. LPT1 defaults to /dev/lp0.. you get the idea.
If you want to change it, you can create a link in .wine/dosdevices from, say, com1 to the device you want it to use. So if for example you wanted com1 to be /dev/cua0, you should have this in dosdevices: lrwxrwxrwx 1 juan juan 9 Oct 4 08:15 com1 -> /dev/cua0
Hope that helps, --Juan
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Also it would be nice to include any info as to the status of using the parallel port to interface into devices like: dongles with are a software unlock key. eprom programmers which require a special driver on NT to access the hardware.
I think the current status is that it will not work or I have not found the correct solution.
Several years ago I had my programmer and one other device working with dosemu and or bochs but after I updated from Mandrake 8.2 I think I have not been able to get it working again. I think the kernel has changed on hardware access and will require special driver to allow simulated direct hardware access.
Paul
Several years ago I had my programmer and one other device working with dosemu and or bochs but after I updated from Mandrake 8.2 I think I have not been able to get it working again. I think the kernel has changed on hardware access and will require special driver to allow simulated direct hardware access.
man ioperm 2
You can use it via a suid-root wrapper program that acquires the port access, drops privileges and executes your wine programs. Works for me. Of course it doesn't work if the windows program needs the special driver to talk to the device. It does work for those old-style windows95 applications that expect to be able to talk to the ports directly.
Cheers, Kuba
"Kuba" == Kuba Ober kuba@mareimbrium.org writes:
>> Several years ago I had my programmer and one other device working >> with dosemu and or bochs but after I updated from Mandrake 8.2 I >> think I have not been able to get it working again. I think the >> kernel has changed on hardware access and will require special driver >> to allow simulated direct hardware access.
Kuba> man ioperm 2
Kuba> You can use it via a suid-root wrapper program that acquires the Kuba> port access, drops privileges and executes your wine Kuba> programs. Works for me. Of course it doesn't work if the windows Kuba> program needs the special driver to talk to the device. It does Kuba> work for those old-style windows95 applications that expect to be Kuba> able to talk to the ports directly.
For both the serial and the parallel port, direct port access can be handled by ioctl() to the devices. So doing direct port access via in() and out() while running as root is only the last resort...
>> Several years ago I had my programmer and one other device working >> with dosemu and or bochs but after I updated from Mandrake 8.2 I >> think I have not been able to get it working again. I think the >> kernel has changed on hardware access and will require special >> driver to allow simulated direct hardware access. Kuba> man ioperm 2 Kuba> You can use it via a suid-root wrapper program that acquires the Kuba> port access, drops privileges and executes your wine Kuba> programs. Works for me. Of course it doesn't work if the windows Kuba> program needs the special driver to talk to the device. It does Kuba> work for those old-style windows95 applications that expect to be Kuba> able to talk to the ports directly.For both the serial and the parallel port, direct port access can be handled by ioctl() to the devices. So doing direct port access via in() and out() while running as root is only the last resort...
The ioperm() method is more general (works for any port, not only for serial/parallel devices) and also faster (doesn't do a syscall). It requires no changes to the win95-style applications. Also, ioperm() doesn't imply running as root. You only need a trivial (couple lines long) suid-root wrapper written in C, that then invokes your regular windows application using wine.
Cheers, Kuba
Hi all,
If the bit-wise manipulation of the parallel port is exposed as some kind of interface under Win9x, we can probably do better than inb() / outb(). Under Linux, there's ppdev (a user-land bit-twiddling interface since 2.4-series kernels).
Advantages of using ppdev over simple inb() / outb() are: should support [*] cross-architecture (arm, alpha, powerpc, ...) should support [*] some esoteric devices (USB-parallel converters, ...) only need permission to open /dev/parport0 (not necessarily root or CAP_SYS_RAWIO).
[*] - I've not tested either of these, though.
The overhead in doing a syscall isn't significant as any outb() operation takes ~1us anyway. There may be an increased risk of context-switching after the syscall (please correct me if I'm wrong here), which would lead to the ppdev being apparently slower. But this, in itself, shouldn't be a problem.
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.
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.
Cheers,
Paul.
On Thursday 06 Oct 2005 14:14, Kuba Ober wrote:
>> Several years ago I had my programmer and one other device working >> with dosemu and or bochs but after I updated from Mandrake 8.2 I >> think I have not been able to get it working again. I think the >> kernel has changed on hardware access and will require special >> driver to allow simulated direct hardware access. Kuba> man ioperm 2 Kuba> You can use it via a suid-root wrapper program that acquiresthe Kuba> port access, drops privileges and executes your wine Kuba> programs. Works for me. Of course it doesn't work if the windows Kuba> program needs the special driver to talk to the device. It does Kuba> work for those old-style windows95 applications that expect to be Kuba> able to talk to the ports directly.
For both the serial and the parallel port, direct port access can be handled by ioctl() to the devices. So doing direct port access via in() and out() while running as root is only the last resort...
The ioperm() method is more general (works for any port, not only for serial/parallel devices) and also faster (doesn't do a syscall). It requires no changes to the win95-style applications. Also, ioperm() doesn't imply running as root. You only need a trivial (couple lines long) suid-root wrapper written in C, that then invokes your regular windows application using wine.
Cheers, Kuba
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
Hi Kuba,
On Thursday 06 Oct 2005 23:23, Kuba Ober wrote:
we can probably do better than inb() / outb().
You can't do any better than that [It] is the only one that makes sense (when you run things on ia32).
... and when you're not on an ia32 platform with a superIO chip?
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?).
Yup, both. A ported applications (via winelib or qemu) should work under any Linux architecture. Unfortunately, it would be a Linux-specific solution; *-BSDs have their own interface.
should support [*] some esoteric devices (USB-parallel converters, ...)
At a huge performance penalty ;)
But it would work, 's my point. The performance of parallel-over-USB is a separate issue.
Legacy devices (such as parallel ports) are being gradually faded out. So writing code that requires a SuperIO chip is not best.
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 think you may be confusing some other activity (maybe an invalid memory access?). A syscall is pretty simple. The application does some bookkeeping and calls int(errupt) 0x80, triggering the switch from user-land to kernel-land. The kernel then picks up the request and carries on. Its described here[1], although the details may have changed slightly with more recent kernels. There's no signalling (in the Unix user-land sense) going on.
[1] http://www.tldp.org/LDP/khg/HyperNews/get/syscall/syscall86.html
Overhead is "currently" (measured for 2.4.0) at slightly under 0.4us (see [2]). For 2.6-series kernels it may have gone down slightly further, but 0.4us would seem a reasonable upper-bound. Assuming the kernel driver is reasonably written, I'd make a complete guess that the overhead is between 0.4 and 0.6us (although I should benchmark the number :^).
[2] http://cs.nmu.edu/~benchmark/index.php?page=null_call
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 can't say I share that experience (about being unacceptably slow, that is). A 40-60% increase in overhead for a single instruction would be definitely noticeable, but only if this is the bottleneck in the program. Other activity takes longer (c.f. context-switching in [2], for example). Even just calling functions take order of 100ns (on my ~700MHz laptop). The time between successive changes of parallel port state might be (much) larger than the 400-600ns overhead in using kernel routines, so the overhead becomes less significant. Of course, this would be application specific.
The worse-case would be something driving the parallel port as a square-wave generator: you'd get the full 40-60% drop in performance (assuming all the above numbers). Perhaps slightly more realistically, the PLIP interface is reckoned[3] to have a 1.2Mbit/s bandwidth, corresponding to a ~3.33us turn-around time. Adding a 0.4-0.6us overhead would reduce the bandwidth to between 1.1Mbit/s and 1.0Mbit/s (8-16% performance drop). Would this matter? No, because if it did you'd go out and buy 100baseT cards and achieve far greater performance (or Myrinet, or ...).
[3] http://yara.ecn.purdue.edu/~pplinux/ppcluster.html
For the particular use-case you have in mind, my understanding is that programmers often require some additional delay mechanism to allow the EPROM to keep up (certainly for write, probably for reads too). This would reduce the impact of the performance hit, perhaps acceptably (or even imperceptibly) so.
Does all this matter? Probably not. I would bet you this smartee here that if a program is worrying about ns response of some function, then that function its good enough, and that some better "higher level" algorithmic optimisation would have a much larger benefit (e.g. ethernet vs PLIP).
Cheers,
Paul.
(apologies for the overly long email!)
we can probably do better than inb() / outb().
You can't do any better than that [It] is the only one that makes sense (when you run things on ia32).
... and when you're not on an ia32 platform with a superIO chip?
That's a moot point. Then you have to emulate ia32 to run windows programs anyway.
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?).
Yup, both. A ported applications (via winelib or qemu) should work under any Linux architecture. Unfortunately, it would be a Linux-specific solution; *-BSDs have their own interface.
If you have access to the source it's simpler to write a native device driver. The only reason d'etre of running legacy windows apps that bit-bang things via direct port i/o is that there's no documentation for the hardware.
should support [*] some esoteric devices (USB-parallel converters, ...)
At a huge performance penalty ;)
But it would work, 's my point. The performance of parallel-over-USB is a separate issue.
Legacy devices (such as parallel ports) are being gradually faded out. So writing code that requires a SuperIO chip is not best.
Sure. But then you're talking about the driver code, not user code.
I think this discussion needs some clarification, as there are distinct use cases:
Case 1. Running legacy ia32 windows code that does port I/O on ia32. Case 2 : Running such legacy code on non-ia32. Case 3. Porting such apps over to winelib when the source code is available.
For (1) ioperm is the only reasonable solution. The hardware is there for you to do the job, so why bother emulating existing functionality.
For (2) you are doing instruction-by-instruction emulation, or at least block translation anyway, i.e. wine running with an ia32 emulator. So it doesn't really matter what you do, as there's no ia32 and likely no direct access to the 'ports' on target hardware. If the target hardware is a serial/parallel port, the motherboard chipset is likely to implement it in a wholly different way (or not at all!). The only chance for 1:1 plug-in compatibility is when target hardware is a PCI card. I don't know how many direct-IO win32 apps are there for PCI cards that are relevant enough to be moved to a more up-to-date non-ia32 hardware.
For (3), the simplest thing to do is to tear off the driver code and port it to the platform's driver infrastructure. Using winelib for any sort of emulation there is a waste of resources.
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 think you may be confusing some other activity (maybe an invalid memory access?).
How's an invalid memory access different from a legacy win32 application trying to do direct port IO without sufficient privileges?
1. You have an IN or OUT opcode in the code. When ioperms are not set, the CPU raises an exception. 2. That exception results in SIGSEGV being signalled to the process. 3. The signal handler has to determine what type of an exception is it. I don't recall whether the exception data has information about the type of exception, but in any event the opcode has to be disassembled just to get the port address and data operands. 4. Then in all likelihood the operands are not immediate constants, so the relevant registers have to be interrogated from the saved below-signal process context. 5. A port-to-filehandle look up has to be performed, in order to determine which open device has to handle that port I/O. 6. An ioctl has to be invoked on that handle. 7. Kernel's ioctl machinery is invoked, and the ioctl percolates to the driver code. Remember that ioctl requests can be handled by different layers of the driver stack, so it has literally to go the slowest path, through all the intermediate layers down to the driver. That's a bunch of switch statements to go through. 8. An actual port I/O is done by the driver, in case of 1:1 mapping, or a request is put to the bus subsystem if a legacy device (like a parallel port) is being handled via a usb/firewire "converter".
This code path is on the order of thousands of instructions long. If you have a legacy ia32 app running under wine on ia32 hardware, there's no point in doing all that in place of a simple port I/O.
A syscall is pretty simple.
Of course. But it's not "just about a syscall". And besides, even a syscall that has just a "ret" on the kernel side is still equivalent to say 40-50 "average" instructions.
At the cost of slowing things down. For devices that bit bang data (like programmers), this makes things unacceptably slow.
I can't say I share that experience (about being unacceptably slow, that is). A 40-60% increase in overhead for a single instruction would be definitely noticeable,
You're talking about a 3 orders of magnitude slow down, not a 40-60% increase.
but only if this is the bottleneck in the program.
When you do bit-banging, that's all that counts. The least a bit-banging application needs to do is to have two port accesses per bit (to flip the clock back and forth). Suppose you need to move 10 kilobytes in that fashion. That's 160 thousand travels through the points 1-8 described above. That'd be some 160 million equivalent instructions, assuming that the 1-8 path takes as much as a 1000 "average" instructions. How does 160 million instructions compare to say 50 thousand?
Putting that in real-life terms, if you're bit-banging to a programmable logic device that's on a PCI card, when you interleave bit-banging code with parse logic that works on a jedec file, you can easily get 5 bits/us on modern hardware.
Now, I'm not saying that there are any useful legacy windows apps that do just that and that would benefit from wine being fast in that respect.
What I'm saying is that for case (1) from the first list above, the ioperm() solution is the only one that makes sense. For other cases, you very likely have to do some hardware emulation anyway, and then it's not general enough to go into wine anyway. Maybe emulating the old-and-good parallel port would be sensible, but that's about as far as one can sensibly go.
The worse-case would be something driving the parallel port as a square-wave generator: you'd get the full 40-60% drop in performance (assuming all the above numbers).
Last time I checked, I could do about 5 million 16-bit writes per second onto an I/O port on a 5V, 32MHz PCI card sitting in my otherwise idle and not very new PIII system. Maybe I was just very lucky, then, but I don't buy the argument that executing steps 1-8 above can be done 5 million times a second.
The real question is: what applications are out there that need "hardware" support in wine. One likely class is applications with usb minidrivers. Those should be easy to handle via libusb, after implementing the necessary WDM functionality in userspace (in wine). Presumably some code for that can be leeched from ndiswrapper and any similar projects.
Cheers, Kuba
-
Juan Lang -
Kuba Ober -
paul -
Paul Millar -
Paul Millar -
Uwe Bonnes