Qt-interest Archive, November 2007
vs2005 manifests
Pages: Prev | 1 | 2 | Next
Message 1 in thread
I am getting towards the end of the herculean task of moving my app from
VC++6/XP/Qt3 to VS2005/Vista/Qt4 and I am struggling to understand
VS2005 manifests. I have read the Trolltech documentation, some posts
here and some MSDN. I just want to check I have got it right.
-I have build Qt 4.3.2 -static -release on Vista
-I have built my app against these static Qt libraries with an embedded
manifest
-I want to deploy my app onto Windows 98/2000/XP/Vista using Innosetup
-I don't want to install anything outside my application directory
(don't want to risk the support issues)
-The MS 'depends' tool shows that my app needs msvcr80.dll
So:
-To make the app work on 98/2000 I have to install msvcr80.dll into the
same directory as my .exe
-To make the app work on XP/Vista I have to install msvcr80.dll into a
Microsoft.VC80.CRT subfolder as specified by the manifest
So I end up having to install msvcr80.dll into 2 separate folders. Is
that correct? How is this better than good old-fashioned 'DLL hell'?
Every time I have to read MSDN I want to cry.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 2 in thread
Andy Brice wrote:
> I am getting towards the end of the herculean task of moving my app from
> VC++6/XP/Qt3 to VS2005/Vista/Qt4 and I am struggling to understand
> VS2005 manifests. I have read the Trolltech documentation, some posts
> here and some MSDN. I just want to check I have got it right.
>
> -I have build Qt 4.3.2 -static -release on Vista
> -I have built my app against these static Qt libraries with an embedded
> manifest
> -I want to deploy my app onto Windows 98/2000/XP/Vista using Innosetup
> -I don't want to install anything outside my application directory
> (don't want to risk the support issues)
> -The MS 'depends' tool shows that my app needs msvcr80.dll
>
> So:
> -To make the app work on 98/2000 I have to install msvcr80.dll into the
> same directory as my .exe
> -To make the app work on XP/Vista I have to install msvcr80.dll into a
> Microsoft.VC80.CRT subfolder as specified by the manifest
>
> So I end up having to install msvcr80.dll into 2 separate folders. Is
> that correct? How is this better than good old-fashioned 'DLL hell'?
> Every time I have to read MSDN I want to cry.
Yes and no. You can install the local SxS way when windows version is >=
XP and local copy for older versions of windows (conditional install).
Then it will work. This works very well with Windows Installer way (eg.
using WiX toolkit by Microsoft (find it on wix.sf.net)- I'm using that).
I'm not sure how you can do that with Inno. I've used that installer as
well but compared to WiX, it has major disadvantages. Maybe I'm biased,
but I think using MSI is the only Right Way to install stuff on Windows
these days.
Of course, with .msi you can just pull in the merge files from VS2005
for the VC80 runtime and have it deploy the right way into the system
directory. This allows for Microsoft to update the runtime through
Windows Update if there is a security issue. This works everywhere
except if you are installing a service and want to start it in the
installer on Vista :)
I've personally struggled with SxS installs and manifest stuff for over
a week before I understood it. When it works, it is much better solution
than the old way. Kind of like the UNIX versioned libraries. Manifests
are complicated because they are a generalized form of UNIX ABI - UNIX
is by convention and manifests do the same on Windows by configuration.
- Adam
PS. There is still a big problem if you are using plugins and you want
local SxS install. That's because plugins may not find your runtime as
they are installed in a subdirectory. I'm actually having that problem
right now as you can see from another post here.
--
[ signature omitted ]
Message 3 in thread
> Yes and no. You can install the local SxS way when windows version is >=
> XP and local copy for older versions of windows (conditional install).
> Then it will work.
Adam,
Thank you for taking the time to reply. Hadn't thought about using a
conditional install. I will investigate, thanks. But the installing the
DLL in 2 places seems to work (if a little wasteful of 600k of disk).
> This works very well with Windows Installer way (eg.
> using WiX toolkit by Microsoft (find it on wix.sf.net)- I'm using that).
> I'm not sure how you can do that with Inno. I've used that installer as
> well but compared to WiX, it has major disadvantages. Maybe I'm biased,
> but I think using MSI is the only Right Way to install stuff on Windows
> these days.
>
When I swapped from the Wise MSI based installer to Innosetup my
installer related support issues dropped pretty much to 0 overnight. I
am not going back to MSI.
> Of course, with .msi you can just pull in the merge files from VS2005
> for the VC80 runtime and have it deploy the right way into the system
> directory. This allows for Microsoft to update the runtime through
> Windows Update if there is a security issue. This works everywhere
> except if you are installing a service and want to start it in the
> installer on Vista :)
>
>
> I've personally struggled with SxS installs and manifest stuff for over
> a week before I understood it.
I am a one man software product company. I can't afford to spend a week
on something that doesn't add any value to my customers.
> When it works, it is much better solution
> than the old way. Kind of like the UNIX versioned libraries. Manifests
> are complicated because they are a generalized form of UNIX ABI - UNIX
> is by convention and manifests do the same on Windows by configuration.
>
>
>
I am not sure what you mean by SxS installs.
> PS. There is still a big problem if you are using plugins and you want
> local SxS install. That's because plugins may not find your runtime as
> they are installed in a subdirectory. I'm actually having that problem
> right now as you can see from another post here.
>
I am not using plugins at present.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 4 in thread
Andy Brice wrote:
>
>> Yes and no. You can install the local SxS way when windows version is >=
>> XP and local copy for older versions of windows (conditional install).
>> Then it will work.
> Adam,
>
> Thank you for taking the time to reply. Hadn't thought about using a
> conditional install. I will investigate, thanks. But the installing the
Found it on their website,
http://www.jrsoftware.org/isfaq.php#difffiles
> DLL in 2 places seems to work (if a little wasteful of 600k of disk).
It will work. But the only way to install these files centrally is
though MSI,
http://news.jrsoftware.org/news/innosetup/msg44508.html
There is a hack in InnoSetup that I found that allows of execution of
msi to install the runtime. Anyway, to install these files you have to
use at least part msi to install the runtime or install the runtime in
the application directory where,
1. it will not be updated by security updated from windowsupdate
2. it will not work with plugins
> When I swapped from the Wise MSI based installer to Innosetup my
> installer related support issues dropped pretty much to 0 overnight. I
> am not going back to MSI.
Wise sucks, period. It is horrible, horrible. I was also using the
Visual Studio 2005 installer creation tool for a while. Turns out it
doesn't even support Vista - one has to hack the msi output with Orca
(msi database editor that is in the Windows SDK) to get proper support
for Vista + administrative custom actions.
Sometime ago, someone wanted advice whether to select WiX or
InstallShield. Richard didn't have kind words for InstallShield!
http://sourceforge.net/mailarchive/forum.php?thread_name=E1ImWm1-0002q3-00%40xmission.xmission.com&forum_name=wix-users
As you know, InstallShield and Visual Studio both create MSI installs.
From my experience, at least the latter sucks.
Moved to WiX, and I love it. Maybe it is just me and ability to create
an installation as customized as I wish with just a simple XML file and
some command line tools (so I can just use nmake to deploy :)
Now, I'm not telling to use WiX but I selected it because,
1. it is free (as free beer and free software)
2. it is used to create installations for Microsoft Office and Visual
Studio and other Microsoft products. If it seems to work there, it
should work for my relatively small projects too! And it does!
Also, MSI installs have a test suit called ICE. You need to pass the
test suite in order for the software to be "designed for Vista" or
"compatible with Vista" or some other label like that. I wander if the
Wise MSI files would pass the ICE tests!
> I am not sure what you mean by SxS installs.
SxS is shorthand for side-by-side assemblies. They apparently were
available since Windows 2003 server and XP (I think Windows 2000 Server
+ SP? has them too, but the DLL ends up installed in the sxs folder as
well as system folder) but Vista has moved to using them exclusively.
The runtime from VS2003 is a regular versioned DLL - apps will also be
using reflected registry/file access and other mostrosities on Vista
because it does not have a manifest file unless you embedd one and you
still have DLL-Hell. VS2005 has a broken manifest generation utility.
With VS2005 SP1, manifest creation and embedding is finally fixed. The
runtime is also a SxS assembly hence the manifest file and nasty errors
if you do not install it right.
Installs of placing the runtime in the application directory are meant
for "copy style installs" (read that in their MSDN file somewhere). The
encouraged way is to use the merge modules.
> I am not using plugins at present.
Then copy style installs will work.
- Adam
--
[ signature omitted ]
Message 5 in thread
Adam M wrote:
>
> It will work. But the only way to install these files centrally is
> though MSI,
>
> http://news.jrsoftware.org/news/innosetup/msg44508.html
>
> There is a hack in InnoSetup that I found that allows of execution of
> msi to install the runtime. Anyway, to install these files you have to
> use at least part msi to install the runtime or install the runtime in
> the application directory where,
>
> 1. it will not be updated by security updated from windowsupdate
>
Thats fine by me. I don't want to be the one to blame if it suddenly
stops working!
> 2. it will not work with plugins
>
I don't use any at present.
>
>
> Wise sucks, period. It is horrible, horrible. I was also using the
> Visual Studio 2005 installer creation tool for a while. Turns out it
> doesn't even support Vista - one has to hack the msi output with Orca
> (msi database editor that is in the Windows SDK) to get proper support
> for Vista + administrative custom actions.
>
Even Microsoft weren't ready for Vista. No wonder it was such a flop. :0(
> ...
>
> Also, MSI installs have a test suit called ICE. You need to pass the
> test suite in order for the software to be "designed for Vista" or
> "compatible with Vista" or some other label like that. I wander if the
> Wise MSI files would pass the ICE tests!
>
I went through the "works with Vista" certification. Complete mess and a
total waste of time and money IMHO. I don't even show the ugly logo now,
because I think some people might think it only works on Vista.
>
>
> SxS is shorthand for side-by-side assemblies.
Ok, thanks.
I think I am go for installing msvcr80.dll for 98/2000 and
Microsoft.VC80.CRT/msvcr80.dll + manifest for XP/2000 using Innosetup. I
think it is the best compromise between easy for me to do and least
likely to cause support issues. I sell low cost, high volume software. I
can't afford to risk DLL related support issues.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 6 in thread
Adam M schrub:
> Andy Brice wrote:
> ...
> use at least part msi to install the runtime or install the runtime in
> the application directory where,
> ...
> 2. it will not work with plugins
On this I can happily disagree! Plugins (both Qt image plugins for
examples and my own plugins) work when the VS2005 C++ runtime is
installed in the application directory (1)!
I have the following setup, for example
[AppDir]
+- TheApp.exe // with embedded manifest
+- Microsoft.VC80.CRT.manifest
+- msvcp80.dll
+- msvcr80.dll
+- msvcm80.dll
+- QtCore4.dll
+- QtGui4.dll
+- imageformats // the Qt plugins
+- qgif4.dll
+- qjpeg4.dll
+- qtiff4.dll
If you copy this application tree layout to a naked target Windows XP
the application works; also the Qt plugins (and my own, not shown above)
work.
ATTENTION: With Qt 3 I ran into the following pitfall (which you might
be in yourself): The Qt 3 plugins come with an external manifest file
(for example qjpeg100.dll.manifest), and I don't know when that has
changed, but my current Qt 4.3.2 plugins don't have this external
manifest anymore.
In any case: DO NOT PUT THIS MANIFEST INTO THE PLUGIN FOLDER!
Else loading the plugin indeed FAILS. This is because manifest files
(qjpeg100.dll.manifest) are obviously also evaluated (on Windows XP and
Vista) when DLLs are dynamically loaded with LoadLibrary (?). So when
the dynamic loader find this qjpeg100.dll.manifest it tries to detect
the C++ runtime somewhere under
c:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_... where (on a naked system)
it cannot be found. Hence the dynamic loader looks in the same (plugin!)
directory where the DLL is located and cannot find the C++ runtime DLLs
either. So the plugin simply won't load!
But without the manifest file the linker simply checks whether the
unresolved (C++ runtime) symbols can be resolved and since the runtime
DLLs are already pulled in by the *.exe the symbols can be resolved and
it works.
(1) You can verify this yourself by checking out my "Application build
framework" on
http://www.till-art.net/software/
The ZIP is a few KBytes, provides a test image viewer application with
the required Qt imageformat plugins, a "GNUmakefile/*.pro" based build
system for Unix (in theory also for Windows), a VS2005 solution and also
provides an MSI installer VS2005 project.
Try building this sample application and put the resulting
'bin/win32-msvc2005_Release/' folder on a naked (no C++ runtime
pre-installed) XP/Vista and run the *.exe. According to my plans it
should start and you should be able to view JPEG, TIFF and GIF images
(the Qt plugins should also load).
Note that in theory (according to the MSDN, or what I got out of it)
copying the C++ runtime DLLs into the application directory - I do not
put them into a separate subfolder! Seems like I have missed this piece
of information in the MSDN, but it seems to work, also on XP and Vista!
- should work. In practice I have succesfully tested in on several naked
XP machines, but one native japanese Windows XP indeed refuses to start
the application!
Also here we have machines where our application also refuses to start
when launched from a /network/ mapped drive (with the message "The
application failed to initialise. Please contact your administrator or
try re-installing it" or the like)! Copying the application onto the
corresponding local harddrive - and what magic - and the application
works on that very same machine!
People on this list have reported that this whole Manifest Fiasko(tm) is
buggy. In any case (also on that Japanese Windows XP) the application
works if you install the runtime using the MSI installer (which puts it
into said folder c:\WINDOWS\WinSxS\...).
--
[ signature omitted ]
Message 7 in thread
Andy Brice schrub:
> Till Oliver Knoll wrote:
>>
>> I have the following setup, for example
>>
>> [AppDir]
>> +- TheApp.exe // with embedded manifest
>> +- Microsoft.VC80.CRT.manifest
>> +- msvcp80.dll
>> +- msvcr80.dll
>> +- msvcm80.dll
>> +- QtCore4.dll
>> +- QtGui4.dll
>> +- imageformats // the Qt plugins
>> +- qgif4.dll
>> +- qjpeg4.dll
>> +- qtiff4.dll
>>
>> If you copy this application tree layout to a naked target Windows XP
>> the application works; also the Qt plugins (and my own, not shown
>> above) work.
> How did you get the embedded manifest to say that msvcr80.dll was in the
> same folder, rather than a Microsoft.VC80.CRT subfolder?
Huh, I don't know really! I created a "Qt 4" project (1) with the "Qt
Addon for Visual Studio" and left all the manifest settings ("Manifest
tool") untouched - so the manifest is embedded into the *.exe (and each
*.dll) with the settings as set in my "Application build framework" on
www.till-art.net/software/. By the way, did you try this example
application, did it work for you when copying the resulting "bin"-folder
on the target machine?
I don't know where in the MSDN I got that information that you can place
the VC++ runtime into the application directory, but I just found this
page about "private assemblies":
ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WIN32COM.v10.en/sbscs/setup/private_assemblies.htm
Quote: "Private assemblies are installed in a folder of the
application's directory structure. Typically, this is the folder
containing the application's executable file. Private assemblies may be
deployed in the same folder as the application, in a folder with the
same name as the assembly, or in a language specific subfolder with the
same name as the assembly."
From this I understand that you can place the "private assemblies" -
and I assume for now that the VC++ runtime is a private assembly when
put into/under the application folder - into either the application
folder (where the *.exe) is located or into a specially named subfolder
("with the same name as the assembly").
To be honest, I don't understand much of this, but putting the VC++
runtime DLLs together with their Microsoft.VC80.CRT.manifest directly
into the application directory seems to work - with the caveats
mentioned in one of my previous posts (see "Japanese Windows XP" - too
bad I could not understand the error message, but I believe it said "The
application failed to initialise. Try re-installing it or contact your
system administrator." ;) )
(1) I think the project manifest properties are the same here as when
creating an empty Win32 *.exe project.
--
[ signature omitted ]
Message 8 in thread
Hello,
> I am not using plugins at present.
What about compiling your app as a monolithic exe, with a statically
linked CRT? You need to recompile Qt with the /MT switch:
http://msdn2.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
This can be done by editing the correct mkspec file:
QMAKE_CFLAGS_RELEASE = -O2 -MT -GL
I also added the /GL arg to get the benefits of WPO:
http://msdn2.microsoft.com/en-us/library/0zza0de8(VS.80).aspx
If you do so, you should also pass -LTCG to the linker:
QMAKE_LFLAGS_RELEASE += -LTCG
Then recompile your app with the same option(s), and you will no longer
rely on msvcr80.dll.
There is also this trick:
http://blog.kalmbachnet.de/?postid=80
Hope it helps.
--
[ signature omitted ]
Message 9 in thread
Aurelien Regat-Barrel wrote:
> Hello,
>
>> I am not using plugins at present.
>
> What about compiling your app as a monolithic exe, with a statically
> linked CRT? You need to recompile Qt with the /MT switch:
> http://msdn2.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
>
> This can be done by editing the correct mkspec file:
> QMAKE_CFLAGS_RELEASE = -O2 -MT -GL
I wish Trolltech would offer this as a standard pre-built binary for
Qt/Windows. Or at least offer it as a configure option.
I will probably leave things now that I have them working, but I might
try this in future. Thanks.
>
> I also added the /GL arg to get the benefits of WPO:
> http://msdn2.microsoft.com/en-us/library/0zza0de8(VS.80).aspx
>
> If you do so, you should also pass -LTCG to the linker:
> QMAKE_LFLAGS_RELEASE += -LTCG
I did some reading on this. It sounds a bit scary!
>
> Then recompile your app with the same option(s), and you will no
> longer rely on msvcr80.dll.
>
> There is also this trick:
> http://blog.kalmbachnet.de/?postid=80
The link appears to be broken.
>
> Hope it helps.
Thanks.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 10 in thread
Andy Brice a écrit :
>> What about compiling your app as a monolithic exe, with a statically
>> linked CRT? You need to recompile Qt with the /MT switch:
>> http://msdn2.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
>>
>> This can be done by editing the correct mkspec file:
>> QMAKE_CFLAGS_RELEASE = -O2 -MT -GL
> I wish Trolltech would offer this as a standard pre-built binary for
> Qt/Windows. Or at least offer it as a configure option.
Yes, I would also appreciate.
> I will probably leave things now that I have them working, but I might
> try this in future. Thanks.
>>
>> I also added the /GL arg to get the benefits of WPO:
>> http://msdn2.microsoft.com/en-us/library/0zza0de8(VS.80).aspx
>>
>> If you do so, you should also pass -LTCG to the linker:
>> QMAKE_LFLAGS_RELEASE += -LTCG
> I did some reading on this. It sounds a bit scary!
It works without -LTCG but you will get a warning that the linker was
restarted and that you should specify -LTCG to improve link time. I
would not say it is scary. It is almost the same in fact, and it works
well. The difference is compile time is reduced because only parsing and
syntax checking is done. On the other hand, link time is much longer,
because code generation + optimization + linking are done during this
stage. The compiler is called back by the linker. It is like all your
source code being compiled in one unique huge file, which make it
possible to better optimize it... If you compile Qt will all the
examples, it can take hours...
>> Then recompile your app with the same option(s), and you will no
>> longer rely on msvcr80.dll.
>>
>> There is also this trick:
>> http://blog.kalmbachnet.de/?postid=80
> The link appears to be broken.
It seems to be ok now. If not, the article is called "How to bypass the
WinSxS for CRT/MFC/ATL DLLs", and Google cached it:
http://72.14.235.104/search?q=cache:mHMoE3v73m4J:blog.kalmbachnet.de/%3Fpostid%3D80+How+to+bypass+the+WinSxS+for+CRT/MFC/ATL+DLLs+-+Jochen+Kalmbach%27s+WebLog&hl=fr&ct=clnk&cd=1
But I realize it is not really what you are looking for :)
Cheers,
--
[ signature omitted ]
Message 11 in thread
Aurelien Regat-Barrel wrote:
>
> It works without -LTCG but you will get a warning that the linker was
> restarted and that you should specify -LTCG to improve link time. I
> would not say it is scary. It is almost the same in fact, and it works
> well.
I just wonder what the optimiser is doing. It might break something that
works at the moment!
>
> It seems to be ok now. If not, the article is called "How to bypass
> the WinSxS for CRT/MFC/ATL DLLs", and Google cached it:
> http://72.14.235.104/search?q=cache:mHMoE3v73m4J:blog.kalmbachnet.de/%3Fpostid%3D80+How+to+bypass+the+WinSxS+for+CRT/MFC/ATL+DLLs+-+Jochen+Kalmbach%27s+WebLog&hl=fr&ct=clnk&cd=1
The link works now thanks.
>
>
> But I realize it is not really what you are looking for :)
The solution I have seems to work fine now. Thanks.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 12 in thread
>> It works without -LTCG but you will get a warning that the linker was
>> restarted and that you should specify -LTCG to improve link time. I
>> would not say it is scary. It is almost the same in fact, and it works
>> well.
> I just wonder what the optimiser is doing. It might break something that
> works at the moment!
It works well:
http://blogs.msdn.com/texblog/archive/2005/10/12/480187.aspx
Before WPO, the optimizer could only optimize in the scope of the
current translation unit, i.e you .cpp file. With WPO, boundary crossed
over to the whole program. Last year at the DevDays one of the trolls
told me he compiled the Qt Mandelbrot example with and without WPO and
could notice a visible improvement.
WPO was introduced with VC++ 2002. I think it is quite mature now. It
has been improved in VC++ 2005, and now includes POGO (Profile Guided
Optimization) : you run your exe, it generates a special file that the
compiler reuse to better optimize. I tried it and was disappointed : my
super optimized exe was... slower! But this just my experience...
Until now I was really successful with WPO. I just once had a crash only
in my release version compiled with WPO. I finally found it was a bug in
my code, or more precisely, a subtle misuse of C++ templates. Each
template must be instantiated exactly the same way in all you app (one
definition rule = ODR). But, with the "security features" of VC++ 2005,
it is easy to break this rule if you define _SECURE_SCL to 0 for
example. This macro affects the generated code of STL templates, so it
is easy to break the ODR if you define it only in some parts of your
project.
That's the kind of things you should pay attention to. In fact, you
should always pay attention to it because you fall in the "undefined
behavior" category. But WPO seems to be more sensitive to this
particular point.
Regards,
--
[ signature omitted ]
Message 13 in thread
Aurelien Regat-Barrel wrote:
>
> It works well:
> http://blogs.msdn.com/texblog/archive/2005/10/12/480187.aspx
>
> Before WPO, the optimizer could only optimize in the scope of the
> current translation unit, i.e you .cpp file. With WPO, boundary
> crossed over to the whole program. Last year at the DevDays one of the
> trolls told me he compiled the Qt Mandelbrot example with and without
> WPO and could notice a visible improvement.
I read up a bit further and global optimisation and it isn't compatible
with debug symbols (/Zi). I create (but don't ship) a .pdb symbol file
for my release. If the software crashes it emails me the address of th
crash and I can use the symbol file to work out which line it crashed
at. This can be very useful for bug fixing.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Message 14 in thread
On November 14, 2007 05:09:04 pm Andy Brice wrote:
> Aurelien Regat-Barrel wrote:
> > It works well:
> > http://blogs.msdn.com/texblog/archive/2005/10/12/480187.aspx
> >
> > Before WPO, the optimizer could only optimize in the scope of the
> > current translation unit, i.e you .cpp file. With WPO, boundary
> > crossed over to the whole program. Last year at the DevDays one of the
> > trolls told me he compiled the Qt Mandelbrot example with and without
> > WPO and could notice a visible improvement.
>
> I read up a bit further and global optimisation and it isn't compatible
> with debug symbols (/Zi). I create (but don't ship) a .pdb symbol file
> for my release. If the software crashes it emails me the address of th
> crash and I can use the symbol file to work out which line it crashed
> at. This can be very useful for bug fixing.
Almost off-topic here, it may be worth your while contacting stardock, authors
of Galactic Civilization 2 and a number of other products. They have
a "smartexception" program which is used to capture crash information. It
would surprise me a bit if they shipped unoptimised code so it may possibly
be worth investigating how they do this.
I am pretty sure they don't sell smartexception. I know it is a free tool for
end-users but I don't think they target developers. Still, may be worth your
while taking a look.
--
[ signature omitted ]
Message 15 in thread
Chris Thompson wrote:
>
> Almost off-topic here,
Almost? ;)
> it may be worth your while contacting stardock, authors
> of Galactic Civilization 2 and a number of other products. They have
> a "smartexception" program which is used to capture crash information. It
> would surprise me a bit if they shipped unoptimised code so it may possibly
> be worth investigating how they do this.
>
It will work with -O1/-O2 optimised code, but not -LTCG from what I read
in MSDN.
> I am pretty sure they don't sell smartexception. I know it is a free tool for
> end-users but I don't think they target developers. Still, may be worth your
> while taking a look.
>
I have already rolled my own one which works on Windows and Mac. I still
haven't worked out how to interpret the Mac one though.
Thanks for the thought.
best regards
Andy Brice
http://www.perfecttableplan.com
http://www.successfulsoftware.net
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
