7zip除了官方下载安装的图形界面工具之外，是有独立控制台程序的，在CPP\7zip\Bundles里面。这个控制台程序还分为全功能版（7zz）的和精简的（7zr），但官方那边能下载到的只有精简的，全功能的那个要自己编译。
在用VS2022编译全功能版的时候我遇到了问题。虽然官方提供了nmake用的编译脚本，但是它跑起来总是报错，而且报错的地方在Windows SDK里面、而不是7z自己的代码。报的错误是C2279，出现在mapi.h头文件里、诸如“这个typedef地方不能写throw标识符”这样的东西。
网上搜索之后能找到的相关的东西不太多，有一个说法是C++标准的问题，现在的Windows SDK需要配合新版本的C++标准（C++17之类）才能正常使用。看了一下7zip源码里nmake脚本加的参数，也确实没有指定标准。
本来想试试换个旧版的Windows SDK行不行，一看要下载那么多东西……烦了，就没试。最后我的做法是，打开CPP下的Build.mk，找到定义 CFLAGS 的那一行，加个 /std:c++17。文件是只读的，要去掉只读属性才能保存。再编译会变成另外的错误，报异常规范不匹配。最简单的去掉警告视为错误（搜索，去掉-WX）可以编译通过。
另外我发现它没加链接时代码生成这样的优化，暂时不知道为什么。试着开了一下，用7zz b看跑分，和不开看不出区别。
要说为什么写这篇，大概只是希望它能“有用”吧。 继续阅读Windows动态链接库简介 →
相信用 Windows API 写过重定向子进程的标准输入输出的人都弄过这东西。大概过程是不难，不过对初学者坑很多。几年前我写了个文大概说这个的 http://blog.sorayuki.net/?p=85 ，现在要说的也是这个话题，不过是另外的事。
之前的经验是这样的，比如我有一个进程，这个进程要开个子进程、并且发数据给子进程。那么做法是创建一对匿名管道，把管道读的那一端拿去给子进程，写的这一端自己留着。容易出错的地方在这个“自己拿着”和“拿去给子进程”。拿去给子进程可以理解为，这个句柄要设置成可继承的，子进程开启以后就带着这个句柄了，那么自己进程拿着的就可以关掉（CloseHandle）了；自己拿着，那么字面意思就是不继承给子进程了。API函数CreatePipe有个 SECURITY_ATTRIBUTES 参数，这个结构体里是可以设置创建的管道句柄能不能继承的，要么两个都能继承要么两个都不能继承。但是现在要的是写的那个不继承、读的那个继承。做法不止一种，不过思路是这么两个，一个是创建的时候两个都不能继承，然后把其中一个改成可以；另一个是创建的时候两个都能继承，然后把其中一个改成不行。改继承属性可以用 SetHandleInformation 也可以用 DuplicateHandle 复制一个能/不能继承的新句柄出来、随后把原来的关掉。我现在是用 SetHandleInformation 的方法，DuplicateHandle 的方法已经忘记是在哪里看的了，现在也不知道怎么比较好坏和必要性。
复杂一点的场景，是我要起两个进程，第一个进程的输出给第二个进程的输入。麻烦一点的办法可以两个都和自己通信、自己在中间做转发；简单的办法可以直接创建一对管道，一个子进程分一个、自己不留。现在这里要说的是后者，复杂性一个表现在管道是自己创建的，但是自己在起了子进程之后一个都不留；另一个表现在要刚好一个进程继承一个，如果有一个进程继承了两个，比如写的那一端一不小心两个进程都继承了，那么很不幸这一对进程永远跑不完了：写入数据的那个子进程写完了关掉了这个写入端，但是由于读取数据的那个子进程也持有这个写端，自己有自己都不知道，也就是说这个写端没法全部被关闭，那么读的那一端就永远在等待了。
虽然上面那个例子只要搞清楚关系、小心操作的话，也没有那么大问题。不过麻烦的事情在，假设我现在是一个有好几个线程在同时执行的程序，在其中一个线程A里，要调用 CreateProcess 的时候，它不知道其他线程比如B有没有创建什么会被继承的句柄，假设这个时候线程B也在调用 CreateProcess，那么线程B创建的这个子进程会把线程A创建的那些句柄也一起继承走。然后问题呢就会出在刚才说的那个场景上，比如一对管道，读取端永远阻塞因为写入端没有全部被关闭。也许会觉得这样的场景只要在要创建子进程的时候锁个整个进程范围的锁就好了，但如果这里面调用了什么第三方库，或者是工程上好多人同时开发一个项目，有些事情就不一定有那么可控了。而且这种Bug还可能在极偶然的情况下才会遇到那么一两次，调试的时候难以重现十分痛苦……啊别说了，害怕。
继续阅读Windows下控制子进程的句柄继承 →
标题之所以那么复杂是因为我把本来应该分开写的东西弄在一起了……
这些事情都是在公司里工作（或者摸鱼？）的时候遇到的。有的记下来了有的没有。记下来的这几个，本来说要写到博客上的，结果丢在桌面的便签上这么久了，现在已经从那家公司离职，又入职新的公司做了一年半，这便签上记录的东西一个都还没写。都是两年前的事了吧
继续阅读返回值优化没了 / FPU爆栈 / 线程池疯长 / 连接被重置 →
今天晚上尝试帮某网友制作一个伪春菜的插件，能够检查两次调用过程中剪贴板里面的东西有没有变化（用GetClipboardSequenceNumber函数）和获取剪贴板里的内容（EnumClipboardFormats和GetClipboardData）。这里都不是重点，重点是我用了 这一篇博客 里面提到的CSaori库来编写。这个库里面的字符是wchar_t类型，这很好，也用了std::basic_string<wchar_t>（其实就是std::wstring），这也很好。不好的地方在于，我为了减小最终DLL的体积、用Windows Driver Kit里面的编译器来编译程序使得动态链接到运行库的时候，报错了。
继续阅读WindowsDDK里用std::wstring的问题 →
还是接着之前那篇关于制作导入库的工具的后续。另一种方法，虽然局限性更大，但是可以满足大多数情况了。
继续阅读编辑VC生成的导入库文件 →
调用DLL早不是什么新话题了。从LoadLibrary和GetProcAddress配合使用的动态加载，到链接导入LIB的静态加载，方法很多。LoadLibrary和GetProcAddress的方法虽然麻烦但是很通用，毕竟调用系统API就可以了，DLL名和函数名和都是字符串形式。导入LIB方式的话，生成DLL的时候会带一个LIB给你，拿来用即可。
后一种方法很方便。这里主要也是讲后一种。
继续阅读自制导入DLL用的LIB文件 →
.net下又写界面又写多线程的一定知道InvokeRequired（CheckForIllegalCrossThreadCalls党退散……）。我说个笑话，昨天被这东西坑了一下。……
继续阅读InvokeRequired大坑爹 →
我是为了证明“这种东西其实我也可以写得出来的！”吗？
感想：用WM_TIMER定时实在是不够准，偏差太大。最后还是换了WaitableTimer
继续阅读贪食蛇 →
根本不是什么新技术，也不是什么新应用，只是嫌麻烦，所以……
继续阅读GetProcAddress给函数指针赋值 →
现在域名是 blog.sorayuki.net ~