dll文件

一、DLL的导出方法 1、使用_declspec(dllexport) 方法 DLL里全是C++的类的话，你无法在DEF里指定导出的函数，只能用__declspec(dllexport)导出类。 extern "C" _declspec(dllexport) int sum(int a,int b);//本文所有的例子只有一个sum即加法函数。 在制作DLL导出函数时由于C++存在函数重载，因此__declspec(dllexport) function(int,int) 在DLL会被decorate，例如被decorate成为 function_int_int，而且不同的编译器decorate的方法不同，造成了在用GetProcAddress取得function地址时的不便，使用extern "C"时，上述的decorate不会发生，因为C没有函数重载，但如此一来被extern"C"修饰的函数，就不具备重载能力，可以说extern 和 extern "C"不是一回事。 在VC++中，如果生成DLL可以不使用.def文件。只需要在VC++的函数定义前要加__declspec(dllexport)修饰就可以了。但是使用__declspec(dllexport)和使用.def文件是有区别的。如果DLL是提供给VC++用户使用的，只需要把编译DLL时产生的.lib提供给用户

之前公司有套C# AES加解密方案，但是方案加密用的是Rijndael类，而非AES的四种模式(ECB、CBC、CFB、OFB，这四种用的是RijndaelManaged类)，Python下Crypto库AES也只有这四种模式，进而Python下无法实现C# AES Rijndael类加密效果了。 类似于这种C# 能实现的功能而在Python下实现不了的，搜集资料有两种解决方案，第一种方式，使用IronPython 直接调用C# dll文件，教程网上很多，不在赘述了，这种方式有个缺点，用的是ironPython而非Python，只是集成了一些.net framework库的Python版本，更新维护少；第二种方式是，C# dll源码编译成Com组件，Python再调用COM组件Dll的方法。 网上有很多Python调用COM dll教程，但大部分是C或C++编写的dll，很少有比较全面的讲解COM组件生成至调用过程，下面结合自己摸索多天的经历，简单介绍下如何生成COM组件，以及用Python如何调用COM dll组件，分享给大家。 我也是小白 ……^ ^，高手请飘过，如有写的不对之处，还请多多包涵以指正... 1. 如何生成 C# COM 组件 我用的是Microsoft visual studio 2010， 首先新建--项目--选择【类库】，名称自定义：ComToPython

关于USB网上有很多现成的资料，我这里对其中一些基本资料进行了下总结。 i.USB的优点 （ 1 ）使用简单。 支持热插拔。 （ 2 ）应用范围广。 USB 系统数据报文附加信息少，带宽利用率高，可同时支持同步传输和异步传输两种方式。 （ 3 ）较强的纠错能力。 USB 系统可实时地管理设备插拔。在 USB 协议中包含了传输错误管理、错误恢复等功能，同时根据不同的传输类型来处理传输错误。 （ 4 ）总线供电。 USB 总线可为连接在其上的设备提供 5V 电压、 100mA 电流的供电，最大可提供 500mA 的电流。 USB 设备也可采用自供电方式。 （ 5 ）低成本。 USB 接口电路简单，易于实现，特别是低速设备。 USB 系统接口 / 电缆也比较简单，成本比串口 / 并口低。 2. USB硬件结构 USB 采用四线电缆，其中两根用来传送数据的串行通道，另两根为下行设备提供电源。 USB 是基于令牌的总线。类似于令牌环网络或 FDDI 基于令牌的总线。 USB 主控制器广播令牌，总线上设备检测令牌中的地址是否与自身相符，通过接收或发送数据给主机来响应。 USB 通过支持悬挂（ suspend ） / 恢复（ resume ）操作来管理 USB 总线电源。 USB 系统采用级联星型拓扑，该拓扑由三个基本部分组成：主机（ Host) ，集线器（ Hub) 和功能设备。 3

EXPORTS EXPORTS 关键字可以在第一个定义所在的同一行或前一行上。.def 文件可以包含一个或多个 EXPORTS 语句。 导出 definitions 的语法为： entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA] entryname是要导出的函数名或变量名。这是必选项。如果导出的名称与 DLL 中的名称不同，则通过 internalname指定 DLL 中导出的名称。例如，如果 DLL 导出函数 func1() ，要将它用作 func2() ，则应指定： 　　EXPORTS 　　func2=func @ordinal 允许指定是序号而不是函数名将进入 DLL 的导出表。这有助于最小化 DLL 的大小。.LIB 文件将包含序号与函数之间的映射，这使您得以像通常在使用 DLL 的项目中那样使用函数名。 可选的 NONAME 关键字允许只按序号导出，并减小结果 DLL 中导出表的大小。但是，如果要在 DLL 上使用 GetProcAddress ，则必须知道序号，因为名称将无效。 可选的 PRIVATE 关键字禁止将 entryname放到由 LINK 生成的导入库中。它对同样是由 LINK 生成的图像中的导出无效。可选的 DATA 关键字指定导出的是数据，而不是代码。例如，可以导出数据变量，如下所示

原文: 使用Advanced Installer制作IIS安装包（二：配置安装包依赖项和自定义dll） 前言：上篇 使用Advanced Installer制作IIS安装包（一：配置IIS和Web.config） 介绍了下使用Advanced Installer配置IIS和Web.config的过程，操作起来是相对比较简单的，只要知道了博主提供的方法，相信都不是问题，其实博主当初寻找相关方法配置IIS和Web.config的时候也是费了九牛二虎之力的，毕竟资料太少，只能各种方式挨个尝试一遍，解决问题之后回过头来看，发现当初也是走了很多的弯路。比如今天要介绍的这个自定义dll的功能。 关于安装包的制作，可能有人觉得没啥叼用，直接将发布的文件拷贝过去，然后再IIS上面新建站点，配置一下相关的选项就行了呗，哪至于像你说的这么复杂！确实，直接配置没有任何问题，但当你的产品做大了之后，总不能每一次部署都远程到客户的服务器上面操作一番吧，并且很多客户是不愿意让你去登陆他的服务器的，这种情况下直接丢一个exe给别人安装是不是更加方便呢？退一步说，哪怕是为了让我们的系统看上去高大上也行嘛~~ 本文原创地址： http://www.cnblogs.com/landeanfen/p/6369192.html 一、配置安装包依赖项 Advanced Installer支持直接在安装包中包含.net

1.编写一个 zdo.bat文件，主要作用是复制dll文件。如： copy Debug\\my.dll ..\\MyText\\ 将Debug文件夹下的my.dll文件复制到上一层文件夹下的MyText文件夹下 2.在自己在编辑的dll工程中，选择Project->settings，进入到设置中，通过左右移动按钮，找到"Post-build step".选择u.bat就可以 3.每次在编译完毕之后，就会自动调用u.bat进行复制操作。 来源： CSDN 作者： Hat_man_ 链接： https://blog.csdn.net/Hat_man_/article/details/104647013

关于 DotNetBar for Windows Forms 11.8.0.8_冰河之刃重打包版 基于 官方原版的安装包 + http://www.cnblogs.com/tracky 提供的补丁DLL制作而成。 安装之后，直接就可以用了。 省心省事。不必再单独的打一次补丁包了。 本安装包和补丁包一样都删除了官方自带的示例程序【我的文档 中 已经编译好的exe文件】。因为示例程序引用的是官方原版的DLL。处理过的DLL和原版DLL的强签名不同，如果再打开示例程序就会报找不到对应强签名的官方原版DLL的错。索性删除，省的大家再手动删除！可用示例代码再次编译生成示例程序。 所以开始菜单中官方的 示例程序查看 链接方式打不开。这是正常的。因为没有示例程序了。【感兴趣的可以分析一下安装目录下面的RunDotNetBarSampleExplorer.exe文件，就会想明白了。】本安装包和补丁包都依然保留了这一个链接。 在此说明和强调这一点！避免某些 小白用户 说处理过的DLL或者是本安装包有问题。 做事要低调！切勿随意传播，导致不必要的麻烦！ 因使用本安装包所导致的一切后果由使用者自身承担，补丁DLL作者和安装包作者皆不承担任何责任!!! 本安装包仅供学习使用，请在下载后24小时之内删除。 安装包里面的补丁DLL版权归tracky所有。 本安装包版权归本人所有。 作者：冰河之刃 博客：

1、如果报错的dll文件位于这个目录 “C:\Windows\System32\DriverStore\FileRepository\igdlh64.inf_amd64_463164d40c3d26ce” ，直接删除就可以 2、如果dll文件位于其他目录， 参考链接 产生原因：我查了很多解决方法，对应我近期的操作，应该是删除了windows.old导致的问题，建议不要删除此文件，过段时间系统会自动清理。 我的问题是第一种情况，为了避免错误删除，可以先行备份，如下： txt备注了具体哪个应用对应哪个dll文件，以便删除错误进行恢复。 不建议随意更改系统文件 。 来源： CSDN 作者： dirkZh 链接： https://blog.csdn.net/qq_40082253/article/details/104616477

今日读了张银奎老师的《软件调试》，前面的CPU和硬件相关的部分离得比較远，所以从第九章操作系统读起，今天的读书笔记： 9.2採集调试消息 调试事件分为8种 typedef enum _DBGKM_APINUMBER { DbgkmExceptionApi = 0, // 异常 DbgkmCreateThreadApi = 1, // 创建线程 DbgkmCreateProcessApi = 2, // 创建进程 DbgkmExitThreadApi = 3, // 退出线程 DbgkmExitProcessApi = 4, // 进程退出 DbgkmLoadDllApi = 5, // 映射DLL DbgkmUnloadDllApi = 6, // 反映射DLL DbgkmErrorReportApi = 7, // 内部错误 DbgkmMaxApiNumber = 8, // 这组常量的最大值 } DBGKM_APINUMBER; 9.2.2 进程和线程创建消息 操作系统就支持向调试系统发送消息，这个我是没有想到的，详细步骤例如以下： 创建用户态windows线程时，首先为线程建立必要的内核对象和数据结构，并分配栈(stack)空间，这些工作完毕后， 该线程处于挂起状态(CREATE_SUSPEND), 而后进程管理器会通知环境子系统，环境子系统会作必要的设置和登记，最后

内核注入 ，技术古老但很实用。现在部分RK趋向无进程,玩的是 SYS+DLL ，有的无文件，全部存在于内存中。可能有部分人会说：“都进内核了.什么不能干？”。是啊，要是内核中可以做包括R3上所有能做的事，软件开发商们也没必要做应用程序了。有时，我们确实需要R3程序去干驱动做起来很困难或者没必要驱动中去做的事，进程 / DLL是不错的选择，但进程目标太大，所以更多的同学趋向于注DLL。 若要开发安全软件、小型工具，可借鉴其思路，Anti Rootkits时，在某些极端情况下，可使用同样的技术发现、清除RK，保证用户电脑的正常使用。在此，我将探讨几种内核注入DLL的思路及实现原理。 (1) APC 技术 给一个Alertbale的用户态线程插APC，让其执行其中的ShellCode,来执行我们的代码。这个方法简单易行，但是不够稳定，兼容性不好。测试中发现经常出现Explorer.exe等插崩溃的情况，而且有杀软在的情况下，插入有时会被拦截，起不到应有的效果。(可参考我以前逆过的一个驱动： 逆向fuck.sys--编译通过--源码 ) (2) 内核Patch [url=file://KnownDLLs/Kernel32.dll]\\KnownDLLs\\Kernel32.dll[/url] CreateThread [url=file://KnownDLLs/]\\KnownDLLs[