advpack: Implement LaunchINFSection on top of DoInfInstall

[James Hawkins]

On 1/13/06, Markus Amsler <markus.amsler at oribi.org> wrote:
>
> I'm aware of that. We just have different approaches. Mine is from
> higher level functions to lower level, yours the other way round. Our
> approaches are not exclusive, we can simply meet in the middle (I know i
> took the easier way :-)). Is that OK for you? I think there's no problem
> if this patches get applied. The next patch will implement an advanced
> inf section infrastructure, based on setupapi install.c (See atachement,
> still needs some work).
>

The problem with meeting in the middle is that once the lower level
APIs are implemented, and the install APIs mostly implemented, we'll
have to try to squeeze in the correct functionality provided by the
lower level APIs, which will leave a big mess.  A similar process led
to our implementation of SHFileOperation...look how that turned out :)

> >The same comments for LaunchINFSection apply here as well.  If these
> >three APIs just call DoInfInstall, then what's the point in having
> >them?
> >
> Don't ask me, ask Microsoft.
> My tests/understanding show all four of them do basically the same work.
> I tested Run(Post|Pre)SetupCommands. All four functions execute this
> advanced inf section (so i guess this is also true for the others).
>

You're right in that they all pretty much do the same basic operation,
but they don't do it by calling DoInfInstall.  We need to add more
test cases to the test suite.  It's a pain to create the INF files on
the fly, but I've added the yuck part already, so you just have to add
the appropriate append_str to the INF.  Another step I'm going to take
is to set up the INF tests to use a cabinet file as well as some of
the more minute details.  The bottom line is that we need to do some
more testing into what all of these functions do and what their roles
are.  I know you want to get the fix in for bug 3636, but we can't
rush it by putting in a temporary hack (I don't mean hack as in poor
quality, just not the correct solution.)

A comment on your patch: since all the advpack APIs are ansi, you
don't need to bother converting to unicode, because we shouldn't be
calling any unicode APIs and we won't get any unicode input.

--
James Hawkins