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
