Re: Windows DLL naming inconsistency

[Jeffrey Altman]

Andy Polyakov wrote:

That would be great, so how does one do that?

Note that I didn't say it would be trivial, nor that I know exactly how
to actually do it:-) I merely said that having observed how system
components [e.g. KERNEL32] are linked there seem to be a way to achieve
this [noble] goal. Step in the direction would be to understand exactly
*why* it's not possible to interchange /MD and /MDd versions. The
conclusion might be hard to accept. As it might turn out that the only
way is to break dependency from MSVCRT, but the catch is that it's
MSVCRT stands for stdio.h, malloc.h and string.h. malloc.h and string.h
are relatively easy to replace (e.g. by linking with the static LIBC),
but probably not stdio.h (linking it statically probably won't work as
it most likely will interfere with another copy of stdio and one most
likely will have to implement some ascetic replacement). A.

What you do is not link to a run-time library and instead use the equivalent
versions provided by the Windows kernel as defined in WinBase.h. For string
functions you use:

 lstrcmp
 lstrcmpi
 lstrcpyn
 lstrcpy
 lstrcat
 lstrlen

For file operations you use:

  _lopen
  _lcreat
  _lread
  _lwrite
  _hread
  _hwrite
  _lclose
  _llseek

For memory allocation you use a combination of:

    GlobalAlloc
    LocalAlloc
    HeapAlloc
    TlsAlloc    (thread local)

depending on what is necessary. Basically, we would approach this by implementing
our own run-time library which is in turn implemented in base OS functions. Then
we would link the DLL without a run time library.

Remember the dependency on the type of run time library is caused by passing of
things like FILE pointers and Memory allocations across the application / library
boundary. If you can ensure that there are no such crossings then you do not have
a dependency. However, with the BIO code I am not sure this is a possibility.

Jeffrey Altman

smime.p7s
Description: S/MIME Cryptographic Signature