如何直接用API来获取当前鼠标的状态，判断当前鼠标时按下还是其他，最好还能判断是左右键？

shixinyu 2001-05-22 02:03:00

...全文

1364 9 打赏收藏转发到动态举报

写回复

用AI写文章

9 条回复

切换为时间正序

请发表友善的回复…

发表回复

shixinyu 2001-05-22

打赏
举报

msdn上说好像是最高位为1时，代表down.

flyswatter 2001-05-22

打赏
举报

返回1时down
返回0时up

eggplant 2001-05-22

打赏
举报

If the function succeeds, the return value specifies whether the key was pressed since the last call to GetAsyncKeyState, and whether the key is currently up or down. If the most significant bit is set, the key is down, and if the least significant bit is set, the key was pressed after the previous call to GetAsyncKeyState. The return value is zero if a window in another thread or process currently has the keyboard focus.

shixinyu 2001-05-22

打赏
举报

fsdfs

shixinyu 2001-05-22

打赏
举报

to flyswatter:
返回值SHORT怎么不是BOOL?
怎么从返回值判断是否按下？

shixinyu 2001-05-22

打赏
举报

拜托，大虾，马上给分

flyswatter 2001-05-22

打赏
举报

SHORT GetAsyncKeyState( int vKey);
vKey的取值：
VK_LBUTTON 01 Left mouse button
VK_RBUTTON 02 Right mouse button

shixinyu 2001-05-22

打赏
举报

拜托，大虾，马上给分

shixinyu 2001-05-22

打赏
举报

拜托，大虾，马上给分

仅收录该书籍以供学习和讨论包含pdf书籍及经过验证的示例执行demo中的示例方式在编译环境下进入demo目录，执行nmake命令在bin目录下生成可执行文件注：demo无注释，对应书本中部分示例。目录第1章　Windows应用程序开发入门　1 1.1　第一个实例程序　1 1.1.1　start.exe　1 1.1.2　Windows API　2 1.1.3　程序入口函数　2 1.1.4　start.c代码分析　2 1.2　编译代码　3 1.2.1　安装Visual Studio　3 1.2.2　安装Microsoft Platform SDK　4 1.2.3　集成Microsoft Platform SDK与Visual C++速成版　5 1.2.4　Vista SDK与Visual Studio 2008　6 1.2.5　Visual Studio专业版或团队系统版　7 1.2.6　使用图形化IDE建立工程、进行编译　7 1.2.7　“解决方案”与“工程”　8 1.2.8　使用命令行工具编译　8 第2章　Windows API概要　10 2.1　Windows数据类型　10 2.1.1　Windows数据类型示例　10 2.1.2　Windows数据类型与标准C数据类型的关系　14 2.1.3　Windows数据类型与Windows API　14 2.1.4　Windows中的数据结构　15 2.2　Windows API的功能分类　15 2.2.1　系统基本服务　15 2.2.2　系统管理　17 2.2.3　用户界面　17 2.2.4　图像和多媒体　20 2.2.5　网络　20 2.2.6　系统安全　20 2.2.7　其他功能　21 2.3　Windows API核心DLL　21 2.3.1　Kernel32.dll　21 2.3.2　User32.dll　21 2.3.3　Gdi32.dll　22 2.3.4　标准C函数　22 2.3.5　其他Dll　22 2.4　Unicode和多字节　22 2.4.1　W版本和A版本的API　24 2.4.2　Unicode与ASCII的转换　24 2.5　对Windows程序设计规范的建议　25 第3章　开发工具配置与使用　26 3.1　使用Visual C/C++编译链接工具　26 3.1.1　编译器cl.exe　27 3.1.2　资源编译器rc.exe　31 3.1.3　链接器link.exe　32 3.1.4　其他工具　38 3.1.5　编译链接工具依赖的环境变量　39 3.1.6　示例：使用/D选项进行条件编译　42 3.2　使用Platform SDK　43 3.2.1　Platform SDK的目录结构与功能　43 3.2.2　为编译链接工具设置环境变量　45 3.2.3　Platform SDK工具集　46 3.2.4　Windows Vista SDK　48 3.3　编写Makefile　48 3.3.1　使用nmake.exe构建工程　48 3.3.2　Makefile实例　50 3.3.3　注释　50 3.3.4　宏　50 3.3.5　描述块：目标、依赖项和命令　53 3.3.6　makefile预处理　55 3.3.7　在Platform SDK的基础上使用nmake　56 3.4　使用WinDbg调试　57 3.4.1　安装WinDbg　57 3.4.2　编译可调试的程序　58 3.4.3　WinDbg命令　59 3.4.4　调试过程演示　59 3.5　集成开发环境 Visual Studio　62 3.5.1　工程类型选择与配置　62 3.5.2　Visual Studio快捷方式　64 3.5.3　生成项目　64 3.5.4　调试　65 3.5.5　选项与设置　65 3.6　开发环境配置总结　66 第4章　文件系统　67 4.1　概述　67 4.1.1　文件系统的基本概念　67 4.1.2　文件系统主要API　68 4.2　磁盘和驱动器管理　70 4.2.1　遍历卷并获取属性　70 4.2.2　操作驱动器挂载点　76 4.2.3　判断光驱中是否有光盘　81 4.2.4　获取磁盘分区的总容量、空闲容量、簇、扇区信息　83 4.3　文件和目录管理　86 4.3.1　删除、复制、重命名、移动文件　87 4.3.2　创建、打开、读写文件，获取文件大小　90 4.3.3　创建目录　96 4.3.4　获取程序所在的目录、程序模块路径，获取和设置当前目录　97 4.3.5　查找文件、遍历指定目录下的文件和子目录　100 4.3.6　递归遍历目录树　103 4.3.7　获取、设置文件属性和时间　105 4.4　内存映射文件　110 4.4.1　使用Mapping File提高文件读写的效率　110 4.4.2　通过Mapping File在进程间传递和共享数据　115 4.4.3　通过文件句柄获得文件路径　118 4.5　总结　121 第5章　内存管理　122 5.1　Windows内存管理原理　122 5.1.1　基本概念　122 5.1.2　分页与分段内存管理、内存映射与地址转换　123 5.1.3　进程的内存空间　125 5.1.4　虚拟内存布局、内存的分工、堆与栈　127 5.1.5　内存的保护属性和存取权限　127 5.1.6　本章API列表　127 5.2　堆管理　129 5.2.1　获取堆句柄、分配与再分配堆　129 5.2.2　获取堆中内存块的大小信息　133 5.2.3　释放内存、销毁堆　134 5.3　全局(Global)和局部(Local)内存管理　136 5.3.1　Global函数　136 5.3.2　Local函数　137 5.3.3　使用全局和局部函数分配和释放内存、改变内存块属性　137 5.4　虚拟内存管理　138 5.4.1　虚拟地址空间与内存分页　139 5.4.2　分配和释放可读可写的虚拟内存页面　139 5.4.3　修改内存页面状态和保护属性、将页面锁定在物理内存中　142 5.4.4　管理其他进程的虚拟内存　143 5.5　内存操作与内存信息管理　144 5.5.1　复制、填充、移动、清零内存块、防止缓冲区溢出　144 5.5.2　获得当前系统内存使用情况　146 5.5.3　判断内存指针的可用性　147 5.6　各种内存分配方式的关系与比较　148 5.6.1　标准C内存管理函数与Windows内存管理API的关系　149 5.6.2　功能性区别　149 5.6.3　效率的区别　149 第6章　进程、线程和模块　150 6.1　基本概念　150 6.1.1　应用程序与进程　150 6.1.2　控制台应用程序与图形用户界面应用程序　151 6.1.3　动态链接库、模块　151 6.1.4　线程、纤程与作业　152 6.1.5　权限与优先级　153 6.2　进程管理　153 6.2.1　创建进程、获取进程相关信息、获取启动参数　153 6.2.2　编写控制台程序和图形用户界面应用程序　158 6.2.3　获取和设置环境变量　158 6.3　线程、纤程　162 6.3.1　创建线程、退出线程、获取线程信息　162 6.3.2　挂起、恢复、切换、终止线程　164 6.3.3　创建远程线程、将代码注入其他进程中执行　167 6.3.4　创建纤程、删除纤程、调度纤程　170 6.3.5　纤程与线程的互相转换　171 6.4　进程状态信息　176 6.4.1　PS API与Tool help API　176 6.4.2　遍历系统中的进程　178 6.4.3　列举进程的模块、线程　182 6.4.4　进程的堆使用、内存占用、虚拟内存大小，页面错误情况　184 6.5　动态链接库　185 6.5.1　加载、释放DLL、通过句柄获取DLL相关信息　186 6.5.2　编写动态链接库、导出函数　186 6.5.3　创建动态链接库工程，配置DLL编译链接选项　188 6.5.4　运行时动态获取DLL导出函数地址并调用　189 6.5.5　声明导出函数、创建lib库，为其他模块提供导入表调用接口　190 6.5.6　通过构建导入表调用DLL导出函数　191 第7章　线程同步　192 7.1　基本原理　192 7.1.1　线程同步的过程　193 7.1.2　同步对象　193 7.1.3　等待函数　193 7.2　同步对象示例　194 7.2.1　使用事件对象(Event)　194 7.2.2　使用互斥对象(Mutex)　199 7.2.3　使用信号量控制访问共享数据的线程数量　202 7.2.4　使用可等待计时器(Timer)　206 7.3　等待进程和线程的执行完成　209 第8章　服务　210 8.1　基本概念　210 8.1.1　服务控制器(SCM)　211 8.1.2　服务程序　211 8.1.3　服务控制管理程序　211 8.1.4　系统服务管理工具　211 8.1.5　服务的属性　211 8.2　编写服务程序　212 8.2.1　入口函数　212 8.2.2　服务主函数　212 8.2.3　控制处理函数　213 8.3　实现对服务的控制和管理　216 8.3.1　创建、删除服务　216 8.3.2　启动、停止服务，向服务发送控制请求　219 8.3.3　管理服务状态、配置服务、服务的依赖关系　222 第9章　图形用户界面　229 9.1　字符界面程序　229 9.1.1　基本概念　230 9.1.2　控制台读写　231 9.1.3　控制台字体、颜色等属性，操作屏幕缓存　234 9.1.4　控制台事件　244 9.2　图形用户界面：基本概念　246 9.2.1　窗口　246 9.2.2　窗口类　246 9.2.3　消息和消息处理函数　247 9.2.4　控件　247 9.2.5　资源　248 9.2.6　对话框　248 9.3　图形用户界面：窗口　248 9.3.1　注册窗口类　249 9.3.2　创建窗口　251 9.3.3　窗口消息处理函数　253 9.3.4　窗口属性、位置和大小　256 9.3.5　窗口显示方式　257 9.3.6　线程消息队列和消息循环　258 9.4　图形用户界面：控件　258 9.4.1　Tree View控件　258 9.4.2　为Tree View控件增加节点　260 9.4.3　Tree View右键菜单　262 9.4.4　List View控件　263 9.4.5　为List View控件增加分栏　265 9.4.6　为List View控件增加项　266 9.4.7　文本框控件　267 9.4.8　为文本框控件设置文字　268 9.5　界面资源　269 9.5.1　资源脚本(.rc)　269 9.5.2　资源ID定义和头文件　272 9.5.3　在程序中使用资源　273 9.6　菜单　273 9.6.1　菜单资源和菜单句柄　273 9.6.2　动态增加、删除、设置菜单及菜单项　274 9.6.3　菜单消息处理　274 9.7　对话框　275 9.7.1　创建对话框　275 9.7.2　对话框消息处理函数　276 第10章　系统信息的管理　277 10.1　Windows系统信息　277 10.1.1　获取系统版本　277 10.1.2　获取计算机硬件信息　279 10.1.3　获取系统目录等信息　281 10.1.4　用户名、计算机名、域名　282 10.1.5　处理系统颜色信息、尺度信息等　284 10.1.6　鼠标、键盘等外设信息　285 10.2　时间信息　286 10.2.1　设置、获取系统时间　286 10.2.2　获取开机至现在持续的时间　287 10.2.3　文件时间与系统时间的转换　287 10.3　注册表　288 10.3.1　注册表的作用及组织形式　288 10.3.2　键、子键、键属性及键值的相关操作　289 10.3.3　列举注册表项及键值　292 10.3.4　通过注册表设置一个自启动的程序　293 10.3.5　设置随程序启动而启动的调试器(任何程序)　294 10.3.6　指定程序崩溃实时调试器　294 第11章　进程间通信　295 11.1　邮槽(MailSlot)　295 11.1.1　创建邮槽、从邮槽中读取消息　296 11.1.2　通过邮槽发送消息　299 11.2　管道(Pipe)　300 11.2.1　创建命名管道　300 11.2.2　管道监听　302 11.2.3　使用异步I/O进行读写　303 11.2.4　关闭管道实例　307 11.2.5　客户端　307 11.3　剪贴板　310 11.3.1　获取、设置剪贴板数据　310 11.3.2　监视剪贴板　317 11.3.3　剪贴板数据格式　325 11.4　数据复制消息(WM_COPYDATA)　327 11.4.1　数据发送端　327 11.4.2　数据接收端　330 11.5　其他进程间通信方式　332 11.5.1　动态数据交换(DDE)和网络动态数据交换(NDDE)　332 11.5.2　通过File Mapping在进程间共享数据　333 11.5.3　Windows Socket　333 第12章　Windows Shell程序设计　334 12.1　Windows Shell目录管理　335 12.1.1　Shell对目录和文件的管理形式　335 12.1.2 “我的文档”等特殊目录相关操作　335 12.1.3　绑定、遍历、属性获取　337 12.1.4　浏览文件对话框　339 12.2　文件协助(File Associations)　340 12.2.1　文件类型相关注册表键值　340 12.2.2　为文件指定默认打开程序　341 12.2.3　定制文件类型的图标　342 12.3　Shell扩展　343 12.3.1　对象及概念　343 12.3.2　CLSID，处理例程的GUID　344 12.3.3　注册Shell扩展　345 12.3.4　COM程序开发基础　346 12.3.5　编写Handler程序　346 12.3.6　Shell扩展程序的调试　362 12.3.7　总结　363 12.4　任务栏通知区域(Tray)图标　363 12.4.1　创建图标窗口　364 12.4.2　创建图标和图标菜单　367 12.4.3　最小化主窗口到通知区域　370 12.4.4　弹出气泡通知　372 12.4.5　动态图标　374 12.4.6　其他功能　376 第13章　Windows GDI　379 13.1　GDI编程接口概述　379 13.1.1　Windows GDI的功能　379 13.1.2　链接库与头文件　380 13.2　设备上下文(DC)、输出操作与图形对象　380 13.2.1　设备上下文类型与关联设备　380 13.2.2　图形对象的作用及与DC的关系　380 13.2.3　各类图形对象的具体属性与作用　383 13.2.4　绘制、填充、写入等图形输出操作　384 13.2.5　修剪与坐标变换　385 13.2.6　设备上下文的图形模式　385 13.3　一个最简单的GDI程序　386 13.3.1　示例　386 13.3.2　DC的操作　387 13.3.3　颜色的表示　388 13.3.4　图形对象：画刷和画笔　389 13.3.5　输出操作：绘制图形和线条　390 13.4　文字和字体　391 13.4.1　选择、设置字体　393 13.4.2　选择字体图形对象　394 13.4.3　文字的颜色　394 13.4.4　输出文字　395 13.4.5　DC图形模式设置　395 13.4.6　遍历字体　396 13.4.7　为系统安装、删除字体文件　398 13.5　绘制线条　398 13.5.1　选择画笔对象　399 13.5.2　直线　399 13.5.3　绘制任意曲线　399 13.5.4　跟踪鼠标轨迹　399 13.5.5　弧线　405 13.6　绘制图形　405 13.6.1　填充颜色与边缘勾勒　406 13.6.2　绘制矩形、椭圆、圆角矩形　406 13.6.3　椭圆弓形和椭圆扇形　411 13.6.4　多边形　411 13.6.5　RECT结构及对RECT的操作　412 13.7　位图操作　414 13.7.1　截取屏幕、保存位图文件　414 13.7.2　将位图显示在界面上　419 13.8　区域(Regions)、路径(Paths)与修剪(Clip)操作　422 13.8.1　区域的创建及形状、位置等属性　422 13.8.2　区域边沿、区域填充、反转与勾勒操作　423 13.8.3　组合、比较、移动等操作　426 13.8.4　点击测试(Hit Testing)　427 13.8.5　路径的创建与操作　431 13.8.6　路径转换为区域　432 13.8.7　使用区域和路径进行修剪操作，限制输出　432 13.9　坐标变换　438 13.9.1　缩放　439 13.9.2　旋转　440 13.10　调色板　440 第14章　网络通信与配置　443 14.1　Socket通信　444 14.1.1　客户端　444 14.1.2　服务端　449 14.1.3　处理并发的客户端连接　455 14.1.4　网络通信的异步I/O模式　456 14.2　IP Helper　456 第15章　程序安装与设置　463 15.1　创建cab文件　463 15.1.1　makecab.exe　463 15.1.2　压缩多个文件　464 15.1.3　Cabinet软件开发工具包(CABSDK)　466 15.2　编写INF文件　466 15.2.1　INF文件格式　466 15.2.2　Install节　468 15.2.3　CopyFiles和AddReg等安装过程　468 15.2.4　源路径和目的路径　469 15.2.5　字符串表　469 15.3　安装程序setup.exe的编号　469 15.4　使用msi文件进行安装　472 15.4.1　Windows Installer Service　472 15.4.2　msi文件的创建与修改工具orca.exe　474 15.4.3　准备工作　475 15.4.4　编辑表组　475 第16章　设备驱动管理与内核通信　476 16.1　设备管理　476 16.1.1　列举设备接口　477 16.1.2　监控设备的加载和卸载　483 16.2　I/O控制、内核通信　488 16.2.1　加载驱动程序　488 16.2.2　控制驱动程序、与驱动程序进行通信　495 16.3　编写设备驱动程序　498 16.3.1　驱动程序开发包：DDK　499 16.3.2　开发驱动程序　499 16.4　I/O模式，同步与异步　504 第17章　用户、认证和对象安全　506 17.1　基本概念　506 17.1.1　访问令牌、权限和用户标识　506 17.1.2　进程的系统操作权限　507 17.1.3　安全对象　508 17.1.4　访问控制列表(ACL)　508 17.2　安全机制程序示例　509 17.2.1　列举进程访问令牌内容和权限　509 17.2.2　修改进程的权限　514 17.2.3　列举安全对象的安全描述符　515 17.2.4　修改安全描述符　521 17.3　用户　522 17.3.1　创建用户　522 17.3.2　用户组　523 17.3.3　删除用户　525 17.3.4　列举用户和用户组、获取用户信息　525 第18章　Windows API的内部原理　532 18.1　关于API的补充说明　532 18.1.1　Windows API的版本演进和Vista新增API　532 18.1.2　64位操作系统的接口　533 18.2　Windows系统中的对象封装　533 18.2.1　什么是对象　534 18.2.2　面向对象的思想　534 18.2.3　Windows系统中的对象：内核对象、GDI对象等　534 18.3　Windows程序设计参考：文档资源与样例代码　534 18.3.1　SDK文档和MSDN　534 18.3.2　SDK示例代码　535 18.4　x86平台程序函数调用原理　535 18.4.1　函数调用的真实过程　535 18.4.2　函数调用约定　539 18.4.3　为什么通过参数返回数据时只能使用指针　540 18.4.4　缓冲区溢出　540 18.4.5　程序运行错误的调试技巧　540 18.5　可执行程序结构与API函数接口内部机理　541 18.5.1　Windows可执行程序结构　541 18.5.2　导入表、导出表、动态链接　543 18.5.3　NTDLL.DLL、NATIVE API和SSDT　544 18.5.4　API HOOK　546 18.6　发布程序　546 18.6.1　合理选择编译链接选项　546 18.6.2　构建到指定路径　546 18.7　模块化，向Windows API学习接口定义　547 18.7.1　lib文件　547 18.7.2　头文件　547 18.7.3　为第三方应用软件提供SDK　547

在delphi中，很多窗体和控件的鼠标事件里面已经将鼠标按键状态封装好传给响应事件的函数，所以这种情况直接使用就可以，但在某些时候，我们没有这些事件可以处理时，想判断鼠标按键是否按下的状态，就需要借助API或者消息了，使用API和消息可分别应对2种不同情形： 1）使用API: GetAsyncKeyState，适合实时检测，下面代码演示判断鼠标是否按下左键 function IsMous...

智能合约虚拟机赋予了区块链运行去中心化应用（Dapp）的能力。它让区块链演化为“操作系统”，孕育出繁荣的Dapp生态。一款优秀的VM不仅仅是要完成确定、高效、安全地执行合约字节码的功能，它应该足够通用，能最大化节省开发者的成本，甚至能形成独立的开发者生态。从架构上来说，VM为智能合约提供计算资源和运行容器，区块链的共识、执行模块与VM是完全解耦的。在区块链2.0项目中，我们看到大部分项目将VM作为区块链项目的一个子模块，一同编译进二进制中；Fabric更进一步，链码被编译成独立的程序，运行于独立的docker容器中，通过grpc与节点交互。如此，可将数据与逻辑彻底分离；在未来，VM可能以硬件的形式安装在“矿机”中，通过更底层的如PCIe接口与区块链进行通信。业界的Nervos CKB使用RISC-V实现VM，为演化成硬件模块做准备。架构设计验证层验证层会对合约字节码及传参进行一些验证，包含ABI验证，环境检查与版本检查三个环节。ABI验证：利用合约ABI对用户发送的合约调用及参数进行校验。环境检查：检查虚拟机执行环境是否符合预期检查Config字段。字节码是否合法。exports是否包含apply与memory，以及类型是否正确；是否包含start（被禁用）；是否包含import，import的模块是否合法。解释器模块是否ready。版本检查：检查合约版本，选择对应版本的解释器。注入层注入层主要对合约字节码注入一些必要的代码，以及构建相应的执行上下文。Gas MeteringGas metering是用于统计每一个操作所须花费的Gas。原理非常简单：实现Env_api方法useGas。将wasm字节码恢复成易于解析的格式化文本（如JSON）。将useGas注入到格式化文本中将格式化文本重新恢复成wasm字节码。这里有一个值得考虑的问题：**Gas Metering能否放到编译期去做？**在编译器做Gas metering注入的好处是只须要注入一次，节省了执行时的开销。但这样的弊端也很明显:Gas Table本属于区块链协议的一部分，但却被放到合约编译器中，恶意用户只须要更改编译器的Gas Table即可完成作恶，作恶成本大大降低。若Gas Table需要修改，无法再对已部署的旧合约更新Gas Metering，导致新老合约的Gas收费标准不一致。在每次执行时进行一次Gas Metering注入，虽然牺牲了一些执行效率，但换来了Gas灵活变更的特性，这对于不断调整、迭代的公链项目是至关重要的。一种更好的方案，是将Gas Table以合约形式部署，无须硬分叉便可更改Gas Table的参数。Env API 注入Env_api是区块链提供给合约层用于与区块链进行交互的接口。注入原理如下：合约字节码(wast)中包含形如(import env getAddress (func ...))的代码段。意为从env模块中导入getAddress函数。env模块从哪来呢？由虚拟机利用解释器的API构建原生模块，并实现预先设计的Env_api。这里的Env_api都须要用原生语言实现。利用解释器的moduleResolver在执行代码前注入。经以太坊基金会Go-team的gary推荐，这里隆重介绍下EVMC这个项目。它提供了一套虚拟机和客户端之间的通用交互接口。不同的VM只需要实现这些接口，即可为以太坊客户端提供交互功能。如此将客户端与虚拟机实现相互分离，更能够根据实际情况灵活切换底层虚拟机实现。上下文构建我们还需要给合约执行构建合理的上下文环境，提供必要的内部模块和数据以供合约使用，包括：区块链账本实例，提供区块、交易等信息的调用接口。状态数据库实例，提供状态数据的增删改查的调用接口。当前Transaction与Action的相关数据。当前区块高度和区块时间。执行层执行层是虚拟机的核心模块，负责执行合约字节码并返回结果。它必须具备以下几个特性：确定性：即相同入参和上下文，无论在什么设备上运行，何时运行，运行几次，都必须获得相同结果。高效执行：虚拟机的执行时间不大于共识算法给于交易执行的最大时间。停机与回滚：须要有相应停机机制。在执行失败时须要对本次执行涉及的所有状态变更进行回滚。沙箱环境：即保证合约与合约之间、合约与宿主系统之间的资源隔离。能够防备恶意和故障合约的不良影响。Apply执行合约字节码，实际是调用合约代码中的apply函数。合约上下文，包括用户指定调用的合约方法名和对应入参，通过Env_api在实际apply实现中获取，最终调用相应的合约方法。栗子详见系列第二篇。Memory合约除了应导出apply函数外，还须要导出memory对象。memory对象是wasm编译器在合约编译时自动注入，通常会开辟一页内存(64KB) (memory $0 1)。解释器会初始化一个线性字节数组作为内存供wasm使用，wasm与区块链数据交互是依靠内存共享的形式，通过该字节数组进行传递。（这也是为何在Env_api设计里，很多数值的传参是offset与length的组合）Wasm的内存数组是按照| static memory | dynamic memory |的次序划分，static memory中存放编译期的字符串或数组，dynamic memory用于运行期的数据存储，并且可以动态扩容。为了防止dynamic memory无限制地扩容，需要有合理的收费机制与内存分配上限。AssemblyScript提供了一个额外的位于static memory之前的预留空间，称为reserved memory。这使得我们在运行期可以将一些变长数据（如字符串，数组等）以Global的形式导入wasm。这样wasm无须调用Env_api即可直接使用上下文的变量，如发送方、接收方、合约地址、当前调用的合约方法名等。状态存储对VM最本质的需求是对状态存储的需求，这种存储是达成共识的、不可逆的，从而实现了去中心化应用中数据的信任存储。Ethereum1出现的状态爆炸问题给我们敲响了警钟——只收取每一次读写操作的费用，而不收取占用存储的费用，是不合理的。如果不对占用存储收费，则用户可以无限制地占用区块链的稀缺存储资源；且由于没有好的数据清理机制，区块链的状态就会不断增长，即所谓“爆炸”。状态存储付费是很自然想到的方案。如何设计合理的状态存储付费方案，有两个底层逻辑需要考虑：用户应当为占用链上的稀缺存储资源付出成本。这里的成本是广义的，可以是代币价值、机会成本与承担额外风险等形式。状态存储的使用属性最大化，投资属性最小化。须要避免出现用户大量囤积存储资源，提高资源利用率。EOS使用【RAM】来解决状态收费的问题。开发者须要使用代币向系统合约购买RAM，存储状态数据须要消耗对应大小的RAM资源，当数据删除时RAM资源也会相应释放，并且可以卖回给系统拿回代币。但开发者须要承担RAM和代币价值波动风险。如何对RAM定价呢？EOS创新性地引入了Bancor算法对RAM进行模拟市场定价。Bancor算法有两个特点：数字货币价格取决于存储金金额和代币流通量，真实模拟了市场供需关系；人机交易，无须对手盘，这使得“巨鲸”可轻易做多或做空，导致价格波动剧烈。也正因为上面两个特性，EOS主网刚上线时，出现了大量RAM资源被囤积，RAM价格被瞬间拉至高位，又在随后的一周内快速下降，造成了“割开发者韭菜”的情况。V神在2018年曾提出过使用【状态租金】来解决状态爆炸问题。状态租金很像当前云计算服务的商业模式，用户不仅花费购买占用空间大小，还须购买占用时间。对于状态租金方案的具体设计，我们仍然须要考虑以下几个问题：用户体验：当状态出租时间快到期时，如何提醒用户续费？时间到期后状态数据是否立马清除？不同级别的数据是否有区别的对待？（云服务厂商都会提供到期后的赎回期，以防止关键数据被意外删除）支付对象：哪些数据需要支付租金？除了合约的状态数据必然要支付租金以外，账户本身的元数据（balance, nonce等）是否也要付租金？如果需要，时间到期后清零，势必损害用户的资金安全（与区块链保护数字资产的理念相背），同时nonce为0后可能会遭受重放攻击。如果不需要，仍然无法抑制因新账户的创建而产生的状态爆炸问题。定价：链上存储资源的稀缺程度，与区块链的生态价值及当下的市场需求密切相关。如何建立一个合理定价模型便是个非常重要的问题。Ethereum Research中有大神对状态租金的方案进行了细化，引入了激励机制用于租赁过期的发现和确认，并且允许在状态数据删除后申请恢复。Nervos CKB结合了状态买卖和状态租金的长处，利用原生代币代表占用全局状态的权利，且汇率恒定，即1 CKB代表1 Bytes的存储空间。同时巧妙地利用【二级发行】机制为代币持有者（存储空间占有者）设置了【通胀税】，以作为支付给矿工的状态租金。靠通胀收取租金的方式既保留了RAM方案的买断存储空间的使用模式，解决了上面所提到的用户体验的问题，又将定价转移到了通胀部分对应的法币价值，完全由二级市场进行价值发现。但这使得状态空间的上限严格等同于当前代币流通量，在初期可能会限制生态的发展。合约安全我们在第一篇中有提到，合约安全分为编译期安全和执行期安全。本篇主要阐述执行期安全的设计思路。执行期安全也成为运行期安全，主要由VM针对以下两方面提供保障：数据安全：不能随意篡改其他用户或其他合约的状态数据。资源安全：CPU、内存、硬盘资源的分配与回收。数据安全加密数字资产真正实现了人类梦寐以求的“私有财产神圣不可侵犯”，它象征着真正的自由。为了捍卫这份“自由”，数据安全是重中之重。VM需要为以下两个方面提供安全保障：用户数据的安全，即利用密码学算法判断是否有修改状态数据的权限。合约状态数据的隔离，即任何合约都不能直接修改其他合约的状态数据，即使该用户拥有权限。第一个维度很好理解，合约会提供根据用户地址和交易签名进行身份权限审查的功能（甚至可提供基于多密钥对的权限管理），以判断本次合约调用是否有权限修改相应的数据。这也是“私有财产神圣不可侵犯”的根源。第二个维度需要特别解释一下。这里的不能直接修改其他合约的状态数据，是指不能在合约A的方法中直接修改合约B的数据。为什么？因为这会导致状态变更无法追溯，带来不确定性。我们知道，区块链环境中只能通过交易(Transaction)来触发状态变更，交易本身就是状态变更的日志。若允许在合约A中直接修改合约B的状态数据，则这次修改是并未生成相关日志的，使得状态修改无法追溯，与区块链“可追溯”的特性相违背。以太坊中跨合约调用也是没有保留日志的。笔者认为这是因为以太坊合约是不可升级的，一旦部署后地址和代码都是不可变更的，因此可结合交易和代码具体片段来追踪状态变更记录。但以太坊并没有提供相关的索引，这导致对状态修改的记录追踪基本不可能，因此我认为这是一个设计上的重大缺陷。在EOS中，我们看到跨合约调用是生成了新的action，并被加入到原action列表中，在链上保留了状态修改的日志。能否利用静态代码分析的方式确定跨合约的对方地址和相关合约方法，从而追溯到状态变更的细节？当然是可行的，但如果有多层调用（合约A -> 合约B -> ... -> 合约Z），这种方案显然开销是非常大的。尽管以太坊提供了tracer，可以在执行交易的过程中追踪跨合约调用的对象，但如果我想查找导致合约X某状态变更的所有历史操作，上述方案必须遍历并模拟执行所有的历史交易，显然是不可取的。我们认为，跨合约交易正确的做法，是通过内联交易的形式调用合约B的方法从而间接修改合约B数据。即生成一个新的交易来触发目标合约的状态变更。该交易也会应放入区块中，视为由原交易生成的日志。这样可为状态变更保留操作记录，也符合“可追溯”的特征。资源安全智能合约通常运行在由虚拟机提供的沙箱环境，我们需要对其能够使用的资源进行适度的把控。这些资源包括三类：CPU、内存、硬盘。下面我们以QA的形式对涉及到的问题进行解答——CPU资源Q1: 合约运行最大能占用多少个进程，多少个线程？一个；一个或多个。Q2: 是否允许合约内开辟新线程？不允许。合约不应有操作系统级别的调用，而应由虚拟机层来确定性地分配CPU资源（线程数）。Q3:多线程下如何保证线程安全？多线程下，不应通过加锁来保证线程安全，原因是加锁无法保证执行顺序，带来不确定性。正确的做法是在执行前通过静态分析、注解等手段对合约调用进行归类。互斥资源的调用顺序遵循交易发送的顺序；非互斥资源的合约调用可以并行执行。Q4: 如何控制执行时间？利用Gas机制控制合约执行时间（在本系列第一篇已提到），避免过度占用CPU时间。Q5: 如何捕捉错误与处理？合约执行的错误不应导致虚拟机的进程终止，虚拟机应当提供错误捕获和处理的机制。常规的做法时合约运行时的错误以error的形式抛出，虚拟机层捕获后做失败处理，包括终止交易执行、状态回滚、资源回收等。内存资源Q1：合约运行最大能占用多少内存？节点能分配多大的内存给虚拟机，是由矿工决定。这本质上经济学问题：扩大内存分配无疑会增加成本，而这部分提升的执行效率能为矿工带来多少收益。若可用内存过少，部分交易执行失败，可能导致分叉；若可用内存过多，又会造成资源浪费，降低矿工收益。Q2: 内存能否动态扩张？可以，但须要付费。为了防止内存无限制扩张，虚拟机还应对合约的内存占用设置上限。Q3: 如何避免内存泄漏？不应交由合约开发者控制内存回收，虚拟机应当实现GC机制。Q4: 如何避免内存溢出？Wasm虚拟机中内存实则为字节数组，本身带有边界控制，能有效防止内存溢出。磁盘资源Q1: 单个合约最多能够存储多少数据？这也是经济学问题，应该设置合理的硬盘占用计费。Q2: 能否修改其他合约的持久化数据？不能直接修改，因为这会影响到【数据安全】章节中提到的确定性。虚拟机为合约创建的上下文环境中，包含相互隔离的数据空间。可以通过创建新的上下文环境进行数据修改，这样的操作视为一次新的合约调用（保留日志）。Q3: 如何防止未知的数据丢失（如磁盘损毁）？当发生数据丢失时，节点执行合约会得到不同的状态结果，导致区块被认定为非法，区块链无法延长。这里需要区块链系统具备状态一致性的检测机制，在解决硬盘故障后采用同步主链块并重放交易的方式进行恢复。系统合约系统合约是指区块链系统在启动时预先部署的，可升级、可治理的合约，提供如权限控制、资源租赁、代币质押等基础服务。系统合约通常有以下三个特点：公开透明，无暗箱操作。可通过Env_api被用户合约调用。合约通过治理进行代码变更，无须硬分叉。系统合约可采用普通合约的实现方式，并在系统预定的合约地址部署。未来优化方向智能合约的并行执行合约并行执行是提升智能合约执行效率的一大思路。这里的并行执行并不是指单个合约方法内部的并行，而是合约间的并行。实现合约并行执行，我们需要考虑两个重要的问题：如何检测本次合约执行所访问的资源对象？如读写状态数据、读取账户余额等互斥操作。如何做合约执行的合理调度？即哪些合约能够并行执行，哪些必须串行？一种容易想到的思路是这样的：通过静态代码分析检测出合约方法可能访问到的资源，对会访问相同资源的合约调用归为同一个组。每个组的执行可以并行化，组内执行则串行化（根据交易发送顺序）。然而，实际设计时需要考虑的因素就复杂很多：如何设计一个完备的算法，准确地检测合约方法可能访问到的资源（包括跨合约调用中的资源访问）？如何设计一个高效的调度算法，将合约调用准确分组？合约并行执行后所带来的性能提升，是否能够追回以上两个算法所带来的开销？预言机预言机是智能合约获取链外数据的桥梁。这些数据通常由第三方可信数据源提供，如天气数据、赛事数据、数字货币价格等。在传统的互联网应用中，我们可以简单地通过HTTP API获取到这些数据。但在智能合约却不行，原因是HTTP调用通常是异步的，时间不可预估且不具备确定性。因此，需要一个专门的基础设施来为智能合约提供这些链外数据。预言机的设计原则中需要考虑三个要点：获取链外数据并保证数据的真实可用。以确定性、同步的方式被智能合约调用获取。预言机网络本身的安全性和可用性。隐私保护密码学的研究推动了隐私领域的创新。隐私研究主要涉及零知识、多方计算、全同态加密等领域。多方计算 MPC 允许一组人基于他们的输入进行联合计算，而不需要每个人显示其输入值。例如，Alice 和 Bob 想要知道谁拥有的比特币更多，那么在不需要他们披露自己拥有多少比特币的情况下就能达到这个目的。遗憾的是，目前多方计算的局限性在于它在实践中使用效率极低。全同态加密 (Fully homomorphic encryption) 则允许人们在加密的数据上计算。几十年来，这一直是密码学领域中的一个未解决的问题，直到 2009 年，斯坦福大学博士生克雷格·詹特利 Craig Gentry 使用「理想格」构建了第一个全同态加密方案。如果 Bob 想在 Alice 的数据上执行任意计算，比如训练机器学习模型，同时不必要求 Alice 显示明文数据，理想格加密方案就能派上用场。全同态加密和多方计算一样，目前仍然基本上停留在理论阶段，在实践中的使用效率太低。

　　通过使用Windows API来获取当前鼠标的图案，不论是系统图片还是自定义图标都能够获取到，在这个示例中，为了方便测试，给Form1添加了一个KeyPress事件，在程序激活状态下，将鼠标移动到任意能使鼠标图案不同的地方，随便按下一个按键，将会将当前鼠标图案描绘到Form1窗体中。 using System; using System.Collections.Generic; us...

《编程之美》1.10的最后提到了一个问题，就是windows中什么api能了解用户是否在使用鼠标或键盘，或者发现用户在几秒之内没有鼠标、键盘的输入？网上搜索了一下资料，觉得大概有两种方法：（1）GetInputState 函数原型: BOOL GetInputState(VOID); 函数功能:该函数确定在当前线程的消息队列中是否有要处理的鼠标,键盘消息. 注意事项:返回值指定是否发

VC/MFC

16,471

社区成员

421,732

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

VC/MFC社区版块或许是CSDN最“古老”的版块了，记忆之中，与CSDN的年龄几乎差不多。随着时间的推移，MFC技术渐渐的偏离了开发主流，若干年之后的今天，当我们面对着微软的这个经典之笔，内心充满着敬意，那些曾经的记忆，可以说代表着二十年前曾经的辉煌……
向经典致敬，或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天，我们期待着MFC技术能够恢复其曾经的辉煌，或许这个期待会永远成为一种“梦想”，或许一切皆有可能……
我们希望这个版块可以很好的适配Web时代，期待更好的互联网技术能够使得MFC技术框架得以重现活力，……

试试用AI创作助手写篇文章吧

+ 用AI写文章