一般来说,从DLL导出函数有两种方法.一种是使用.def文件:另一种是使用__declspec(dllexport). 使用上面两种方法各有优缺点.使用.def文件就是需要额外维护,当导出函数更改名字或者追加导出函数.而使用__declspec(dllexport)则需要注意使用的调用约定,在使用C++编译器时. 调用约定 在使用C++或者在常见的windows API的声明头文件常见的WINAPI,而WINAPA就是__stdcall.在C++还有__cdecl.而__pascal和__thi

前言 最近在编写dll注入程序的时候,因为想注入到系统进程,结果发现总是注入失败.自闭了好长一会发现我忘记了我的系统是64位的,系统进程也是64位的,而我编写的待注入的DLL是32位了,所以才导致失败.在配置编写64位dll环境时碰见一些坑,总结一下希望能帮助到其他人. 环境配置 以vs2010的设置为例,其他版本的vs应该差不多. vs2010默认生成的是32位版本的程序(EXE,DLL),我们需要点击配置管理器自己进行配置 然后我们在活动解决方案平台下拉,新建. 然后设置为x64,其余选项默

发布日期:2009.12.29 作者:Anytao © 2009 Anytao.com ,Anytao原创作品,转贴请注明作者和出处. 问题的提出 晚上翻着群里的聊天,发现一个有趣的问题:如何通过编码方式来判断一个dll或者exe为debug build还是release build?由于没有太多的讨论,所以我只好自己找点儿办法,试图解决这个问题,为夜生活带点刺激.于是,便有了本文的探索和分析. 当然,为了充分的调动起大家的主意,省去不必要的google操作,我觉得有必要对Debug和Relea

1. COFF文件头中偏移0处的Machine指示目标机器类型(IMAGE_FILE_MACHINE_AMD64等),偏移18处的Characteristics位指示文件属性(IMAGE_FILE_32BIT_MACHINE0x0100,IMAGE_FILE_LARGE_ADDRESS_AWARE0x0020). 但我们判断dll或exe支持的目标平台并不使用COFF头,而使用可选文件头(PE32,PE32+即位于此处),因为可选文件头用于为加载器提供信息. 可选文件头分为3个部分:标准域,wi

自从操作系统升级到64位以后,就要不断的需要面对32位.64位的问题.相信有很多人并不是很清楚32位程序与64位程序的区别,以及Program Files (x86),Program Files的区别.同时,对于程序的dll文件应该放到System32文件夹,还是SysWow64,大部分人做的决定是,32位程序放到System32,64位程序放到SysWow64.是不是这样呢,那么今天就由我身边发生的一个案例来详细的说明一下. dll文件不匹配导致数据库无法启动 前段时间,数据库做了一些功能上的

最近使用golang调用c++的dll库文件,简单了解了一下,特作此笔记:一.DLL 的编制与具体的编程语言及编译器无关 dll分com的dll和动态dll,Com组件dll:不管是何种语言写的都可以调用,但com分很多种.比如而php只能调用com的dll的特定的几种.不能直接调用动态dll,要使用第三方的dll文件dynwrap.dll或者编译PHP扩展来迂回调用动态dll:只要遵循约定的 DLL 接口规范和调用方式,用各种语言编写的 DLL 都可以相互调用.譬如 Windows 提供的系统

DLL是Dynamic-Link Libraries(动态链接库)的缩写,库里面是一些可执行的模块以及资源(如位图.图标等).可以认为DLL和EXE基本上是一回事,只是DLL不能直接执行,而必须由应用程序或者其他DLL调用.DLL为应用程序间的资源共享提供了方便,同时也是多语言混合编程的重要手段.由此可见学习使用DLL是Windows程序员必须掌握的一项重要技术.   注:该内容是整理自以下链接 http://www.cnblogs.com/IceKernel/articles/2848848.

阅读目录 dll文件不匹配导致数据库无法启动 究竟是System32还是SysWow64 区分dll文件32位64位的程序让我倍感迷惑 再次判断究竟是System32还是SysWow64——意想不到的坑 Program Files (x86)与Program Files 32位程序真的需要访问System32吗 32位程序与64位程序的区别总结 参考资料 自从操作系统升级到64位以后,就要不断的需要面对32位.64位的问题.相信有很多人并不是很清楚32位程序与64位程序的区别,以及Program

原文地址:http://www.cnblogs.com/hbccdf/archive/2014/03/09/3590916.html 自从操作系统升级到64位以后,就要不断的需要面对32位.64位的问题.相信有很多人并不是很清楚32位程序与64位程序的区别,以及Program Files (x86),Program Files的区别.同时,对于程序的dll文件应该放到System32文件夹,还是SysWow64,大部分人做的决定是,32位程序放到System32,64位程序放到SysWow64.

DLL一定是要C语言导出的符号,也就是extern “C”. 当然,我们都知道DLL调用分为动态调用和静态调用. 动态调用的一般思想为,先LoadLibrary那个你想加载的DLL,然后通过GetProcAddress这个API获取导出函数的地址,赋值给函数指针就可以调用了,这种方式灵活性更高.所有语言都适用. 静态调用就是一般生成DLL会有个导入库(import library).这个编译器要调用该DLL,用链接静态库的方式链接这个导入库就可以了. 其实Delphi也是用了动态调用的方式,那种

动态链接库 / Dynamic Link Library 目录 动态链接库简介 函数封装DLL 组件对象模型COM 如何判断.dll文件是COM还是DLL 辅助工具 1 动态链接库简介 / DLL Introduction 动态链接库(Dynamic Link Library, DLL),是微软在Windows操作系统中,实现共享函数库概念的一种方式,在Windows下,这些库函数的扩展名可以是.dll/.ocx(ActiveX)/.drv(旧式系统驱动程序),在Linux系统中常常是.so文件

因为机子上没有安装Visual Studio,所以找到了一种通过code::blocks编译dll的方式,踩到的坑是code::blocks默认的compiler是32位的,这样编译出的dll也是32位的,编译64位的需要借助MinGW-w64的toolchain. 为code::blocks配置外部MinGW-w64编译器可以参考Compile 64-bit under windows with MinGW-w64. 使用code::blocks创建一个dll的工程,如下图: go和next到

  最近手头有个需求:dll需要注入到某个进程常驻,该dll具备自我升级能力,当发现新的可用版本时,立即Free自己,加载新的.下面是一个实现方案: 开启一个监听线程,从网络上拉新的可用版本,下载放到一个临时目录,如果发现需要升级,则立即FreeLibrary自身,然后执行更新过程.    由于FreeLibrary之后当前模块的内存区域已经无效,所以更新的过程使用一个单独的线程,并将要更新过程的代码通过shellcode的形式写到分配的内存中执行.更新过程中将会使用一些系统API函数,这里不能

原文:http://blog.csdn.net/fengrx/article/details/4171629 这些问题是以前在csdn当版主是一些朋友整理的,今天找到了,贴到这里来! #1 如何使用控件不能改变大小? 答:有时我们需要创建不可改变大小的控件,像那种在运行时没有界面的控件(例:时间控件,SysInfo 等),想做到这种功能的话,请把以下代码加入到控件类的构造函数: m_bAutoSize = TRUE; SIZEL size = {24, 24}; AtlPixelToHiMetr

Visual Studio 项目对程序的发布和调试版本分别有单独的配置.顾名思义,生成调试版本的目的是用于调试,而生成发布版本的目的是用于版本的最终分发. 如果在 Visual Studio 中创建程序,Visual Studio 将自动创建这些配置并设置适当的默认选项和其他设置.在默认设置下: 程序的“调试”配置用全部符号调试信息编译,不进行优化.(优化会使调试复杂化,因为源代码和生成的指令间的关系更加复杂.) 程序的“发布”配置被完全优化,不包含任何符号调试信息.调试信息可在单独的 PDB

EasyHook远程代码注入 最近一段时间由于使用MinHook的API挂钩不稳定,经常因为挂钩地址错误而导致宿主进程崩溃.听同事介绍了一款智能强大的挂钩引擎EasyHook.它比微软的detours好的一点是它的x64注入支持是免费开源的.不想微软的detours,想搞x64还得购买. 好了,闲话不多说,先下载EasyHook的开发库,当然有兴趣的同学可以下载源码进行学习.下载地址:http://easyhook.codeplex.com/releases/view/24401.我给的这个是2

脱壳ASProtect 2.1x SKE -> Alexey Solodovnikov 用脚本.截图 1:查壳 2:od载入 3:用脚本然后打开脚本文件Aspr2.XX_unpacker_v1.osc,运行,很快的,不管. http://download.csdn.net/detail/kfyzk/1461400 4:提示点确定 5:打开运行记录 6:找到最下面 7:修复刚脱壳的文件 8:对脱壳后的文件查壳运行无异常 09:脱壳完成. ==============================

好书推荐:Effective Java中文版(第2版) JVM JIT编译器优化技术有近100中,其中最最重要的方式就是内联(inlining).方法内联可以省掉方法栈帧的创建,方法内联还使让JIT编译器更多更深入的优化变成可能.本人在fastxml(速度比XPP3(基于xmlpull)还快的xml解析器)开源项目中针对方法内联进行了很多学习和实践,这里总结一下,介绍一下怎么让你的代码更好的被JVM JIT Inlining. Inlining相关的启动参数 上一篇博客<Java JIT性能调优

插件式的例子 QQ电脑管家,有很多工具列表,点一下工具下载后就可以开始使用了 eclipse ,X Server 等等 插件式的好处 插件降低框架的复杂性,把扩展功能从框架中剥离出来 让第三方有机会来扩展程序的功能 思路       公开一个插件接口,如果.DLL或.EXE的代码中有继承这个接口就将其示为插件,并将这些插件放在同一目录.运行程序的时候扫描目   录并通过反射判断.DLL或.EXE中是否存在该接口,若存在,则当作插件加载进来.如下图示   基于.net 职责链来实现 插件模式   

库用于将相似函数打包在一个单元中.然后这些单元就可为其他开发人员所共享,并因此有了模块化编程这种说法- 即,从模块中构建程序.Linux支持两种类型的库,每一种库都有各自的优缺点.静态库包含在编译时静态绑定到一个程序的函数.动态库则不同,它是在加载应用程序时被加载的,而且它与应用程序是在运行时绑定的. 使用共享库的方法有两种:您既可以在运行时动态链接库,也可以动态加载库并在程序控制之下使用它们.本文对这两种方法都做了探讨. 静态库较适宜于较小的应用程序,因为它们只需要最小限度的函数.而对于需要多