为什么没有Oracle Forms或Reports反编译器? (技术上) [英] Why there is no oracle Forms or Reports decompiler ? (Technically)

问题描述

我不明白为什么找不到这样的工具(Oracle Forms或Reports反编译器)

I cant understand why I can't find such tool (oracle Forms or Reports decompiler)

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

It's very valuable because many enterprises use oracle based systems.

有人知道.FMX或.REP格式的文件结构中有什么特殊之处，可以防止为他们构建反编译器吗?

Does anyone know what's special in the .FMX or .REP format files structure that prevents building a decompiler for them ?

推荐答案

鉴于SAP刚刚因侵犯知识产权而获得SAP赔偿13亿美元，Oracle可能不是最好的选择.公司要么拥有自己的内部开发系统(包括源代码)，要么从大公司那里购买了第三方应用程序(加上支持).他们为后者付出高昂的代价，一家大公司将对做某件事以欺骗另一家大公司进行三思而后行.

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.

从技术角度来看，在Forms 3.0之后，源"也不是纯文本，因此您很难将FMX解码为可以理解的内容，然后将其重新组装为有效的FMB.

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.

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

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.

在Forms 3.0时代，您可以手动编辑INP文件(源代码，相当于FMB)，因为它们是纯文本.

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.

当他们移至FMB时，我记得曾在考虑将FMB转换为FMT(文本格式)，进行更改，然后再返回.但是转换为可以接受的FMB是一个问题.如果从.class创建.java，则将得到一个通过编译器运行的文件，它会告诉您源代码出了什么问题(如果有的话). Java编译器旨在接受外部创建的内容(例如，在文本编辑器中)并进行解析，并返回所有解析问题.

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.

如果您手动创建FMB，但它是错误的，它将导致加载错误或崩溃.它并非旨在告诉您源代码"有什么问题，因为它并不打算加载外部创建的内容.

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.

因此，构建有效的FMB(更不用说FMX中的FMB了)是很棘手的.

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

将FMX解析为可读格式而不是FMB可能是可行的.但是绝大多数Forms用户将拥有FMB，并且有更多的用例将FMB解析为可用的内容而不是FMX.周围有很多实用程序(包括Oracle iself的Forms-to-Apex迁移工具，以及一些第三方应用程序，例如

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).

这篇关于为什么没有Oracle Forms或Reports反编译器? (技术上)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！