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

Larry Lindstrom wrote:



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.


Aside from the side-by-side versioning, manifests are a big POS.

On Sat, 05 Apr 2008 14:05:16 -0700, Larry Lindstrom
<nobody@aracnet.com> wrote:

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.

Sebastian G. wrote:
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.


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?

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

In article <Xe6dnVGtsqUCk2TanZ2dnUVZ_g-dnZ2d@comcast.com>,
Larry Lindstrom <nobody@aracnet.com> wrote:
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.


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

Nathan Mates wrote:
Thanks Nathan:

I'm getting the impression from perusing the net that
vcredist_x86.exe connects to Microsoft and downloads the appropriate
CRT.

If this is correct I'll talk to my partner, I'm the technical guy
and he has the user's perspective. I'll see if requiring the user's
PC be connected to the internet for this to load is appropriate.

My application uses static linking. It uses the Firebird database
engine which has DLL's of its own. I'm using Inno to install the
application's .exe and the Firebird installation .exe on a directory
of the user's choice, defaulting to \Program Files\product_name.
When my app is run it checks to see if Firebird has been installed,
by looking for it's entry in the registery, and runs CreateProcess()
to install Firebird if needed. If Firebird is installed, I put it in
\Program Files\Firebird\Firebird_2_0.

Inno is serving me flawlessly, I've taken a bit of time to make a
few simple modifications to its script, and it now do what I want.
I'd rather not abandon that for a setup and deploy project generated
by VS 2008. Would that task even be doable with that tool? I
haven't investigated.

One of the things I tried was to build this into a VS 2008 setup and
deploy project, thinking that this would silently install the CRT and
the executable, and then Inno could manage the installation. But that
didn't work, VS 2008's setup.exe opened dialogs for installation by
the user.

So I've been experimenting by putting different files in the
\Program Files\product_name directory. The idea being that once I
find something that works, I'll modify Inno's script to do the same.

The last thing I attempted was to add the application's
product_name.exe.intermediate.manifest and the CRT's 3 DLLs and
manifest to \Program Files\product_name. This seems to get the
application running, though one of Firebird's executables is
failing to run. I'll investigate more tomorrow.

I'm wondering if the application is running because I have figured
out what I need to do to get this going, or because the CRT got loaded
during my earlier attempt to run the setup and deploy project. If
this is running because of earlier stumblings, then I haven't solved
anything.

By "Just Runs", I mean my applications, when compiled with VC6,
run flawlessly on Win98, Win 2000, Win XP and the low end Vista.

I've given this a lot of though over the last couple of years of
Windows development. When I was exclusively a Unix developer people
would tell me how programmer friendly Unix is, I never understood
what they were talking about.

After developing for Windows I'd describe Windows as "Programmer
Hostile".

Windows' big advantage is the vast number of applications that
have been written for it. The only leverage we have is that we can
port our apps to Apple, Linux and Solaris. I believe Apple's OS is
a Unix variant. Perhaps that will take a dollar away from Microsoft.
I can vouch for Solaris being a very nice development environment.
And the OS is free, as is it's very nice IDE.

People who are Knowledgeable in the subject tell me Windows
continues to be the weakest with regard to security as well.

Nathan, I appreciate your advice.

Thanks
Larry

In article <kqidneiine5fWWTanZ2dnUVZ_vamnZ2d@comcast.com>,
Larry Lindstrom <nobody@aracnet.com> wrote:
Not for 2005 it doesn't. (Haven't gotten around to installing 2008
at home yet). 2005's vcredist_x86.exe is a 2.5MB file that contains
all the DLLs, and is suitable for offline installation. You can *find*
and download that file online, which is why you may be getting
confused. You can find them online here, if you don't have VS
installed on your boxes.

VS2005's vcredist_x86.exe:
http://www.microsoft.com/downloads/d...displaylang=en

VS2005 SP1's vcredist_x86.exe:
http://www.microsoft.com/downloads/d...displaylang=en

2008's vcredist_x86.exe :
http://www.microsoft.com/downloads/d...displaylang=en

See
http://blogs.msdn.com/astebner/archi...-packages.aspx
for how to do a silent install. I tried that in one app I'd done, and
that didn't seem to work on some of my tester's boxes. So, I just do
the noisy install by default.

I have to say that I think it's gotten a fair bit better. I
actually appreciate MS's secure string handling functions, e.g.
strcpy_s vs strcpy. If you're targeting Windows only, or can do some
preprocessor tricks (e.g. #define STRCPY strcpy_s on Windows, #define
STRCPY strcpy on non-Windows), I find it's pretty easy to do a lot of
hardening of your app for just the cost of a search-and-replace.
(Yes, some people will say you should use std::string or such for
everything; I find that to be a lot more work and generally
counterintuitive to me.) There's also a lot more buffer overrun
detection and preemptive app termination if it's detected with Visual
Studio 2005/2008. I think the core OS has gotten a lot more secure,
which is why everyone's starting to switch to exploits to apps
commonly installed (e.g. Safari, Flash, Office, etc).

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

Larry Lindstrom wrote:



Yes.


Yes. Even though it's more preferable to take the vcredist_x86/x64.exe
package to permanently install them on the target PC, since they can then be
shared by all applications (both on disk and in memory) and centrally
managed. Or, if you want to add them to a MSI installer, use the MSM (merge
modules) instead.

Yes, this is a way to make them locally visible to only the application if
you don't prefer a permanent installation.


Dunno about your static library. I was talking about linking the Visual C++
runtime statically, since then it would run without the DLLs and the
manifest - but it would also be bigger and updating them would require
re-linking and redistribution.

Well, these are most likely the link libraries of your application, which
either contain the actual code (static linking) or the references to the
DLLs (dynamic linking). Or maybe the project takes some of the compiled or
even third-party libraries and copies them to the Release directory, though
one would normally simply add them to the dependency list or the library
search path.


Well, static linking - with all the consequences.

I don't know any way how to get it dynamically linked against the VC 7.0 or
VC 7.1 runtime (which don't require manifest) instead, and it would probably
involve all kinds of bugs, including many old bugs in the runtime that have
been fixed in the newer versions. Up from VC 8.0 the dynamic libraries
always require the manifest, both inside the application and for loading the
CRT DLLs.

Larry Lindstrom wrote:



No. It's just that all version (8.0, 8.0 SP1, 9.0) have the same name for
the installer file.


Bonus points for finding the flags that do silent installation. Solution at
the end of this posting (please guess before looking).





























































Solution #1: /q:a /r:n - calling it with /? tells you immediately
Solution #2: unpack the installer to get vscredis.cab and vcredis.msi, and
call "msiexec /qb /l* tmp.log /i vcredis.msi". For the current versions, and
simple ShellExecute("vcredis.msi","open",..) will suffice as well.

Nathan Mates wrote:


The will be included in the next version of the ISO C standard, so it's
pretty safe to start using them now. Even though you example is bogus, since
strncpy() is a already existing portable and secure standard solution.


A much simpler argument that std::string doesn't make any sense for pure C.

Sebastian G. wrote:
Thanks again Sebastian and Nathan and Peter:

It's working now. I threw a bunch of solutions at the issue, so I'm
now not certain which one broke the obstruction, but it's working.
I'm now running vcredist_x86.exe on each installation. I'll know if
this is the fix that worked when I try to install on another PC.

Nathan, I was referring to the reputation all of the Windows,
including Vista, have among people who deal with attacks on
computer systems. Perhaps these secure string operations have a
positive impact on that problem, I've never understood how a stack
overflow can open up access to a computer.

Among this community, no version of Windows is held in much regard.

VS 2008 generated 770 warnings about my insecure strings. I was
converting int, double and int64_t values into text, I believe the
100 char buffer was safe from overflow. But I converted all of them.
The operation would have been easier the _s had the same return value
as the insecure itoa. But the text isn't returned by the function,
so I had to do lots of little surgeries to my application. If this
is, infact, an ISO standard, then Microsoft had to follow the draft
convention, but it could have been easier.

I'm now having trouble with a CreateProcess() call. That's a
topic for a new thread.

As I've said before. I appreciate all the advice you have
given me.

Larry