Delphi objektfähig machen

[Phistev]

Zitat:

Zitat von malo

Zitat:

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

Mit dem Wissen kann ALLES in Assembler geschrieben werden: Bildschirmausgaben, Verarbeitung von Tastatur- und Mauseingaben, Drucken, Soundausgabe, Zugriff auf Laufwerke, etc. Dieses Wissen (u. a. über die Interna das Mainboards und die des Prozessors) hat nur keiner. Deshalb gibt es Programmiersprachen wie C oder Delphi und die APIs.

[tommie-lie]

Zitat:

Zitat von Phistev

Bildschirmausgaben, Verarbeitung von Tastatur- und Mauseingaben, Drucken, Soundausgabe, Zugriff auf Laufwerke, etc. Dieses Wissen (u. a. über die Interna das Mainboards und die des Prozessors) hat nur keiner. Deshalb gibt es Programmiersprachen wie C oder Delphi und die APIs.

Du vielleicht nicht...
Insbesondere für die erstgenannte Liste an allerlei Hardwarezugriff gibt es fest definierte Standards, die sich jeder durchlesen kann. Und die Interna des Mainboards interessieren mich auch nicht, die implementieren ein Interface und das spreche ich an, mehr will ich gar nicht wissen. Genauso wenig interessiert mich, wie der Prozessor nun 1+1 rechnet, mir reicht, daß er es rechnet.

Und insbesondere bezüglich der Programmiersprachen, die du am Ende aufführst, verweise ich hier mal auf Dieter Nuhr ;-)

@Stefan:

Zitat:

Zitat von stefan2005

das einzige was ich halt wissen wollte ist, welche Einträge man vornehmen muss, damit auch Objekte erzeugt werden können.

Prinzipiell TObject implementieren. Dafür würde ich dir aber dringend die Besorgung der RTL-Quellcodes (Delphi ab Professional Edition) anraten (ein altes Delphi3 tut's da auch und ist bei eBay sicherlich günstig zu bekommen), da Teile des Speichermanagers und viel Rundrum (TObject implementieren selbst bringt nämlich nichts, du musst ja auch die Funktionalität zur Verfügung stellen) pure Magic sind und als solche auch viele Magic Symbols benutzen, die du dir am besten aus dem Quellcode zusammensuchst.

[mael]

Zitat:

Zitat von alcaeus

Ein Delphi-Kompilat wird immer ausschliesslich nur auf Windows laufen, fertig.

Leider falsch. Schau Dir mal http://www.dwp42.org/ an.
Außerdem hat man, wenn man die System.pas auf das Nötigste kürzt, schon eine Möglichkeit. Z.B. kann man Delphi .obj-Dateien erzeugen lassen, und dann mit speziellen Tools daraus eine Flat-Binary (also ohne PE-Header und Co machen). Sonst könnte man auch noch versuchen aus einer EXE den Code-Teil zu extrahieren, und die Basis-Address auf 00000000 anstatt 00400000 zu setzten.

Zitat:

Zitat von alcaeus

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.

C hat BS-Programmierung nicht gepachtet. Mit Freepascal geht sowas recht gut. Ein Minimalprogramm das was auf den Schirm schreibt nachdem es von einem in Assembler geschriebenen Bootloader geladen wurde ist sehr leicht zu machen. (siehe z.B. das Delphine-Projekt)


@stefan2005: Ich habe auch mal probiert das mit Delphi zu machen, aber es gibt zwei Gründe warum ich aufgegeben habe:
1.) Ich werde Delphi auf dem neuen OS nicht neu kompilieren können und daher keine nativen Module oder nativen Treiber erstellen können. Zwar könnte man einen PE-Patcher schreiben oder PE selbst verwenden, aber das schränkt doch sehr stark ein.
2.) Die Übersetzung der System.pas ist sehr sehr sehr aufwändig. Die Windows-API Aufrufe sind nicht so sehr das Problem, sondern eher daß viele Funktionen in der System.pas ein fertiges BS mit vielen Highlevel Funktionen vorraussetzen und daher kaum Kernelmodule erstellt werden können. Was im Moment keine Probleme macht weil es fehlt, wird nach Erweiterung des Programms/Treibers dann doch gebraucht.
Noch ein Problem: Viele Funktionen setzten den User-Modus(also Ring 3) wo der Speicher geschützt ist vorraus, z.B. um fehlerhafte Pointer zu erkennen (erste 64 KB sind immer geschützt, Pointer in diesem Bereich=Zugriffsverletzung). Diese Vorrausetzungen sind im Kernel-Modus alle unangenehm und potentiellen Fehlerquellen.

Fazit: So schön es wäre den Delphi-Compiler zu verwenden, meiner Meinung nach ist FreePascal hier besser geeignet. Natürlich ist es möglich Delphi-Kompilate zu verwenden, aber ich frage mich ob der Arbeitsaufwand sich lohnt. Außerdem müßtest Du Dir die Professional kaufen, denn den SoureCode darf man nicht weitergeben.

[malo]

Wegen der implementierung von TObject: Der Freepascal-Compiler muss doch imho genau das auch implementieren und ist OpenSource. Es muss also keine Delphi-Pro gekauft werden, sondern nur die entsprechenden UNits (eventuell mit dem Compiler) runtergeladen werden.

Wenn du dir nur den Source als "Gedächtnisstütze" ansehen willst, kannst du dir imho auch eine Delphi-Trial runterladen und dir die Sourcen ansehen. Ich weiß jedoch, wie legal das ist ;)

[stefan2005]

hi,
das mit Freepascal ist ne gute Idee.
Aber in einer Delphi Trial sind doch sicherlich nicht die Sources dabei, oder ?

cu,
stefan2005

[malo]

Zitat:

Zitat von stefan2005

Aber in einer Delphi Trial sind doch sicherlich nicht die Sources dabei, oder ?

Doch, imho sind sie schon dabei. Ich hab nur grade keine Trial installiert, sodass ich nicht nachsehen kann. Ich meine mich aber erinnert zu haben, bereits mit den Sourcen rumgespielt zu haben ;)

[Robert_G]

Zitat:

Zitat von malo

Ich meine mich aber erinnert zu haben, bereits mit den Sourcen rumgespielt zu haben ;)

kannst mir ja per PN schicken was du da eingenommen hast und woher ich es kriegen kann. :mrgreen:
Natürlich sind da keine Saucen bei. ;)

[Traudix]

Hallo Stafan2005!

Stöbere grad hir bissl rum und finde diesen Thread. Ich kann Dir die Objects Unit aus Freepascal anbieten, nach Delphi portiert.

Zitat:

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

Es gibt doch auch für DOS gute Grafikbibliotheken. ZB.:

VenomGFX (go32 Version)

gfx (Leider nur Turbo Pascal und damit 16 Bit)

grx (Leider mit Borland C++ 4.5 als .lib vorcompiliert. Freier BCC++ Compiler hat Version 5.5)

Da mich das Problem auch interessiert, werde ich mich mal mit VenomGFX beschäftigen. Deren Funktionen werden nach folgendem Muster aufgerufen:

VenomGFX-Funktion(Festerdatenstruktur,Koordinaten);
Koordinaten :: x1,y1,x2,y2
Fensterdatenstruktur :: Bei VenomGFX ein Record

Warum sollte es da nicht möglich sein, das Windows API nachzubilden. Und zwar mit Hilfe so einer Grafikbibliothek. Das Handle, das bei der Windows API statt der o.g. Fensterdatenstruktur mit übergeben wird, kann doch auf diese Datenstruktur zeigen.

Beispiel:

Delphi-Quellcode:

FensterDatenstruktur = record
  ... die Definition der Struktur
end;


WINAPI
function PutPixel(Handle: THandle; x,y: Integer);
var var_Fensterdatenstruktur: Fensterdatenstruktur absolute Handle;
begin
   VenomGFX_PutPixel(var_Fensterdatenstruktur,x,y);
end;

Mag sein, das unter Windows das Handle wirklich nur eine Fensternummer darstellt. Wie ich aber bis jetzt das Windoes API verstanden habe, muß ich doch ohne VCL eine Fensterklasse registrieren indem ich eine Datenstruktur mit Anfangswerten belege und dann das Fenster mit diesen Anfangswerten erzeuge. Also ist doch das Handle wohl doch eher die Anfangsadresse dieser Struktur. Deshalb bin ich fest davon überzeugt, das ich mit einer geeigneten Grafikbibliothek, nehmen wir doch gleich vVenomGFX, das API nachgebildet werden kann.

Ich habe mal die VenomGFX Bibliothek rangehangen. Außerdem die auf Delphi portierte Objects.pas, die ja für Freepascal freigegeben ist. Außerdem die Units Dos und Dpmi, die von der nach Delphi portierten go32 Unit verwendet werden. Dos und Dpmi stammen aus dem WDosX Projekt von Michael Tippach.

Die Moderatoern bitte ich, die angehangenen Quelltexte in der Delphi Praxis verfügbar zu machen.

Viel Erfolg wünscht Dir

Traudix

[stefan2005]

hi,
Vielen Dank ! :-D
ich werds mir dann morgen mal genauer anschauen !

cu,
stefan2005

[Traudix]

Hallo Stefan2005!

Hier noch eine Datei, die ich vorhin vergessen habe, mitzuliefern. Die brauchst Du, um die Objects.pas erfolgreich zu übersetzen. Ich hoffe, das läuft dann. Habe nämlich die portierten Units noch nicht weiter getestet. Soweit ich weiß, brauchst Du für go32 die cwsdpmi.exe, die aber bei Freepascal für DOS dabei ist. Sonst findest Du die auch im Internet.

So, und nun noch einmal die grf.zip, ergänzt um die fehlende .inc Datei, die Objects.pas noch haben will. Es ist WDosGetmem.inc

Dann müßte es eingentlich funzen.

Traudix