Qt-interest Archive, February 2007
retrieve file date and time stamp
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Hi,
I want to retrieve the date and time stamp for files in a particular
directory. How do I do it? Is there a class/function that will return these
values in Qt?
Thanks,
Ashish
Message 2 in thread
On 08.02.07 09:49:11, Ashish Singh wrote:
> I want to retrieve the date and time stamp for files in a particular
> directory. How do I do it? Is there a class/function that will return these
> values in Qt?
Yes there is. See QFileInfo.
Andreas
--
[ signature omitted ]
Message 3 in thread
This is a quick note that might help anyone upgrading
to VS2005 when you discover that the plugins no longer load on
clean-install PCs.
I just spent a frustrating day resolving this problem (with
help from the as-always excellent TrollTech support folks),
so thought I'd share the problem & solution with others in
case you run into the same problem.
Symptoms of the problem are that plugins, such as the JPEG
image IO plugin, don't work on a clean-install PC.
The problem occurs if the target PC does not yet have have
the VS2005 C runtimes installed (Microsoft.VC80.CRT.manifest,
msvcm80.dll, msvcp80.dll, and msvcr80.dll) *and* you install
these in your local application directory, plugins will no longer work.
The problem sequence is this:
- The application will run with the local C runtime DLLs
- The plugin DLLs will try and load, but won't be able
to load the C runtimes, because MS's new DLL manifest
logic seems to require the DLLs to be in the system
directory.
- Because the plugins failed to load, Qt marks them
as failed and will not load them again in subsequent
program runs - even if you fix the problem (this was
the bit that made debugging hard until support highlighted
this issue to me).
At this point, even if you install the run time DLL's in
the system directory, the application will not load the plugins
until you touch the plugins DLL timestamp.
In short, it seems you can no longer ship an application
with local C runtime DLL's (at least, I've not found a way
to do it). Note you can't register the local DLLs with Windows
either - it reports an error when trying to do this.
The only solution that I've found that works is to include
the Microsoft supplied redistributable program "vcredist_x86.exe"
with your application, and be sure to run it on install *before*
any Qt application runs that might use plugins. That program
installs the C runtimes
The bottom line is that shipping an application with your
own local copies of the C runtime distributables no longer
works with VS2005 compiled applications - you need to install
them into the system, and not have local copies.
Hope this helps others with this.
Regards,
Stuart
--
[ signature omitted ]
Message 4 in thread
Stuart Nixon wrote:
> The only solution that I've found that works is to include
> the Microsoft supplied redistributable program "vcredist_x86.exe"
I admit that this is the preferred way to install applications on
Windows, and probably the "political correct one", too. When you build
an MSI installer you can mark a checkbox somewhere and have this
vcredist_x86.exe as "prerequisite" - it is then automatically installed
by the MSI if it detects that the runtime does not yet exist on the
target machine.
We have a "custom installer" though, so the solution below also works
for us.
> ...
> The bottom line is that shipping an application with your
> own local copies of the C runtime distributables no longer
> works with VS2005 compiled applications - you need to install
> them into the system, and not have local copies.
Uhm...actually this very setup works for us, I've tried it several times
on a virgin WinXP installation (that is, no VS or any MS runtime DLLs
installed previously).
This setup is also described by the Qt docs, "Deploying an application
on Windows":
http://doc.trolltech.com/4.2/deployment-windows.html#visual-studio-2005
Checking with a Dependency Walker on that virgin system also confirms
that the locally installed runtime DLLs (msvcp80.dll and msvcr80.dll, to
be specific) are taken (but then again, I'm not sure if the Dependency
Walker takes manifest files into account - on the other hand on my
development box the dependency walker indeed shows that the runtime DLLs
from somewhere under c:\Windows\WinSxS\... are taken (even though there
exist also copies in the local application directory!) - I think this
means that the Dependency Walker of Visual Studio 2005 DOES take
manifest files into account!).
This works as long as you ship the Microsoft.VC80.CRT.manifest, too. But
I guess you already did that.
However I observed certain network configurations where starting our
application did NOT work from a network mapped drive! The error message
was a strange and non-specific "Application initialization error -
Please contact your system admin" (or the like). Just as if you forgot
to install the runtime manifest file in the local directory.
Has probably something to do with read/write permissions or what do I
know. The network mapped drives were Unix drives, mapped via NFS or
something...
Anyway, installing the application on a local drive always works.
Cheers, Oliver
--
[ signature omitted ]
Message 5 in thread
> > ...
> > The bottom line is that shipping an application with your
> > own local copies of the C runtime distributables no longer
> > works with VS2005 compiled applications - you need to install
> > them into the system, and not have local copies.
>
> Uhm...actually this very setup works for us, I've tried it several times
> on a virgin WinXP installation (that is, no VS or any MS runtime DLLs
> installed previously).
Till,
Thanks for your comments.
Are you saying plugins worked with your approach? I found
that the application works with local C DLLs (and their VC80 manifest of course),
but the plugins would not load. I had to do a system-install of the C DLLs
to get the plugins to work. The plugins in question were direct copies
of the ones in the standard Qt Commercial binaries for Windows (I did not
recompile Qt).
My (possibly incorrect) theory was that because the manifest for the plugins
specified the system C DLLs, they would not use the local-install version
of the DLLs. Certainly it seems that my application was running from the
local DLLs quite happily, but the plugins would not not. That is still
puzzles me.
I'd like to get to the bottom of this problem if possible.
Cheers
Stuart
--
[ signature omitted ]
Message 6 in thread
Stuart Nixon schrieb:
>>> ...
>>> The bottom line is that shipping an application with your
>>> own local copies of the C runtime distributables no longer
>>> works with VS2005 compiled applications - you need to install
>>> them into the system, and not have local copies.
>> Uhm...actually this very setup works for us, I've tried it several times
>> on a virgin WinXP installation (that is, no VS or any MS runtime DLLs
>> installed previously).
>
> Till,
>
> Thanks for your comments.
>
> Are you saying plugins worked with your approach? I found
> that the application works with local C DLLs (and their VC80 manifest of course),
> but the plugins would not load. I had to do a system-install of the C DLLs
> to get the plugins to work. The plugins in question were direct copies
> of the ones in the standard Qt Commercial binaries for Windows (I did not
> recompile Qt).
Hmmm, I only later realized that you were actually referring to the
plugins, but I just double-checked:
I've copied our application on a Windows XP without Visual Studio 2005
runtime DLLs previously installed. I checked with the Dependency Walker
which showed me that the *.exe is indeed linking with the runtime DLLs
in the application directory.
Running the Dependency Walker with a Qt plugin (Qt 3! See below), for
example qjpeg100.dll, gives me an error indicating that the VS 2005
runtime DLL cannot be found (which is actually good, since that tells me
that no other runtime DLLs are lying around in the system).
But this is okay since the runtime DLLs are dynamically loaded by the
*.exe (from the application directory) and the plugins are explicitly
loaded by the application - at this time the runtime DLLs are already
linked, so that's fine for the plugins.
[application dir]
+ application.exe
+ Microsoft.VC80.CRT.manifest
+ msvcp80.dll (*)
+ msvcr80.dll
+ lib <- plugin path set by application
+ imageformats
+ qjpeg100.dll
+ qmng100.dll
+ qpng100.dll
+ TiffIO.dll
(*) Note: in our case we do not seem to need the msvcm80.dll which is
also located in C:\Program files\Microsoft Visual Studio
8\VC\redist\x86\Microsoft.VC80.CRT - the Dependency Walker shows no
dependency of our *.exe with this DLL and the application just runs fine
without it.
But I must admit that I am talking about a Qt 3 application! Hence the
Qt 3 dll is also compiled by ourselves with Visual Studio 2005, which
might explain the difference to what you are experiencing (we have
ported the application to Qt 4 by now with the binary release of Qt 4.2,
but I haven't checked that one just now).
The Qt 3 image format plugins are also installed in the application
directory (in a sub-directory, with the plugin path set accordingly in
the application, see above) and they load fine. I've tested the JPEG
plugin (qjpeg100.dll - the Qt 3 plugin) by loading a JPEG image into our
application and it works. Even a custom TIFF plugin appears in the
available image import filter list (indicating that the TIFF plugin has
been loaded).
Except from the registry entries written by QSettings (application
settings) we do not modify the registry in a Qt specific way ourselves,
at least not explicitly; so I cannot tell if some magic registry entries
are done by Qt itself - but I doubt so.
Does that help? Cheers, Oliver
--
[ signature omitted ]
Message 7 in thread
Till Oliver Knoll schrieb:
> Stuart Nixon schrieb:
>>>> ...
>>>> The bottom line is that shipping an application with your
>>>> own local copies of the C runtime distributables no longer
>>>> works with VS2005 compiled applications - you need to install
>>>> ...
> But I must admit that I am talking about a Qt 3 application! Hence the
> Qt 3 dll is also compiled by ourselves with Visual Studio 2005, which
> might explain the difference to what you are experiencing (we have
> ported the application to Qt 4 by now with the binary release of Qt 4.2,
> but I haven't checked that one just now).
*hmmpff* - I just tried to run the ported Qt 4.2 based application -
with the same application directory layout as the Qt 3 one - on the same
test machine... and it does not run!
Complaining something about "Could not initialize the application.
Re-installing might help." (That is it is _not_ complaining about a
missing DLL - this kind of error message is typical when something with
the manifest file is wrong or the DLLs are not at the expected place).
*sigh* - sorry, can't help you more. But it seems you have at least the
application itself running, so you are one step ahead of me now ;)
Before we had the "DLL hell", now we have the "Manifest file hell" ...
Cheers, Oliver
--
[ signature omitted ]
Message 8 in thread
> *hmmpff* - I just tried to run the ported Qt 4.2 based application -
> with the same application directory layout as the Qt 3 one - on the same
> test machine... and it does not run!
Rats. I was kind of hoping you had solved the problem and I was missing something
> Complaining something about "Could not initialize the application.
> Re-installing might help." (That is it is _not_ complaining about a
> missing DLL - this kind of error message is typical when something with
> the manifest file is wrong or the DLLs are not at the expected place).
I've discovered this is the new way of reporting a DLL that is missing
a manifest (or registered manifest - not sure which). So that message
essentially means "We found your DLL, but the DLL is missing the manifest,
but we are not going to tell you which DLL/Manifest to keep you guessing."
Makes it tricky to debug.
> *sigh* - sorry, can't help you more. But it seems you have at least the
> application itself running, so you are one step ahead of me now ;)
I got the application to run with the manifest and *all* three DLL's
(not just the ones you need). This I assume was because the manifest
was checking that all DLL's were present - not just the ones needed by
the application.
Once you get the application to run, I'd still be interested to see if
you can get the plugins to work with the app-local DLL's.
> Before we had the "DLL hell", now we have the "Manifest file hell" ...
It just goes from bad to worse. I'm just waiting for someone to discover
that editing manifests allows DLLs to be swapped under the system/application
causing all sorts of new security hassles....
Thanks for looking into this vexing problem and helping solve it.
Stuart
--
[ signature omitted ]
Message 9 in thread
>> *hmmpff* - I just tried to run the ported Qt 4.2
>> based application - with the same application
>> directory layout as the Qt 3 one - on the same
>> test machine... and it does not run!
>
> Rats. I was kind of hoping you had solved the
> problem and I was missing something
Double-rats! I was hoping you guys could solve
this so I could use your solution.
>> Complaining something about "Could not initialize
>> the application. Re-installing might help." (That
>> is it is _not_ complaining about a missing DLL -
>> this kind of error message is typical when
>> something with the manifest file is wrong or the
>> DLLs are not at the expected place).
>
> I've discovered this is the new way of reporting a
> DLL that is missing a manifest (or registered
> manifest - not sure which). So that message
> essentially means "We found your DLL, but the DLL is
> missing the manifest, but we are not going to tell
> you which DLL/Manifest to keep you guessing."
> Makes it tricky to debug.
<snip>,
> > Before we had the "DLL hell", now we have the
> "Manifest file hell" <snip>,
> It just goes from bad to worse. <snip>,
> Thanks for looking into this vexing problem and
> helping solve it.
Is there some "Quick Tips To Deploy" we could use?
(Has anyone written about this?)
I'm running the same config as you: VS2005, Qt4.2.2.
--charley
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!
http://mobile.yahoo.com/services?promote=mail
--
[ signature omitted ]
Message 10 in thread
Charley Bay schrieb:
> > ...
> Is there some "Quick Tips To Deploy" we could use?
> (Has anyone written about this?)
Well basically it is this document:
http://doc.trolltech.com/4.2/deployment-windows.html
which will tell you to copy the Visual Studio 2005 runtime DLLs,
including their manifest file, into your application folder.
Summary: this works for me on a clean (no VS2005 runtime DLLs installed
previously) Windows XP with the Qt3 based application (and even without
the msvcm80.dll), also the plugins work; but with the Qt4 ported
application I get the "Application initialisation" error message.
The fun thing is we have another application in the same directory, also
using Qt 4 - and this one DOES start up! But badly enough just for a
split second, then it terminates without error message; the other guy
porting that application probably still has some issues there ;) So I
cannot verify the plugins there for now.
And as to make things even more fun: on my developer box (VS 2005
runtime DLLs installed under C:\WINDOWS\WinSxS) when I remove those DLLs
in the WinSxS\... folder temporarily (msvcm80.dll, msvcp80.dll and
msvcr80.dll) the Qt3 based application does also NOT RUN ANYMORE, even
when I copy the "not needed" msvcm80.dll into the application folder.
The error message is similar as on the naked test Windows XP system, but
it is NOT QUITE the same: This time I get an error code (0xc0000034) and
the message says nothing about "re-installing might help", even though
this might be a translation issue (the attached error message from my
developer box is obviously german and says "Click on 'OK' as to
terminate the application", whereas the test system is english and says
"Re-installing the application might help"). Still I'm pretty sure the
test system does NOT give me an error code at all, so the error
situation must be a different one... ain't it so much fun, huh?
I think the reason for this error code is that on my developer box I
once have had vcredist_x86.exe (can be found under C:\Program
files\Microsoft Visual Studio
8\SDK\v2.0\BootStrapper\Packages\vcredist_x86) install the runtime DLLs
and I assume they somehow get registered in the registry. So when you
remove them manually from C:\WINDOWS\WinSxS\... it doesn't matter
whether you put them into the application folder or not: once they have
been installed under C:\WINDOWS\WinSxS\... they are expected to be
there, point. Or so it seems...
I will try to see if I can get our Qt4 based application run on the test
system and tell you more later on.
Sorry for this long post, but this is a major issue where everyone is
bound to run into and I am also very interested in finding a general
solution (for now it seems running the vcredist_x86.exe is the only
reliable solution).
Cheers, Oliver
Message 11 in thread
> Charley Bay schrieb:
> > > ...
> > Is there some "Quick Tips To Deploy" we could use?
> > (Has anyone written about this?)
Till Oliver Knoll respondeth:
> Well basically it is this document:
> http://doc.trolltech.com/4.2/deployment-windows.html
Yes -- I'm working with that. Unfortunately, I'm
looking for a document like your email: When
things go *wrong* (e.g., you get the useless "App
failed to initialize, re-install might help"), what
are you supposed to do? ;-))
<snip, interesting and different failed behaviors
with Qt3 and two different Qt4 applications, on
clean XP systems and ones where vcredist_x86.exe
had run>
We're also getting "app failed, re-install" on clean
XP/tablet systems, and successful app launch followed
by an abrupt crash on developer systems when launched
from a USB key. This is very disturbing, as the app
seems to run fine when launched from VS2005 or when
installed using vcredist_x86.exe.
My summary: Our application and its data commonly
runs from a USB key (medical workers plug their key
into any computer, even one where the application is
not installed). This works with Qt4/VS2003, but we've
recently ported to Qt4/VS2005, and get the "App failed
to initialize, please re-install".
For this to work, we can't use "vcredist_x86.exe"
because there's no install (in fact, users usually
don't have administrative privileges to install
anything). (Do you need "admin rights" to run
"vcredist_x86.exe"?) For us, all application files
and DLLs reside in the same USB directory, and
launches through "autorun.inf" in the USB root, or
the user launches the application explicitly.
I'm absolutely amazed debugging an install is this
hard. I'm ok with the idea of the manifest, but these
useless messages are ridiculous. Either I'm missing
some fundamental understanding, or somebody needs to
be taken out back and spanked for messing up
deployment.
> Sorry for this long post, but this is a major issue
> where everyone is bound to run into and I am also
> very interested in finding a general solution (for
> now it seems running the vcredist_x86.exe is the
> only reliable solution).
Don't be sorry! It was a very informative post,
and this is the only forum where I'm getting
information on this (very serious) problem.
Unfortunately for us, I don't think vcredist_x86.exe
will work (we need to run from a USB without an
install). I'm wondering if we'll simply have to
statically link everything, or if that's even possible
anymore...
--charley
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
--
[ signature omitted ]
Message 12 in thread
Charley Bay schrieb:
>> Charley Bay schrieb:
>>>> ...
>>> Is there some "Quick Tips To Deploy" we could use?
>>> (Has anyone written about this?)
>
> Till Oliver Knoll respondeth:
^^^^^^^^^^
>> Well basically it is this document:
To read or not to read the fine manual, that is the question—
Whether 'tis nobler in the memory to suffer
The slings and arrows of outrageous manifest files,
Or to take debuggers against a DLL of troubles,
And by opposing, end them. To kill(), to sleep()—
No more; and by a crash to say we end.
>
> Yes -- I'm working with that. Unfortunately, I'm
> looking for a document like your email: When
> things go *wrong* (e.g., you get the useless "App
> failed to initialize, re-install might help"), what
> are you supposed to do? ;-))
Ask Microsoft? Okay, that was just a suggestion ... ;)
> ...
> We're also getting "app failed, re-install" on clean
> XP/tablet systems, and successful app launch followed
> by an abrupt crash on developer systems when launched
> from a USB key. This is very disturbing, as the app
> seems to run fine when launched from VS2005 or when
> installed using vcredist_x86.exe.
Just as an informative note (it doesn't help much, though): as written
in an earlier post of mine our Qt 3 based application seems to run (VS
2005 runtime DLLs installed in the application directory, no
vcredist_x86 ever run before). BUT: on certain platforms that FAILS also
when the application is started from some network mapped drive. I don't
know the details, but it seems it depends on HOW the network drive is
mapped. When it is mapped via NFS (from a Unix server) then I also got
"Application initialisation errors". I assume that has to do with the
file permission mappings.
When copying the whole application directory from the network mapped
drive onto a local hard disk then the application runs fine. I don't
know how network mapped drives are related to USB sticks, but maybe
there's a connection.
>
> My summary: Our application and its data commonly
> runs from a USB key (medical workers plug their key
> into any computer, even one where the application is
> not installed). This works with Qt4/VS2003, but we've
Yes, because VS2003 didn't know the concept of manifest files.
> recently ported to Qt4/VS2005, and get the "App failed
> to initialize, please re-install".
...that's where the new concept of manifest files comes into play.
>
> For this to work, we can't use "vcredist_x86.exe"
> because there's no install (in fact, users usually
> don't have administrative privileges to install
> anything). (Do you need "admin rights" to run
> "vcredist_x86.exe"?)
Yes, I believe you do need administrative rights, because usually the
runtime DLLs are installed under c:\WINDOWS\WinSxS\... I don't know what
happens if you run vcredist_x86.exe with normal user rights, maybe it
falls back to install the runtime DLLs into some user profile? Or even
into the application directory itself (assumning that the user has write
permissions on the USB stick)? I have never tried it.
> ...
> Unfortunately for us, I don't think vcredist_x86.exe
> will work (we need to run from a USB without an
> install). I'm wondering if we'll simply have to
> statically link everything, or if that's even possible
> anymore...
Again, in theory that SHOULD work! I remember reading in the Microsoft
docs about this manifest concept that an application can indeed install
the runtime DLLs locally (local = somewhere under the application
directory) - but that also depends on the manifest configuration linked
into the *.exe/*.dll itself... or so, I didn't dig too deep, because it
works with our Qt 3 application. Maybe re-compiling Qt 4 would indeed
help? Maybe the binary release of Qt 4(.2.2) does indeed expect the
runtime DLLs to be under c:\WINDOWS\WinSxS? (But to be honest I wouldn't
know how to reconfigure the Qt manifest file ...)
Cheers, Oliver
--
[ signature omitted ]
Message 13 in thread
> Unfortunately for us, I don't think vcredist_x86.exe
> will work (we need to run from a USB without an
> install).
OK, I've spent some more time on this. I believe TrollTech support
is also looking at the issue.
The story so far:
1. Qt4 apps compiled with VS2005 won't load plugins (such
as the standard pre-compiles ones shipped with
Qt Commercial Win32 2005). Most of the problems are
not really Qt, but Windows, specifically the new DLL Manifest
system in VS2005 compiled applications.
2. Symptoms are the application won't load at all, or it
loads but can't find plugins.
3. If a plugin fails, it will continue to fail from then on (even
if you fix the problem) because of Qt plugin load-state caching.
Solution is to delete the Qt cache (no idea how to do this) or
to "touch" each plugin DLL which will cause Qt to re-attempt to
open it.
5. The document http://doc.trolltech.com/4.2/deployment-windows.html
is helpful but does not solve the problem.
6. Different people are seeing different problems, although they
all seem related. Some people have reported being able to load
plugins on a clean install machine with local DLLs for some
plugins - but not tested using the standard Qt plugins structure.
7. You can solve the problem by running the Microsoft-supplied
"vcredist_x84.exe", but this is not possible under some
situations (such as apps running off a USB key), and it also
means the libraries get installed in the system directory, rather
than the app dir. Also, the user must have appropriate admin
privilages. Not a desirable solution.
8. I've done some more testing, with clean Win XP SP2 (running
under vmware, but that should not be a factor).
Test config:
OS: Win XP 32 SP2 clean install
DLLs: No VC80 CRT dlls installed in the system.
Tested by installing them into the app's
local directory. So C:\Program Files\MyApp\ contains:
MyApp.exe
msvcm80.dll
msvcp80.dll
msvcr80.dll
Microsoft.VC80.CRT.manifest
plugins (directory)
plugins/imageformats (directory with plugin DLLs)
App: Qt 4 / VS 2005 (but also compiled with Qt3 compat for
a few Qt3 classes - so it is not a pure "clean" Qt4 app).
Build: Built as a release, from a VS2005 project that was auto-created
from a Qt .pro file.
I think this might be an important issue ^^^^^^^
Plugins:
The *standard* Qt4 pre-compiled plugins. Specifically,
the JPEG plugin (qjpeg1.dll and qjpeg1.dll.manifest),
installed in plugins/imageformats under the application
directory.
Run:
Directly launched the application by clicking on it.
9. This is what I've found, by testing various combinations.
a. No CRT dlls present:
Crash with the following error:
"Windows error:
C:\Program Files\MyApp\MyApp.exe
This application has failed to start because the application
configuration is incorrect. Reinstalling the application
may fix this problem."
Conclusion:
Missing CRT 80 DLLs now reports an obscure error (thanks,
Microsoft), instead of reporting the missing DLL(s).
b. CRT Manifest (Microsoft.VC80.CRT.manifest) present but DLLs missing
Application crashes, with the following error:
"The application failed to initialize properly (0xc00000034).
Click on OK to terminate the application."
Conclusion:
If the manifold is present but not the DLL, you get a straight
crash and not the obscure error message.
c. CRT dlls present but manifest missing:
Same as 9(a)
Conclusion:
Obscure error means the manifest is missing, regardless of
if the DLLs are present or not. Crash with an address
reported (e.g. 0xc0000034) means manifest is present, but
the DLLs are missing.
d. CRT dlls and manifest both present
Application launches and runs fine, but then reports
it can not find the plugins (specifically, the JPEG IO one)
Conclusion:
The plugin is not finding the
e. I then dug into the DLL dependencies for the plugin
(using depends.exe; http://www.dependencywalker.com/)
Depends reports the following error for "qjpeg1.dll":
"Error: The Side-by-Side configuration information for
"c:\program files\photake\myapp\imageformats\QJPEG1.DLL"
contains errors. This application has failed to start
because the application configuration is incorrect.
Reinstalling the application may fix this problem (14001)."
Notice the similarity of this error and the one from 9(a) and 9(c).
In fact, even deleting the qjpeg1.dll.manifest resulted in the same
error.
Clearly, the DLL is looking for CRT80 but can't find it.
Even adding the application's path to the PATH makes no difference.
f. I then tried putting a copy of the DLLs and manifest into the
plugins directory itself (myapp/plugins/imageformats).
This kept depends happy, and (after touching the qjpeg1.dll to
flush Qt cache), the application happily ran.
g. It still works as per (f) even if qjpeg1.dll.manifest is deleted.
So that file is not required?
That is as far as I've got in looking into this problem.
Thoughts:
Clearly, the standard plugins as compiled by TT (and perhaps if recompiled
anyway) are not finding the CRT DLL's and manifest UNLESS THE CRT 80 DLLs
ARE IN THE PLUGIN DIRECTORY OR INSTALLED IN THE SYSTEM PATH. Having CRT DLLs in
the application directory is not good enough for a VS2005 compiled app it seems.
This is not yet a solution (unless you want to copy the DLLs into
each of the plugins sub-directory - and even then I'd be very nervous
about running what would be in effect multiple copies of the CRT DLLs in
the same application [multiple memory allocators perhaps?]), but it
might get us closer to finding a solution.
Also, if you do install the DLLs into the local directory, I'd make
sure you install all 3 DLLs. Otherwise I think the CRT80 manifest will
report an error (perhaps thus the obscure app crash some people people
have been getting even with local CRT80 DLLs).
Over to the next person in the tag-team in tracking this
problem down. I can't spend any more time on this for a while due
to other commitments.
Stuart
--
[ signature omitted ]
Message 14 in thread
Stuart Nixon schrieb:
> [very informative stuff]
>
> e. I then dug into the DLL dependencies for the plugin
> (using depends.exe; http://www.dependencywalker.com/)
>
> Depends reports the following error for "qjpeg1.dll":
>
> "Error: The Side-by-Side configuration information for
> "c:\program files\photake\myapp\imageformats\QJPEG1.DLL"
> contains errors. This application has failed to start
> because the application configuration is incorrect.
> Reinstalling the application may fix this problem (14001)."
>
>
> Notice the similarity of this error and the one from 9(a) and 9(c).
> In fact, even deleting the qjpeg1.dll.manifest resulted in the same
> error.
> ...
> g. It still works as per (f) even if qjpeg1.dll.manifest is deleted.
> So that file is not required?
That just reminds me: in our Qt 3 based application we did NOT ship the
plugin manifest files such as qjpeg100.dll.manifest! Only the DLLs
themselves are copied into the [app_dir]\lib\imageformats folder.
This is by pure chance, because I simply found out I don't need them; I
had never tested it on our clean test machine WITH *.manifest though,
that's why I never ran into this one.
(And yes, it's those tiny little details in live which keep us
programmers happy ;)
The plugins are loaded explicitly at runtime anyway with something like
OpenLibrary() (?) (win32 system call), and I don't think the manifest
files are taken into account when loading DLLs this way. The only thing
that matters when explicitly loading plugin DLLs with OpenLibrary() is
that all symbols can be resolved - and this is the case with the CRT,
since those DLLs are already implicitly linked at program startup by the
application.exe.
So my answer to g.) would be you simply don't need those plugin manifest
files.
Conclusion: it seems that the solution is to simply NOT SHIP THE PLUGIN
MANIFEST FILES! (To be verified)
Cheers, Oliver
--
[ signature omitted ]
Message 15 in thread
Till Oliver Knoll schrieb:
> ...
> The plugins are loaded explicitly at runtime anyway with something like
> OpenLibrary() (?) (win32 system call), and I don't think the manifest
I meant LoadLibrary() here.
Cheers, Oliver
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
