Hi Terry, I'll jump in on this if you don't mind.
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.
Almost. I think it's trying to get the GUID of all devices that full under the "Ports" class. This includes serial and parallel ports. I suspect it will then try to enumerate devices of that class, using e.g. SetupDiGetClassDevsA. Right now a very hackish implementation of SetupDiGetClassDevsA/W exists for serial ports, but not for parallel ports.
I note it trys to get some info on a ControlClass key from the registry. This fails.
Yep, this appears to be missing from the registry. Some keys probably should be added to tools/wine.inf, there isn't much point in searching the registry for these keys if they're never added.
Both of these should be addressed, but you can probably hack something for the moment: have SetupDiGetClassGuidsFromNameExA return some GUID you make up for "Ports", and see how far your app gets. If if then calls some other SetupDi function with that GUID, hack up that function to return something. I'm not suggesting that should go into Wine, but you can probably coax the app into getting farther.
- How well does wine generally work when "windows=winxp" ?
Depends on the app.
- 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 ?
CDROM_DeviceIoControl will fail if it's not a CDROM device, so you can try a parallel port ioctl afterward if you like.
--Juan
__________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
-
Juan Lang