为什么没有Oracle窗体或报表反编译器?(技术上)

考虑到他们刚刚因侵犯知识产权而对SAP做出的13亿美元的裁决,甲骨文可能不是最佳人选。公司要么有自己的内部开发系统,包括源代码,要么从一家大公司购买第三方应用程序(加上支持)。他们为后者付出了巨大的代价,一家大公司会再三考虑做些违法的事来欺骗另一家大公司。

因此,这种软件的合法市场将非常小。

从技术角度来看,在表单3.0之后,“源”也不是纯文本,因此您很难同时将fmx解码为可理解的内容,然后将其重新组装为有效的fmb。

再加上表单的多个版本(主要版本和单个补丁集),创建在各种平台上运行的可执行文件。

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

没有资源,只有模糊的记忆。

在表单3.0时代,您可以手动编辑inp文件(源代码,类似于fmb),因为它们是纯文本。

当他们移动到fmb时,我记得我在考虑将fmb转换为fmt(文本格式),进行更改,然后再次返回。但是,转换成一个可以被接受的功能性营销是一个问题。如果你从.class创建一个.java,你会得到一个通过编译器运行的文件,它告诉你源代码有什么错误(如果有的话)。Java编译器被设计为采取外部创建的东西(例如在文本编辑器中),并解析它并返回任何解析问题。

如果您手动创建一个FMB,它是错误的,它将在加载时出错或只是崩溃。它不是用来告诉你“源代码”有什么问题的,因为它不是用来加载外部创建的东西。

因此,建立一个有效的fmb(更不用说fmx中的fmb)是很困难的。

将一个fmx解析为可读格式,而不是fmb,可能是可行的。但是绝大多数表单用户将拥有fmb,并且有更多的用例将fmb解析成可用的东西,而不是fmx。还有一些实用程序可以做到这一点(包括Oracle ISELF的Apex迁移工具表单,以及一些第三方应用程序,如 PITSS )

我确信你回答了你自己的问题: It's very valuable because many enterprises use oracle based systems.
对于甲骨文来说,你不能对他们的系统进行反编译也是非常有价值的。