QWebView doesn't show JPEG images on a clean XP machine

[mentalmushroom]

I use QWebView in my application. On my machine where Qt 4.7.2 and visual studio 2008 are installed QWebView displays images without any problems. But when I tried to run it on a clean XP SP2 it didn't.

Found some posts about the same problem:
http://www.qtcentre.org/archive/index.php/t-17469.html
http://stackoverflow.com/questions/4047366/qt-dll-deployment-on-windows

As it was suggested there, I copied imageformats folder to the directory where my app is located. So the file/folder structure is "MyAppFolder\imageformats" and "MyAppFolder\myapp.exe". But still have no JPEG images displayed. By the way, Qt sample facybrowser has the same problem.

[pkj]

use dependency walker to find out the dependencies. BTW copying imageformats was all that was needed... but you can read more on deploying qt applications in qt assistance.

[mentalmushroom]

as far as i see both applications don't even try to load that plugins: dependency walker doesn't show me qjpeg4.dll or any other image plugin.

[pkj]

yes since it is a plugin, it will not come as qjpeg4.dll but some other strange dlls missing. I use it in case of plugins to know if plugins are being detected. Does the dependency walker show any troubles?

[mentalmushroom]

It tells cannot find MSJAVA.DLL, also I see a mismatch in QTCORE4.DLL checksum and, finally, it tells "Warning: At least one delay-load dependency module was not found. Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.", but i see those messages in most any application.

[pkj]

check if this link is relevant to you...qjpeg4 on some systems (http://lists.qt.nokia.com/pipermail/qt-interest/2009-October/013783.html) ,
msjava.dll afaik is used by sql drivers..have you added em too... since they too are plugins... but i may be wrong...

[mentalmushroom]

well that was for qt demo application called fancybrowser. people say it normally displays images. i don't care much about how it deals with java or sql dirvers, the only need is to make images work. did you try that sample on a clean machine?

[janton]

Perhaps you need to build it with:
qApp->addLibraryPath("C:/customPath/plugins");

http://doc.trolltech.com/4.7/deployment-windows.html#qt-plugins

By default, the plugins subdirectory of the Qt installation is the first plugin search path. However, pre-determined paths like the default one have certain disadvantages. For example, they may not exist on the target machine. For that reason, you need to examine various alternatives to make sure that the Qt plugins are found... (more in the link)

Added after 7 minutes:

or this:
QCoreApplication::addLibraryPath(QCoreApplication: :applicationDirPath()+"/imageformats");

[mentalmushroom]

Nothing helps, still didn't find the solution. Also noticed the same problem with QImage::load. Yet another Qt sample (imageviewer) is unable to load images on clean XP. I tried it on different machines with the same success. Could someone be so kind to create a small sample application that is able to load JPEG image on the clean XP. For now looks like a Qt bug. I tried only Qt 4.7.2, not sure about later versions.

[wysota]

If the plugin doesn't load, then no Qt application will display JPEG images. Make sure you have the proper imageformats directory copied -- if your app is built in debug mode, you need plugins in debug version as well, if it's built in release mode, you need release mode plugins. In doubt compare the output of dependency walker ran on the main application binary and the plugin dll, check that both reference the same Qt DLLs.

[mentalmushroom]

I use release version of my project and release version of qjpeg plugin (without 'd' letter). I have imageformats directory in the same folder as my exe-file located. I am not very familiar with dependency walker, but it fails to process qjpeg4.dll. Also I don't see qjpeg dll in the dll list of my application (or any other application mentioned here). Should I somehow manually load this plugin in order to get images displayed? I thought Qt samples should work out of the box.

[wysota]

I am not very familiar with dependency walker, but it fails to process qjpeg4.dll
Fails how?


Also I don't see qjpeg dll in the dll list of my application (or any other application mentioned here).
You won't see it because your application doesn't depend on qjpeg.dll


I thought Qt samples should work out of the box.
If the plugin is available then yes.

[mentalmushroom]

This is how dependency walker fails when processing qjpeg4.dll
http://xmages.net/storage/10/1/0/0/5/upload/29008e5c.png (http://xmages.net/show.php/3023727_fail-png.html)

This is imageviewer qt sample along with necessary qt dlls, Visual Studio CRT dlls and plugin dlls:
http://xmages.net/storage/10/1/0/f/0/upload/bcd72560.png (http://xmages.net/show.php/3023738_imageviewer-png.html)

This is the content of imageformats directory:
http://xmages.net/storage/10/1/0/3/5/upload/ddeb6fa3.png (http://xmages.net/show.php/3023759_imageformats-png.html)

Finally, here you can see how imageviewer sample "nicely" fails to load an ordinary jpeg file. Also fancy browser doesn't show images while opera browser displays it very well for the same site on the same system:
http://xmages.net/storage/10/1/0/8/f/upload/377f94d1.png (http://xmages.net/show.php/3023752_noimages-png.html)

[wysota]

Is your Qt built against MSVC or MinGW? How did you install Qt in your system?

[mentalmushroom]

I downloaded ready-made binaries for visual studio 2008 and installed with the standard installer it comes with. I am talking about the machine where I develop the project (Windows 7 x64 + Visual Studio 2008 + Qt 4.7.2) that has no image showing problem. The target machine is clean XP, so I simply copy needed dlls along with my exe (as shown in the previous post).

[wysota]

I don't know why Dependency Walker can't process your jpeg plugin but probably because of the same reason also your application can't load it. Maybe it's a matter of architecture (64b vs 32b) as the target machine seems to be 32b (x86)? We can't help you much without access to your computer, so you're on your own here. The only advice I can give you is that you need to make sure your app can load the qjpeg plugin. Maybe this helps somehow: http://buffered.io/2008/05/17/resolving-side-by-side-configuration-issues/

[mentalmushroom]

Maybe it's a matter of architecture (64b vs 32b) as the target machine seems to be 32b (x86)?
Yes, target is x86, but I develop only x86 version, so if there was something related to x86/x64, I think I would rather have problems on windows 7 x64 than on XP x86. Anyway, also tried to build on Vista x86 - the same problem.

Just noticed that images don't work on clean Vista also. I suppose if you try it on your machine where clean windows OS is installed you will have the same, so access to my computer is not really needed. Already tried on several different machines. The problem is nobody wants to try it himself.

Added after 6 minutes:

Finally, it seems I found it! I have clean OS on my virtual machine (VMWare) and it doesn't work there, but on a real machine it works.

[wysota]

I suppose if you try it on your machine where clean windows OS is installed you will have the same, so access to my computer is not really needed.
I believe you are wrong because I never had any serious problems with image plugins on any Windows machine (be it real or virtual). The problem is clearly with the machine configuration and not Qt itself.

[mentalmushroom]

Hm.. But other people also have this on VMWare

[wysota]

Maybe while installing the machine on VMWare something gets installed which causes the side-by-side configuration problems. Try using VirtualBox instead of VMWare and see if the problem persists.

[janton]

i also have the same problem with VMware 7.0.1 build-227600 and a clean windows XP

Added after 1 25 minutes:

we found the problem, will report back when we know the solution!

[mentalmushroom]

Ok, just found out that plugins require visual studio redistributable package installed or crt folder inside the imageformats directory. I think this is why most people don't experience problems with plugins, but users are not obligated to have vcredist installed.

[wysota]

but users are not obligated to have vcredist installed.
If you build an application using MSVC then each and every one will require the C runtime from that compiler. It's quite common knowledge and many apps and games include vcredist in their installations and tell users to run it in case they experience problems.

[mentalmushroom]

Not every one. Some apps statically link those libs. For my project I simply include crt folder. It would be strange to install vcredist for a small tool.

[wysota]

Not every one. Some apps statically link those libs.
Nothing prevents you from doing the same (including statically linking the image plugins). Just remember that if you statically link the application, you include a static version of the C runtime as well, as regardless of linking mode the C runtime is still required.

[mentalmushroom]

Is it possible to link qt plugins statically when I use compiled binaries? I tried to build and got this error:

error LNK2019: unresolved external symbol "class QObject * __cdecl qt_plugin_instance_qjpeg(void)" (?qt_plugin_instance_qjpeg@@YAPAVQObject@@XZ) referenced in function "public: __thiscall StaticqjpegPluginInstance::StaticqjpegPluginInstan ce(void)" (??0StaticqjpegPluginInstance@@QAE@XZ)
Perhaps, compiled version allows dynamic linking only.

[wysota]

For linking statically you need statically linked versions of the libraries you use (including Qt and the C runtime of your compiler).

[mentalmushroom]

Is it possible to place plugin dlls to the folder other than imageformats? Namely I'd like to have those dlls nearby my exe-file, so I don't have to copy crt libraries two times.

I tried QCoreApplication::addLibraryPath(qApp->applicationDirPath()), but it didn't work.

[wysota]

Not without rebuilding Qt. But you shouldn't need two crt sets, one is enough, provided they are the same crt file.

[mentalmushroom]

One crt folder is needed for exe file, another one is needed for imageformats directory. If I could place plugins to the same folder as exe then I could use only one crt folder.

[wysota]

One crt folder is needed for exe file, another one is needed for imageformats directory.
Is it the same file? With the same size, timestamp, etc.? You're the only one who claims two crt files are needed, by the way, so something is wrong on your end and I doubt placing the plugin in the same directory as the executable would help.

[mentalmushroom]

as i told yesterday, image plugins don't work without vcredist. if installing vcredist is not an option it is possible to place crt libraries inside imageformats folder - then it works. another crt folder is needed for the project itself, because it was built with msvc 2008. yes, both crt folders are absolutely the same and i am trying to avoid duplication, but plugins don't work if i place them to the same directory as exe file.

[wysota]

as i told yesterday, image plugins don't work without vcredist.
My question is very simple -- is it the same file (I'm not asking about the file name)? I assume you know what dll files are and how they work so you surely know that if this is the same file (or even exporting the same symbols), only one copy of the file will be open and the other will be totally ignored.

[mentalmushroom]

I'd like to clear up what file are you talking about? If crt dlls, then yes, they are absolutely the same. I copied Microsoft.VC90.CRT folder into imageformats directory. It is stupid, but this is the only way I got images work in the browser on clean machine (without vcredist).

[wysota]

I copied Microsoft.VC90.CRT folder into imageformats directory.
You copied the folder or its contents? Did you also copy this same folder (or its contents) to the directory containing your binary or were the crt files already there (or did you copy them from elsewhere)?

[mentalmushroom]

I tried it different:

1) I have crt folder nearby my exe, but not inside the imageformats folder:

http://xmages.net/storage/10/1/0/d/0/upload/1593958f.png (http://xmages.net/show.php/3029011_doesnt-work-png.html)

As you can see, doesn't work.

2) I have content of crt folder nearby my exe, but not inside imageformats folder:

http://xmages.net/storage/10/1/0/1/2/upload/9d97bef0.png (http://xmages.net/show.php/3029020_doesnt-work-2-png.html)

Also doesn't work.

3) I have content of crt folder nearby my exe, also I have all plugin dlls there, so everything is in the same directory:

http://xmages.net/storage/10/1/0/e/5/upload/4bffe4b2.png (http://xmages.net/show.php/3029029_doesn-t-work-all-in-one-png.html)

Doesn't work either.

4) I have crt folder nearby my exe, and the copy of it inside imageformats folder.

http://xmages.net/storage/10/1/0/e/7/upload/bf10cfc8.png (http://xmages.net/show.php/3029040_works-png.html)

Now it works.

[wysota]

Please use the attachment feature of the forum to attach images instead of using 3rd party sites.

You have something seriously screwed up since as far as I know by default the Windows dynamic loader doesn't look into any subdirectories for dll files. Apparently the application manifest states the file should be found there. Check the manifest for your application and make sure Qt and your application are compiled using the same version of the compiler.

Also if you built the program from within Visual Studio, please try building it from the command line using qmake && nmake and see if the problem persists.

[mentalmushroom]

As you can see there is no manifest file for the application at all, and the application I tested was imageviewer. It is a sample qt app, I didn't even build it, just copied exe file to my virtual machine. But generally, yes, I use Microsoft Visual Studio 2008 SP1 and I already had problems with manifest and libraries, but this is not the case, I think.

[wysota]

As you can see there is no manifest file for the application at all
As far as I know the manifest is embedded into the binary file. You need to extract it and have a look. How to do that is out of scope of this forum though, I'm sure you'll find something using your favourite search engine. It's likely you tweaked some configuration in visual studio (or your build system) during your previous struggles with manifests which somehow influences your current setup. Did you try building from the command line as asked?

[mentalmushroom]

I didn't build it. I downloaded Qt binaries here (http://qt.nokia.com/downloads/windows-cpp-vs2008) (only it was 4.7.2 at that time), then installed it, found imageviewer sample and copied exe file to a clean XP on my virtual machine. If somebody tweaked visual studio configuration, that was not me, but Qt people who created those binaries. As long as the test application is qt sample I post it to Qt forum. I guess Microsoft people won't help me much with Qt demo.

If something is done wrong in Qt binaries, I hope it to be fixed. Otherwise, I'd like to know how to run those samples, because as you can see it is not that easy to run when Visual C++ Redistributable is not installed.

[wysota]

I didn't build it.
So please open the Visual Studio command prompt and build your application from within the command line, as requested.


If something is done wrong in Qt binaries, I hope it to be fixed. Otherwise, I'd like to know how to run those samples, because as you can see it is not that easy to run when Visual C++ Redistributable is not installed.
Strangely it works for thousands if not millions of people but not you. Probably Qt binaries have a special "if" block detecting your machine so that loading images fails on your machines only.

[mentalmushroom]

Ok, I've built it. It works with the same result. By the way, I am wondering why should I rebuild Qt samples, aren't those binaries correct?


Strangely it works for thousands if not millions of people but not you. Probably Qt binaries have a special "if" block detecting your machine so that loading images fails on your machines only.
I think, most people use it along with Visual C++ Redistributable package, so they don't have this problem, or even with some another compiler. Unfortunately, I can't use redistributable package.

I extracted manifest from imageviewer.exe:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"></assemblyIdentity>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>


Here goes manifest from crt folder:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInheritable></noInheritable>
<assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
<file name="msvcr90.dll" hashalg="SHA1" hash="98e8006e0a4542e69f1a3555b927758bd76ca07d"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>+CXED+6HzJlSphyMNOn27ujadC0=</dsig:DigestValue></asmv2:hash></file> <file name="msvcp90.dll" hashalg="SHA1" hash="3aec3be680024a46813dee891a753bd58b3f3b12"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>MyKED+9DyS+1XcMeaC0Zlw2vFZ0=</dsig:DigestValue></asmv2:hash></file> <file name="msvcm90.dll" hashalg="SHA1" hash="0195dd0896d74b62531e4f3c771904a3d996450e"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>EeyDE7og6WoPd2oBhYbMEnpFHhY=</dsig:DigestValue></asmv2:hash></file>
</assembly>

[totem]

I think, most people use it along with Visual C++ Redistributable package, so they don't have this problem, or even with some another compiler. Unfortunately, I can't use redistributable package.


Why so ?
From Qt docs (here) it seems it's necessary; not sure you have the choice

[mentalmushroom]

It is possible to distribute the application with crt folder. But in my case I have to distribute imageformats folder also and those plugins don't work unless I include crt folder duplicate inside.

[wysota]

Ok, I've built it. It works with the same result. By the way, I am wondering why should I rebuild Qt samples, aren't those binaries correct?


I think, most people use it along with Visual C++ Redistributable package, so they don't have this problem, or even with some another compiler. Unfortunately, I can't use redistributable package.
The problem is with your machine and with your machine only. There is a trio here that needs access to the C runtime:
1) Qt libs
2) Qt plugins
3) your application

Furthermore Qt plugins depend on Qt libs. If all those components required the same C runtime, you'd only need one runtime. If they somehow require different runtimes then they have not been built using the same settings. Furthermore if Qt libs and Qt plugins require a different runtime then apparently they haven't been built together. You can see that in QtSDK where there are loads of plugins for Creator (which is built with MSVC), there is no runtime in each plugin directory and strangely enough everything works fine even on a "clean XP" machine. I don't know what you did, I don't know how you deployed your program to the target machine but apparently you didn't do it correctly. That's the whole story and putting the blame on Qt libraries is a silly thing to do. After all you don't need a copy of Qt libs in the "imageformats" directory even though the plugins depend on Qt, right? So where is the difference between plugins requiring Qt libs and plugins requiring the C runtime? Welcome to DLL hell!

Here is a fragment of the docs you should read too:

Visual Studio 2008 And Manual Installs

As well as the above details for VS 2005 and onwards, Visual Studio 2008 applications may have problems when deploying manually, say to a USB stick.

The recommended procedure is to configure Qt with the -plugin-manifests option using the 'configure' tool. Then follow the guidelines for manually deploying private assemblies.

In brief the steps are

create a folder structure on the development computer that will match the target USB stick directory structure, for example '\app' and for your dlls, '\app\lib'.
on the development computer, from the appropriate 'redist' folder copy over Microsoft.VC80.CRT and Microsoft.VC80.MFC to the directories '\app' and '\app\lib' on the development PC.
xcopy the \app folder to the target USB stick.

Your application should now run. Also be aware that even with a service pack installed the Windows DLLs that are linked to will be the defaults. See the information on how to select the appropriate target DLLs.

[mentalmushroom]

The problem is with your machine and with your machine only
No, I tried it on a different machine. It was a different computer with a different version of XP. Only it was on the virtual machine also, but I think it should not cause problems, because I tried both VMWare and VirtualBox.


I don't know what you did, I don't know how you deployed your program to the target machine but apparently you didn't do it correctly.
Well, I told you several times how I did it, even posted screenshots yesterday. I installed Qt binaries downloaded from Qt site and copied demo application along with imageformats and crt folder. Yes, I understand very well it should work without imageformats inside each directory, but the problem is it doesn't work otherwise.


The recommended procedure is to configure Qt with the -plugin-manifests option using the 'configure' tool
I guess this can be done when you build qt yourself. I use ready-made binaries, but as long as they are intended to be used with visual studio, I think it should be configured properly.


create a folder structure on the development computer that will match the target USB stick directory structure, for example '\app' and for your dlls, '\app\lib'.
on the development computer, from the appropriate 'redist' folder copy over Microsoft.VC80.CRT and Microsoft.VC80.MFC to the directories '\app' and '\app\lib' on the development PC.
xcopy the \app folder to the target USB stick.
I think, I did what was said here, but I didn't copy mfc directory. As long as it works without it when I include crt inside imageformats, I think mfc is not needed.

Perhaps all test systems I tried were incorrectly configured or I did something wrong in deploying, I would be highly appreciated if somebody could show how to do it right. I think for those who also use compiled binaries from qt site it is not that much work to try, because enough is to test the demo application (e.g. imageviewer). But important thing is the target system (XP) should be clean without vcredist and other optional software.

[wysota]

Well, I told you several times how I did it, even posted screenshots yesterday.
I know a picture can speak one thousand words, but definitely not in this case.


I guess this can be done when you build qt yourself. I use ready-made binaries, but as long as they are intended to be used with visual studio, I think it should be configured properly.
So stick to the rules and deploy dependencies properly.


I think, I did what was said here, but I didn't copy mfc directory. As long as it works without it when I include crt inside imageformats, I think mfc is not needed.
I have no idea why this section of docs mentions MFC. "Just in case", probably. Nevertheless you didn't teach your bundle to look for the crt in a proper directory.


Perhaps all test systems I tried were incorrectly configured or I did something wrong in deploying, I would be highly appreciated if somebody could show how to do it right.

Launch vcredist install from your installer, use a different compiler, build Qt yourself or deploy your application statically. The choice is yours to make. Unfortunately Windows deployment model sucks but we all have to live with it.