易水的专栏

一个小毛病的解决：编译器报连接错误：LINK: fatal error LNK1561: entry point must be defined通常的原因是未指定平台或者未定义入口函数解决方案是增加相关定义 /subsystem:windows /entry:mainCRTStartup 即可不过有种比较少见的场景是编译参数缺少/c。在编译命令栏加上即解决具体细节参考https://www.cnblogs.com/shines77/archive/2013/08/10/324962.

继续研究压缩文件，我又崩溃了。压缩文件以16个簇为单位进行压缩，按压缩后的数据的尺寸分配磁盘空间，然后配上相应的稀疏流，形成完整的单元描述。比如，某16簇数据压缩之后只占用7个簇，系统从卷的210H簇起分配了7个簇，那么其描述如下：21 07 10 02 01 09因为不同的数据压缩率不同，对于某些类型的数据，可能压缩之后的尺寸反而大于压缩前，因此，对于此类数据，直接写入磁盘反而提高效

最近研究写NTFS驱动下的读写压缩/稀疏文件功能的时候被微软雷到了。真不愧“微软让事情变得复杂 (Microsoft make things complicated)”的传闻。压缩/占位流描述组居然可以分别存放到两个属性中.......彻底囧掉了......为了省几个字节的空间，代码复杂度起码提高一个数量级，犯得上么....... 然后又发现一个更囧的情况：NTFS属性中的流可以被

研究NTFS很久了，一直以来看到的NTFS分析资料都声称NTFS的目录结构是B+树，甚至连wiki上关于B+树的条目里都标明NTFS使用B+树。但昨天翻了一下严蔚敏的《数据结构》才发现按照数据结构的定义，NTFS的目标结构应该是B-树。因为按B+树的概念，所有的数据都能在叶子节点上找到，而明显NTFS的目录结构不是这样的。真不明白这些人是怎么写资料的。 PS：反倒是百度百科里说NT

要进入一个密室，先要找到它的钥匙才能打开房门。　　要访问一种文件系统，也需要一把钥匙，而引导记录就是文件系统的钥匙。让我们从分析NTFS的引导记录来开始壮丽的NTFS文件系统探密吧。　　NTFS引导记录占用8个扇区，它由3个部位组成　　一。　兼容FAT/HPFS的标准分区记录　　二。　NTFS分区记录　　三。　NTFS引导代码 第一部分：标准分区头偏

1。除非是预编译头文件，否则不要在头文件中引用别的文件2。每个对齐预编译命令要确保作用域只对需要的范围有效(比如仅对本文件内，或特定结构)3。每个内存问题的报告，肯定意味着代码有问题，必须仔细检查

一种Windows下一种Windows下探测野指针的方法在一个大型项目中遇到了crt报告HEAP: Free Heap block XXXXXXXX modified at YYYYYYYY after it was freed。原因很明确：野指针，但是因为项目里大量使用了智能指针，因此要定位问题就略头痛了。最初是准备在程序运行时建立内存断点以监视所有对YYYYYYYY的写操作