为什么没有 oracle Forms 或 Reports 反编译器？（技术上）

发布于 2024-10-04 15:31:17 字数 139 浏览 7 评论 0原文

我不明白为什么我找不到这样的工具（oracle Forms或Reports反编译器）

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

有谁知道 .FMX 或 .REP 格式文件结构有什么特殊之处，导致无法为其构建反编译器？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

吖咩 2024-10-11 15:31:17

鉴于他们刚刚因 SAP 侵犯知识产权而获得 13 亿美元的赔偿，甲骨文可能不是最好的选择。公司要么拥有自己的内部开发系统，包括源代码，要么从大公司购买第三方应用程序（加上支持）。他们为后者付出了很多代价，一家大公司会三思而后行，是否会做一些非法的事情来欺骗另一家大公司。

因此，此类软件的合法市场非常小。

从技术角度来看，在 Forms 3.0 之后，“源”也不再是直接文本，因此您很难将 FMX 解码为可理解的内容，然后将其重新组装成有效的 FMB。

加上多个版本的 Forms（主要版本和单独的补丁集），创建在各种平台上运行的可执行文件。

付出很大的努力，市场很小，法律问题……

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

早在 Forms 3.0 时代，您就可以手动编辑 INP 文件（源代码，相当于 FMB），因为它们是平面文本。

当他们转向 FMB 时，我记得曾考虑将 FMB 转换为 FMT（文本格式），进行更改，然后再次返回。但转换为能被接受的 FMB 是一个问题。如果您从 .class 创建 .java，您将获得一个通过编译器运行的文件，它会告诉您源代码有什么问题（如果有的话）。 java 编译器旨在获取外部创建的内容（例如在文本编辑器中）并解析它并返回任何解析问题。

如果您手动创建 FMB 并且错误，则加载时会出错或直接崩溃。它的目的不是告诉您“源代码”有什么问题，因为它无意加载外部创建的内容。

因此构建有效的 FMB（更不用说从 FMX 构建 FMB）非常棘手。

将 FMX 解析为可读格式而不是 FMB 可能是可行的。但绝大多数 Forms 用户都会拥有 FMB，并且将 FMB 解析为可用内容的用例比 FMX 更多。并且有一些实用程序可以执行此操作（包括 Oracle 本身的 Forms-to-Apex 迁移工具，以及一些第三方应用程序，例如来自 PITSS）。

Given the $1.3bn award they just got against SAP for intellectual property infringement, Oracle are probably not the best people to pick on. Either a company has its own in-house developed systems, including source code, or they buy a third-party application (plus support) from a major company. They pay a lot for the latter and a big company is going to think twice about doing something illegal to cheat another big company.

So the legitimate market for such software would be pretty small.

From a technical point of view, after Forms 3.0, the 'source' is also not straight text so you have the difficulty of working out both decoding of the FMX into something understandable, then re-assembling it into a valid FMB.

Plus multiple versions of Forms (both major releases and individual patchsets), creating executables that run on a variety of platforms.

A lot of effort, small market, legal issues....

No resources but vague memories.

Back in the days of Forms 3.0 you could manually edit INP files (the source code, sort of equivalent of FMB) as they were flat text.

When they moved to FMB, I recall looking at converting the FMB to FMT (the text format), making changes, then going back again. But converting to an FMB that would be accepted was a problem. If you create a .java from a .class you get a file that you run through a compiler and it tells you what's wrong with the source code (if anything). The java compiler is designed to take something created externally (eg in a text editor) and parse it and return any parsing issues.

If you manually create an FMB and it is wrong it will either error on load or just crash. It isn't designed to tell you what is wrong with the 'source code' because it isn't intended to load something that has been created externally.

So building a valid FMB (let alone a FMB from an FMX) is tricky.

Parsing an FMX into a readable format, rather than to an FMB, might be doable. But the vast majority of Forms users will have the FMB and there's more use cases for parsing an FMB into something usable rather than the FMX. And there are utilities around to do this (including the Forms-to-Apex migration tool from Oracle iself, plus some third-party apps like those from PITSS).

回复收藏 0 原文