From: Larry Lindstrom on
Hello Folks:

I replaced Visual C 6.0 with Visual Studio 2008 last week
and I've been busy replacing _itoa with _itoa_s, and other
similar tasks, in order to get my 100k line application to
work with the new development system.

I finally got things working, and ran a few tests of the
applicaiton. It seems to work fine. It was with great
anticipation than I sent my partner a shiny new executable
yesterday.

He called to tell me that nothing ran. When launched
from inno it just blew up with a complaint that CreateProcess()
failed with an error of 14001, and the following text:

This application has failed to start because the application
configuration is incorrect. Reinstalling the application may
fix this problem.

A search of the newsgroups pointed at a manifest problem.

Manifest? I never needed a manifest when developing code
in VC6.

I've found some documentation about manifests, but I'm
having trouble connecting the dots for my situation.

This is the disk layout visual C++ created for the
application's solution:

app_name
Debug
Release
Lots of .lib files
app_name.exe
app_name.pdb
app_name
Debug
Release
app_name.exe.intermediate.manifest

I gather that in addition to the .exe file, a manifest
must also be included with my distribution.

The libraries I've built for my application are static.
Have they been statically linked into app_name.exe? Why are
there copies of all of those .lib files in app_name\Release?

The application also uses the following "additional" DLLs
gdiplus.lib comctl32.lib Version.lib.

The manifest is a little thing. Do I just add that to
the client's \Program Files\app_name?

Do I need to copy each of the .lib files to the client's
\Program Files\app_name?

How about the additional DLL? Do I need to hunt for those
and add them to the distribution?

Does the manifest make programmer's lives easier somehow?
What advantage do they offer?

Thanks
Larry
From: Sebastian G. on
Larry Lindstrom wrote:


> He called to tell me that nothing ran. When launched
> from inno it just blew up with a complaint that CreateProcess()
> failed with an error of 14001, and the following text:
>
> This application has failed to start because the application
> configuration is incorrect. Reinstalling the application may
> fix this problem.


You have been linking the C runtime dynamically, and the client is missing
the Visual C++ 2008 Runtime Libraries. Either let them download via
Microsoft Download Center, or ship them with the installer, or use a merge
module, or (least preferably) include the Microsoft.VC90.CRT.manifest and
the DLLs in the application folder.

> Manifest? I never needed a manifest when developing code
> in VC6.


Aside from the side-by-side versioning, manifests are a big POS.
From: PeterD on
On Sat, 05 Apr 2008 14:05:16 -0700, Larry Lindstrom
<nobody(a)aracnet.com> wrote:

>Hello Folks:
>
> I replaced Visual C 6.0 with Visual Studio 2008 last week
>and I've been busy replacing _itoa with _itoa_s, and other
>similar tasks, in order to get my 100k line application to
>work with the new development system.
>
> I finally got things working, and ran a few tests of the
>applicaiton. It seems to work fine. It was with great
>anticipation than I sent my partner a shiny new executable
>yesterday.
>
> He called to tell me that nothing ran. When launched
>from inno it just blew up with a complaint that CreateProcess()
>failed with an error of 14001, and the following text:
>
> This application has failed to start because the application
> configuration is incorrect. Reinstalling the application may
> fix this problem.
>
> A search of the newsgroups pointed at a manifest problem.
>
> Manifest? I never needed a manifest when developing code
>in VC6.
>
> I've found some documentation about manifests, but I'm
>having trouble connecting the dots for my situation.
>
> This is the disk layout visual C++ created for the
>application's solution:
>
> app_name
> Debug
> Release
> Lots of .lib files
> app_name.exe
> app_name.pdb
> app_name
> Debug
> Release
> app_name.exe.intermediate.manifest
>
> I gather that in addition to the .exe file, a manifest
>must also be included with my distribution.
>
> The libraries I've built for my application are static.
>Have they been statically linked into app_name.exe? Why are
>there copies of all of those .lib files in app_name\Release?
>
> The application also uses the following "additional" DLLs
>gdiplus.lib comctl32.lib Version.lib.
>
> The manifest is a little thing. Do I just add that to
>the client's \Program Files\app_name?
>
> Do I need to copy each of the .lib files to the client's
>\Program Files\app_name?
>
> How about the additional DLL? Do I need to hunt for those
>and add them to the distribution?
>
> Does the manifest make programmer's lives easier somehow?
>What advantage do they offer?
>
> Thanks
> Larry

Have your user check the event log, there will be a logged entry for
this error, post that event log item and possibly someone can answer
the question.

A manifest can either be included as a resource, or as a seperate
file. Using a file allows easier updating, but creates issues with
users who try (or accidently) modify it.
From: Larry Lindstrom on
Sebastian G. wrote:
> Larry Lindstrom wrote:
>
>
>> He called to tell me that nothing ran. When launched
>> from inno it just blew up with a complaint that CreateProcess()
>> failed with an error of 14001, and the following text:
>>
>> This application has failed to start because the application
>> configuration is incorrect. Reinstalling the application may
>> fix this problem.
>
>
> You have been linking the C runtime dynamically, and the client is
> missing the Visual C++ 2008 Runtime Libraries. Either let them download
> via Microsoft Download Center,

Thanks Sebastian:

This will be a product for use by non technical people. Any solution
that beginse with "let them download" is a non-starter. This must be
transparent.


> or ship them with the installer,

This sounds doable. No burden on the customer, right?

I looked through \Program File\Microsoft Visual studio 9.0 and found
a directory called "Microsoft.VC90.CRT". It has a manifest and 3 dlls,
msvcm90.dll, msvcp90.dll and msvcr90.dll. Are these the runtime libs
you are talking about? Are they legally redistributable? If these are
the files, do I put them in \Program Files\app_name on the customer's
PC?

What of my static library? Has it been statically linked into
app_name.exe? What are all of those .lib files doing in the app's
Release directory?

> or use a
> merge module, or (least preferably) include the
> Microsoft.VC90.CRT.manifest and the DLLs in the application folder.
>
>> Manifest? I never needed a manifest when developing code
>> in VC6.
>
>
> Aside from the side-by-side versioning, manifests are a big POS.

Is there some way to tell Visual Studio 2008 to build the same
executable VC6 does? Something that just runs?

Sebastian, I do appreciate your attempts to assist me.

Thanks
Larry
From: Nathan Mates on
In article <Xe6dnVGtsqUCk2TanZ2dnUVZ_g-dnZ2d(a)comcast.com>,
Larry Lindstrom <nobody(a)aracnet.com> wrote:
> I looked through \Program File\Microsoft Visual studio 9.0 and found
>a directory called "Microsoft.VC90.CRT". It has a manifest and 3 dlls,
>msvcm90.dll, msvcp90.dll and msvcr90.dll. Are these the runtime libs
>you are talking about? Are they legally redistributable? If these are
>the files, do I put them in \Program Files\app_name on the customer's
>PC?

Close, but not quite. What you want to do is look for
vcredist_x86.exe, which should be installed in the DevStudio folder
under C:\Program Files\ . (There's also a vcredist_x64.exe, for 64-bit
software and OSs, but that's probably not what you're building
for). What you want to do is include that vcredist exe with your
installer, and run it as part of the install. Then, it'll be present
for your app and every other app that wants to use it on their system.

Alternatively, if your app is a single exe, no DLLs, you can set it
up for static linking, *and* disable manifests for it. Right click on
your project, get properties, and go to C/C++ -> Code Generation. For
Runtime library, pick Multithreaded (for your release builds), and
Multithreaded Debug for your debug builds. Then, go to linker ->
Manifest file, and set 'Generate Manifest' to no. Then go to Manifest
Tool -> Input & Output, and set 'Embed Manifest' to no. This does
bloat up your exe by at least a few hundred KB.


> Is there some way to tell Visual Studio 2008 to build the same
>executable VC6 does? Something that just runs?

No, because "just runs" is apparently a dirty word to some folks at
Microsoft. I've said this before that the deploy instructions for
HelloWorld.exe should be *no* longer than the source code for said
project (5 lines). However, MS has some fantasy that everyone will (1)
memorize their instructions about manifests buried deep in the bowels
of MSDN, and (2) use their obtuse installer technology and manage
every last little bit. Manifests are clearly a technology that slipped
into the world a few years too early -- the error handling for them is
useless at best. An app missing a DLL will clearly state that it's
looking for msfoobar32.dll. An app missing things in the manifest will
die with a "the application parameter is incorrect" in the messagebox,
which tells people nothing useful.

Microsoft has a reputation for getting things right,
eventually. It's been years and two compiler versions (2005, 2008)
using them. It's not gotten a lick easier. Whomever is in charge of
the manifest technology at MS seems to be on a power trip of trying to
make sure people jump thru lots of weird hoops. I don't appreciate it.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein