Prev: C++ For Dummies.
Next: WIN 2K, VC6 - Where is ULONG_PTR Defined?
From: Larry Lindstrom on 7 Apr 2008 02:52
Nathan Mates wrote:
> 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.

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.

> 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.

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.

>> 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.

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

> 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.

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
From: Nathan Mates on 7 Apr 2008 12:44
In article <kqidneiine5fWWTanZ2dnUVZ_vamnZ2d(a)comcast.com>,
Larry Lindstrom <nobody(a)aracnet.com> wrote:
> I'm getting the impression from perusing the net that
>vcredist_x86.exe connects to Microsoft and downloads the appropriate
>CRT.

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/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en

VS2005 SP1's vcredist_x86.exe:
http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en

2008's vcredist_x86.exe :
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

> 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.

See
http://blogs.msdn.com/astebner/archive/2007/02/07/update-regarding-silent-install-of-the-vc-8-0-runtime-vcredist-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.

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

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
From: Sebastian G. on 7 Apr 2008 12:56
Larry Lindstrom 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?


Yes.

> Are they legally redistributable?


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.

> If these are the files, do I put them in \Program Files\app_name on the
> customer's PC?

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

> What of my static library?


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.

> What are all of those .lib files doing in the app's Release directory?

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.

>> 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?


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.
From: Sebastian G. on 7 Apr 2008 13:13
Larry Lindstrom wrote:


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


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

> 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.


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.
From: Sebastian G. on 7 Apr 2008 13:17
Nathan Mates wrote:

> 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.


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.

> (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.)


A much simpler argument that std::string doesn't make any sense for pure C.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: C++ For Dummies.
Next: WIN 2K, VC6 - Where is ULONG_PTR Defined?