【请问】静态lib、DLL和驱动区别

【请教】静态lib、DLL和驱动区别
最近在写一些代码，比较庞大，涉及多个模块。
可以把我目前做的东西视作一个协议栈。
这个协议栈是通过uart和外部设备通信的。

现在协议栈内提供n个功能子块。
希望提供给系统内的多个exe使用。
每个exe使用的协议栈内的子块不重复。

好比，子块1给exe1使用，子块2给exe2使用，……
子块1、子块2 ……都会和协议栈串口层上来的分包层打交道。

如果只有1个exe在使用这个协议栈，
协议栈无论是生成静态lib，dll还是流驱动形式通过标准的函数访问，
这个都好理解。

现在需要被多个exe访问，那么这个接口应该如何提供出来？

如果是静态lib，感觉上是不可行的？说不上原因。
如果是dll，那么每个exe不管是静态加载还是动态加载，在内存里都只有一份吗？
           协议栈的串口层和分包层是被共用的吗？
驱动的情形又是怎样的呢？

tcp/ip协议栈可以被多个网络程序共用，说明了肯定有什么形式可以解决这个疑问？
估计这个是计算机方面的知识。

没什么概念，看到帖子的都来发表下看法。

谢谢！



------解决方案--------------------
静态lib可以啊，为什么不行！只是每个 EXE 中有一份 LIB 的代码，EXE 的文件大一些。
------解决方案--------------------
现在需要被多个exe访问，那么这个接口应该如何提供出来？
//本身没有区别，把他放到多个exe里面就可以了，lib是看不到多少人用了它的。

如果是静态lib，感觉上是不可行的？说不上原因。
//也可以。

如果是dll，那么每个exe不管是静态加载还是动态加载，在内存里都只有一份吗？
           协议栈的串口层和分包层是被共用的吗？
驱动的情形又是怎样的呢？
//映射到了进程的虚拟空间里面，dll的内存数据归进程，申请也是从进程的堆栈里面申请的，所以每个进程都有该dll的内存空间。驱动一般只加载一次，在内核态不一样，但是如果在应用态加载，也一样的。

tcp/ip协议栈可以被多个网络程序共用，说明了肯定有什么形式可以解决这个疑问？
估计这个是计算机方面的知识。
//本身就可以被多个使用。

当exe1和exe2同时运行的时候，假设exe1让uart层和分包层跑起来，那么exe2能够得到来至分包层的数据吗？这是我疑惑的地方
//串口是特殊的，因为硬件只支持一次打开，所以如果你是在dll里面打开的UART，那么就有问题了，串口不能够在多个进程里面打开，所以你需要考虑进程间通信。或者内存共享，或者进行封装。

------解决方案--------------------

引用:

当exe1和exe2同时运行的时候，假设exe1让uart层和分包层跑起来，那么exe2能够得到来至分包层的数据吗？这是我疑惑的地方。

就是exe1和exe2会共用一些变量，可是如果是静态lib形式，那么可以达到共用的目标吗？

共用，是要用代码来实现的，而不是用动态或静态LIB就可以的。
------解决方案--------------------
封装成dll，然后必要的变量采用#pragma data_seg方式共享。或者CreateFileMapping也可以。
------解决方案--------------------
PS：静态lib是否可行我不清楚，我基本没用过静态库，不清楚使用的时候他到底存在几份拷贝，方式于dll有何差异。所以并不否决他。

关键是动态库比静态库编译出来的exe比较小。其他的你自己考虑。协议的东西具体你怎么弄只有你清除。
------解决方案--------------------
LZ是打算只使用一个物理串口吗？
封装协议栈为dll，供各个程序调用？dll操作物理串口？

封装成dll或者是静态库都可以解决各个程序调用独享的问题，
但是你要解决多个dll同时操作一个串口的问题。
------解决方案--------------------

引用:

Quote: 引用:

封装成dll，然后必要的变量采用#pragma data_seg方式共享。或者CreateFileMapping也可以。

引用:

LZ是打算只使用一个物理串口吗？
封装协议栈为dll，供各个程序调用？dll操作物理串口？

封装成dll或者是静态库都可以解决各个程序调用独享的问题，
但是你要解决多个dll同时操作一个串口的问题。

所以我的问题不紧紧是共享一段内存的问题，还存在操纵串口的问题。

我目前发现了别人的一个协议栈，是这样做的。
1 把对串口的读写和分包数据层做成一个流驱动，各个子功能都分配一个ioctrl_code_xxx。
2 再做一个dll，这个dll实现了各个子块的功能，
  各个子块通过deviceioctrl和ioctrl_code_xxx和驱动交互数据。
3 这样exe1、exe2、exeN就可以用同一个dll来做了。
这个办法是利用了文件设备的特点来做的。
文件设备驱动允许多个exe来访问，相当于多个exe“同时”操纵了一个串口设备。
这样做的话，发送是相对直接了。但是各个exe接收属于自己的数据，视乎有些不及时？
是不是可以对n个子块定义n个命名事件，然后当驱动接收到串口属于某个子块的数据时，就设置对应子块的事件，子块有个线程，等待事件，等到了也用deviceiocontrl或者readfile去读数据？

其实方法前面有人讲到了，可以用进程间通信，什么共享内存，管道，邮箱……
甚至消息机制，消息也是可以跨进程的。

但是就不知道什么办法是比较直接和延迟最小的，受什么优先级等的影响比较小的。

这样分是正确的，可以解决串口唯一性的问题。
按你说的，可以把串口操作和你多个exe读写串口的操作序列化，然后再收到信息的时候调用注册的callback。这样在你的exe或者dll封包中进行数据操作，就可以尽量减少流驱动那边的等待时间，最大化串口的读写效率
------解决方案--------------------
封装dll，然后在dll中处理好对串口访问的冲突不就好了吗？这样何来要考虑串口多份的问题。
我让你用data_seg也只是让你针对一些数据需要全局保持一致，比如某些状态等。
你确定你弄个流驱动出来真的就能保证访问顺利？如果你几个exe同时读写你怎么办？
我没看出你问题的重点是在这里。