Driver static library

NTDEV
1

Hi,

I need to provide a static library, but I would like to expose only the API, so the user won’t be able to call all functions (similar to DLL and EXPORT).
Is it possible?

Thanks,
Shai

2

I assume you’re talking about a KERNEL-MODE library (otherwise, why post here, right?)

This is a kernel-mode DLL, also called an “EXPORT-DRIVER”

http://www.osronline.com/article.cfm?id=171

and

http://msdn2.microsoft.com/en-us/library/aa489613.aspx

Peter
OSR

3

xxxxx@gmail.com wrote:

I need to provide a static library, but I would like to expose only the API, so the user won’t be able to call all functions (similar to DLL and EXPORT).
Is it possible?

No. A library is just a collection of straight COFF object files, and
the linker treats them as if they were separate object files. If files
outside your library can’t find an entry point, then modules inside your
library won’t be able to, either.

The Unix library tools do have the ability to do some pre-resolving of
internal references within a library for this purpose. Unless I missed
a staff meeting somewhere, the Microsoft library manager does not.

On the other hand, real users typically do not have the smarts to know
how to dump the contents of a lib, so there is little danger.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

You cannot. Any non-“static” function is exported from the .LIB

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi,
>
> I need to provide a static library, but I would like to expose only the API,
so the user won’t be able to call all functions (similar to DLL and EXPORT).
> Is it possible?
>
> Thanks,
> Shai
>
>

5

Maxim S. Shatskih wrote:

You cannot. Any non-“static” function is exported from the .LIB

So one solution for the OP is to refactor the code in a way that the
only non-static functions in the .LIB are the API members.

Other possibilities to prevent external calls to own functions could be:

  • use of very unwieldy names
    (“_private_DoNOTcallThisIsMyInternalFunction1(int x, …”)
  • “lock” the “private” function, e.g. by providing a token (passwort
    value) that is required to run the function successfully
  • manipulate the .LIB export table (discouraged, and it has to be made
    sure the library is internally linked)

Neither alternative is elegant.

6

> So one solution for the OP is to refactor the code in a way that the

only non-static functions in the .LIB are the API members.

Any inter-file calls in a LIB will be non-static too.

  • manipulate the .LIB export table (discouraged, and it has to be made
    sure the library is internally linked)

LIB has none. LIB is a collection of OBJs, and each OBJ has its own export
table.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

7

Maxim S. Shatskih wrote:

> So one solution for the OP is to refactor the code in a way that the
> only non-static functions in the .LIB are the API members.

Any inter-file calls in a LIB will be non-static too.

So there must be no (non-API) inter-file calls. Hence the necessity for
refactoring. :slight_smile: