raw parallel port access

[BRC]

After quite a few days of perusing wine
doc/source/config/mailing lists, I have found very
scant references to accessing the raw parallel ports
using wine.

I am running FC2 linux (up-to-date) and have confirmed
I can access the parallel port (dongle) presented to
VMWare running a Windows 2000 guest OS successfully
ie. access to /dev/parport0 works.

I can also run all the programs included with 
wine-20040914 as well as some tests I wrote with mingw
as well as those I compiled with VC++.  The latter
just cannot access the parallel port as VMWARE can
though it runs normally until it can't access the
dongle on LPT1.

I've tried running as root too to no avail.  What am I
missing?  If no answer is available, can someone at
least point to the relevant sources so I can puzzle it
out further:  I am determined.

Running with WINEDEBUG=+io yields no output yet
WINEDEBUG=+all spews the world as expected.

The relevant setup options I've played with are:

ln -s /dev/parport0 ~chris/.wine/dosdevices/lpt1

When I run as root, I symlink ~root/.wine ->
~chris/.wine for convenience.

The config ( I go back and forth on [ports] as I've
found different messages/doc professing both).

[parallelports]
"lpt1" = "/dev/lp0"

[ppdev]
;; key:  io-base of the emulated port
;; value : parport-device{,timeout}
;; timeout for auto closing an open device ( not yet
implemented)
"378" = "/dev/parport0"
;;"278" = "/dev/parport1"
;;"3bc" = "/dev/parport2"

[spooler]
"FILE:" = "tmp.ps"
"LPT1:" = "|lpr"
"LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred
-q -"
"LPT3:" = "/dev/lp3"

[ports]
"read"  = "0x779,0x379,0x280-0x2a0"
"write" = "0x779,0x379,0x280-0x2a0"

#"read" = "0x378,0x379,0x37a,0x37c,0x77a"
#"write" = "0x378,0x379,0x37a,0x37c,0x77a"

Thanks!

Chris

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

[Uwe Bonnes]

> > > > > "BRC" == BRC   writes:

BRC> After quite a few days of perusing wine doc/source/config/mailing
    BRC> lists, I have found very scant references to accessing the raw
    BRC> parallel ports using wine.

How does your windows program try to access the port?

Probably by callig DeviceIOControl() on some unknown VXD. As has been told
several times in the last days, wine is for running windows user programs,
not for running windows kernel drivers. If you know what the VXD does and
what interfaces it exposes, you can try to recreate/reimplement that VXD
with Linux.

If your program is an old Win31 program, accessing the port directly, wine
captures these accesses and either translates them in an hopefully
acceptable way.

Bye

[Primorec]

I am trying to achieve the same goal as Chris to no avail. My Windows
program uses INPOUT32.DLL for talking to the parallel port.  Does this
dll belongs to "some unknown VXD" ?

Regards

Igor

On Wed, 22 Sep 2004 09:49:30 +0200, Uwe Bonnes
 wrote:
> > > > > > "BRC" == BRC   writes:
> BRC> After quite a few days of perusing wine doc/source/config/mailing
> BRC> lists, I have found very scant references to accessing the raw
> BRC> parallel ports using wine.
>
> How does your windows program try to access the port?
>
> Probably by callig DeviceIOControl() on some unknown VXD. As has been told
> several times in the last days, wine is for running windows user programs,
> not for running windows kernel drivers. If you know what the VXD does and
> what interfaces it exposes, you can try to recreate/reimplement that VXD
> with Linux.
>
> If your program is an old Win31 program, accessing the port directly, wine
> captures these accesses and either translates them in an hopefully
> acceptable way.
> Bye
>
> Uwe Bonnes                [e-mail]
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------

[Uwe Bonnes]

> > > > > "Primorec" == Primorec   writes:

Primorec> I am trying to achieve the same goal as Chris to no avail. My
    Primorec> Windows program uses INPOUT32.DLL for talking to the parallel
    Primorec> port.  Does this dll belongs to "some unknown VXD" ?

http://www.logix4u.net/inpout32.htm

tells:

2) Using a kernel mode driver embedded in the dll

However 
http://www.logix4u.net/inpout_theory.htm
shows that when running under win9x, it should use inp/outp. 
So try setting the wine version to win98. With the ppdev part configures
right, and you as user having access right to the configured /dev/parport,
things should work. Look with WINEDEBUG=+io,+int,+vxd
This could be your first approach.

Regarding inpout32:
The source can be found on http://www.logix4u.cjb.net. The dll only exposes
two functions:

LIBRARY INPOUT32

EXPORTS

Inp32           @1
Out32           @2

So to reimplement it in Wine, you only need create a new wine dll named
INPOUT32. All the dll implementation has to do is to forward these functions
to DOSVM_inport and DOSVM_outport. Can I leave the implementation to you?

However the way the original dll loads the hardwrae driver is very
instructive!

Bye

[Andreas Mohr]

Hi,

On Wed, Sep 22, 2004 at 10:50:24AM +0200, Uwe Bonnes wrote:
> Regarding inpout32:
> The source can be found on http://www.logix4u.cjb.net. The dll only exposes
> two functions:
>
> LIBRARY INPOUT32
>
> EXPORTS
>
> Inp32           @1
> Out32           @2
>
> So to reimplement it in Wine, you only need create a new wine dll named
> INPOUT32. All the dll implementation has to do is to forward these functions
> to DOSVM_inport and DOSVM_outport. Can I leave the implementation to you?

In this case it's actually justified, I think (since this DLL is used
by many, many programs and the Wine implementation would be extremely small).

However since I think that we'll have many similar cases of non-Windows DLL
(and VxD!) rewrites in Wine (almost always for hardware interfacing),
should this be done in dlls/oem_drivers/ or so?
This might need Makefile structure changes, though.
I'd hate to see the main dlls/ directory polluted with dozens of vendor
DLL reimplementations...

Andreas Mohr

[Mike Hearn]

> should this be done in dlls/oem_drivers/ or so?

+1 from me, though I'd vote for a new top level directory,

thirdparty/

or somesuch where we can move DLLs that aren't a part of the core 
Windows OS but apps need anyway. There are some DLLs in dlls/ that are 
basically a mystery - for instance, monodbg.vxd. The comments say it was 
for Origin games but it appears that the implementor (was it marcus?) 
doesn't actually know what it's for either!

"thirdparty" is a bit of an awkward name. Maybe vendor?

[Andreas Mohr]

Hi,

On Wed, Sep 22, 2004 at 01:21:56AM -0700, Primorec wrote:
> I am trying to achieve the same goal as Chris to no avail. My Windows
> program uses INPOUT32.DLL for talking to the parallel port.  Does this
> dll belongs to "some unknown VXD" ?

Who knows... there are many different methods to get parallel port access
on Windows.

Run winedump and strings on it to find out more.

Andreas Mohr