On 1/13/06, Markus Amsler markus.amsler@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