我在 Windows 7 - 64位操作系统上使用 GoAsm汇编程序，我会问你一些（不是那么愚蠢）的问题。
第一个问题：
如何找到文件的实际地址？ 假设文件“Text.txt”位于我的C：\分区的根目录下。 有没有办法获得这个文件所在的确切内存地址？
第二个问题：
如果调用C函数，是否可以调用一个例程？
（即：考虑一个C函数“WriteToScreen”，是否可以使用相同的函数，但是在汇编程序格式中，这意味着无需使用高级调用来完成这项工作？
第三个问题：
网上是否有一些包含GoAsm的文件包含有用的例程，如（移动，复制，编辑，删除）命令？我首先想到的是ms-dos中断，但我无法让它们在没有崩溃程序的情况下工作。我猜它只是与Windows操作系统不兼容，即使命令提示符的行为类似于 ms-dos ......？
第四个问题：
我从不同的消息来源和我自己听说NASM在 Win7 x64 上工作得非常糟糕，这是真的，还是我做错了？
答案 0 :(得分：0)
<强> 1 从逻辑的角度来看，硬盘驱动器可以看作是一系列“块”（更常见的名称是扇区）。如何在磁盘上物理组织这些块可以被忽略，但驱动程序必须知道当然如何获取数据，尽管你发送给现代高清驱动程序“高级”命令，据你所知，这些命令并不强烈相关数据的实际位置（您可以说“阅读块123”，但没有外部证据证明该块存在于何处）。
然而，通过这种方式，您可以使用数字“命名”一个块，并说明例如块0是MBR。每个块包含几个字节（512,1024 ......）。并非所有使用的块都包含文件的实际数据，实际上存在任何类型的元信息，具体取决于文件系统，但甚至与hd的“结构”（我的意思是分区）有关。
位于高清上的文件不会自动加载到内存中，因此它没有内存地址。一旦你阅读它，如果不是所有的一部分当然都被复制到你给的内存中，这不是文件的固有属性。 （文件系统检索属于该文件的块并“显示”它们，因为我们习惯看到它们，作为单个“单元”，文件）
总结：文件没有内存地址。物理地址可以是保存文件的数据（和元数据，如inodes）的块的集合，或者只是第一个块（但如果数据块是N，则N + 1不能属于同一个块）文件 - 块不需要一个接一个就可以了。要了解它们，您必须分析您使用的文件系统的结构。我不知道是否有一个API可以轻松地检索它们，但在最坏的情况下，你可以分析文件系统的源代码......祝你好运！
<强> 2 C函数被转换为程序集。如果您尊重C调用约定，则可以直接在汇编中编写“C函数”。尝试阅读this和this for x86。
第3 您可以从asm调用Windows API。忘了MS-DOS，MS-DOS死了，MS-DOS不是Windows，cmd是一种“仿真”......确实没有，不是仿真而只是一个类似于MS-DOS用户的命令行界面被用来。但它不是同样的，即没有可以使用的MS-DOS系统中断。 Iczelion's assembly tutorials虽然陈旧，但可能是一个有趣的资源。 （如果链接过期，请尝试使用wayback machine）
<强> 4 我没有自己的Win7，也没有在Windows上安装过nasm，所以我不能说什么。
答案 1 :(得分：-1)
对于第一个问题，只需将文件拖到浏览器的地址栏中
即可