文件句柄

目录 一丶简介 二丶原理与代码. 2.1原理 2.2原理伪代码讲解 3.代码实现 4.用到的结构 5.代码演示截图. 6.附加 一丶简介 在windows系统下.句柄是很常用的. 骚操作的方法可以通过句柄拷贝方式拷贝到另一个进程让其占用句柄.比如独占文件. 但是有时候比如驱动想删除文件.强删文件的时候就会用到句柄类型. 但是此时一般都是写死的.网上也很少相关资料.这里就介绍一下.怎么通过句柄获取指定句柄类型(任何内核对象 句柄都可以使用) 下面以文件举例 二丶原理与代码. 2.1原理 原理还是使用未文档化的API 1.使用 ZwQuerySystemInformation 的16号功能遍历全局句柄表 2.创建文件(什么文件都可以)得出 文件句柄 3.遍历句柄表,判断文件句柄是否和遍历出的句柄表中记录的句柄一样. 4.如果一样.获取句柄表中 objectindex 即可.这个则是记录的文件句柄. 2.2原理伪代码讲解 主要是两个结构体.在使用 ** ZwQuerySystemInformation**的时候遍历的句柄的详细信息的结构 如下: typedef struct _SYSTEM_HANDLE_TABLE_ENTRY_INFO { USHORT UniqueProcessId; USHORT CreatorBackTraceIndex; UCHAR

　　 背景 ：SAP session的左下角消息非常有用，我们在做SAP的自动化脚本时可以设法读到这个消息的内容，作为程序后续动作的判断条件。如下图： 　　比如小爬之前给财务的同事制作了一个批量导出SAP各类报表的脚本工具：基于公司IT团队用ABAP编写的这几张表，SAP每次执行完导表动作，数据传输过程，左下角消息为 “Transferring package1 of 1...” ，当表格数据完整导出后，则显示 “已传输N个字节” 。我们的脚本可以去捕获“已传输...”这个消息，来判断报表内容是否已经完整导出，来决定是否要导出下一张报表。 　　事实上，通过原生的“脚本录制与回放”，我们可以得到这个消息：语法为： sapMessage=session.findById("wnd[0]/sbar").text 。非常简单实用！实际编写脚本过程中遇到的问题是，当我们的脚本动态地顺序往下执行到等待报表出来的过程，控制权交到了导出的excel文件，我们的sapMessage=session.findById("wnd[0]/sbar").text无法获得执行，如果该消息文本恰好作为脚本中循环退出的条件，则脚本程序因为循环无法退出，导致界面卡死。 　　我想到的解决方法是，前期的参数输入等都通过脚本录制功能生成代码，到了点击“执行（F8）”这个动作，改由window api

1. 对象的创建 1. 遇到 new 指令时 ，首先检查这个指令的参数是否能在 常量池中定位到一个类的符号引用 ，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，执行相应的 类加载 。 2. 类加载检查通过之后，为 新对象分配内存 (内存大小在类加载完成后便可确认)。在堆的空闲内存中划分一块区域(‘指针碰撞-内存规整’或‘空闲列表-内存交错’的分配方式)。 A、假设Java堆是规整的，所有用过的内存放在一边，空闲的内存放在另外一边，中间放着一个指针作为分界点的指示器。那分配内存只是把指针向空闲空间那边挪动与对象大小相等的距离，这种分配称为“指针碰撞” B、假设Java堆不是规整的，用过的内存和空闲的内存相互交错，那就没办法进行“指针碰撞”。虚拟机通过维护一个列表，记录哪些内存块是可用的，在分配的时候找出一块足够大的空间分配给对象实例，并更新表上的记录。这种分配方式称为“空闲列表“。 C、使用哪种分配方式由Java堆是否规整决定。Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定。 D、分配对象保证线程安全的做法：虚拟机使用CAS失败重试的方式保证更新操作的原子性。（实际上还有另外一种方案：每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲，TLAB。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时

Delphi创建虚拟桌面实现后台调用外部程序 核心提示：最近在做的一个软件，其中有一部分功能需要调用其它的软件来完成，而那个软件只有可执行文件，根本没有源代码，幸好，我要做的事不难，只需要在我的程序启动后，将那个软件打开，在需要的时候，对其中的一个文本框设置一些文字，再点击一个按钮就可以了。... 最近在做的一个软件，其中有一部分功能需要调用其它的软件来完成，而那个软件只有可执行文件，根本没有源代码，幸好，我要做的事不难，只需要在我的程序启动后，将那个软件打开，在需要的时候，对其中的一个文本框设置一些文字，再点击一个按钮就可以了。 说到这里，相信你也有了对该功能的一些初步设想了，没错，其基本思路就是： 1）调用CreateProcess（）打开目标程序。 2）用FindWindow（）找到目标程序的窗口Handle。 3）找到文本框的Handle，以及按钮的MessageID，用SendMessage（）方法设置文字，并触发事件。 好了，这样确实很简单吧，但是当我实现它后，却发现这样做的结果则是：当我的程序启动并打开目标程序时，它的Splash窗口，以及主窗口都将显示出来，即使当我用FindWindow（）找到主窗口Handle后，调用SendMessage（WindowHandle， SW_HIDE）来隐藏该窗口，还是会有一瞬主窗口被显示出来的

开始本应该是一篇洋洋洒洒的文字, 不过我还是提倡先做起来, 在尝试中去理解. 先试试这个: procedure TForm1.Button1Click(Sender: TObject); var i: Integer; begin for i := 0 to 500000 do begin Canvas.TextOut(10, 10, IntToStr(i)); end; end; View Code 上面程序运行时, 我们的窗体基本是 "死" 的, 可以在你在程序运行期间拖动窗体试试... Delphi 为我们提供了一个简单的办法(Application.ProcessMessages)来解决这个问题: procedure TForm1.Button1Click(Sender: TObject); var i: Integer; begin for i := 0 to 500000 do begin Canvas.TextOut(10, 10, IntToStr(i)); Application.ProcessMessages; end; end; View Code 这个 Application.ProcessMessages; 一般用在比较费时的循环中, 它会检查并先处理消息队列中的其他消息. 但这算不上多线程, 譬如: 运行中你拖动窗体, 循环会暂停下来...

文件的拖放和打开拖拽 user shellapi type TForm1 = class(TForm) ListView1: TListView; procedure FormCreate(Sender: TObject); private { Private declarations } public { Public declarations } procedure AppMessage(var Msg: TMsg; var Handled: Boolean);///////消息处理函数 end; procedure TForm1.FormCreate(Sender: TObject); begin //设置需要处理文件WM_DROPFILES拖放消息 DragAcceptFiles(ListView1.Handle, TRUE); //设置AppMessage过程来捕获所有消息 Application.OnMessage := AppMessage; end; procedure TForm1.AppMessage(var Msg: TMsg; var Handled: Boolean); var nFiles, I: Integer; Filename: string; ListItem: TListItem; begin // // 注意！所有消息都将通过这里！ //

打開剪貼板: OpenClipboard 返回值為BOOL，成功返回非0，若失敗或剪貼板被佔用，返回0. CloseClipboard：關閉 EmptyClipboard：清空 前一個程序調用關閉，後一個程序調用清空后，打開剪貼板的當前窗口才擁有剪貼板。 SetClipboardData向剪貼板中防止數據。 參數： nFormat:剪貼板格式 hMem:具有指定格式的數據的句柄 ------------------------------------------------------------------- 延遲提交技術 ------------- 第一次調用SetClipboardData時，將其hMem參數設置為NULL，在剪貼板上以指定的剪貼板格式放置一個 空的剪貼板數據塊。然後直到其他進程需要數據或自身進程需要終止運行時再次調用SetClipboardData函數，這次 才真正提交數據（不需再調用OpenClipboard和EmptyClipboard） IsClipboardFormatAvailable(format)//檢測剪貼板上是否包含了參數format指定的格式的數據 GetClipboardData(CF_TEXT);//從剪貼板上獲得指定數據 --------------------------------------------------------

如何自动检查内存泄漏和句柄耗尽 1. 背景 当程序的子模块数量和规模扩大之后，在开发阶段，系统长时间允许后经常会碰到下面一些bug: 内存泄漏。随着时间允许，系统可用的内存越来越少，最后kernel 出现oom 错误； 文件句柄耗尽。程序可以打开的文件、套接字、管道越来越少，最后出错在用完了最后一个可用句柄的代码附近； 死锁。线程拥有一把锁A，正在申请锁B；但在此时锁B被另外一个线程拥有，且那个线程又在申请锁A。形成一个循环等待、占用且不可释放的状态。 调试这些问题，当然可以从代码流程和逻辑出发，结合ps/gdb/proc/core等命令和信息，一步步挖出root cause。但一般要求对代码、线程关系和相关命令比较熟悉，一般耗时较长。所以，一般大型公司都封装了标准的glibc,做了一个wraaper，然后再wrapper里面加入了对上面调试的支持。还有的可采用专业内存泄漏等检查工具，去做代码检测。那么，对于咱工程师而言，能否能自己设计并实现一个资源检查工具呢？ 2. 原理 针对上面的三个例子使用中的资源，我们可以归纳成两类：数量有限的共享资源，比如上面空间有限的内存和数量有限的文件句柄；需要独占的互斥资源，比如上面例子中提到的锁。 下面就分别针对这两种情况，分别展开分析。 2.1 对共享资管的检查 共享资源的特点是：总量有限，通过申请接口获得，使用完了之后通过释放接口归还

tcp socket文件句柄泄漏 今天发现有台redis机器上出现socket个数告警，这是很奇怪的现象。因为一台redis服务器上就部署了几个redis实例，打开的端口应该是有限。 1、netstat显示的tcp连接数正常 netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'` TIME_WAIT 221 ESTABLISHED 103 netstat -nat |wc -l 368 建立的tcp连接数并不是很多。 ss -s显示大量的closed连接 ss -s Total: 158211 (kernel 158355) TCP: 157740 (estab 103, closed 157624, orphaned 0, synrecv 0, timewait 173/0), ports 203 Transport Total IP IPv6 158355 - - RAW 0 0 0 UDP 9 6 3 TCP 116 80 36 INET 125 86 39 FRAG 0 0 0 closed 157624 而我的系统监控取值方法是: cat /proc/net/sockstat | grep sockets | awk '{print $3}'