为什么没有oracle Forms或Reports反编译器？(在技术上)

Question

我无法理解为什么我找不到这样的工具(oracle Forms或Reports反编译器)

它非常有价值,因为许多企业使用基于oracle的系统.

有谁知道.FMX或.REP格式文件结构中有什么特别的东西阻止为它们构建反编译器？

Answer 1

鉴于他们刚刚针对SAP侵犯知识产权而获得了13亿美元的奖励,甲骨文可能并不是最好的人选.公司有自己内部开发的系统,包括源代码,或者他们从一家大公司购买第三方应用程序(以及支持).他们为后者付出了很多,一家大公司会考虑采取非法行动来欺骗另一家大公司.

因此,此类软件的合法市场将非常小.

从技术角度来看,在Forms 3.0之后,'source'也不是直文,所以你很难将FMX的解码解析为可理解的东西,然后将其重新组装成有效的FMB.

加上多个版本形式(包括主要版本和个别补丁集)的,创建在各种平台上运行可执行文件.

很多努力,小市场,法律问题....

没有资源,但模糊的记忆.

回到Forms 3.0的时代,您可以手动编辑INP文件(源代码,相当于FMB),因为它们是平面文本.

当他们搬到FMB,我记得在看转换FMB到FMT(文本格式),进行更改,然后再回去.但转换为可接受的FMB是一个问题.如果从.class创建.java,则会得到一个通过编译器运行的文件,它会告诉您源代码有什么问题(如果有的话).Java编译器旨在利用外部创建的东西(例如,在一个文本编辑器),并对其进行解析,并返回任何解析问题.

如果你手动创建一个FMB并且它是错误的,它将在加载时出错或者只是崩溃.它的目的不是要告诉你什么是错的"源代码",因为它不打算装入已外部创建的东西.

因此,构建有效的FMB(更不用说来自FMX的FMB)非常棘手.

解析FMX成可读的格式,而不是一个FMB,可能是可行的.但是绝大多数Forms用户都会拥有FMB,并且有更多的用例可以将FMB解析成可用的东西而不是FMX.并且还有一些实用程序可以执行此操作(包括来自Oracle iself的Forms-to-Apex迁移工具,以及一些来自PITSS的第三方应用程序).