神秘编译的（BASIC？）遗留程序

Question

我有一个遗留程序，我假设是用 BASIC 编写的（一个以 .bas 结尾的文件）。好像已经编译过了！当在十六进制编辑器中打开时，字符串和注释都是可读的，而完成计算的部分则不可读。 AFAIK，BASIC 是一种解释语言。

问题：

Answer 1

对于老式 BASIC 程序，编译和标记化之间存在差异。编译将 BASIC 代码转换为机器代码，并且通常会以文件扩展名存储，表明代码应该直接运行而不是解释；通常，此扩展名是“.BIN”的某种变体。至少在个人电脑上，编译通常需要第三方软件将 BASIC 语句转换为机器代码。

虽然 BASIC 程序通常可以保存为直接 ASCII，并且 BASIC 语句完全由其文本表示，但大多数 BASIC 默认情况下都会对保存的程序进行标记。标记化文件通常以 .BAS 文件扩展名的某些变体保存。

标记化通常是将 BASIC 语句/函数一对一转换为该语句或函数的一字节或两字节代码。这节省了系统空间；较旧的个人计算机上的磁盘空间和 RAM 都有限。但它也使系统更容易地动态运行代码（解释它）并且使解释速度更快。

如果没有标记化，例如，Radio Shack Color Computer 的 Extended Color BASIC 中的

RESET

和

RESTORE

之间的差异只有在比较第四个字符时才会显示出来。通过标记化，差异会在比较第一个字符（9D 与 8F）时显现出来。

去标记化，或者从标记到语句的文本表示的转换，只是简单地颠倒了这个过程。每次用户列出该程序时都会执行此反转。在现代计算机上，去标记化程序应该能够轻松地用任何现代脚本语言编写。只要您知道格式，去标记化只需逐字节检查标记化文件并将标记转换回其等效的 BASIC 语句或函数即可。

例如，bascat声称要对 GW-BASIC 进行去代币化。

这是一个标记化的例子；我使用 TRS-80 Color 计算机的扩展颜色 BASIC，因为我有易于使用的工具来对其进行标记，但基本思想对于大多数老式 BASIC 来说是相同的。

（有点无意义的）BASIC 程序：

10 RESET(14,15)
20 RESTORE

标记化文件的十六进制转储：

00000000  26 0b 00 0a 9d 28 31 34  2c 31 35 29 00 26 11 00
00000010  14 8f 00 00 00                                  
00000015

前两个字符是下一行的地址；当从文件中去标记时，如果您的特定语言使用这些地址，您可能会忽略这些地址。（它们主要用于运行代码：例如，如果一行中有 GOTO 60，解释器可以找到第 60 行，而无需解释标记来到达那里。）

后两个字符是行号：000A 是 10。下一个字符 9D 是

RESET

的标记化。那么，28 是左括号的 ASCII 值，31 是“1”，34 是“4”（即 14 作为

RESET

的第一个参数；2C 是逗号，31 和 35 是 1 和 5第二个参数到

RESET

，29是右括号，00是行尾。

接下来的两个字符是下一行的地址，0014是第二行的行号：14是20的十六进制。最后，8F是

RESTORE

的标记，00结束该行，最后两个零结束程序。

Answer 2

这是一个简单的 LINE.BAS，保存在 QB45 十六进制转储中。

我不认为 QB45 编码与 GW-BASIC 编码类似，我的猜测是它有第二层，因为我无法理解它。另外，中间全是 0，它似乎没有以任何方式压缩，看起来更像是编译器可能生成的东西，或者故意混淆的东西（因为数据代码比文本代码有更多字节） .

有人可以请比尔·盖茨进来吗？