Linux的（linux的dll）
linux下的.so文件为共享库，相当于windows下的dll文件，使用方法如下：
在你的工程源代码里包含.h头文件，然后可以调用动态库里的函数，在链接的时候加上如下编译器参数：
-l xx.so
如果你的so文件是以lib开头的，还可以直接这样使用：
-lxx
xx是你的.so文件名
其实使用方法和你使用数学库函数是一样的，源代码中添加
#include
如何在Windows和Linux上进行跨平台P/Invoke？NET的程序是和Java一样的托管代码，在底层操作上，具有很大的局限性，像Java的JNI一样，.NET具有Platform Invoke（平台调用，通常叫P/Invoke）。本文中，Linux下的.NET托管代码运行在Mono CLR上。之所以做跨平台的P/Invoke，是因为考虑到有些客户在Win32/WinCE等系统中开发的.NET程序，需要换到Linux平台运行。嵌入式开发中，经常需要操作IO，.NET程序就通过P/Invoke来调用一些用比如c/c++一类语言开发的native代码完成IO操作。这时候针对windows编写的native代码，就不能不加修改的移植到Linux上，要完成这个移植工作就需要编写Linux下的native代码。但如何做到不修改.NET程序呢，下面就让笔者以实例讲述。r 要保证.NET程序不加修改，不许重新编译，需要做到native代码具有一致的接口。比如我们有native.dll何libnative.so两个不同系统下的动态链接库，在.NET程序中，调用动态库中的getSum(int a,int b)函数，则需要在native.dll和libnative.so中都存在getSum(int a, int b)函数，而且导出的名字要一致，都是getSum。编译时要注意编译器对符号名称的修饰，vc编译器中，可以用Module-Defination File(.def)文件来规范到处的函数名称。r 在.NET的代码中，透过DllImport引入外部函数时，指定的链接库模块不要加扩展名。比如native.dll，只要写native就好。windows中，会自动寻找native.dll，Linux下对应的是libnative.so。r 以下是实例代码：r using System;r using System.Runtime.InteropServices;r namespace Managedr {r class Programr {r r public static extern int getSum(int a, intb);r r static void Main(string args)r {r System.Console.WriteLine("Managed code out.");r System.Console.WriteLine("1+2=" + getSum(1, 2));r }r }r }r 上边的代码演示了从外部动态链接库引入函数的方式，注意没有加扩展名。接下来在看看windows下的c代码是如何编写的：r /**r * native.h 头文件，声明函数原型r */r #ifndef NATIVE_Hr #define NATIVE_Hr #ifdef __cplusplusr extern "C" {r #endifr int __stdcall getSum(const int a, const intb); // 原型r #ifdef __cplusplusr }r #endifr #endifr r /*r * native.cppr * 2013-03-05 实现功能的代码r */r #include "native.h"r #include
efe文件是什么意思？efi 文件就是一个小的module ，是一种可执行文件类型。比如Microsoft PE/COFF , Linux EFL 等等。这些可执行文件类型都有相似之处，应为都是同一种文件类型发展演化出来的。
efi 文件里面包的文件类型可能是PE32， TE（精简版PE）， PE32+中的一种。efi 文件作为可以被动态载入然后被执行，那么其中的文件类型可以选择linux 下.so 和 windows .dll。 相比so 文件，dll 文件重定向更简单，效率可能会高点，但是dll 会比.so 文件占用更多的空间。
文件头是什么？首先，解释一下为什么可执行文件需要有文件头。
对于一个可执行文件来说，操作系统在执行它之前需要知道：1、它所依赖的操作系统版本，比如有些只能在DOS下运行，有些可以在Windows里运行；有些必须在64位环境下运行等等。2、它的入口在哪，并不是所有可执行文件的入口都在文件的最前面，还可以在中间，或者最后面，所以需要有东西来描述。3、它的哪部分是代码，哪部分是数据，因为通常对于代码而言，代码部分应该是只读的，数据部分才是可读写的。4、哪些数据需要初始化为0，通常，在可执行文件中，有一个叫BSS段的部分，这部分数据需要操作系统在加载可执行文件时对BSS清零。5、它运行时的虚拟地址是什么，如果无法加载到指定的地址上，操作系统该怎么做（重定向表）。6、初始的寄存器的值是多少。……所以，要描述这些信息，就必须给可执行文件加上一个文件头。否则操作系统就不能正确加载并运行可执行文件。那么有没有不需要文件头的可执行文件呢？是有的。我能记得的有两种：第一种是DOS时代的COM文件，这种文件的入口就是它的第一个字节，寄存器的大部分初始化都由自己完成，尺寸不允许超过一个16位的段大小（64KB），功能非常有限。另一种就是嵌入式开发里用的BIN文件，它的入口就是它的第一个字节，有些BIN文件能自己初始化段寄存器，所以可以基本认为它是一个没有文件头的可执行代码。但是由于BIN没有统一的规范，所以具体到某个BIN文件，就不好说它到底有没有文件头了。然后，再解释一下为什么不同系统的文件头不一样。
一方面由于历史原因，不同的操作系统都是各个玩各自的，所以造成了格式的差异。但更本质的原因是操作系统环境不同。比如，WindowsXP32位系统中，虚拟地址空间里，用户地址占用的是0x00000000-0x7FFFFFFF的地址范围，内核空间地址是0x80000000-0xFFFFFFFF的地址范围，用户空间是2GB，内核空间是2GB，通常默认是这样的。但是在Linux里，用户空间是3GB，内核空间是1GB，这种内存分布的差异就造成了很多东西都是不同的，包括可执行文件的入口地址范围、可用内存等等，因此Linux里的ELF文件和Windows里的PE文件就不可能定义的完全一样。并且PE格式都包含一个DOS文件头，Linux里是没有这个东西的，PE里还要指定使用Windows子系统的类型，Linux肯定不会支持。而且DLL库和SO库也不一样。所以，因为以上的原因，不同操作系统里的可执行文件头格式也不一样。 总结以上是真正的电脑专家为你收集整理的Linux的（linux的dll）的全部内容，希望文章能够帮你解决所遇到的问题。
如果觉得真正的电脑专家网站内容还不错，欢迎将真正的电脑专家推荐给好友。