View Full Version : Installdriver table manager service and Atl.dll v2

11-29-2004, 01:42 PM
Anyone know the purpose of the InstallDriver Table Manager service?

It seems to be install if setup.exe is run. It also seems to need Atl.dll v3. On nt systems that have Atl.dll v2, I get an error stating that ordiinal 57 in Atl.dll cannot be found. After this even the .msi is unable to run.

Is there something I'm missing?
Is there a work around?

11-29-2004, 04:31 PM
It's intended to prevent some nasty cases where IDriver communication would break down and cause a failed installation/uninstallation. You may be able to condition the ISScript1050.msi component for IDriverT.exe to only install on later versions of Windows (e.g. VersionNT >= 500). I'm surprised that this was a problem, as I thought even I ran it on NT; perhaps my image was too recent a version.

11-30-2004, 08:09 AM
This service only gets installed if the setup.exe is run, not if the .msi (with the InstallShield Engine 10 MM included) is run.
Would changing the component conditions work for this case?
And am I allowed to chage the conditions is an InstallShield MM?

11-30-2004, 11:25 AM
I don't believe it's in the Merge Module; I'm only aware of its presence in the ISScript1050.msi that appears in the disk1 folder of an uncompressed release, and is used only for InstallScript MSI projects.

If you're resourceful, you can find the source of that copy under Redists\Language Independent\i386 so you can make modifications that are included in a compressed release. In general we cannot support such modifications, but if you can make clean ones like the one I mentioned above it should be safe. Test accordingly.

11-30-2004, 03:38 PM
That seems to work fine.
I Just didn't want my hand slapped for modifing it.

12-20-2004, 11:15 AM
ATL.dll problem windows NT.

I have a Windows Installer installation (Basic MSI Project) which needs to be installed onto old Windows NT machines.

I get the ATL.dll error every time I try to install on a NT machine, is there some workaround for this, other then hacking the setup.exe.

Otherwise Installshield 10.5 is useless to me.

12-20-2004, 11:22 AM
A Basic MSI shouldn't trigger this, as the service is for use with InstallScript MSI setups. Could you verify that the service is either not present, or is disabled before starting the installation, to make sure your Basic MSI is in fact installing/enabling the service? Also, while you imply that this setup worked in a previous version, can you confirm that for me so I can rule out any dependencies in, e.g., your custom actions?

12-21-2004, 03:59 AM
I was a bit vague in my description of my project, here is what I do:

- I have a Basic Msi Project, but the installation uses installscript in CA. (Behaviour and Logic- InstallScript.)
- Since my installation includes a installscript I get the options on how to include the Installscript Enginge in the release Wizard. - Extract at build.

If I try to run this installation on a NT machine I get Error on ATL. (See attachment)

If I create a Basic MSI project without scripting the installation runs without errors on Windows NT. (Windows NT 4 SP 6)

So since my installation needs to target all operation systems, excluding windows 95, on the Windows Platform. Installshield 10.5 seems to be useless for me.

Which I think is quite sad, so the big question is:
Am I doting something seriously wrong here or is there a way around this ?

12-21-2004, 11:42 AM
Well, IDriverT is installed by the ISScript1050.msi as described earlier in this thread. It's a pretty trivial modification to block it from installing on Windows NT, and that should apply for any setup.exe that installs it. Just open the source file in the direct editor, modify the condition, save, and rebuild your main project.

Or have you done this and it didn't help? If so, please try building uncompressed and verifying the condition you placed is present on the ISScript1050.msi in your build folder as well.

12-22-2004, 07:28 AM
VersionNT >= 500 Works.

Thanks MichaelU.

Christopher Painter
01-11-2005, 06:39 PM

I thought you and I had a thread earlier where I discussed my changes to the AppID in iscriptxx.msi to support pushing through sms as system while a user is logged on. I can't find that thread though. If we did, I was wondering if you could comment on IDrivert.exe in 10.5. I just upgrade to 10.5 today ( AdminStudio 6.0 VP1 ) and I went to migrate my changes to the new iscript redist when I saw this new IDriverT.exe that I had never seen before.


01-17-2005, 03:31 PM
I think you might be talking about this thread (http://community.installshield.com/showthread.php?t=140005). The IDriverT just assists the IDriver, allowing it to communicate across odd identity scenarios where MSI and Setup.exe would disagree about who the installation was running as. The scenario I know this was necessary involved nobody being logged in, but it may help in other scenarios as well. If the service in IDriverT is not present on the machine, it will cleanly fall back to old behavior.

Christopher Painter
01-17-2005, 04:09 PM
Yes thats the thread. ( Doh, don't know why I couldn't find it. )

So it looks like I'm going to continue to run with a modified ISScript package to have both IDrivers run as launching not interactive. My initial migration to 10.5 seems to support that this is still a needed and viable solution to my SMS 2003 problem.