Re: When were scanf_s functions introduced?
- From: "Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx>
- Date: Sat, 11 Mar 2006 12:03:13 -0500
Thanks for this very detailed answer. Great answers!
Most of the apps I am building are rather small and are designed
to demonstrate some very specific type of functionality.
I need to know this basic information, because I don't have
resources to test on several OSs so need to understand these issues.
Thanks,
- Mitch
"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message news:uTAljoRRGHA.1688@xxxxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- When were scanf_s functions introduced?
- From: Mitch Gallant
- Re: When were scanf_s functions introduced?
- From: Skywing
- Re: When were scanf_s functions introduced?
- From: Mitch Gallant
- Re: When were scanf_s functions introduced?
- From: Skywing
- Re: When were scanf_s functions introduced?
- From: Mitch Gallant
- Re: When were scanf_s functions introduced?
- From: Skywing
- Re: When were scanf_s functions introduced?
- From: Mitch Gallant
- Re: When were scanf_s functions introduced?
- From: Skywing
- Re: When were scanf_s functions introduced?
- From: Mitch Gallant
- Re: When were scanf_s functions introduced?
- From: Skywing
- When were scanf_s functions introduced?
- Prev by Date: Re: Export Public/Private Keys
- Next by Date: Re: When were scanf_s functions introduced?
- Previous by thread: Re: When were scanf_s functions introduced?
- Next by thread: Re: When were scanf_s functions introduced?
- Index(es):
Relevant Pages
|