Rob Shearman wrote:
Terry Barnaby wrote:
Rob Shearman wrote:
Terry Barnaby wrote:
Hi,
I am trying to get the K'nex CyberKnex Programmer Windows program working under wine on Fedora 3. It appears to be generally working but this program needs direct access to the LPT1 parallel port to drive an external "flash key" programmer.
I have tried setting the "Windows" parameter to "winxp" and setting "export WINEDEBUG=+io,+int,+vxd;". This still does not work I get the error messages:
fixme:setupapi:SetupDiClassGuidsFromNameExA trace:vxd:DeviceIoControl (0xffffffff,222074,0x7e8e00b4,4,(nil),0,0x72c9f57c,(nil))
I understand, from reading mailing lists and looking at the program, that the program is using a DLL which has the capability of loading an embedded VXD driver to access the LPT1 port.
Some questions:
- Should this VXD driver loaded when the window system is set to
"winxp" ?
No. NT doesn't support VXDs, just like we don't (although we fake a few).
- Is there any way I can get this program to communicate with the
LPT1 port ?
Possibly. I'd look at working at which IOCTL and see if you can handle it either by translating it into a Linux ioctl (preferable) or by faking the information returned to satisfy the program. It doesn't look as though the setupapi call is important as the program seems to carry on without it.
Rob
Hi Rob,
Thanks for the feedback. I am new to wine development, could you give me a little extra pointers ?
Sure. I would start with looking at DEVELOPER-HINTS in the wine source.
- What should the "setupapi" call do, should it load a standard NT
driver, how would the program expect to access the LPT1 port under NT ?
Typically, programs use setupapi to enumerate devices to find one that matches their needs. The functions are documented on MSDN. Here is a link to the one called by your program: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/install/hh/...
- I assume the
vxd:DeviceIoControl(0xffffffff,222074,0x7e8e00b4,4,(nil),0,0x72c9f57c,(nil))
is an effective Windows IOCTL ?Yes.
- Is the first parameter to vxd:DeviceIoControl() a device handle, -1
indicating some device opening routine actually failed ?
Good point, yes. This could be because of the setupapi stub.
- Are you stating that I can change the wine code that handles the
vxd:DeviceIoControl() to "do the right thing" ?
Yes. It might be cleaner to put the code in ntdll rather than kernel32, but we can cross that bridge when we come to it.
Rob
Hi Rob,
I hope you don't mind me asking a few more questions ? I have now donloaded the wine CVS and built it and started adding debug printf's.
I have "windows=winxp" in my config. It appears that my program, in the "setupapi", calls SetupDiClassGuidsFromNameExA with the name "Ports". So I presume this is trying to get a handle for the "Ports" driver which looks like it is not implemented. I note it trys to get some info on a ControlClass key from the registry. This fails. Some questions:
1. How well does wine generally work when "windows=winxp" ? I presume wine has been more fully developed for the case where "windows=win98" ? Should I try and stick with win98 and implement a driverx.vxd or use winxp and implement a "Ports" driver within ntdll ? 2. I have setup my registry and C: drive using winetools. For winxp operation, is there a different way of setting up the registry and drivec ? 3. I note that the device NtDeviceIoControlFile ioctl interface in ntdll only supports CDROM devices. Also there does not seem to be a way of dynamically attaching devices. Should I just hard code a "Ports" driver in ntdll ?
Cheers
Terry