Source aus Programm wiederherstellen

[BenderD]

Hallo,

mit Observability gabs da mal was in der amerikanischen News400:
http://www.news400.com/code/newscode/code9709.exe
ohne Observability gabs auch mal Firmen, die Decompiler oder entsprechende Dienste angeboten haben, ich weiß aber nicht, ob es da aktuell noch was gibt.

D*B,

der immer wieder staunt, wie leichtsinnig man so im AS400 und RPG Umfeld ist (wer kennt schon CVS? und Sicherung scheint auch was für Angsthasen zu sein)

Hallo zusammen,

ich habe im Forum nix zu diesen Thema gefunden..

gibt es die Möglichkeit eine Source aus einem umgewandelten RPGLE Programm wieder herzustellen???

Vielen Dank im Voraus

[holgerscherer]

der immer wieder staunt, wie leichtsinnig man so im AS400 und RPG Umfeld ist (wer kennt schon CVS? und Sicherung scheint auch was für Angsthasen zu sein)

Backup ist was für Mädchen (sorry, Damen hier im Forum ;-)
ich habe einigen Kunden angewöhnt, alle Spools per OutQ eh zur Seite zu kopieren (als Abfalleffekt der PDF-Generierung). Kann manchmal wirklich nicht schaden, wenn man kein CVS verwendet und ein Programmierer wüst den ganzen Tag 3 Zeilen ändert, compiliert, was anderes probiert, wieder compiliert und am Ende nicht mehr weiss, was das Programm eigentlich mal gemacht hat.

-h

[AS400.lehrling]

Hallo,

mit Observability gabs da mal was in der amerikanischen News400:
http://www.news400.com/code/newscode/code9709.exe
ohne Observability gabs auch mal Firmen, die Decompiler oder entsprechende Dienste angeboten haben, ich weiß aber nicht, ob es da aktuell noch was gibt.

D*B,

der immer wieder staunt, wie leichtsinnig man so im AS400 und RPG Umfeld ist (wer kennt schon CVS? und Sicherung scheint auch was für Angsthasen zu sein)

Können solche decompiler auch den kernel der i5 decompelieren, damit man mal nachschauen kann wie man einen linuxkernel schreiben müßte

Gruß AS400.lehrling

[BenderD]

- ein rpg decompiler sicherlich nicht, da das nicht in rpg geschrieben ist
- den linux kernel kann man im Quellcode bekommen und direkt einsehen, da braucht man keinen decompiler
- alles was unterhalb der C Schichtung ist, ist Assembler und Maschinencode
- Ein Decompiler kommt nie tiefer, als er selber aufsetzt

D*B

Können solche decompiler auch den kernel der i5 decompelieren, damit man mal nachschauen kann wie man einen linuxkernel schreiben müßte

Gruß AS400.lehrling

[AS400.lehrling]

- ein rpg decompiler sicherlich nicht, da das nicht in rpg geschrieben ist
- den linux kernel kann man im Quellcode bekommen und direkt einsehen, da braucht man keinen decompiler

Wenn der linux kernel direckt, sprich ab IPL laufen würde-würde ich nicht fragen

- alles was unterhalb der C Schichtung ist, ist Assembler und Maschinencode

Mit anderen Worten Statsgeheimnis von IBM

- Ein Decompiler kommt nie tiefer, als er selber aufsetzt

D*B

Das ist klar, was der decompiler nicht kennt kann er auch nicht rückübersetzen.

AS400.lehrling

[BenderD]

da is nix mit Geheimnis, Linux auf der AS/400 ist ziemlich genau dasselbe, wie Linux auf der p Series (zumindest, was das C level angeht) und es dürfte sich um eine ziemlich gewöhnliche Portierung auf C Source Ebene handeln. Das spezifische daran liegt drunter, oder steckt in dem, was man auf manchen Büchsen Treiber nennt.
Die Linux Implementierungen auf i, p, z, da muss man sich mal einen Ami vorstellen, der sich an solchen technischen Spielereien freut - und dann kommen ein paar deutsche Marketiers her, die davon nix verstehen, verkaufen das als bare Münze und das tollste ist, dass es dann Leute gibt, die es besser wissen müssten und das nicht nur glauben, sondern auch noch benutzen wollen...
Das ist so, als ob sich jemand einen Chrysler (den wollte nicht mal Simca behalten) gekauft hat und dann gemeint hat, es wäre ein Daimler... (vielleicht war das auch nur der Herr Schrempp, der den Kunden ein C für ein D vormachen wollte)

D*B

Mit anderen Worten Statsgeheimnis von IBM

AS400.lehrling

[AS400.lehrling]

da is nix mit Geheimnis, Linux auf der AS/400 ist ziemlich genau dasselbe, wie Linux auf der p Series (zumindest, was das C level angeht) und es dürfte sich um eine ziemlich gewöhnliche Portierung auf C Source Ebene handeln. Das spezifische daran liegt drunter, oder steckt in dem, was man auf manchen Büchsen Treiber nennt.
Die Linux Implementierungen auf i, p, z, da muss man sich mal einen Ami vorstellen, der sich an solchen technischen Spielereien freut - und dann kommen ein paar deutsche Marketiers her, die davon nix verstehen, verkaufen das als bare Münze und das tollste ist, dass es dann Leute gibt, die es besser wissen müssten und das nicht nur glauben, sondern auch noch benutzen wollen...

D*B

Bleibt immer noch das problem mit den einstufigen Speicher, soweit ich es zu wissen glaube verwendet nur noch die i5 das einstufen Speichermodel.

Man müßte also einen linuzkernel so umschreiben das er ebenfalls mit diesem Speichermodell arbeitet.

AS400.lehrling

[BenderD]

die Tatsache, dass linux sich nicht ohne os400 booten lässt, spricht dafür, dass linux oberhalb der Speicherverwaltung von os400 sitzt und im virtual storage von os400 arbeitet.

D*B

Bleibt immer noch das problem mit den einstufigen Speicher, soweit ich es zu wissen glaube verwendet nur noch die i5 das einstufen Speichermodel.

Man müßte also einen linuzkernel so umschreiben das er ebenfalls mit diesem Speichermodell arbeitet.

AS400.lehrling

[Fuerchau]

Wenn denn der Speicher das einzige Problem wäre.
Der einstufige Speicher ist eine unterstützung des Micro-Codes, liegt also quasi unterhalb des OS.

Verwende ich ein 32-Bit-Programm, kann ich eben max. 2^32 Bytes adressieren, nehme ich 64-Bit eben 2^64.

Dass ich den Speicher auch erhalte wird eben z.B. durch C-Funktionen wie malloc() realisiert.
In Windows-C wird durch malloc() eben die Windows-Implementation GlobalAlloc() aufgerufen, die mir dann den virtuellen Speicher zur Verfügung stellt (oder, wenn die Pagefile zu klein ist, eben einen Fehler auslöst).

In der AS/400 ist eben jede Adresse (Pointer) auf 128-Bit ausgerichtet und deshalb kann das MI-Äquivalent des malloc() mir virtuellen Speicher (egal wo dieser liegt) liefern.

Was du also machen kannst, ist eben per AS/400-C-Compiler einen Linux-Kernel zu erstellen, wobei du alle "Hardware"-spezifischen Funktionen durch eigene Treiber noch entwickeln musst.

[BenderD]

heißt doch nur, dass ein 32 bit Kernel von Linux die Speicher Variablen in 32 bit anlegt und ein 64 bit Kernel das in 64 bit tun muss.
Wenn ein Linux auf OS400 draufhockt, dann liegt zwischen Hardware und dem Linux Kernel noch der MI Kernel (das ist nicht dasselbe, wie MI!!!) und der Speicher in dem dieses Linux zu arbeiten glaubt ist virtual storage von OS400 (mit der Konsequenz, dass alle Hardware Treiber gefummelt werden müssen).
Hockt das Linux auf einer i direkt auf p (was wohl kaum wirkungsvoll abgeklemmt ist, weil das eh keiner tut - warum soll ich den MI Kernel für sehr viel Geld mitkaufen, wenn ich ihn n i c h t haben will), dann greift er direkt auf die Hardware (genauer gesagt, auf die dafür vorgesehene Schichtung, denn auch die hat ein MI - bei Intel Büchsen hat man das mal BIOS genannt).
Das einzige, wo IBM ein wirkliches Interesse am zunageln hat, ist dass man das OS/400 nicht direkt auf der p Hardware zum laufen kriegt. Die hierfür verwendeten Nägel sind dann Lizenzrecht, vielleicht ein paar Eproms und ein paar Fallstricke.

D*B

Wenn denn der Speicher das einzige Problem wäre.
Der einstufige Speicher ist eine unterstützung des Micro-Codes, liegt also quasi unterhalb des OS.

Verwende ich ein 32-Bit-Programm, kann ich eben max. 2^32 Bytes adressieren, nehme ich 64-Bit eben 2^64.

Dass ich den Speicher auch erhalte wird eben z.B. durch C-Funktionen wie malloc() realisiert.
In Windows-C wird durch malloc() eben die Windows-Implementation GlobalAlloc() aufgerufen, die mir dann den virtuellen Speicher zur Verfügung stellt (oder, wenn die Pagefile zu klein ist, eben einen Fehler auslöst).

In der AS/400 ist eben jede Adresse (Pointer) auf 128-Bit ausgerichtet und deshalb kann das MI-Äquivalent des malloc() mir virtuellen Speicher (egal wo dieser liegt) liefern.

Was du also machen kannst, ist eben per AS/400-C-Compiler einen Linux-Kernel zu erstellen, wobei du alle "Hardware"-spezifischen Funktionen durch eigene Treiber noch entwickeln musst.

[holgerscherer]

Das einzige, wo IBM ein wirkliches Interesse am zunageln hat, ist dass man das OS/400 nicht direkt auf der p Hardware zum laufen kriegt. Die hierfür verwendeten Nägel sind dann Lizenzrecht, vielleicht ein paar Eproms und ein paar Fallstricke.

D*B

Ein Stapel Papier, ein EEPROM und keine Doku, wo man fummeln müsste ;-) Ähnlich damals die Karten für interaktive Kapazität.

Aber ich frage mich immer wieder, warum man sich einen Akt machen will, Linux direkt und ohne Umwege auf der teuren iHardware laufen zu lassen. Man gewinnt ja nichts.

-h

[AS400.lehrling]

Ein Stapel Papier, ein EEPROM und keine Doku, wo man fummeln müsste ;-) Ähnlich damals die Karten für interaktive Kapazität.

Aber ich frage mich immer wieder, warum man sich einen Akt machen will, Linux direkt und ohne Umwege auf der teuren iHardware laufen zu lassen. Man gewinnt ja nichts.

-h

Ist bei mir so en bischen Hey schaut mal her es geht doch

Ein unterschieb in sachen Funktionalität und efektivität ist auf einer B35 eh nicht zu erwarten bzw nicht tragisch

Gruß AS400.lehrling