Setupapi improvements

Hi!

I have been working on some improvements to the device installer functions
of the setupapi dll. I am able to install class installers on my machine and
retrieve information about installed class installers.

My plan is to reorganize the setupapi dll in order to add the configuration
manager apis to this dll and to convert setupapi to a ReactOS dll. The
reason for this change is that additions to the device installer apis or
configuration manager apis are not usable by WINE because it does neither
support windows drivers nor a PnP-Manager. Of course, all additions to
setupapi will be licensed under the LGPL so Wine developers can port useful
code as they see fit.

What do you think?

Regards,
Eric

[Steven Edwards]

Hi Eric,

--- Eric Kohl [e-mail] wrote:
> My plan is to reorganize the setupapi dll in order to add the
> configuration
> manager apis to this dll and to convert setupapi to a ReactOS dll.
> The
> reason for this change is that additions to the device installer apis
> or
> configuration manager apis are not usable by WINE because it does
> neither
> support windows drivers nor a PnP-Manager. Of course, all additions
> to
> setupapi will be licensed under the LGPL so Wine developers can port
> useful
> code as they see fit.

I think winehq may still be interested in working with us on it as Aric
Stewart is planning on adding support for mass stoage drivers "ipod usb
and frirewire" to Wine. We looked at using libusb to develop a common
interface that can be shared on Linux and ReactOS but he has had to
work on other things so it might be some time before more work is done.

Thanks
Steven

PS. It does work now via some really dirty hacks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

"Steven Edwards" [e-mail] wrote:
> I think winehq may still be interested in working with us on it as Aric
> Stewart is planning on adding support for mass stoage drivers "ipod usb
> and frirewire" to Wine. We looked at using libusb to develop a common
> interface that can be shared on Linux and ReactOS but he has had to
> work on other things so it might be some time before more work is done.

The problem is that Wine needs to use an entirely different approach than
ReactOS. We cannot rely on libusb, our configuration manager apis need to
call to the user-mode-pnp-manager (umpnpmgr.dll) via RPC. Umpnpmgr.dll
communicates with ntoskrnl via NtPlugPlayControl and NtGetPlugPlayEvent. As
a short-term sollution we can retrieve some information from the registry
instead of calling umpnpmgr.
> PS. It does work now via some really dirty hacks.

Which setupapi functions are needed for this hack?
I implemented:
 - SetupDiBuildClassInfoList(ExW)
 - SetupDiClassGuidsFromName(W/ExW)
 - SetupDiClassNameFromGuid(W/ExW)
 - SetupDiGetActualSectionToInstallW
 - SetupDiGetClassDescription(W/ExW)
 - SetupDiInstallClassW partially
 - SetupDiOpenClassRegKey(ExW)

Regards,
Eric

[Steven Edwards]

Hi,

--- Eric Kohl [e-mail] wrote:
> The problem is that Wine needs to use an entirely different approach
> than
> ReactOS. We cannot rely on libusb, our configuration manager apis
> need to
> call to the user-mode-pnp-manager (umpnpmgr.dll) via RPC.
> Umpnpmgr.dll
> communicates with ntoskrnl via NtPlugPlayControl and
> NtGetPlugPlayEvent. As
> a short-term sollution we can retrieve some information from the
> registry
> instead of calling umpnpmgr.

Right I understand. I was hoping we could use libusb as it currently
work on both Windows and Linux but I see what you mean about the
implementation issues...maybe it will still be of help to someone.
> Which setupapi functions are needed for this hack?

Right now its a hardcoded hack to SetupDiGetClassDevsA that looks for
the iPods Vendor ID by talking to the /proc filesystem. If it finds the
device it does some other magic to access it. In the future we were
going to add some enumeration for other mass storage devices. I was
hoping we could make it generic enough that ReactOS and Wine could both
use the same code for device identification at least on the userspace
side because if I understand it correctly all USB devices under any OS
use the same ID system. I dont know how the other hardware such as PCI
and friends work.

Anyway there is not much to what we(codeweavers) already have and I
agree I dont think working together on this is going to be much help.

Thanks
Steven

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

"Steven Edwards" [e-mail] wrote:
> Right I understand. I was hoping we could use libusb as it currently
> work on both Windows and Linux but I see what you mean about the
> implementation issues...maybe it will still be of help to someone.

AFAICS libusb bypasses the pnp manager and uses direct access to USB
devices. This is not what we need for ReactOS.
> Right now its a hardcoded hack to SetupDiGetClassDevsA that looks for
> the iPods Vendor ID by talking to the /proc filesystem. If it finds the
> device it does some other magic to access it. In the future we were
> going to add some enumeration for other mass storage devices. I was
> hoping we could make it generic enough that ReactOS and Wine could both
> use the same code for device identification at least on the userspace
> side because if I understand it correctly all USB devices under any OS
> use the same ID system. I dont know how the other hardware such as PCI
> and friends work.
>
> Anyway there is not much to what we(codeweavers) already have and I
> agree I dont think working together on this is going to be much help.

Pehaps we can use the same internal device tree representation but different
ways to create it.

Regards,
Eric

[KJK::Hyperion]

At 06.13 19/10/2004, you wrote:
> > Which setupapi functions are needed for this hack?
>
> Right now its a hardcoded hack to SetupDiGetClassDevsA that looks for the 
> iPods Vendor ID by talking to the /proc filesystem.

I've heard about the PnP support in the newest Linux versions. Their HAL 
sounds a lot like our PnP Service. Maybe the Wine people should rather have 
a look at that - I doubt direct access can be made portable enough (save 
for some special cases - e.g. SCSI)
> I was hoping we could make it generic enough that ReactOS and Wine could 
> both use the same code for device identification at least on the userspace 
> side because if I understand it correctly all USB devices under any OS use 
> the same ID system. I dont know how the other hardware such as PCI and 
> friends work.

it depends (but in general it's some variation of the vendor id/device id 
scheme). In fact, Windows has several enumerators, one per bus, each 
supporting a different kind of device enumeration and identifications (FYI, 
PCI devices have a vendor id, a device id, a subsystem vendor id, a 
subsystem device id and a revision id), plus a root enumerator that 
implements a default behavior (the identifier is a GUID) that should be 
good enough for everything else (if not, you write your own enumerator). 
You generally don't use these identifiers directly, anyway