April 2005 - Wine-Devel - list.winehq.org

Wine and twain

by Brouard Nicolas

Hi, I haven't seen recent information on wine and twain. I already sent a similar mail to wine-users two weeks ago without answer. I am trying to test a Finereader Office (version 5) with an USB scanner. Everything seems working. But I get scanner not ready when searching for scanner. Sane, gimp or whatever are working well with my scanner. Doing WINEDEBUG=+loaddll wine finereader.exe I get: ... trace:loaddll:load_dll Loaded module L"C:\\program files\\abbyy finereader 5.0 office\\scan\\scanman0.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\ \msvcrt.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\ \msvcrt.dll" : builtin err:module:load_builtin_dll loaded .so for L"Twain.dll" but got L"twain_32.dll" instead - probably 16-bit dll trace:loaddll:MODULE_LoadModule16 Loaded module "c:\\windows\ \Twain.dll" : builtin Scanning driver not ready. But the scanner is ready: # sane-find-scanner -v searching for USB scanners: checking /dev/usb/scanner... failed to open (Invalid argument) checking /dev/usb/scanner0... failed to open (Invalid argument) ... checking /dev/usbscanner15... failed to open (Invalid argument) found USB scanner (vendor=0x03f0 [hp], product=0xb402 [photosmart 7700 series]) at libusb:002:002 found USB scanner (vendor=0x04b8 [EPSON], product=0x010f [EPSON Scanner 010F], chip=LM9832/3) at libusb:001:003 # scanimage -L device `plustek:libusb:001:003' is a Epson Perfection 1250/Photo USB flatbed scanner device `net:localhost:plustek:libusb:001:003' is a Epson Perfection 1250/Photo USB flatbed scanner Thus the device is something like "plustek:libusb:001:003" and # scanimage -d plustek:libusb:001:003 >foo.pnm works. Is there any wine test (windows exe) in order to test twain? Regards, Nicolas -- Brouard Nicolas <nicolas.brouard(a)libertysurf.fr>

April 2, 2005

Re: Improve the HHCTRL.OCX stub

by Jacek Caban

Hi. Two small suggestions. +static char *command_to_string(UINT command) It could be const char. +{ +#define X(x) case x: return #x + + switch (command) + { + X( HH_DISPLAY_TOPIC ); + X( HH_DISPLAY_TOC ); + X( HH_DISPLAY_INDEX ); + X( HH_DISPLAY_SEARCH ); + X( HH_SET_WIN_TYPE ); + X( HH_GET_WIN_TYPE ); + X( HH_GET_WIN_HANDLE ); + X( HH_ENUM_INFO_TYPE ); + X( HH_SET_INFO_TYPE ); + X( HH_SYNC ); + X( HH_RESERVED1 ); + X( HH_RESERVED2 ); + X( HH_RESERVED3 ); + X( HH_KEYWORD_LOOKUP ); + X( HH_DISPLAY_TEXT_POPUP ); + X( HH_HELP_CONTEXT ); + X( HH_TP_HELP_CONTEXTMENU ); + X( HH_TP_HELP_WM_HELP ); + X( HH_CLOSE_ALL ); + X( HH_ALINK_LOOKUP ); + X( HH_GET_LAST_ERROR ); + X( HH_ENUM_CATEGORY ); + X( HH_ENUM_CATEGORY_IT ); + X( HH_RESET_IT_FILTER ); + X( HH_SET_INCLUSIVE_FILTER ); + X( HH_SET_EXCLUSIVE_FILTER ); + X( HH_INITIALIZE ); + X( HH_UNINITIALIZE ); + X( HH_PRETRANSLATEMESSAGE ); + X( HH_SET_GLOBAL_PROPERTY ); + } + +#undef X +} If command is not one of specificed in switch, function won't return a valid string. Thanks, Jacek

April 2, 2005

Re: Wine device drivers proposal

by James Courtier-Dutton

Damjan Jovanovic wrote: > Hi > > I've been trying to add STI (still image) support to > Wine, and I've made some progress. However, I see a > deep and unsurmountable need to add (at least > user-space) device drivers to Wine, and I would like > some feedback on these ideas. > > Basically, many Windows device drivers are really > trivial, but required for many apps. A scanner driver > typically just accepts commands from a user-space app, > does minimal processing, and forwards that to Windows. > I've already hacked up Wine to get the same > functionality, and it works - partially. > > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() > > The problem is, how is a handle mapped to the > appropriate driver? I've thought about it, and come up > with 3 solutions. The first 3 don't require changes to > the wineserver but aren't pretty. > > 1. Make the driver a true Linux kernel mode driver, > and the handle its device file handle. Since > ReadFile() and WriteFile() just do read() and write() > system calls, this can be done. The problem is, > DeviceIoControl() has to be implemented using ioctl(), > and that's dangerous (sending the right codes to the > wrong device can be catastrophic). Also, it's not > portable to other OS's, and requires writing a kernel > module (which isn't fun). > > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. > > 3. KERNEL32.DLL and / or NTDLL.DLL keep their own > handle table so they know which handles are driver > handles and deal with those appropriately. Having to > look up these tables for every call to ReadFile(), > WriteFile() and DeviceIoControl() might be very > inefficient, though. > > 4. Use an in-process solution, like a winelib DLL that > has exports for dealing with ReadFile(), WriteFile() > and DeviceIoControl(). This could be the most > efficient, but then again, you need an efficient way > to test a handle for being a driver handle, find the > appropriate driver, and call the right exported > function, which likely means the wineserver needs to > have knowledge of these drivers and provide > functionality for testing a handle for being a driver > handle and have a way to find the driver. > > Let me know what you think. > > Bye > Damjan > I would like this but mainly for a different reason. I help reverse engineer hardware so that we can write linux drivers for it. This reverse engineering task would be easier if I could install the windows drivers on my linux box and run them, and then watch their activity with the hardware. For this to work, we would have to implement the HAL.DLL in wine, a small kernel module for it to communicate with and probably a few other bits. This would greatly help the hardware reverse engineering requirements in order to get hardware to interoperate with Linux. Currently, I have to installed special .DLLs on a windows box and perform the logging there. I would much prefer to do it all on Linux. The side effect of this would be that wine will support some hardware even before Linux gets support for it. This "kernel module" would only be run for the reverse engineering task, as it would most likely make the linux kernel very insecure. Any comments James

April 2, 2005

Re: Nearly all Installshield installers fail

by Robert Shearman

Joaquín Fernández wrote: > > With my application (Route 66), it enables me to start copying files, > > however the progress bar never moves. However, the installer is doing > > something but seems to be stuck somewhere. Maybe some deadlocks. > > I have had many problems with InstallShield but i was able to install > the programs (about 3 or 4 programs using InstallShield that i need) > using WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". You can probe with > this.. it worked for this programs in Wine 2004XXXX and 2005XXXX. > Obviously, you must verify that this DLLs exist in the system dir. This is not a good long-term solution since it requires a download from Microsoft. There are a number of issues with InstallShield currently. I had hoped that getting one working would get all working, but this doesn't seem to be the case from the current discussion on wine-devel. I am aware of 3 issues with ole32, 2 deadlocks and one error. The remaining issues appear to be with the typelib marshaler, which unfortunately lacks regression tests. Rob

April 2, 2005

Nearly all Installshield installers fail

by Joaquín Fernández

> With my application (Route 66), it enables me to start copying files, > however the progress bar never moves. However, the installer is doing > something but seems to be stuck somewhere. Maybe some deadlocks. Español: Yo tuve varios problemas con algunos programas que usan InstallShield como instalador (alrededor de 3 o 4) pero pude instalarlos usando WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". Puedes probar esto a ver si te funciona, para mí si funciona con estos programas en Wine 2004XXXX y 2005XXXX. Obviamente, verifica que tengas esas DLLs en el sistema. English: I have had many problems with InstallShield but i was able to install the programs (about 3 or 4 programs using InstallShield that i need) using WINEDLLOVERRIDES="ole32,oleaut32,rpcrt4=n,b". You can probe with this.. it worked for this programs in Wine 2004XXXX and 2005XXXX. Obviously, you must verify that this DLLs exist in the system dir. Regards Joaquin -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

April 2, 2005

Re: wine/dlls wininet/netconnection.c user/text.c ...

by Vincent Béron

Le mer 30/03/2005 à 00:40, Dimitrie O. Paun a écrit : [snip] > Other than that, are all strncpy() instances gone? If so we should > also nuke strncpyW() from wine/unicode.h too. No, they're not all gone yet (or are in not applied patches). Vincent

April 2, 2005

Re: Wine device drivers proposal

by Vincent Béron

Le ven 01/04/2005 à 17:06, Kuba Ober a écrit : [snip] > All that without touching the kernel in any way. And I mean > here full support for *any* usb device, rain or shine. Network adapters > (visible in wine only, but so what?), Does that mean we'd need a database of USB identifiers? For network adaptors visible in Wine only: Wine doesn't have a TCP/IP stack. Would that be needed to use such network adaptors? Vincent

April 1, 2005

Re: discusion about a message loop in listview.c

by Dimitrie O. Paun

On Tue, Mar 29, 2005 at 06:52:07PM +0200, Dietrich Teickner wrote: > I have some weeks before reported, FlashFXP v3.02 loops with a > message-loop in listview.c after login. It does this in Odin and in Wine. > In Odin it stops in smaller time (deep 1000). Wine has a bigger stack, > and so needs wine more time for this, bat I can see in the loog, the > args for the function are more and more locatet at lower stack adresses. > I have written this workarout for testing this problem in wine and in > odin. with this FlashFXH 3.02 will display the contence of the server > dir very fast at both environment. In the log I can see, that the > message-loop was reported and stopped. I thing, we need a flag inside > any item to report every function, that can called recursive, this item > is in work (function-separart, or global ?), that can stop recursions of > this type in the future or many programms. I have also found this try > does also helps Agent 2.0 in the groups->defailt propertys (only > odin-tested). > This does also every crashs in earlyer builds with stack overflow in odin. Dietrich, You need to create a small example app that exhibits this behaviour such that it crashes on Wine/Odin, but runs in Windows. As things stand, I can not test with either app since they don't install under Wine. In any event, a small example app would be better, since the source would be available too. -- Dimi.

April 1, 2005

Re: Wine device drivers proposal

by Kuba Ober

> I am not trying to _load_ a Windows driver (that > either requires kernel support for the Windows DDK, > like ndiswrapper has, or emulation of an entire x86, > like bochs does). Not really. It just needs some sort of device-class-specific forwarding protocol. usbfs and libusb already do that, and you should be able to run any windows driver that way without even touching the kernel. ndiswrapper does what it does because they want to expose non-usb devices and to the whole linux system at that. I.e. they support pci devices as well as usb. If they wanted to support usb only, it's all plain userspace. You can emulate network adapters in userspace using TAP or however it's called, and you can talk to arbitrary usb devices from userspace via usbfs and libusb. In fact, for a wide variety of PCI drivers out there it should be perfectly feasible to provide a "short-circuit" kernel driver that could expose full access to a PCI device do a userland application, thus allowing wine to support arbitrary PCI devices as well. Considering that 2.6 kernel already has hardware abstraction that disconnects actual hardware accesses (like port/read writes and so on) from the logic of the PCI device drivers, it wouldn't be that hard to make such a gizmo. http://vtun.sourceforge.net/tun/faq.html http://libusb.sourceforge.net/ Cheers, Kuba

April 1, 2005

Re: WineConf Agenda

by Steven Edwards

Hi, On Fri, 2005-04-01 at 02:20, Jakob Eriksson wrote: > 2) What's almost never been brought up on wine-devel is the > unit testing in the XP sense. The problem is you need to write a stub interface for all of the functions the function or library you are testing due to all the cross-calls win32 makes. You end up spending a huge ammount of time just writting stubs. In the ReactOS CIS system Casper has implemented support for this and while its a good idea it a rather large beast. I think he developed a system to automagicly generate the stubs needed but then you end up having two sets of tests to test the same functions. Not to mention I don't see how it can work on Linux anyway..... Thanks Steven

April 1, 2005