写着玩-系统调用与API
0x00 口胡
这本书快完了，加快效率。。。
0x01 系统调用
由于系统有限的资源有可能被多个不同的应用程序同时访问，因此，如果不加以保护，那么各个应用程序难免产生冲突。现代OS采取的策略是将这些可能产生冲突的系统资源给保护起来，然后给我们提供相应的接口去让我们按照OS所能接受的范围去操纵这些资源，这些接口就是所谓的系统调用。系统调用是较底层的接口，我们所写的用户层的程序以及运行库这种，它的一些函数都是对系统调用的封装。当然，我们可以直接使用系统调用
系统调用往往通过中断来实现，比如linux使用0x80号中断作为系统调用的入口，windows采用0x2e号中断作为系统调用入口。
对于windows来讲，系统调用实际上不是它与应用程序的最终接口，而是API，我们暂可以把API与系统调用等同起来，API的数量从最初的450个增加到了现在的数千个。
对于linux来说，系统调用由0x80中断完成，各个通用寄存器用于传递参数(如我们熟悉的用EAX传递功能号)我们完全可以绕过glibc的fopen、fread、fclose(这些函数也是封装的系统调用)打开读取和关闭文件，而直接使用open()、read()和close()来实现文件的读取，就不举例了。
我们可以使用linux的man命令查看每个系统调用的详细说明，比如查看read(参数2表示系统调用手册)：1
$ man 2 read
系统调用的弊端
不到万不得已，不要直接用系统调用写程序，使用不便和不跨平台(不兼容)
运行库已经帮助我们把系统调用给封装好了，C语言的标准库是跨平台的，就是说他会把平台的差异(即使系统调用符号、实现不同)给屏蔽掉，提供给我们统一的接口，这个接口是统一的功能：
感谢写C标准库的人，使他们使我们的编程变得简单。但是为了保证跨平台性，它只能取所有的平台，所有的OS都支持的功能
关于中断的详细分析，可以去看我写的两篇OS相关的，这里就不啰嗦了。
linux的新型系统调用机制
关于dd命令
也就是说想要dump内存的话，可以通过dd命令，借助/proc/pid/mem的内存快照来达到dump pid对应进程的任意地址处的内存内容
0x02 Windows API
没有什么是加层解决不了的，如果有，就再来一层
Windows API 是指Windows操作系统提供给应用程序开发者的最底层的、最直接与Windows打交道的接口。Windows操作系统下，CRT是建立在Windows API之上的，另外还有很多对Windows API的各种包装库，MFC就是很著名的一种以C++形式封装的库。
其中有一个头文件”Windows.h”包含了Windows API的核心部分，只要我们在程序里面包含了它，就可以使用Windows API的核心部分了。
模块相当于在API的基础上又封装了一层，从而提供更加集成化的功能。
API的核心就是：
不管内核如何改变接口，只要维持API层面的接口不变，理论上所有的应用程序都不用重新编译就可以正常运行，这也是Windows API存在的主要原因，解决兼容性的问题就交给具体的API实现了，我们只需要最后的API接口，我们只需要知道这个接口可以达到什么样的目的就ok了。
0xFF 最终结
此书的最后一章主要讲解了如何去实现一个自己的迷你运行库(miniCRT)，以及在最初的架构上如何对其进行扩展，对此没什么兴趣，所以就不谈这一章了。
后面还有一些手册类的东西，比如ELF文件结构中的常见段的一个简要功能介绍，GCC(编译器)命令行参数参考、ld(GNU链接器)命令行参数参考、objdump(GNU目标文件可执行文件查看器)命令行参数参考、cl(MSVC编译器)命令行参数参考、link(MSVC链接器)命令行参数参考、dumpbin(MSVC的COFF/PE文件查看器)
到这，程序员的修养大法这本书就算做完笔记了，也算是给了自己一个交代。
挺不错的一本书，讲了很多理论干货，也算是自己读的比较认真的一本书了。
接下来会去读其他的书，毕竟书是有体系的，跟着书学也能够让自己沉下心来，光看帖子，浏览网站学习容易浮躁，果然还是要打牢理论基础。
接下来的计划就是读C++反汇编与逆向分析这本书，挑战是在最短的时间内干完此书，继续人丑就该多读书系列。
就酱。
