Delphi objektfähig machen

[alcaeus]

Ein Delphi-Kompilat wird immer ausschliesslich nur auf Windows laufen, fertig. Wenn du Betriebssystemunabhaengig programmieren willst, musst du dir den wahren Kern in Assembler schreiben, den Kernel des Betriebssystem in einer Systemsprache wie C, und den Rest kannst du in einer x-beliebigen Sprache schreiben. Wenn man bedenkt dass du es in Delphi schreiben willst, wirst du die ganze Windows-Umgebung in dein Betriebssystem mitnehmen muessen, weil du wirst Delphi nie dazu bringen, Kompilate fuer ein anderes Betriebssystem als Windows zu erstellen.
Weiters empfehle ich dir mal eine Suche nach "Betriebssystem programmieren" in der DP. Hier waren schon einige die ein OS programmieren wollten, den Plan aber gleich weggeworfen haben, sobald rausgekommen ist, was dazu notwendig ist

Greetz
alcaeus

[Aenogym]

hi stefan,

eie art OS in delphi proggen? ....
wie andreas schon sagte, entweder du nimmst das so hin und überlegst dir etwas anderes, oder du kaufst dir eine professional version. aber das nachbasteln der system.pas...... viel glück - wir sprechen uns in ein paar jahren wieder

...aenogym

ediT. andy war schneller^^

[stefan2005]

hi,
natürlich ist mir bewusst, dass ein OS nicht gerade einfach zu proggen ist
Es ist jetzt nur mal für den Kernel wichtig, dass, wenn dieser gestartet wird keine WinAPI Befehle aufgerufen werden.

Ich kann ein Delphi-Kompilat auch für mein OS kernel benutzen, solange wirklich keine WinAPI Befehle aufgerufen werden.
Das einzige was nötig ist, ist, dass ich einen Kernelloader habe, der den Delphi Kernel in den rbeitsspeicher läd und ausführt(was bei jedem anderen Kernel, egal ob Asm oder C, auch so ist) und die Startadresse der EXE Datei ausließt.

cu,
stefan2005

[alcaeus]

Zitat von stefan2005:

Es ist jetzt nur mal für den Kernel wichtig, dass, wenn dieser gestartet wird keine WinAPI Befehle aufgerufen werden.

Naja, irgendwas wird doch mit der API zu tun haben, z.B. die Messageloops usw. Wie ich gesagt habe, mit Delphi kannst du keinen OS-Kernel programmieren.

Zitat von stefan2005:

Ich kann ein Delphi-Kompilat auch für mein OS kernel benutzen, solange wirklich keine WinAPI Befehle aufgerufen werden.

Siehe oben: es wird nicht funktionieren.

Zitat von stefan2005:

Das einzige was nötig ist, ist, dass ich einen Kernelloader habe, der den Delphi Kernel in den rbeitsspeicher läd und ausführt(was bei jedem anderen Kernel, egal ob Asm oder C, auch so ist) und die Startadresse der EXE Datei ausließt.

Du meinst den Kernel den du in Delphi geschrieben hast? Und was soll der machen wenn er keine Messages bekommt? Dir ist schon klar damit erstmal eine exe laeuft, du die Umgebung dazu erstellen musst? Dir ist schon klar dass du erstmal ein System programmieren musst, dass mehrere Anwendungen "gleichzeitig" laufen koennen? Bevor das nicht alles funktioniert, kannst du dein Delphi getrost in Ruhe lassen

Greetz
alcaeus

[alzaimar]

Frage für Theoretiker:
Was passiert, wenn ich die System.dcu austausche, alle anderen DCU (auch die der VCL), die auf System.dcu aufbauen, jedoch nicht?

Wer kennt die Meldung:
"Das Modul Foo wurde mit einer anderen Version von Bar erstellt." (sinngemäß)

Preisfrage:
Was haben die Frage und die Compilermeldung miteinander zu tun?

[tommie-lie]

Mein Gott, was seid ihr hier eigentlich? (gemeint ist nicht Stefan )

@Stefan:
Theoretisch würde sowas funktionieren, aber du musst später immer noch das Kompilat entsprechend zurechtstutzen, da windowsspezifische Dinge enthalen bleiben. Für den Bootloader ist es *wesentlich*(!) einfacher, ihn komplett in Assembler zu schreiben, das kriegt man noch an einem Nachmittag hin. Willst du wirklich in Delphi weiterprogrammieren, brauchst du dann sehr schnell einen Programmlader, der PE-Dateien von Windows lesen und starten kann. Dein Vorhaben, die System.pas zu ersetzen ist zwar theoretisch der richtige Weg, aber damit arbeitest du dich zu tode. In der system.pas implementiert Borland sämtliche Compiler-Magic, wenn du die benutzen willst, musst du sie komplett reimplementieren. Und das ist definitiv keine angenehme Sache Mit sehr viel weniger Widerstand kommst du wirklich mit einem alternativen Compiler an dein Ziel. Ich habe mal erfolgreich mit GnuPascal (zwar 100% Inline-Assembler, aber ein unveränderter GnuPascal-Compiler) an einem Bootloader gearbeitet, den ich mangels Interesse wieder verworfen habe. Mit den GNU-Compilern kommst du also sehr weit, wenn du Lust hast. Das Problem an Delphi wird sein, daß wenn du dein System komplett darauf aufbauen möchtest, du die komplette RTL neu implementieren musst (es sei denn du willst einen API-kompatiblen Windows-Kernel nachprogrammieren). Das musst du zwar so oder so, du bist aber an sämtliche Design Flaws von Delphi und Windows gebunden.
Glaub' mir also, sowas machst du wirklich besser mit einem anderen Compiler, damit erspartst du dir das ganze zurechtgeschnippele der PEs und kannst deine eigenen Ideen sehr viel flexibler verwirklichen als mit Delphi, dessen Compiler bis zum letzten bit auf reine Windows-Programmierung ausgelegt ist.

[stefan2005]

hi,
das einzige, was Delphi mit veränderter System.pas noch Windows-Spezifisch macht, ist, dass es ein Win32-PE EXE erzeugt. Dieses Format ist aber nicht kompliziert und ich habe bereits einen Bootloader und Kernelloader, der von Diskette (mit FAT12 Support) diesen Kernel ausließt und zurechtbereitet, komplett in Assembler.

das einzige was ich halt wissen wollte ist, welche Einträge man vornehmen muss, damit auch Objekte erzeugt werden können. (aber Windows ist afaik auch nicht Objektorientiert programmiert )

cu,
stefan2005

[jbg]

ca. 1000 Zeilen für das TObject und IInterface und dann noch die Compiler-Magic Funktionen für Strings. Dazu kommt dann noch der Speichermanager New/Dispose/GetMem/AllocMem/FreeMem/ReallocMem und ein paar andere kleinere und größere Dinge. (Viel Spaß dabei )

[Phistev]

Ich würd auch sagen, TObject und alles was dazugehört. Inklusive des Memory Managers, TMethod, etc. Das ist allerdings das kleinere Übel. Wesentlich schwieriger dürfte es sein, die WinAPI-Aufrufe zu ersetzen. Mit Entfernen ist es häufig nicht getan, da diese Aufrufe ja etwas bewirken (wie Speicher zuweisen, Zugriff auf die Festplatte (FAT16, FAT32, evtl. NTFS), Ausgabe auf dem Bildschirm (Konsole / GUI)...). Bei einem Betriebssystem müsstest du das alles in C oder Assembler implementieren. Besonders beim Zeichnen auf dem Bildschirm: viel Spaß

P.S.: Bei mir (Delphi 2005 Pro) enthält die System.pas ohne Kommentare, Komplier-Direktiven und Leerzeilen 13345 Zeilen.

[malo]

Zitat von Phistev:

Wesentlich schwieriger dürfte es sein, die WinAPI-Aufrufe zu ersetzen. Mit Entfernen ist es häufig nicht getan, da diese Aufrufe ja etwas bewirken (wie Speicher zuweisen, Zugriff auf die Festplatte (FAT16, FAT32, evtl. NTFS), Ausgabe auf dem Bildschirm (Konsole / GUI)...).

Hardwarezugriffe können notfalls IMMER in Assembler gemacht werden (sofern das nicht extern verhindert wird).