Re: When were scanf_s functions introduced?

My knowledge of doing complicated MSI setup apps is fairly limited, but I'll
try to answer these as best I can.

1- Most of this space overhead with the static CRT is because the .lib is
really a collection of many .obj files, and each of these have their own
headers and debug information included separately. Between redundant
headers and the separately packaged debug information you are looking at
most of the space increase. (If you do a dumpbin on libcmt.lib you will see
that 4.6MB of space is taken up by debug information alone.)

2- This depends on your setup environment, really. Assuming these are
Internet-distributed installs, you could use the route that Microsoft goes
for many of their setups (i.e. service packs, SDK setup, etc): have two
installers, one that is a "full install" (includes everything and will be
usable even on computers without a network connection) and one that is a
"web install" (checks dependencies and only downloads those that are
missing, but obviously requires an active network connection on the machine
you are installing on). If you are doing media-based installs (e.g.
physical CDROM or something similar), then the amount of space for the CRT
installer is probably not going to matter much and it would be worth just
always shipping it.

3- In general, you can't redistribute system dlls as they have their own
dependencies on other system dlls, new features in the kernel or drivers
shipped with that OS version, etc. There are a few exceptions, mostly
listed on this page: <
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
. If you need to figure out what your minimum OS requirements are, yes,
the MSDN documentation will give you that information. Another tool you can
use to check is Dependency Walker - you could install your program on a
fresh install of the OS you want to check and see if Dependency Walker finds
any unresolved imports (note that this is of course not always going to
indicate that your program will run correctly, as there are some differences
between OS versions other than just new functions being added, and some
things are stubbed out on downlevel OS versions (e.g. Win9x stubs out many
"W" (Unicode) versions of APIs that were released with NT4 and many of the
security-related APIs that were released with NT4 with dummy functions that
return an appropriate failure code)).

4- To my knowledge, you don't need to have .NET installed, although you will
probably need to install a more recent version of Windows Installer on
ancient (e.g. Win9x) platforms. As far as I know, if the platform supports
assembly bindings, the installer will install the CRT DLLs into the
appropriate location under %SystemRoot%\WinSxS, otherwise they are just
dropped into the system directory.

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:ePtPoARRGHA.5500@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the useful answer. I read something similar in MS "
Deployment Examples" section in MSDN.

A few more questions:
(1) Why is the CRT static object library libcmt.dll about 10 times larger
than
the CRT dll MSVCR80.dll? Is it because libcmt.dll contains other
functions included
in other dlls already on the client?

(2) The following example shows clearly how to build a proper C++
Setup/Deployment
project:
http://msdn2.microsoft.com/en-us/library/ms235317(VS.80).aspx
so that it will include MSVCR80.dll (and other dependencies in my
application) if I build
my app with /MD. Say I have several different apps to deploy. What is
the best approach
for packaging/information in terms of Setup/Deployment projects. I clearly
don't want
to have the same client have to dnld larger files each time (including
MSVCR80.dll) if
they have already installed another app with the necessary dependency. How
should this
be managed? Two different versions of deployment projects ? Ask the user
before
downloading the installation?

(3) In terms of dependencies, for example if I run :
dumpbin /dependents cathash.exe
...
WINTRUST.dll
CRYPT32.dll
KERNEL32.dll
ADVAPI32.dll
MSVCR80.dll

I know that most of my users won't have MSVCR80.dll .. hence need to
include that
in my Merge Modules project. However, what about other basic dlls like
Crypt32.dll?
I gather that I need to read the MSDN docs on those system dlls and look
at any OS
version dependencies? And if the fn' I wish to deploy is not available in
the version of
the dll on the target system, see if the system dll is redistributable??
aka similar discussion to :
http://msdn2.microsoft.com/en-us/library/8kche8ah(VS.80).aspx

(4) Say the OS (Win98) has the system dll functonality required and so I
only need
to add MSVCR80.dll into my deploy project. Does the target OS (98) need
any other
capability to run the Setup/Deployment exe once I've built it in VS 2005?
I noticed the
use of "assemblies" in the MSDN Setup/Deploy doc above .. this doesn't
mean that
the target OS needs .NET runtime to run Setup project??

Thanks,
- Mitch

"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:u%23b84QLRGHA.336@xxxxxxxxxxxxxxxxxxxxxxx
Yes, that's about how static linking works. There are a few downsides
though:

- Increased memory usage (if you run two apps with the CRT static linked
instead of two apps with the CRT dynamic linked, then you might be
increasing physical commit as the CRT code inside the DLL could be
copy-on-write shared cross process while the static linked CRT code can't
be shared in memory between different .exes (although it could be for
different processes running from the same .exe on disk).
- Requires you to recompile your app if there is a security patch for the
CRT and you static linked to an affected function (instead of just
deploying another CRT DLL).
- When working with multiple binaries that link to the CRT, you may
actually end up saving space by linking to the DLL version if the CRT
code is duplicated enough times.

If you are just making a simple, small standalone app, then static
linking is probably a good idea. For nontrivial apps I would go with the
DLL route though.

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:uMECVNIRGHA.4344@xxxxxxxxxxxxxxxxxxxxxxx
The DLL version required to support security-enhanced fucntions is
MSVCR80.dll which is 612 kb in size.

I relinked statically (/MT) which statically links in libcmt.lib
(about 7.4 Mb).
However the resultant apps (which are not very big) amount to
about 100 kb ; e.g. this file hasher utility
http://www.jensign.com/hash/index.html

I don't have a good understanding of how static linking works with obj
.dll
libraries but I gather it just extracts the code from the static CRT
library that
is referenced in the application (hence my resultant code is still
small ) ?

Thanks,
- Mitch

"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:eVoz2bHRGHA.336@xxxxxxxxxxxxxxxxxxxxxxx
I would just redistribute the DLL version of the CRT. VC2005 comes with
a prepackaged installer and merge modules for it, I believe.

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:OJnLX3GRGHA.196@xxxxxxxxxxxxxxxxxxxxxxx
Thanks. So I guess I need to recompile with /MT to static
link code into my application to ensure backward compatiblity.
- Mitch

"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:eEh$qqGRGHA.4572@xxxxxxxxxxxxxxxxxxxxxxx
Yes unless somebody else has already installed MSVCR80.dll.

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:uS1GA6FRGHA.256@xxxxxxxxxxxxxxxxxxxxxxx
(a bit rusty on VC++ here ..)
I was looking at my compile options in VS 2005 and the /MD switch
is used for release by default. Does this mean that if I compile my
C code in VS 2005 with the default /MD compile switch, and specify
scanf_s() functions, the target platform will need updated dll
(MSVCR80.dll)
with those functions since the CRT is not statically linked into my
application?
http://msdn2.microsoft.com/en-us/library/abx4dbyh.aspx
Thanks,
- Mitch

"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:uVxeG5ERGHA.4344@xxxxxxxxxxxxxxxxxxxxxxx
They ship with the VS2005 CRT (and probably later CRTs). They were
not present in the VS2003 (or earlier) CRTs.

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:uNz0KsERGHA.4960@xxxxxxxxxxxxxxxxxxxxxxx
When were the security-enhanced functions, like scanf_s, sscanf_s
etc. introduced?
I noticed that they are not included in the PSDK April 2005 MSDN
documentation,
but are included in VS 2005 docs.
- Mitch




















.

Relevant Pages

  • Re: When were scanf_s functions introduced?
    ... one that is a "web install" (checks dependencies and only downloads those that are missing, ... then the amount of space for the CRT installer is probably not going to matter much and ... the CRT dll MSVCR80.dll? ... Say I have several different apps to deploy. ...
    (microsoft.public.platformsdk.security)
  • Re: When were scanf_s functions introduced?
    ... Why is the CRT static object library libcmt.dll about 10 times larger than ... the CRT dll MSVCR80.dll? ... Say I have several different apps to deploy. ... I gather that I need to read the MSDN docs on those system dlls and look at any OS ...
    (microsoft.public.platformsdk.security)
  • Re: When were scanf_s functions introduced?
    ... that's about how static linking works. ... Increased memory usage (if you run two apps with the CRT static linked ... another CRT DLL). ...
    (microsoft.public.platformsdk.security)
  • Re: Green Hills CEO: Linux threat to free world!
    ... >required an updated DLL, and when that DLL is installed finding that other ... Then you haven't used Windows. ... That's because Microsoft apps just install the DLL ... I have had apps stop working because someone installed Visual C++. ...
    (comp.arch.embedded)
  • Re: App built by VS2008 causes "side-by-side configuration"-error in Vista
    ... the directories needed whenever I install my application? ... you don't depend on having the redistributables installed. ... If you want to link against DLL version of the CRT, ...
    (microsoft.public.vc.language)