Qt-interest Archive, February 2007
Qt 4 DLLs in assemblies?
Message 1 in thread
I have a plugin into another application that uses Qt for its UI. This
means I am linking with the Qt DLLs, and the host application needs to
be able to find them so it can load my DLL.
Supposedly, I can edit a manifest file which is embedded into my DLL,
which can point to the Qt DLLs I use, and allow me to put the Qt DLLs
right along with my DLL.
Unfortunately, I can't find any information on how someone might do this.
Has anyone done this, and if so, can you point me in the right direction?
--
[ signature omitted ]
Message 2 in thread
Windows? Read MSDN about functions LoadLibrary and SearchPath.
In short, application can load any dll by defining full path to this dll. If
dll is defined witout name (usualy it is), application will look for it:
1) The directory from which the application loaded.
2) The current directory.
3) The system directory. Use the GetSystemDirectory function to get the path
of this directory.
4) The 16-bit system directory. There is no function that retrieves the path
of this directory, but it is searched.
5) The Windows directory. Use the GetWindowsDirectory function to get the
path of this directory.
6) The directories that are listed in the PATH environment variable.
Search are not recursive.
"Paul Miller" <paul@xxxxxxxxxx> wrote in message
news:45CB9EE6.30605@xxxxxxxxxxxxx
> I have a plugin into another application that uses Qt for its UI. This
> means I am linking with the Qt DLLs, and the host application needs to
> be able to find them so it can load my DLL.
>
> Supposedly, I can edit a manifest file which is embedded into my DLL,
> which can point to the Qt DLLs I use, and allow me to put the Qt DLLs
> right along with my DLL.
>
> Unfortunately, I can't find any information on how someone might do this.
>
> Has anyone done this, and if so, can you point me in the right direction?
>
> --
> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
>
> --
> 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 3 in thread
George Brink wrote:
> Windows? Read MSDN about functions LoadLibrary and SearchPath.
> In short, application can load any dll by defining full path to this dll. If
> dll is defined witout name (usualy it is), application will look for it:
Yes, this works fine if I was loading and binding to each Qt function
directly, but this isn't really workable is it?
And, I can't control the DLL search path of the host application, so
that's out.
For some reason, I thought it was possible to have a DLL and its
dependent DLLs treated as an "assembly", and the loader would find the
dependent DLLs in this case, but I guess this really isn't possible.
I just hate to have to stuff my Qt DLLs into the host application's
directory (or worse, the system32 directory) to make my plugin work.
> 1) The directory from which the application loaded.
> 2) The current directory.
> 3) The system directory. Use the GetSystemDirectory function to get the path
> of this directory.
> 4) The 16-bit system directory. There is no function that retrieves the path
> of this directory, but it is searched.
> 5) The Windows directory. Use the GetWindowsDirectory function to get the
> path of this directory.
> 6) The directories that are listed in the PATH environment variable.
> Search are not recursive.
>
>
> "Paul Miller" <paul@xxxxxxxxxx> wrote in message
> news:45CB9EE6.30605@xxxxxxxxxxxxx
>> I have a plugin into another application that uses Qt for its UI. This
>> means I am linking with the Qt DLLs, and the host application needs to
>> be able to find them so it can load my DLL.
>>
>> Supposedly, I can edit a manifest file which is embedded into my DLL,
>> which can point to the Qt DLLs I use, and allow me to put the Qt DLLs
>> right along with my DLL.
>>
>> Unfortunately, I can't find any information on how someone might do this.
>>
>> Has anyone done this, and if so, can you point me in the right direction?
>>
>> --
>> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
>>
>> --
>> 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/
>
>
> --
> 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 4 in thread
"Paul Miller" <paul@xxxxxxxxxx> wrote in message
news:45D1CDA6.5040302@xxxxxxxxxxxxx
> George Brink wrote:
> > Windows? Read MSDN about functions LoadLibrary and SearchPath.
> > In short, application can load any dll by defining full path to this
dll. If
> > dll is defined witout name (usualy it is), application will look for it:
> Yes, this works fine if I was loading and binding to each Qt function
> directly, but this isn't really workable is it?
Incorrect. All I said about how DLL is searched is applicable to both -
static and dynamic linking of DLL. There is no differences.
> And, I can't control the DLL search path of the host application, so
> that's out.
I repeat: first two directories to search for DLL is the directory from
which the application loaded and current application directory.
So drop all your DLLs, right next to your EXE and problem solved.
Or, you can make a special "common/bin" directory, put all dlls there and
add this directory into PATH environment variable from installer.
>
> For some reason, I thought it was possible to have a DLL and its
> dependent DLLs treated as an "assembly", and the loader would find the
> dependent DLLs in this case, but I guess this really isn't possible.
>
> I just hate to have to stuff my Qt DLLs into the host application's
> directory (or worse, the system32 directory) to make my plugin work.
>
> > 1) The directory from which the application loaded.
> > 2) The current directory.
> > 3) The system directory. Use the GetSystemDirectory function to get the
path
> > of this directory.
> > 4) The 16-bit system directory. There is no function that retrieves the
path
> > of this directory, but it is searched.
> > 5) The Windows directory. Use the GetWindowsDirectory function to get
the
> > path of this directory.
> > 6) The directories that are listed in the PATH environment variable.
> > Search are not recursive.
> >
> >
> > "Paul Miller" <paul@xxxxxxxxxx> wrote in message
> > news:45CB9EE6.30605@xxxxxxxxxxxxx
> >> I have a plugin into another application that uses Qt for its UI. This
> >> means I am linking with the Qt DLLs, and the host application needs to
> >> be able to find them so it can load my DLL.
> >>
> >> Supposedly, I can edit a manifest file which is embedded into my DLL,
> >> which can point to the Qt DLLs I use, and allow me to put the Qt DLLs
> >> right along with my DLL.
> >>
> >> Unfortunately, I can't find any information on how someone might do
this.
> >>
> >> Has anyone done this, and if so, can you point me in the right
direction?
> >>
> >> --
> >> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
> >>
> >> --
> >> 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/
> >
> >
> > --
> > 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/
> >
> >
>
>
> --
> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
>
> --
> 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 5 in thread
George Brink wrote:
> "Paul Miller" <paul@xxxxxxxxxx> wrote in message
> news:45D1CDA6.5040302@xxxxxxxxxxxxx
>> George Brink wrote:
>>> Windows? Read MSDN about functions LoadLibrary and SearchPath.
>>> In short, application can load any dll by defining full path to this
> dll. If
>>> dll is defined witout name (usualy it is), application will look for it:
>> Yes, this works fine if I was loading and binding to each Qt function
>> directly, but this isn't really workable is it?
> Incorrect. All I said about how DLL is searched is applicable to both -
> static and dynamic linking of DLL. There is no differences.
Sorry - when you said "In short, application can load any dll by
defining full path to this dll", I took that as a suggestion to use
LoadLibrary to read the Qt DLLs. Which as you know is not workable.
>> And, I can't control the DLL search path of the host application, so
>> that's out.
> I repeat: first two directories to search for DLL is the directory from
> which the application loaded and current application directory.
> So drop all your DLLs, right next to your EXE and problem solved.
> Or, you can make a special "common/bin" directory, put all dlls there and
> add this directory into PATH environment variable from installer.
You seem to be missing my point - I'm not writing an application. I'm
writing a PLUGIN into an application that I have no control over. I was
looking for a method OTHER than dumping my Qt DLLs into the
application's directory, and, messing with the PATH isn't really a good
idea - what if some other application uses Qt and is using a different
version than I am?
So, it still doesn't seem possible to write a PLUGIN that links with Qt
and have the Qt libs sit alongside the plugin DLL - unless I modify the
PATH.
On the Mac, I can bundle my dependent frameworks right inside my plugin
bundle. There doesn't seem to be a Windows equivalent to this, except
for "assemblies", which nobody can explain to how make work with Qt DLLs.
>
>> For some reason, I thought it was possible to have a DLL and its
>> dependent DLLs treated as an "assembly", and the loader would find the
>> dependent DLLs in this case, but I guess this really isn't possible.
>>
>> I just hate to have to stuff my Qt DLLs into the host application's
>> directory (or worse, the system32 directory) to make my plugin work.
>>
>>> 1) The directory from which the application loaded.
>>> 2) The current directory.
>>> 3) The system directory. Use the GetSystemDirectory function to get the
> path
>>> of this directory.
>>> 4) The 16-bit system directory. There is no function that retrieves the
> path
>>> of this directory, but it is searched.
>>> 5) The Windows directory. Use the GetWindowsDirectory function to get
> the
>>> path of this directory.
>>> 6) The directories that are listed in the PATH environment variable.
>>> Search are not recursive.
>>>
>>>
>>> "Paul Miller" <paul@xxxxxxxxxx> wrote in message
>>> news:45CB9EE6.30605@xxxxxxxxxxxxx
>>>> I have a plugin into another application that uses Qt for its UI. This
>>>> means I am linking with the Qt DLLs, and the host application needs to
>>>> be able to find them so it can load my DLL.
>>>>
>>>> Supposedly, I can edit a manifest file which is embedded into my DLL,
>>>> which can point to the Qt DLLs I use, and allow me to put the Qt DLLs
>>>> right along with my DLL.
>>>>
>>>> Unfortunately, I can't find any information on how someone might do
> this.
>>>> Has anyone done this, and if so, can you point me in the right
> direction?
>>>> --
>>>> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
>>>>
>>>> --
>>>> 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/
>>>
>>> --
>>> 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/
>>>
>>>
>>
>> --
>> Paul Miller | paul@xxxxxxxxxx | www.fxtech.com | Got Tivo?
>>
>> --
>> 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/
>
>
> --
> 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
Paul Miller schrieb:
> George Brink wrote:
>> ..
> So, it still doesn't seem possible to write a PLUGIN that links with Qt
> and have the Qt libs sit alongside the plugin DLL - unless I modify the
> PATH.
Assuming that the application itself does NOT already link with Qt
that's correct.
But maybe you could use the approach which I have previously described
in a previous post for setting the PATH temporarily for an *.exe, using
the registry - maybe this approach also works with *.dll:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
Add the 2 values there:
(Standard) c:\complete\path\to\myapp\plugins\my_Qt_plugin.dll
Path c:\complete\path\to\myapp\plugins\
But then again, the registry key name ("App Paths") already suggests
that this is only doable with *.exe files, but it's worth a try...
> There doesn't seem to be a Windows equivalent to this, except for "assemblies", which nobody can explain to how make work with Qt DLLs.
"Assemblies" is probably the better way than the registry approach
metioned above (that's the "old fashioned way" of telling the
application.exe where its DLLs are), but I'm still struggling myself
with those manifest/assembly stuff. Can't help you there either.
Cheers, Oliver
--
[ signature omitted ]
Message 7 in thread
"Paul Miller" <paul@xxxxxxxxxx> wrote in message
news:45D1E8E3.8090807@xxxxxxxxxxxxx
> You seem to be missing my point - I'm not writing an application. I'm
> writing a PLUGIN into an application that I have no control over. I was
> looking for a method OTHER than dumping my Qt DLLs into the
> application's directory, and, messing with the PATH isn't really a good
> idea - what if some other application uses Qt and is using a different
> version than I am?
Oh! Sorry. Indeed, I missed that "tiny" detail. Well, in that case it would
be difficult to find appropriate path for staticaly linked DLLs... I,
personaly, strongly dislike using in plugin-dll anything other than dlls
used by host. Sure, it set some restrictions on me, but it is so much easier
to live later...
> On the Mac, I can bundle my dependent frameworks right inside my plugin
> bundle. There doesn't seem to be a Windows equivalent to this, except
> for "assemblies", which nobody can explain to how make work with Qt DLLs.
On Windows you can not include existing DLL inside your application or DLL.
And without recompiling QT into static libraries you wont be able to get
read of Qt*.dll...
--
[ signature omitted ]
Message 8 in thread
> You seem to be missing my point - I'm not writing an application. I'm
> writing a PLUGIN into an application that I have no control over. I
was
> looking for a method OTHER than dumping my Qt DLLs into the
> application's directory, and, messing with the PATH isn't really a
good
> idea - what if some other application uses Qt and is using a different
> version than I am?
>
> So, it still doesn't seem possible to write a PLUGIN that links with
Qt
> and have the Qt libs sit alongside the plugin DLL - unless I modify
the
> PATH.
>
> On the Mac, I can bundle my dependent frameworks right inside my
plugin
> bundle. There doesn't seem to be a Windows equivalent to this, except
> for "assemblies", which nobody can explain to how make work with Qt
DLLs.
why not just statically link Qt to your .dll?
thats what we do, and this works fine.
Cheers,
Peter Prade
--
[ signature omitted ]
Message 9 in thread
Sorry, I just jumped right into this thread, because it seems to be
related to the other thread "VS2005/Qt plugins/VC80 DLL installation
problems & solutions (for JPEG plugin and friends)".
So please ignore when what I say does not make any sense ;)
George Brink schrieb:
>> ...
>> And, I can't control the DLL search path of the host application, so
>> that's out.
> I repeat: first two directories to search for DLL is the directory from
> which the application loaded and current application directory.
That's not true anymore when it comes to "manifested DLLs" (that's a
term made up by me). For example you can have the Visual Studio runtime
DLLs (msvcm80.dll, msvcp80.dll, msvcr80.dll) right in your application
directory and your application STILL takes the ones installed under
c:\WINDOWS\WinSxS\... once you have installed them there with the
vcredist_x86.exe installer.
See also other thread going on: "VS2005/Qt plugins/VC80 DLL installation
problems & solutions (for JPEG plugin and friends)"
Bye bye "DLL Hell", welcome "Manifest fiasko"(tm)
> So drop all your DLLs, right next to your EXE and problem solved.
For your own DLLs - unless you mess around with the default manifest
settings in Visual Studio 2005 - I guess this is still valid.
> Or, you can make a special "common/bin" directory, put all dlls there and
> add this directory into PATH environment variable from installer.
Another approach is to insert a registry entry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths
There you create a key with the name of the executable, e.g "myapp.exe".
To this key you add two values:
(Standard) c:\complete\path\to\myapp\myapp.exe
Path c:\complete\path\to\myapp\my_dlls\
Like this the directory c:\complete\path\to\myapp\my_dlls\ automatically
gets into the PATH, once you run c:\complete\path\to\myapp\myapp.exe.
DLLs in this directory will hence be found, as if they were in the PATH
(in fact, they ARE in the PATH, but just as long as the *.exe is running).
But the new and preferred approach (according to the MSDN docs) is to
use "assemblies/manifests" which locate the correct DLLs instead of
messing around with the registry...
Cheers, Oliver
--
[ signature omitted ]
Message 10 in thread
"Till Oliver Knoll" <oliver.knoll@xxxxxxxxxxx> wrote in message
news:45D1E957.3060803@xxxxxxxxxxxxxx
> Sorry, I just jumped right into this thread, because it seems to be
> related to the other thread "VS2005/Qt plugins/VC80 DLL installation
> problems & solutions (for JPEG plugin and friends)".
No problem, I'm reading your thread with curiosity :)
> George Brink schrieb:
> > I repeat: first two directories to search for DLL is the directory from
> > which the application loaded and current application directory.
>
> That's not true anymore when it comes to "manifested DLLs" (that's a
> term made up by me). For example you can have the Visual Studio runtime
> DLLs (msvcm80.dll, msvcp80.dll, msvcr80.dll) right in your application
> directory and your application STILL takes the ones installed under
> c:\WINDOWS\WinSxS\... once you have installed them there with the
> vcredist_x86.exe installer.
But "manifested DLL" is made by .Net compiler for .Net environment, isn't
it?
And we still can use "normal" DLLs even in .Net, so why do you start to play
with manifests anyway? :)
> For your own DLLs - unless you mess around with the default manifest
> settings in Visual Studio 2005 - I guess this is still valid.
Well, that's the problem with Visual Studio. I prefer to use MinGW for
Windows. With it, I do not need to make a dozens of #ifdef when I move
sources from VS C++ on Windows to GNU C++ on Linux and back :)
--
[ signature omitted ]
Message 11 in thread
George Brink schrieb:
> ...
>>> I repeat: first two directories to search for DLL is the directory from
>>> which the application loaded and current application directory.
>> That's not true anymore when it comes to "manifested DLLs" (that's a
>> term made up by me). For example you can have the Visual Studio runtime
>> DLLs (msvcm80.dll, msvcp80.dll, msvcr80.dll) right in your application
>> directory and your application STILL takes the ones installed under
>> c:\WINDOWS\WinSxS\... once you have installed them there with the
>> vcredist_x86.exe installer.
> But "manifested DLL" is made by .Net compiler for .Net environment, isn't
> it?
Yes and no: by default Visual Studio also produces Manifest files for
normal C++ applications. In fact I believe you HAVE to include a
manifest file into your *.exe/*.dll when you want to link with the VS
2005 runtime DLLs (msvcm80.dll, msvcp80.dll and msvcr80.dll). You DO
have the option to turn off manifest file generation for your
application, but when starting your application you will get a nasty
error message, telling that your application "Could not be initialized"
or the like.
Reading the MSDN docs will tell you that the VS 2005 runtime simply
REFUSE to be linked against a "non-manifested" application.
In other words: this whole manifest file concept is NOT connected to the
.Net runtime environment. It is a completely new concept from Microsoft
which also applies to normal C++ (and I'm also talking about
"non-managed C++ code, that is code which is not linked against the .Net
runtime) applications as to avoid the "DLL hell".
In theory you can specify exactly in your manifest file which DLLs are
to be taken by your application (and I'm not only talking about the
runtime DLLs, but also your own DLLs), ignoring any DLLs which are just
lying around in the PATH. This way Microsoft is trying to avoid the "DLL
hell".
So you could install never runtime DLLs which behave differently without
breaking old applications already installed on the box - because they
still link to the old runtime DLL (which off course still lives on under
c:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd,
for example, taking disk space - but we do have enough disk space, now
do we ;).
In practice I have not yet mastered the manifest file theory and leave
the default Visual Studio 2005 settings as they are - don't touch a
running system ;)
> And we still can use "normal" DLLs even in .Net, so why do you start to play
> with manifests anyway? :)
I try not to play around with them ;) - I just leave the default
settings as they are and they keep me happy on their turn. Well, most of
the time anyway, until it comes to releasing the application on a naked
system.
But this issue seems to clarify now, too (see other thread).
>> For your own DLLs - unless you mess around with the default manifest
>> settings in Visual Studio 2005 - I guess this is still valid.
> Well, that's the problem with Visual Studio. I prefer to use MinGW for
> Windows. With it, I do not need to make a dozens of #ifdef when I move
> sources from VS C++ on Windows to GNU C++ on Linux and back :)
Off course when you use MinGW you are entirely not affected by manifest
files since you do not need to link against the VS 2005 runtime DLLs (at
least I assume MinGW brings along its own C/C++ runtime DLLs).
Cheers, Oliver
--
[ signature omitted ]
Message 12 in thread
I'm about the quote a large body of code, and I apologize in advance.
However, given the nature of this (important to many) subject, I wanted
to keep everything in context.
Till Oliver Knoll wrote:
> George Brink schrieb:
>> ...
>>>> I repeat: first two directories to search for DLL is the directory from
>>>> which the application loaded and current application directory.
>>> That's not true anymore when it comes to "manifested DLLs" (that's a
>>> term made up by me). For example you can have the Visual Studio runtime
>>> DLLs (msvcm80.dll, msvcp80.dll, msvcr80.dll) right in your application
>>> directory and your application STILL takes the ones installed under
>>> c:\WINDOWS\WinSxS\... once you have installed them there with the
>>> vcredist_x86.exe installer.
>> But "manifested DLL" is made by .Net compiler for .Net environment, isn't
>> it?
>
> Yes and no: by default Visual Studio also produces Manifest files for
> normal C++ applications. In fact I believe you HAVE to include a
> manifest file into your *.exe/*.dll when you want to link with the VS
> 2005 runtime DLLs (msvcm80.dll, msvcp80.dll and msvcr80.dll). You DO
> have the option to turn off manifest file generation for your
> application, but when starting your application you will get a nasty
> error message, telling that your application "Could not be initialized"
> or the like.
>
> Reading the MSDN docs will tell you that the VS 2005 runtime simply
> REFUSE to be linked against a "non-manifested" application.
>
> In other words: this whole manifest file concept is NOT connected to the
> .Net runtime environment. It is a completely new concept from Microsoft
> which also applies to normal C++ (and I'm also talking about
> "non-managed C++ code, that is code which is not linked against the .Net
> runtime) applications as to avoid the "DLL hell".
>
> In theory you can specify exactly in your manifest file which DLLs are
> to be taken by your application (and I'm not only talking about the
> runtime DLLs, but also your own DLLs), ignoring any DLLs which are just
> lying around in the PATH. This way Microsoft is trying to avoid the "DLL
> hell".
>
> So you could install never runtime DLLs which behave differently without
> breaking old applications already installed on the box - because they
> still link to the old runtime DLL (which off course still lives on under
> c:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd,
> for example, taking disk space - but we do have enough disk space, now
> do we ;).
Till has summarized this nicely, and it seems we're both at about the
same level of understanding on the subject.
The amazing thing is I have spent literally HOURS trying to find more
information on setting up manifests and assemblies for private
applications/DLLs and I have come up empty every time. I was hoping
someone else had dealt with this by now.
It gets even more complicated with plugins - since I don't have any
control over the path the application uses, and I don't want to go
editing the registry.
It sounds like Trolltech should make an "assembly" out of the Qt DLLs,
and allow them to be installed in a standardized system location (SxS?),
then we could use them just like the VC8 runtime assembly.
>
> In practice I have not yet mastered the manifest file theory and leave
> the default Visual Studio 2005 settings as they are - don't touch a
> running system ;)
>
>> And we still can use "normal" DLLs even in .Net, so why do you start to play
>> with manifests anyway? :)
>
> I try not to play around with them ;) - I just leave the default
> settings as they are and they keep me happy on their turn. Well, most of
> the time anyway, until it comes to releasing the application on a naked
> system.
>
> But this issue seems to clarify now, too (see other thread).
>
>>> For your own DLLs - unless you mess around with the default manifest
>>> settings in Visual Studio 2005 - I guess this is still valid.
>> Well, that's the problem with Visual Studio. I prefer to use MinGW for
>> Windows. With it, I do not need to make a dozens of #ifdef when I move
>> sources from VS C++ on Windows to GNU C++ on Linux and back :)
>
> Off course when you use MinGW you are entirely not affected by manifest
> files since you do not need to link against the VS 2005 runtime DLLs (at
> least I assume MinGW brings along its own C/C++ runtime DLLs).
>
> Cheers, Oliver
>
> --
> 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 13 in thread
On Tuesday 13 February 2007 18:58, Paul Miller wrote:
>
> It sounds like Trolltech should make an "assembly" out of the Qt DLLs,
> and allow them to be installed in a standardized system location (SxS?),
> then we could use them just like the VC8 runtime assembly.
>
Don't MS have some utilities that do something like that?
tlbex is the tool I think might have some relevance, but forgive me if I'm WAY
off the mark - not something I've played with yet.
--
[ signature omitted ]
