Need help to get LCDHype flying with Parallel-Port

[lsmod]

Hello together,

i want to run LCDHype in Linux under wine, because there is no adequate other program that supports graphically LCD-Displays.

I already opened a discussion in the forum of LCDHype (sorry - is in german language):
http://lcdhype.condense.de/index.php?showtopic=4963

I already found an older version (V 0.6) of LCDHype that installs and the frontend is up and running.
But now i am at the point where i need to get the Parallel-Port running.
Many LCD-Displays are connected directly to LPT1 also my KS108.

The developer of LCDHype is also interested to get this running and he helps as much as possible.
Normally LCDHYpe is using the free SPPort95NT Driver to get direct access to the Parport.
But this driver fails to load in wine and that does not surprise me.

Now is the question how we can get direct access to the Parport in Wine?
I already found and tested the hints from here:
http://wiki.jswindle.com/index.php/Wine ... allel_Port
But it's not understandable where the difference between /dev/parport0 and /dev/lp0 should be?

Our last try was to test the access with a small Testprogram written by ViRuSTriNiTy in C.
But i didn't have success and now we don't know how to progress?

[vitamin]

Now is the question how we can get direct access to the Parport in Wine?
I already found and tested the hints from here:
http://wiki.jswindle.com/index.php/Wine ... allel_Port
But it's not understandable where the difference between /dev/parport0 and /dev/lp0 should be?

Those instructions look complete to me. If done correctly (and if that part still works under Wine) your program should be able to access in/out ports assigned to the parallel port. As for devices - just make sure your user have full access to them:

Code: Select all

sudo chmod a+rw /dev/parport0
sudo chmod a+rw /dev/lp0

[lsmod]

Thank you for youe answer.

I tested now with another version of the testprogram and it runs without any errors.
But only in the "Windows ME" mode and not in "Windows 2000".

Can you tell me the difference?

At this time i can't say if the program lcdhype.exe itself will run proper in "Windows ME".
It starts, but some content is not displayed in parts of the window.
The better way is to start it under "windows 2000", but it seems not possible to get access to the parport here?

Running programs in wine that will have access to an interface is not easy.
Is there any documentation what to do under which emulation?

[vitamin]

But only in the "Windows ME" mode and not in "Windows 2000".

My guess it tries to use drivers which of course won't work on Wine.

[lsmod]

So it is only possible to get access to ParPort and SerPort with an wine-emulation below "Windows 2000" ?

In principle it should be possible to allow access to the interfaces also in the emulation of the NT era.
If some kind of access exists, it could be implemented in LCDHype now.

[vitamin]

So it is only possible to get access to ParPort and SerPort with an wine-emulation below "Windows 2000" ?

Correct. Wine doesn't implement enough of kernel to let NT+ drivers access any hardware. Unless those drivers just open up access to some I/O ports from within kernel.

[lsmod]

Unless those drivers just open up access to some I/O ports from within kernel.

Yes - that's what i mean.
We only need the possibility to access the I/O ports in NT+ emulations.

It seems that most of the applications are using this free driver:
http://lcdhype.condense.de/stuff/lcdhyp ... custom.zip

And in LCDHype this two functions are used:

Code: Select all

UCHAR DLPORT_API
DlPortReadPortUchar(
    IN ULONG Port
    );

VOID DLPORT_API
DlPortWritePortUchar(
    IN ULONG Port,
    IN UCHAR Value
    );

Here we only need a workaround to implement this two access methods.
With this driver or with an own one. Or with a workaround.
Is it possible to get direct access to /dev/lp0 in wine in NT+ emulations?

Of course i understand that it is to much work to implement this I/O kernel stuff for only some applications who need this.
But on the other hand I/O access in wine is only possible for applications which are designed below NT+ now. That's really not the standard 2010.
And the question is which applications are interesting to run in wine?
From my experience this are applications i don't get in linux, because they are very special.
And all this applications which are driving special hardware are typical for this.

[vitamin]

And in LCDHype this two functions are used:

Code: Select all

UCHAR DLPORT_API DlPortReadPortUchar(IN ULONG Port);
VOID DLPORT_API DlPortWritePortUchar(IN ULONG Port, IN UCHAR Value);

So it's communicating with the driver and actually doing I/O from the kernel...

No, those won't work. As I said before Wine missing 90% of what's required to make that work. The best you can do is create fake driver and some how fool your program into using it instead of real one. Or even better, if you using a dll as an interface to those drivers make a fake dll.

[lsmod]

My problem is that i am not a C-Programmer.
I already understand that the I/O communication is not implemented in wine in NT+ emulations.

The programmer of LCDHype is programming in C and he also would write a driver dll (or direct access in LCDHype), when he knows what he must do.
But this is not so easy here, because this "driver" has not to work like in windows and it is not the same like working in linux.
What i mean is the question in which way the program is "captured" in wine?

How this driver must be written that it has the needed access to the parallel port?
We don't have an idea how to bridge between the windows application through wine to the linux kernel?

[vitamin]

We don't have an idea how to bridge between the windows application through wine to the linux kernel?

As you said yourself - Wine already does that if you trying to access ports win9x way (just talk directly to I/O ports nothing special required). Write your dll that replaces the LCDHype's one. And make it talk directly to I/O ports.

[lsmod]

As you are describing it, the program can run in "Windows 2000" and the access should work in the "Windows ME" way.

I already has wrote that ViRuSTriNiTy has written a small test program with parport access.
http://lcdhype.condense.de/index.php?ac ... 50&index=0

Here the shell output in "Windows ME" emulation:

> wine ParPortTest.exe read 888
Data read from parallel port is 255



> wine ParPortTest.exe write 888 255
Data written to parallel port is 255

And here the shell output in "Windows 2000" emulation:

> wine ParPortTest.exe read 888
wine: Unhandled privileged instruction at address 0x401074 (thread 0025), starting debugger...
Unhandled exception: privileged instruction in 32-bit code (0x00401074).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:00401074 ESP:0032fe90 EBP:0032fee8 EFLAGS:00010202( - 00 - -RI1)
EAX:00000378 EBX:7eddc156 ECX:00000000 EDX:00000378
ESI:00000002 EDI:00521da0
Stack dump:
0x0032fe90: 00521dda 00000002 00000893 004013b4
0x0032fea0: 00000003 00521da0 00521df0 704467d0
0x0032feb0: 7bf012e0 001104d0 7ee4c7dc c0000096
0x0032fec0: 00000000 00000005 00000000 7bf012e0
0x0032fed0: 0032feac 0032f968 0032ff14 00402420
0x0032fee0: 70362dc8 00000000 0032ffe8 7ee07a5d
Backtrace:
=>0 0x00401074 in parporttest (+0x1074) (0x0032fee8)
1 0x7ee07a5d start_process+0x158(arg=(nil)) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/kernel32/process.c:914] in kernel32 (0x0032ffe8)
2 0xf7e5ad3f wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x00401074: inb %dx,%al
Modules:
Module Address Debug info Name (17 modules)
PE 400000- 410000 Export parporttest
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7ed88000-7eed3000 Dwarf kernel32<elf>
\-PE 7eda0000-7eed3000 \ kernel32
ELF 7eed3000-7eede000 Deferred libnss_files.so.2
ELF 7eede000-7eee8000 Deferred libnss_nis.so.2
ELF 7eee8000-7ef00000 Deferred libnsl.so.1
ELF 7ef00000-7ef24000 Deferred libm.so.6
ELF 7ef44000-7f000000 Deferred ntdll<elf>
\-PE 7ef60000-7f000000 \ ntdll
ELF f7cc5000-f7cc9000 Deferred libdl.so.2
ELF f7cc9000-f7e1b000 Deferred libc.so.6
ELF f7e1b000-f7e32000 Deferred libpthread.so.0
ELF f7e34000-f7e37000 Deferred iso8859-1.so
ELF f7e37000-f7e40000 Deferred libnss_compat.so.2
ELF f7e52000-f7f8f000 Dwarf libwine.so.1
ELF f7f92000-f7fb1000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008
00000009 0
0000000c
00000019 0
0000000e 0
0000000d 0
00000016
0000001b 0
0000001a 0
00000018 0
00000017 0
0000001c
0000001d 0
00000024 (D) E:\DL\ParPortTest.exe
00000025 0 <==
Backtrace:
=>0 0x00401074 in parporttest (+0x1074) (0x0032fee8)
1 0x7ee07a5d start_process+0x158(arg=(nil)) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/kernel32/process.c:914] in kernel32 (0x0032ffe8)
2 0xf7e5ad3f wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)

> wine ParPortTest.exe write 888 255
wine: Unhandled privileged instruction at address 0x4010ee (thread 0029), starting debugger...
Unhandled exception: privileged instruction in 32-bit code (0x004010ee).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:004010ee ESP:0032fe88 EBP:0032fee8 EFLAGS:00010216( - 00 -RIAP1)
EAX:000003ff EBX:000000ff ECX:00000000 EDX:00000378
ESI:00000002 EDI:00521da0
Stack dump:
0x0032fe88: 0040b3d8 00521de0 00521de8 7eddc156
0x0032fe98: 00000893 004013b4 00000004 00521da0
0x0032fea8: 00521df8 7d71f02f 7bf012e0 001104e8
0x0032feb8: 7ee4c7dc c0000096 00000000 00000005
0x0032fec8: 00000000 7bf012e0 0032feac 0032f960
0x0032fed8: 0032ff14 00402420 7d03ba37 00000000
Backtrace:
=>0 0x004010ee in parporttest (+0x10ee) (0x0032fee8)
1 0x7ee07a5d start_process+0x158(arg=(nil)) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/kernel32/process.c:914] in kernel32 (0x0032ffe8)
2 0xf7e0ad3f wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
0x004010ee: outb %al,%dx
Modules:
Module Address Debug info Name (17 modules)
PE 400000- 410000 Export parporttest
ELF 7bf00000-7bf03000 Deferred <wine-loader>
ELF 7ed88000-7eed3000 Dwarf kernel32<elf>
\-PE 7eda0000-7eed3000 \ kernel32
ELF 7eed3000-7eede000 Deferred libnss_files.so.2
ELF 7eede000-7eee8000 Deferred libnss_nis.so.2
ELF 7eee8000-7ef00000 Deferred libnsl.so.1
ELF 7ef00000-7ef24000 Deferred libm.so.6
ELF 7ef44000-7f000000 Deferred ntdll<elf>
\-PE 7ef60000-7f000000 \ ntdll
ELF f7c75000-f7c79000 Deferred libdl.so.2
ELF f7c79000-f7dcb000 Deferred libc.so.6
ELF f7dcb000-f7de2000 Deferred libpthread.so.0
ELF f7de4000-f7de7000 Deferred iso8859-1.so
ELF f7de7000-f7df0000 Deferred libnss_compat.so.2
ELF f7e02000-f7f3f000 Dwarf libwine.so.1
ELF f7f42000-f7f61000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
00000008
00000009 0
0000000c
00000019 0
0000000e 0
0000000d 0
00000016
0000001b 0
0000001a 0
00000018 0
00000017 0
0000001c
0000001d 0
00000028 (D) E:\DL\ParPortTest.exe
00000029 0 <==
Backtrace:
=>0 0x004010ee in parporttest (+0x10ee) (0x0032fee8)
1 0x7ee07a5d start_process+0x158(arg=(nil)) [/mnt/ramdisk/wine-1.1.17~winehq1/dlls/kernel32/process.c:914] in kernel32 (0x0032ffe8)
2 0xf7e0ad3f wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)

Here it will not work.
But my hope was to use "Windows 2000" emulation because LCDHype runs better there.

[Martin Gregorie]

On Mon, 2010-01-25 at 08:59 -0600, lsmod wrote:

My problem is that i am not a C-Programmer.
I already understand that the I/O communication is not implemented in wine in NT+ emulations.

The programmer of LCDHype is programming in C and he also would write a driver dll (or direct access in LCDHype), when he knows what he must do.
But this is not so easy here, because this "driver" has not to work like in windows and it is not the same like working in linux.
What i mean is the question in which way the program is "captured" in wine?

How this driver must be written that it has the needed access to the parallel port?
We don't have an idea how to bridge between the windows application through wine to the linux kernel?

Linux traditionally names its parallel ports /dev/lp0, /dev/lp1, ...
WINE's equivalent would be to put symbolic links in .wine/

You could try writing the driver to write to LPTn: and putting a symlink
in .wine/dosdevices:

ln -s /dev/lp1 LPT2:

but beware that by default all parallel ports are owned by root.
Read/write access to them is restricted to root and members of the lp
group. This means that either you'll need to include the user where
you're running LCDHype in the lp group or you'll need to extend your
parport's access rights at boot time. There are two choices here: either
by adding a chmod command to /etc/rc.d/rc.local "chmod uga+rw /dev/lp1"
or by adding a local rule to /etc/udev/rules.d to extend its access
permissions.

If none of this works there is a less obvious way:

- write the .dll to send commands and accept responses over a socket.

- write a Linux C server that talks to your device over the parport
and uses a socket to accept commands and return responses to the .dll.
This should be a pretty simple program to write since it only needs to
deal with a single socket connection at a time. It goes without saying
that, unless the parport is supplied via the .dll, it will need a way
to configure the port it is to use, but that's also easy enough.

- If you treat the server as a daemon (start it at boot time and run it
as a root process) or run it under the 'super daemon' xinetd it will
work with the parport's default access permissions: otherwise my
previous remarks about access permissions are relevant to this
approach.


Martin

[lsmod]

Thank you for the explanation.

I already created these symlinks in .wine/dosdevices.
But are they necessary?
The keys in the registry are pointing direct to the port 378h and the Testprogramm also attempts to write direct to this address.

In my tests there where no error message and i have done this tests with my personal user and not as root.
I am running Debian Lenny (stable) and here the group lp exists.
Now i added my user to this group.

In the next step i will try to measure if write attempts will cause toggling the signals on the data bits.

Have i understand correct that your proposal with the daemon and socket is for running the application in NT+ emulation?

[Martin Gregorie]

On Mon, 2010-01-25 at 10:15 -0600, lsmod wrote:

Thank you for the explanation.

I already created these symlinks in .wine/dosdevices.
But are they necessary?

They are needed to translate LPTn:, which is all a well-written Windows
program should accept as a printer name, to correct Linux /dev/lpn
parallel ports.

The keys in the registry are pointing direct to the port 378h and the
Testprogramm also attempts to write direct to this address.

You are doing something else: bypassing the Linux drivers by attempting
to talk direct to the hardware. While this may be acceptable with older
Windows versions its not a good idea with Linux.

Have i understand correct that your proposal with the daemon and
socket is for running the application in NT+ emulation?

It shouldn't matter because AFAIK Wine supports Windows sockets for all
Windows emulations. Sockets is a reliable way of communicating between
Windows programs and Linux native programs.


Martin

[lsmod]

You are doing something else: bypassing the Linux drivers by attempting
to talk direct to the hardware. While this may be acceptable with older
Windows versions its not a good idea with Linux.

What is a good idea to solve the problem in Linux?

At this time i have no idea how the parport is implemented in the Linux-Kernel.
But i am optimistic that the kernel will not allow something that is not good for him.

It shouldn't matter because AFAIK Wine supports Windows sockets for all
Windows emulations. Sockets is a reliable way of communicating between
Windows programs and Linux native programs.

Of course this is a universal solution to cover all the problems.
But a separate Linux-daemon is needed and it would be better if we could avoid this, because someone must write him in C.
But i will search if maybe someone already has written one.

Karsten

[Martin Gregorie]

On Mon, 2010-01-25 at 12:08 -0600, lsmod wrote:

Martin Gregorie wrote:

You are doing something else: bypassing the Linux drivers by attempting
to talk direct to the hardware. While this may be acceptable with older
Windows versions its not a good idea with Linux.

What is a good idea to solve the problem in Linux?

I think there are only three options:

1) Live with always setting the Wine windows version to Windows 98/ME
and change the .dll 'driver' to use the same parport access methods
as the test program

2) Try changing the test program to open /dev/lpn instead of the
hardware address. If/when it works, use these parport access
methods in the .dll 'driver'.

3) Put the 'driver' code in a native Linux server that's accessed using
sockets and make the .dll into a minimal shell that presents the API
expected by LCDHype but does nothing more than pass commands to the
server and return responses to LCDHype via the API.

The amount of extra work in (3) as compared with (1) is quite small.
Some time ago I wrote a complete client and the matching multi-user
server in ANSI C. Together they contain 258 C statements. Both are just
skeletons capable of parsing command lines, outputting help text and
passing messages between each other: message assembly and display (in
the client) and message handling and reply assembly (in the server) are
separate modules and not included in the statement totals.


Martin

[lsmod]

1) When the application will run in "Windows ME" emulation it would be the easiest way to do this.
But i have seen more problems than in the "Windows 2000" emulation.

2) I asked to change the testprogram, so i hope we can test this.

3) Every workaround is really far away from the original application and should be the last option.
The goal was to use the existing engine and drivers to access an graphic LCD-display.
If there is much to do in Linux stuff, it would be better to develope in the real linux project.
http://ssl.bulix.org/projects/lcd4linux/

Another question:
Normally there is shown important system information on an LCD-Display.
This information is normally grabbed via the Windows "performance helper api".
In Linux nearly all of this information can be grabbed via shell commands from the system.
Is it possible to submit a shell command in wine and fetch the output?

Karsten

[Martin Gregorie]

On Tue, 2010-01-26 at 06:46 -0600, lsmod wrote:

1) When the application will run in "Windows ME" emulation it would be the easiest
way to do this.
But i have seen more problems than in the "Windows 2000" emulation.

2) I asked to change the testprogram, so i hope we can test this.

3) Every workaround is really far away from the original application and should be
the last option. The goal was to use the existing engine and drivers to access
an graphic LCD-display. If there is much to do in Linux stuff, it would be
better to develope in the real linux project.
http://ssl.bulix.org/projects/lcd4linux/

Yes, I would agree. Have you looked at porting LCDHype to Linux?

BTW, the lcd4linux website says that using /dev/lp* doesn't work, so you
should try using /dev/parport* instead. Note that some distros
use /dev/parports/* while others, such as Fedora, use /dev/parport*

Another question:
Normally there is shown important system information on an LCD-Display.
This information is normally grabbed via the Windows "performance helper api".
In Linux nearly all of this information can be grabbed via shell commands from the system.
Is it possible to submit a shell command in wine and fetch the output?

It should also be available via the /proc pseudo-file system. By default
drive z: is a symlink to /, so you can access /proc as z:\proc from
Wine. You can't see it in winefile for some reason and running 'dir' in
wine's command shell doesn't show it, but this Wine shell command works:

Z:\>type z:\proc\version
Linux version 2.6.27.41-170.2.117.fc10.i686
([email protected]) (gcc version 4.3.2 20081105 (Red
Hat 4.3.2-7) (GCC) ) #1 SMP Thu Dec 10 11:00:29 EST 2009

Z:\>

This means that you should be able to open the pseudo files in /proc
from a Wine application and read their contents, which will give you
much of the system information that Linux utility programs can show.

It is also possible to run Linux programs via a shell: look in the Wine
wiki for details.


Martin

[lsmod]

O.K. Most of the interesting things should be found in the /proc.
But sometimes it is easier to use a program like sensors for collecting and formatting the informations.
For the shell you mean this wiki: http://wiki.winehq.org/Shell32 ?

It is not so easy to understand the difference between the kernel drivers for the parallel port.
At least all kernel-drivers seem to access the parport driver.
With lsmod i can see that the kerneldriver parport is used by ppdev, lp, parport_pc

Additional i had found some links that helps understanding the stuff:

http://www.mjmwired.net/kernel/Document ... arport.txt

152 modes Parallel port's hardware modes, comma-separated,
153 meaning:
154
155 PCSPP PC-style SPP registers are available.
156 TRISTATE Port is bidirectional.
157 COMPAT Hardware acceleration for printers is
158 available and will be used.
159 EPP Hardware acceleration for EPP protocol
160 is available and will be used.
161 ECP Hardware acceleration for ECP protocol
162 is available and will be used.
163 DMA DMA is available and will be used.


http://www.mjmwired.net/kernel/Document ... wlevel.txt

155 PARPORT_MODE_TRISTATE The data drivers may be turned off.
156 This allows the data lines to be used
157 for reverse (peripheral to host)
158 transfers.



http://parapin.sourceforge.net/
Parapin makes it easy to write C code under Linux that controls individual pins on a PC parallel port. This kind of control is very useful for electronics projects that use the PC's parallel port as a generic digital I/O interface.


http://gramlich.net/projects/parallel_server/index.html
The state of this project that it is totally and completely dead!

[Martin Gregorie]

On Tue, 2010-01-26 at 08:25 -0600, lsmod wrote:

O.K. Most of the interesting things should be found in the /proc.
But sometimes it is easier to use a program like sensors for
collecting and formatting the informations.
For the shell you mean this wiki: http://wiki.winehq.org/Shell32 ?

No, I meant the top item on this page:
http://wiki.winehq.org/FAQ#head-68d921c ... 58d76ff51f

If your C compiler's library supports popen() and it will allow Linux
programs to be run this way you should be able to read their output from
the popen pipe but you'll most likely get Linux newlines, not DOS CRLF
line terminators. I have no idea whether popen() is part of the standard
library for Windows compilers, though djgpp (a port of the GNU compiler
for DOS) does, so at a guess mingw would too.


Martin

[lsmod]

Thanks.

Currently the question is how to access /dev/lp0 directly in the test-program?

The Test-program is based on this article: http://logix4u.net/Legacy_Ports/Paralle ... acing.html

So the access to the parport is coded through the _inp() and _outp() functions.
It is not clear what the libraries are doing here?

We are working now in the grey area between Windows and Linux and this is very special.
You don't find many informations about such topics ...

[Martin Gregorie]

On Wed, 2010-01-27 at 10:18 -0600, lsmod wrote:

Thanks.

Currently the question is how to access /dev/lp0 directly in the test-program?

The Test-program is based on this article: http://logix4u.net/Legacy_Ports/Paralle ... acing.html

Did you look at the second page of that article?
The one that deals with InpOut32.dll?
Your obvious first step is to write/download a test program using it.
Read this:
http://logix4u.net/Legacy_Ports/Paralle ... NT/XP.html

Download InpOut32.dll and try using it with one of the test programs
referenced from it. If that works, you're home and dry. Just change
LCDHype and its dll to work with InpOut32.dll

So the access to the parport is coded through the _inp() and _outp() functions.
It is not clear what the libraries are doing here?

I think they are very simple functions that make direct access to
parallel ports for DOS/Windows systems.

We are working now in the grey area between Windows and Linux and this is very special.
You don't find many informations about such topics ...

Actually, there's rather a lot available and its rather easy to find.

Here's some reading about the Linux side:
http://www.kernel.org/pub/linux/kernel/ ... arport.txt
http://people.redhat.com/twaugh/parport/html/x916.html

These were found with an Altavista search on "/dev/parport" and were the
top two items on the first page of search results. Google may or may not
be your friend (Altavista finds fewer useless comparison sites and
doesn't show adverts) but you should make more use of them.


Martin

[lsmod]

Read this:
http://logix4u.net/Legacy_Ports/Paralle ... NT/XP.html

Download InpOut32.dll and try using it with one of the test programs
referenced from it. If that works, you're home and dry. Just change
LCDHype and its dll to work with InpOut32.dll

That sounds good.
I hope ViRuSTriNiTy will make a testprogram with it.

I think they are very simple functions that make direct access to parallel ports for DOS/Windows systems.

Of course.
But the question was how to access /dev/lp0 in wine with an Windows compiler?
I think the only way is to patch the libraries.

Actually, there's rather a lot available and its rather easy to find.

I also find this - but i am always skeptical to rely on this, when i see that this information is very old and for kernel 2.4.
Too many things have changed.
Specially the interfacing with udev in kernel 2.6

Karsten

[Martin Gregorie]

On Thu, 2010-01-28 at 04:46 -0600, lsmod wrote:

Of course.
But the question was how to access /dev/lp0 in wine with an Windows compiler?
I think the only way is to patch the libraries.

Yes, of course, but since you said your guy was going to make a dll
containing the Windows driver functions that's at most a very small
addition to his code and one that may not be needed if you use
InpOut32.dll it may not be necessary. Its the sort of thing that gets
put in conditional compilation if its a line or two or in a
platform-dependencies module if its bigger.

Regardless of whether the parallel port stuff I pointed you to is kernel
2.4 or 2.6, read and understand it: the parallel port API didn't change
and it looks to me that using /dev/parport0 would be better suited to
your needs than using /dev/lp0.

If you don't have the test gadget described in the article you
referenced, it may be useful to make one.

Specially the interfacing with udev in kernel 2.6

There's not a lot of documentation on udev anyway - at least not that
I've found, but the rules aren't hard to understand and modify if all
you're changing are access permissions. One point: *don't* change an
existing rules file because the changes will be lost if there's a udev
upgrade. Instead, add a local rules file named to run after the rule you
want to override and containing the minimum rule needed to change the
access permission for just the device(s) you need to access.


Martin

[lsmod]

Sorry - up to now i didn't study the kernel parallel port stuff.
But i will try to get more knowledge how this works.
As i have understund, the interface must be set into the right mode (ECC, EPP, ...).
Then it can be accessed over different functions - correct?

What i also cannot understand is why the InpOut32.dll will help?
Should it help in NT+ or Win* emulation?
As you have written the NT+ should never work, because the functionality of kernel interfacing is not implemented.

In the time between i tried out some other simple things.
I tried out to pass data direct to /dev/lp0 with the simple shell-command

Code: Select all

echo "A" > /dev/lp0

This works with no error if an LCD-Display is connected to the parport.
When no display is connected the command hangs. I think the reason is that there is no busy-signal on the line.

After that i remember another old problem trying to use the parport in wine and tested this again:
http://forum.winehq.org/viewtopic.php?p=39025

I would say that there is generally no access to the parport in wine now.

Karsten