Software Deployment

you can probably use run32dll.exe, just extract your dll from the resource table to a file on your hard disk, then execute RUNDLL32.EXE and give it the path and arguments for the dll file. Not sure what output you might get, it depends on the dll author (it might get nothing outside of an MSI).

Let us know how it goes, I've never done this but it looks interesting!

Hi Joe,

Wouldn't the log file with the /L*vx switch (extra log info for WI 3.1) tell you how the CA is run?

Regards
Wayne

The verbose log would definitely tell you how the CA was run during the installation, but Joe was inquiring about running the DLL as a standalone program from the command line.

Hi Joe,
to call it, use:
RUNDLL32.EXE F84988_btins.dll, BTINS_StartBtWizardSilentMode

Almost for sure, you have to "translate" the file name "F84988_btins.dll" to its real name. Just search the MSI's file table for it.

But be aware: This might work, work partly or does nothing.
It depends on the environment, the DLL expects. If it relays on being called by Windows Installer, you can forget this.
But you got some chances here, because normally, CA DLL's called by the Installer are embedded into the MSI's binary table and invoked true CA type 1.
Good luck.
Regards, Nick

oops I meant to say Binary Table there I go being Wise -Centric [:)]

Hi Owen,
the CA is type 81, that means 64+17 => type 17 "DLL file that is installed with a product".
Therefore, no binary table action is necessary.
Regards, Nick

Ah so it is, I overlooked the type. So I guess Joe would do an installation and just test the file from there, or extract it from the msi or cab and do it...
thanks!
OG

Thanks for the help. I found this msi interesting in that all it does is install files and after the install finalize action runs some custom actions all pointing to this particular dll file. I wanted to discover how these custom actions are somehow able to automagically allow windows to suddenly discover new hardware that wasn't detected previously. What is even more annoying is when you uninstall, the hardware again disappears from device manager. Is this what is called hardware enumeration?

I dunno that's weird, does it throw any input or output when you run it from rundll32.exe or does it just recognize hardware? is the sofware related to the hardware? is there a condition on the ca? is there an uninstall ca?
veddy interestink [8D]

Does not appear to do anything when run manually. Will error out if I use the wrong parameter. The installer is the Widcomm bluetooth stack. There is a condition on the custom action (Not Installed) OR (BTW_MINOR_UPGRADE=1) so I don't think that has anything to do with it. There is a custom action to uninstall and when I invoke it like this rundll32 btins.dll, BTINS_Uninstall it did uninstall but not the msi.


ORIGINAL: aogilmor

I dunno that's weird, does it throw any input or output when you run it from rundll32.exe or does it just recognize hardware? is the sofware related to the hardware? is there a condition on the ca? is there an uninstall ca?
veddy interestink [8D]

Update: I was able to remove the custom actions in the install execute table (for testing only of course) that were ran after install finalize. The msi installed successfully and I was able to then manually run the custom actions from a command prompt. Now this is where it really annoys me. Basically all the msi does is install some files and reg entries. The whole driver install is actually accomplished through the custom actions at the end. So why in the heck did they even bother using an msi if they weren't going to use it to do the install. I hate crappy vendors that do that. Well at least I learned some more good stuff along the way.

You answered your own question: crappy vendors :)

ORIGINAL: joedown
Update: I was able to remove the custom actions in the install execute table (for testing only of course) that were ran after install finalize. The msi installed successfully and I was able to then manually run the custom actions from a command prompt. Now this is where it really annoys me. Basically all the msi does is install some files and reg entries. The whole driver install is actually accomplished through the custom actions at the end. So why in the heck did they even bother using an msi if they weren't going to use it to do the install. I hate crappy vendors that do that. Well at least I learned some more good stuff along the way.

I've learned a lot through crappy vendors too. Java is horrible about that. The files aren't even installed through the feature/component/file database hierarchy but through custom actions. So if you want to modify the install you have to use your own CA's to write to the registry or perform file actions. Removing the vendor CA isn't an option, then the files won't be installed! Thanks Sun! [:@]

Owen, be honest: that response is lifted more or less verbatim from one you made a few months ago, is it not? LOL

What we all learn, of course, is that as long as there are crappy vendors, we'll be in jobs.

ORIGINAL: VBScab
Owen, be honest: that response is lifted more or less verbatim from one you made a few months ago, is it not? LOL

More or less...any excuse to bitch about the Java package...truly one of the worst, LOL.

See my new thread