Hi,
I am attempting to create a ThinApp package for a 32-bit applicaiton that will be ran on Windows 7 but will not work natively. We are attempting to see if ThinApp will be a better solution then Window 7's XP Mode.
I have created a VM running Windows XP SP3 and the only other application installed in the ThinApp packager.
I have done a pre-scan, installed the application, installed patches, ran the application did some tests and then done a post-scan.
I am not using an MSI, and selected the appropriate EXE as the sole entry-point.
When I run the ThinApp package on the test Windows 7 PC, the package is ran and then an MSI installer runs attempting to install something. After a second or two a warning box appears with the error "Error 1719: The windows installer service could not be accessed..."
The Event Viewer on the Windows 7 PC has the following entry:
Detection of product '{CDBE7633-3674-4B99-9E08-688DF8E8CE97}', feature 'Supporting_Files', component '{303994BA-6487-47AE-AF1D-7AF6088EEBDB}' failed. The resource '' does not exist.
Has anyone had any experience with this error message, is there something that I am missing when creating the package?
Please check this:
http://blogs.vmware.com/thinapp/2010/08/captured-on-xp---running-on-win-7.html
What is the observation when launching the ThinApp on Windows XP?
Thanks
Lakshman
Hi Laksham,
I have followed the blog article, I was running 4.6, so have upgraded to 4.6.1.
After re-creating the package using 4.6.1 and running it on the Windows 7 PC, the installer was still displaying, however in Event Viewer it mentioned that two DLL files were missing from C:\Windows\System32 - msvbvm50.dll and mfc40.dll. I copied these from the source PC to the packages %SystemSystem% folder and rebuilt the application, again with no success.
Running the package on a Windows XP PC (without the software already installed) has no issues with the application loading with no installer windows appearing.
The DLL's mentioned in the blog do not exist in the %SystemSystem% folder.
Is there anything that XP SP3 has that may not be present in Windows 7 that normally causes these issues? The application is a few years old (hence not installing it directly to Windows 7), and so I doubt it requires anything .Net.
When installing the application, the application is installed using an ini file located on a network server and it also communicates with some servers on the network, would this cause issues?
Matt
Matt,
Is the application supported on Win 7? What happens if you install the native application on Win 7 and launch it?
Thanks
Lakshman
No it is not supported on Windows 7.
When I try to install the application, it fails to register the DLL's, and even when that is resolved a whole heap of other errors come up. I cant remember the specific details now, but it will not run under Windows 7 natively, so that is why we are looking at ThinApp.
We have got the application to work via Windows 7's XP Mode, however this incurrs a performance hit on the users PC which could present some issues to some of our impatient users.
It would be great if we could get ThinApp to work because then it would give us something to present when asking for some funds to increase our license to expand the use of ThinApp, but if we have to use XP Mode then this won't happen.
If you need anything else then please dont hesitate in asking.
Matt
Just to clarify..
ThinApp will not magically make an application run on Win7 if it is not supported on Win7. That said, we do offer some help with ThinApp. Great examples are Internet Explorer 6, Adobe Reader 5 and Lotus Notes 6.5.6. All not running natively on Win7 but does so with the help of ThinApp. It may be tricky to find the solution and there is no guaranties. The work around is often to include older Windows XP dlls into the package and that will make the application run on Win7.
These files tend to be of interest:
MFC40.DLL
MFC40U.DLL
MFC42.DLL
MFC42U.DLL
NOTE: Sometimes there are other MFC DLLs which may need to be loaded but are not listed here. A review of the Log Monitor logs may indicate this.
MSVBMxx.DLL (where "xx" is the version number such as 50, 60, 70, 80, etc.)
MSVCRT.DLL
MSVCRT20.DLL
MSVCRT40.DLL
MSVCPxx.DLL (where "xx" is the version number such as 50, 60, 71, 80, etc. MSVCP50.dll helped me just the other day)
COMADDIN.DLL (not often needed)
COMCAT.DLL (not often needed)
COMCTL32.DLL
COMDLG32.DLL (not often needed)
COMMDLG.DLL (not often needed)
That is truely a suprise. I was under the impression that ThinApp worked somewhat independant of the OS to allow applications to run.
I will check out these DLL's and see if this can make any difference.
Thanks heaps for the clarification, ThinApp may not (still have hope) be of use for this problem, but at least we wont put this experience down to a failure of ThinApp and will still look at it for other applications or as a way to deal with non-SOE applications.
Matt
Hi,
ThinApp does not hide the basic operating system but in general allows to run an application allowing it to see a different installbase as realy available. This is done by providing the virtualised application the real filesystem & registry overlayed with the differences captured during the 'install/capture' phase.
In general the MS os is quite backward compatible. However if a file is missing in the capture (because tha capture is performed on a non-clean system) or in the base os (the 'target' os does no longer contain the file) it is not 'automagically' presented. Nice examples are:
If you capture on a system with office preinstalled, the virtualised application captured will miss all files already installed by the office installation. So running on a system that also has (the same version) of office installed works fine but on a 'clean' system the applcation could throw 'file not found' errors.
Same when capturing on an os and running the application on an os that has different base installations (like the dll's given by pbjork in the previous post). If the newer system no longer contains these dll's, you will have to unclude them in the package so the virtualised application still finds them...
Another problem could be that files are referenced on the wrong location...
If a virtualised application is captured on a system with windows installed in c:\windows, and runs on a system with c:\winnt, the application might not find this file. ThinApp does detect most of these translations, but sometimes a setting is missed or a application can not handle this...
So no, ThinApp is no OS hider or , but it eases deploying applications on different systems. But you still require testing and possibly patching settings. Besides that a lot of other features are available (like sandboxing, updatemanagement, keeping the system clean etc), but this is not question now.
Kind regards,
Michael Baars
Comprehensive ICT Solutions - Weert (NL)
(Please remember to mark your question answered if so and reward points to those who helped you...)
