Qt-interest Archive, September 2007
Problems on Win Vista
Message 1 in thread
Hello,
might be off-topic but my problem is deploying a Qt (3.3.8 - but i guess
that's not important here) application on Win Vista.
Built with VS2005 (in Release mode) it runs fine on my development
machine but not on XP or any other Vista PC.
The app is as simple as:
#include <qapplication.h>
int main(int argc, char ** argv)
{
QApplication a(argc, argv);
return a.exec();
}
I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
The app doesn't really start cause i get the following error:
"The application could not be initialized properly."
Any ideas someone?
Thx,
RZ
--
[ signature omitted ]
Message 2 in thread
RZ wrote:
> I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
> mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
>
> The app doesn't really start cause i get the following error:
> "The application could not be initialized properly."
>
> Any ideas someone?
First of all, does it produce the same error on XP as as Vista?
If yes, then the problem is most likely in the installation of the MS VC
runtime DLLs.
http://msdn2.microsoft.com/en-us/library/ms235624(VS.80).aspx
And make sure to read the comments.
Hope this helps,
- Adam
--
[ signature omitted ]
Message 3 in thread
Hi!
I had the same problem (and an very angry customer ^^).
Solution:
Compile your project and qt with Visual Studio 2003 and deploy with the
msvc*71.dll files.
The new assembly system of Microsoft seems to be buggy. Even though I
added every single required dll/manifest and compiled the exe with an
embedded manifest, it did not work.
Greetings
Niklas
RZ schrieb:
> Hello,
>
> might be off-topic but my problem is deploying a Qt (3.3.8 - but i guess
> that's not important here) application on Win Vista.
> Built with VS2005 (in Release mode) it runs fine on my development
> machine but not on XP or any other Vista PC.
>
> The app is as simple as:
> #include <qapplication.h>
>
> int main(int argc, char ** argv)
> {
> QApplication a(argc, argv);
>
> return a.exec();
> }
>
>
> I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
> mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
>
> The app doesn't really start cause i get the following error:
> "The application could not be initialized properly."
>
> Any ideas someone?
>
> Thx,
>
> RZ
--
[ signature omitted ]
Message 4 in thread
You probably need to run the vcredist_x86.exe package installer on the
target machines. Still, I agree that M$'s system is terribly buggy. Even
after installing the DLL's (which should be part of the system in the first
place), it still doesn't always find them correctly. The manifests are a
terrible idea.
On 09-27-2007 11:10 AM, "Niklas Hofmann" wrote:
> Hi!
>
> I had the same problem (and an very angry customer ^^).
>
> Solution:
> Compile your project and qt with Visual Studio 2003 and deploy with the
> msvc*71.dll files.
>
> The new assembly system of Microsoft seems to be buggy. Even though I
> added every single required dll/manifest and compiled the exe with an
> embedded manifest, it did not work.
>
> Greetings
>
> Niklas
>
>
> RZ schrieb:
>> Hello,
>>
>> might be off-topic but my problem is deploying a Qt (3.3.8 - but i guess
>> that's not important here) application on Win Vista.
>> Built with VS2005 (in Release mode) it runs fine on my development
>> machine but not on XP or any other Vista PC.
>>
>> The app is as simple as:
>> #include <qapplication.h>
>>
>> int main(int argc, char ** argv)
>> {
>> QApplication a(argc, argv);
>>
>> return a.exec();
>> }
>>
>>
>> I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
>> mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
>>
>> The app doesn't really start cause i get the following error:
>> "The application could not be initialized properly."
>>
>> Any ideas someone?
>>
>> Thx,
>>
>> RZ
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
Keith Esau
Staff Engineer (dpSHEET)
PDF Solutions, Inc.
keith.esau@xxxxxxx
408-283-5681 (San Jose)
913-515-2135 (mobile)
kaesau@xxxxxxxxxxxxx (home/personal)
===========================================================================
CONFIDENTIALITY NOTICE: This email contains information that may be
confidential and privileged. Unless you are the intended recipient (or
authorized to receive for the intended recipient), you are prohibited from
reviewing, using, copying, forwarding, keeping, or disclosing to anyone
other than PDF Solutions, Inc. this email or any information in the email
(including any attachment). If you have received this email in error,
please send a reply email only to the sender <keith.esau@xxxxxxx> (delete
the original message body from the reply), and please delete this message
from your system. My apologies for the inconvenience, and thank you in
advance for your cooperation.
===========================================================================
--
[ signature omitted ]
Message 5 in thread
In theory it should be sufficient to add the runtime assemble as private
assemble (just deliver the exe with the Microsoft.VC80.CRT.manifest +
DLLs) and you have to add a binary manifest to you exe (which says that
it requires Microsoft.VC80.CRT).
Maybe your practical advice would have solved the situation, and in fact
I asked my customer to do so - but he was angry and did not want to try
:-D Therefore it is still a secret to me...
Greetings
Niklas
Keith Esau schrieb:
> You probably need to run the vcredist_x86.exe package installer on the
> target machines. Still, I agree that M$'s system is terribly buggy. Even
> after installing the DLL's (which should be part of the system in the first
> place), it still doesn't always find them correctly. The manifests are a
> terrible idea.
>
>
> On 09-27-2007 11:10 AM, "Niklas Hofmann" wrote:
>
>> Hi!
>>
>> I had the same problem (and an very angry customer ^^).
>>
>> Solution:
>> Compile your project and qt with Visual Studio 2003 and deploy with the
>> msvc*71.dll files.
>>
>> The new assembly system of Microsoft seems to be buggy. Even though I
>> added every single required dll/manifest and compiled the exe with an
>> embedded manifest, it did not work.
>>
>> Greetings
>>
>> Niklas
>>
>>
>> RZ schrieb:
>>> Hello,
>>>
>>> might be off-topic but my problem is deploying a Qt (3.3.8 - but i guess
>>> that's not important here) application on Win Vista.
>>> Built with VS2005 (in Release mode) it runs fine on my development
>>> machine but not on XP or any other Vista PC.
>>>
>>> The app is as simple as:
>>> #include <qapplication.h>
>>>
>>> int main(int argc, char ** argv)
>>> {
>>> QApplication a(argc, argv);
>>>
>>> return a.exec();
>>> }
>>>
>>>
>>> I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
>>> mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
>>>
>>> The app doesn't really start cause i get the following error:
>>> "The application could not be initialized properly."
>>>
>>> Any ideas someone?
>>>
>>> Thx,
>>>
>>> RZ
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>
> Keith Esau
> Staff Engineer (dpSHEET)
> PDF Solutions, Inc.
> keith.esau@xxxxxxx
> 408-283-5681 (San Jose)
> 913-515-2135 (mobile)
> kaesau@xxxxxxxxxxxxx (home/personal)
>
> ===========================================================================
> CONFIDENTIALITY NOTICE: This email contains information that may be
> confidential and privileged. Unless you are the intended recipient (or
> authorized to receive for the intended recipient), you are prohibited from
> reviewing, using, copying, forwarding, keeping, or disclosing to anyone
> other than PDF Solutions, Inc. this email or any information in the email
> (including any attachment). If you have received this email in error,
> please send a reply email only to the sender <keith.esau@xxxxxxx> (delete
> the original message body from the reply), and please delete this message
> from your system. My apologies for the inconvenience, and thank you in
> advance for your cooperation.
> ===========================================================================
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 6 in thread
Niklas Hofmann schrieb:
> In theory it should be sufficient to add the runtime assemble as private
> assemble (just deliver the exe with the Microsoft.VC80.CRT.manifest +
> DLLs) and you have to add a binary manifest to you exe (which says that
> it requires Microsoft.VC80.CRT).
Right!
> Maybe your practical advice would have solved the situation, and in fact
> I asked my customer to do so - but he was angry and did not want to try
> :-D Therefore it is still a secret to me...
Huh, manifests again ;)
I can assure everyone that deploying the VS2005 C++ runtime DLLs within
the application directory WORKS if you do it The Right Way(tm) -
whichever that is, but anyway, we have a working configuration, see
below. Note that shipping and running the vcredist.exe is surely the
PREFERRED Microsoft Way(C), but if you do not want to run this then do
the following (for Qt 3.3.8, analog for Qt 4.x):
- Compile your *.exe with the default manifest options, the ones
which are setup when you either create an empty Win32 or a Qt
project (that is, the manifest is embedded into your *.exe/*.dll)
- Compile in RELEASE and with the /Md (multithreaded DLL) switch
- Make sure that you compile your Qt 3.3.8 with the SAME compiler
service pack (VS 2005 SP1) as your application. I have found out
that it does also work with a Qt 3.3.8 compiled on a Visual Studio
2005 WITHOUT Service Pack, linked against a SP 1 *.exe, you are on
the safe side recompiling Qt 3.3.8
- Put and ship the following VS2005 C++ runtimes into your APPLICATION
directory (the same place where your *.exe is):
Microsoft.VC80.CRT.manifest
msvcp80.dll
msvcr80.dll
While in practice I have found out that these DLLs are sufficient in
theory you also need:
msvcm80.dll
The Dependency Walker showed no dependency of any of my *.exe/*.dlls
with this runtime and Qt 3.3.8 also does not seem to need it. But YOU
NEED IT when compiling Qt 4.x applications (at least Qt 4.x needs it).
- NOW COMES THE CRUCIAL PART: Do NOT (!) ship the *.manifest files
of the Qt plugins with your application! I repeat: DO NOT SHIP
qjpeg100.dll.manifest
qpng100.dll.manifest
etc.
Only ship the plugins *.dll alone, for example:
[app_dir]
+- your_app.exe
+- your_library_for_the_app.dll
+- Microsoft.VC80.CRT.manifest
+- msvcp80.dll
+- msvcr80.dll
+- msvcm80.dll // optional for Qt 3.3.8, as it seems
+-imageformats
+- qjpeg100.dll // NO *.manifest files here..
+- qpng100.dll
+-styles
+- qwindowsxpstyle.dll // ... nor here!
Why is that? The plugins are loaded dynamically, and obviously on
Windows XP and above the *.manifest files ARE parsed when
found!
Since those manifest files say "Look into the CURRENT
directory or somewhere under c:\Windows\WinSxS\..." and the
CURRENT directory would e.g. be [app_dir]\imageformats where
obviously NO C++ runtime DLLs are, the loading of the plugin would
fail!
Now I might have forgotten some crucial details, but the above setting
should work! Maybe I have forgotten some magic Visual Studio project
settings, but most of them I left as is after creating a Qt project.
Mostly I just made sure that I compiled with "Multithreaded DLL" and set
a few (application relevant) DEFINES.
To the OP: If you want I can compile your little Qt application, put all
the required DLLs into a ZIP and send it to you in private, then you can
test it on a "naked" system (no C++ runtimes installed previously).
While we are developing on Windows XP I ran your Qt 3.3.8 based
application also on a naked Windows Vista, and IT ALSO worked! I have
not yet tried the ported Qt 4.x version yet, but I assume it also works
the same way (when shipping the additional msvcm80.dll).
Also note that we have tested both with and without SP1 for Visual
Studio 2005, it works both ways - just make sure that you ship the RIGHT
set of C++ runtime DLLs (you compile your app with SP1 -> you ship the
SP1 runtime DLLs)! By the way I copied them from:
C:\Program files\Microsoft Visual Studio
8\VC\redist\x86\Microsoft.VC80.CRT
Cheers, Oliver
--
[ signature omitted ]
Message 7 in thread
Have you installed vcredist_x86.exe or vcredist_x86-sp1.exe on the target
computer (vcredist_x86.exe if you haven't apply the SP1 for VS2005,
vcredist_x86-sp1.exe otherwise) ?
-----Message d'origine-----
De : RZ [mailto:rz@xxxxxxxxxxxx]
Envoyé : jeudi 27 septembre 2007 17:43
À : qt-interest@xxxxxxxxxxxxx
Objet : Problems on Win Vista
Hello,
might be off-topic but my problem is deploying a Qt (3.3.8 - but i guess
that's not important here) application on Win Vista.
Built with VS2005 (in Release mode) it runs fine on my development
machine but not on XP or any other Vista PC.
The app is as simple as:
#include <qapplication.h>
int main(int argc, char ** argv)
{
QApplication a(argc, argv);
return a.exec();
}
I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
The app doesn't really start cause i get the following error:
"The application could not be initialized properly."
Any ideas someone?
Thx,
RZ
--
[ signature omitted ]
Message 8 in thread
RZ schrieb:
> Hello,
> ...
> I deploy the app.exe, qt-mt338.dll, libmySQL.dll (as Qt was built with
> mysql), msvcr80.dll and Microsoft.VC80.CRT.manifest.
^^^^^^^^^^^
Hmmm, the solution might be as easy as shipping msvcp80.dll as well -
does that make a difference? At least with our application it shows up
as a dependency with Dependency Walker.
Cheers, Oliver
--
[ signature omitted ]
Message 9 in thread
Thx for all the help, problem could be solved by running the
vcredist_x86.exe (don't know what this does - and even don't want to).
I apologize for blaming Vista in the subject - the 'evil' was VS2005.
Totally off-topic for this group but concerning Vista (and also deployment):
the 'Feature' of translating directory names:
c:\program files in a german windows explorer get's translated to
c:\programme
some installers also create folders named e.g. c:\programme\myapp -
leading to the real wonderful thing that i now got _two_ "c:\programme"
in my windows explorer with of course different contents
this is ... (yes, what? - i can't imagine nobody at m$ noticed that ....)
--
[ signature omitted ]
Message 10 in thread
RZ schrieb:
> Thx for all the help, problem could be solved by running the
> vcredist_x86.exe (don't know what this does - and even don't want to).
It simply installs the C++ runtime DLLs somewhere under
c:\WINDOWS\WinSxS\... that's the place specified in the manifest files:
"Look in WinSxS (system-wide assembly) or in the application directory
(private assembly)".
Note that the system-wide assembly has ALWAYS precedence, which means:
even if you put the C++ runtime DLLs into the application folder the
system-wide DLLs (the ones in the WinSxS subfolders) are taken. The PATH
is completely ignored AFAIK when it comes to finding DLLs. That's
DIFFERENT of how "old style DLLs" (without manifests, as produced by VS
6 and 2003 aka .Net) are searched (1. application directory, 2. PATH, 3.
c:\WINDOWS\system (? not sure about the later ?))
Like this Microsoft tried to escape the "DLL Hell"(tm), now they have
entered the "Manifest Fiasco"(tm) ;)
>
> I apologize for blaming Vista in the subject - the 'evil' was VS2005.
"Microsoft is GOOD!"
;)
> Totally off-topic for this group but concerning Vista (and also
> deployment):
> the 'Feature' of translating directory names:
> c:\program files in a german windows explorer get's translated to
> c:\programme
Again this is not specific to Vista. In fact this has been the case
since Windows 95 I believe (where have you been the last 10 years? Did
you not suff^H^H^H^ enjoy Windows since then? ;) On german systems the
"application folder" is called "Programme", whereas on english systems
it is "Program Files" (okay, so much you already figured out yourself ;).
And this is exactly the reason why you should never hardcode such a
folder name but use %ProgramFiles% (environment value) or an installer
which takes care of these issues (also note that folders such as "My
documents" etc. are also translated!).
If you need to find out programmatically such paths (e.g. where to put
your documents, application settings (*.ini style) etc.) use the Win32
API/registry and/or use environment variables (in theory not reliable
since the users could falsify them, they could not be set at all etc.;
but "out of the box" systems have at least %ProgramFiles% and a few
others set).
> some installers also create folders named e.g. c:\programme\myapp -
> leading to the real wonderful thing that i now got _two_ "c:\programme"
> in my windows explorer with of course different contents
>
> this is ... (yes, what? - i can't imagine nobody at m$ noticed that ....)
Those installers are broken off course. Which one are you referring to?
The one shipped with Visual Studio 2005 (Professional) works for sure ;)
Cheers, Oliver
--
[ signature omitted ]
Message 11 in thread
>
>> Totally off-topic for this group but concerning Vista (and also
>> deployment):
>> the 'Feature' of translating directory names:
>> c:\program files in a german windows explorer get's translated to
>> c:\programme
>
> Again this is not specific to Vista. In fact this has been the case
> since Windows 95 I believe (where have you been the last 10 years? Did
> you not suff^H^H^H^ enjoy Windows since then? ;) On german systems the
> "application folder" is called "Programme", whereas on english systems
> it is "Program Files" (okay, so much you already figured out yourself ;).
>
i don't think we talk about the same here.
as you can see in the attached part of a screenshot i now got two
(physically not identical!) folders given the same name.
(one who's really named c:\programme and one who's translated to
c:\programme).
if this feature existed in pre-vista then i luckily missed it - cause it
breaks one of IMHO fundamental computer laws
Message 12 in thread
> i don't think we talk about the same here.
> as you can see in the attached part of a screenshot i now got two
> (physically not identical!) folders given the same name.
> (one who's really named c:\programme and one who's translated to
> c:\programme).
> if this feature existed in pre-vista then i luckily missed it - cause it
I can confirm this.. and I think Apple invented it (Mac OS X) ;-)...
Greetings
Niklas
--
[ signature omitted ]
Message 13 in thread
Niklas Hofmann schrieb:
>> i don't think we talk about the same here.
>> as you can see in the attached part of a screenshot i now got two
>> (physically not identical!) folders given the same name.
>> (one who's really named c:\programme and one who's translated to
>> c:\programme).
>> if this feature existed in pre-vista then i luckily missed it - cause it
>
> I can confirm this.. and I think Apple invented it (Mac OS X) ;-)...
>
> Greetings
>
> Niklas
Sorry, my statement was not clear.
I can confirm this on Vista, not on pre-Vista.
Greetings
Niklas
--
[ signature omitted ]
