Setupapi & VBox additions

[Thomas Faber]

Hi,

I've been looking at VirtualBox 4.1.x guest additions, which don't install
in ROS [1] and came up with a patch [2] that seems to fix them.

While patchbot says this is okay [3] (and the last hunk even fixes a few
setupapi tests), I am very unsure about the SP_COPY_NOOVERWRITE part.
The correct solution might instead be to handle SetupCopyOEMInf returning
ERROR_FILE_EXISTS or I might be "fixing" something in the completely
wrong place.

It would be great if someone with some insight into setupapi
(Eric? Hervé? ;]) could review this and give some pointers.

Thanks!

-Thomas

[1] http://www.reactos.org/bugzilla/show_bug.cgi?id=6522
[2] http://www.reactos.org/bugzilla/attachment.cgi?id=6753
[3] http://www.reactos.org/testman/compare.php?ids=8272,8294,8303,8305

Patch explanation:
- The first hunk isn't really required, but I guess it shouldn't break
  anything, and seems to find what it's looking for this way.
- The second hunk is in the code path used by VBox guest additions setup.
  It is apparently called with an already-existing inf file, but I have
  no idea why. :|
- The third hunk is a trivial bug that our CreateService just didn't
  complain about before r53872/r53886

[Cameron Gutman]

I think the problem with INF conflicts is that we don't accurately replicate
the way Windows copies INF files. When Windows installs a driver, it creates
an INF called "oemX.inf". I suspect that we simply copy the INF with its
current file name into our INF directory which can obviously lead to
conflicts, especially during driver updates. Correcting our implementation 
of
OEM INF copying will fix the problem the proper way.

"When third-party drivers are installed correctly, the .inf is renamed to
Oemxx.inf (where xx is a sequential number) to make sure that there are no
name conflicts with drivers that are included with the product and with
other third-party drivers"

Reference: http://support.microsoft.com/kb/813449

The rest of the patch looks ok to me.

Regards,
Cameron