> From: owner-openssl-us...@openssl.org On Behalf Of Aswin
Premachandran
> Sent: Thursday, 19 November, 2009 03:12
> I downloaded the openssl tar ball from the site and generated lib
files
> (libeay32.lib and ssleay32.lib) using the command "nmake -f ms\nt.mak".
You're supposed to do the perl Configure and do_{ms,nasm,masm}.bat
(which together do mk1mf into the ms\*.mak files) first*. I don't
know if the release process ensures that these files are valid
(and consistent with opensslconf.h?) in the tarball; it certainly
isn't documented as far as I've seen. It might happen because
whoever does the checkin(s) or packaging happened to have done
a Windows VC build recently enough, but I wouldn't rely on it.
(* But at least through 0.9.8k, do_ms tries to do VC-CE versions
that don't work for a normal=WIN32 env. Unless you're actually
doing WINCE dev just ignore those two errors. The (few?) folks
doing WINCE should be experienced enough to get it to work.)
>The lib files generated has a size of 3839 KB and 667 KB for
> libeay32.lib and ssleay32.lib simultaneously. I am not able to
> generate dll files with the command mentioned.
That's right. nt.mak does a static build, not a DLL build.
> Then I used the command "nmake -f ms\ntdll.mak" (preferred
> as per the install file available in the tar ball), I got both
> the dll and lib files. But the lib files (libeay32.lib and ssleay32.lib)
> size is very less compared to the size of the former lib files.
And that does a DLL build. Hence the name.
The .LIB's are export libraries. This is a standard MS-dev feature
and not specific to OpenSSL. When you build any DLL the actual code
(and data) goes in the .DLL, and a tiny "stub" (basically a pointer)
goes in the explib. When you compile app code to implicitly use the DLL
(as opposed to explicit calls to LoadLibrary etc.) you (must!) link it
against the explib; the stubs are put into the .EXE. At load time
these stubs are patched to point to the bodies in the .DLL, and
at run time the calls in the .EXE go through the stubs to the bodies.
If you're using the IDE (Visual Studio whichever) this is handled
for you automatically, but the same steps actually happen. Step
through a build examining the .plg's and .tmp's and you'll see it.
> So which one should I prefer?
It's up to you, or (as applicable) your users/customers/boss(es).
Advantages of DLL:
- can be shared at runtime = may save some memory. In the days
of 640K this was a big deal; nowadays on most systems not.
- can be replaced (upgraded), with a compatible version,
without rebuilding/releasing/installing the application(s).
Can be more convenient, especially with large user population.
- conversely application can be installed to use already-installed
copy of OpenSSL (if compatible), and replaced/upgraded without
also reinstalling/replacing OpenSSL. In the days of floppy disks
and 300baud modems this was often valuable; today almost never.
Disadvantages of DLL:
- can be replaced without the application(s) knowing. If the
replaced version isn't compatible this causes problems, and
if the replaced version is corrupt it's a security hole.
(Of course there are so many security holes on typical Windows
systems already, what's one more?)
- depending on user's/program's PATH may find the wrong version,
causing problems that may be hard to recreate and investigate
- calls are, and I think some generated code may be, slightly
less efficient. In the days of 4MHz 8086 this might matter;
nowadays on nearly all systems not. (Rule of thumb: if you
can afford ANY modern crypto, you can afford poor code gen.)
> Also I am not able to generate
> openssl.cfg using both the commands. Please let me know whether
> there is any procedure for generating the openssl.cfg.
It's .cnf not .cfg. (Which unfortunately is one of the extensions
that at least some Windows Explorer versions including mine insist
on hiding even when I check every available option 'yes I want
to actually see the files in my file system and I don't need you
to decide which ones somebody in Redmond likes'. But I digress.)
It's a text file. It doesn't need to be generated. Just copy
the one in apps\openssl.cnf as a starting point, and use any
plaintext editor to make any changes you want. If you use
'nmake -f whichever install' it will do this copy for you
along with the other (header, library, commandline) files.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
