Delphi objektfähig machen

[stefan2005]

hi,
für mein Projekt habe ich eine eigene System.pas, also nicht die System.dcu von Borland.
Aber was muss ich in die System.pas alles reinschreiben bzw hinzufügen, damit ich Klassen und Objekte benutzen kann ?

(ich benutze Delphi 6 PE -> hab keinen Source von System.pas o.ä.)

cu,
stefan2005

[Insider2004]

komische Frage. D ist objektfähig.

[stefan2005]

hi,
ja das dachte ich am Anfang auch, aber ich glaube Delphi hat alles, was dazu benötigt wird in der System.dcu die eh ja immer miteinkompiliert wird.
Da ich aber eine eigene System.pas schreiben möchte, funzt das jetzt nicht.

cu,
stefan2005

[alcaeus]

Hallo stefan2005,

Die Frage ist, warum verwendest du eine eigene system.pas? Ich denke mal du muesstest die Deklaration von TObject da reinschreiben, schliesslich ist das die Basisklasse fuer alles andere. Ich verstehe aber nicht, warum man die system-Unit komplett austauschen will. Erweitern? Ja. Aber austauschen? :gruebel:

Greetz
alcaeus

[Die Muhkuh]

Für was brauchst du eine eigene System.pas? :shock:

[edit] Andy , warum bist du immer schneller als ich? Ausserdem hatte ich wieder nen toten Kasten [/edit]

[stefan2005]

hi,
ich schreib die System.pas ja auch nicht zum Spaß neu.
Mir ist da zu viel WinAPI Zeug drin, das ih nicht brachen kann/darf.

Aber wie kann ich TObject oder so deklarieren.
Es würde vielleicht schon reichen, die System.pas einfach an einigen Stellen abzuändern, aber ich hab ja den Source nicht :wink:

cu,
stefan2005

[malo]

Zitat:

Zitat von stefan2005

hi,
ich schreib die System.pas ja auch nicht zum Spaß neu.
Mir ist da zu viel WinAPI Zeug drin, das ih nicht brachen kann/darf.

Aber wie kann ich TObject oder so deklarieren.
Es würde vielleicht schon reichen, die System.pas einfach an einigen Stellen abzuändern, aber ich hab ja den Source nicht :wink:

cu,
stefan2005

Erm, du musst das WinAPI-Zeugs ja nicht benutzen. Lass es doch einfach sein, wenn du es nicht benutzen darfst :roll:

[stefan2005]

hi,
klar
In der System.dcu ist auch eine procedure namens _InitExe und die ruft teilweise API Funktionen auf.
Und einfach rauslöschen kann ich die nicht :wink:

cu,
stefan2005

[alcaeus]

Hallo stefan,

naja, du hast die Wahl:

• akzeptiere die Tatsache dass viele Dinge drin sind, die du evtl. nicht brauchst.
• Schreibe die System-Unit neu, diesmal ohne das WinAPI-Zeugs
• Kauf dir eine Professional und somit auch das Recht, die VCL-Sourcen zu bearbeiten.

Ich wuerde definitiv Loesung 1 oder 3 nehmen, die system-Unit neu programmieren.....nicht schlecht

Greetz
alcaeus

[malo]

Zitat:

Zitat von stefan2005

hi,
klar
In der System.dcu ist auch eine procedure namens _InitExe und die ruft teilweise API Funktionen auf.
Und einfach rauslöschen kann ich die nicht :wink:

cu,
stefan2005

Naja, wenn du die System.pas neuschreiben willst, wünsch ich dir viel Erfolg. Ich hoffe, du kannst gut Assembler ;)

[Die Muhkuh]

Zitat:

Zitat von malo

Zitat:

Zitat von stefan2005

hi,
ich schreib die System.pas ja auch nicht zum Spaß neu.
Mir ist da zu viel WinAPI Zeug drin, das ih nicht brachen kann/darf.

Aber wie kann ich TObject oder so deklarieren.
Es würde vielleicht schon reichen, die System.pas einfach an einigen Stellen abzuändern, aber ich hab ja den Source nicht :wink:

cu,
stefan2005

Erm, du musst das WinAPI-Zeugs ja nicht benutzen. Lass es doch einfach sein, wenn du es nicht benutzen darfst :roll:

Wahrscheinlich will er das raushaben, weil das die exe vergrößert.

[stefan2005]

hi,
eine kleine System.pas hab ich schon mit _InitExe, _InitLib, _, _halt0
die sind halt komplett leer (rufen auch kein API zeug auf), bloß Delphi braucht die unbedingt.
Um die Dateigröße geht es mir eigentlich nicht, eher vielmehr um die WinAPI aufrufe.
Bis jetzt läuft es auch prima, bloß ich bräuchte halt noch ein paar Einträge, damit ich auch Objekte und Klassen verwenden kann.

cu,
stefan2005

[malo]

Zitat:

Zitat von stefan2005

Bis jetzt läuft es auch prima, bloß ich bräuchte halt noch ein paar Einträge, damit ich auch Objekte und Klassen verwenden kann.

Wie gesagt: Ich hoffe, du kannst gut Assembler ;)

Die System.pas besteht nämlich aus mehr Assembler-Code als Delphi-Code.



Aber erklär uns doch erstmal, WOFÜR du eine neue System.pas brauchst. Vielleicht gibt es eine viel einfachere Lösung für dein Problem. Was stört dich an den WinAPI-Funktionen?

[kiar]

hallo Stefan,

schau mal bei NicoDE.Er hat auf seiner seite eine Minimalversion.

Raik

[stefan2005]

hi,
Assembler sollte kein Problem sein.
Das Problem an den WinAPI Funktionen ist, dass sie ohne Windows nicht laufen :wink:

Die Minimalversion von NicoDE hab ich mir schon mal angeschaut, leider steht da nix von Objekten oder TObject drin.

cu,
stefan2005

[malo]

Zitat:

Zitat von stefan2005

hi,
Assembler sollte kein Problem sein.
Das Problem an den WinAPI Funktionen ist, dass sie ohne Windows nicht laufen :wink:

Die Minimalversion von NicoDE hab ich mir schon mal angeschaut, leider steht da nix von Objekten oder TObject drin.

cu,
stefan2005

Falls du vorhast, unter Linux zu programmieren, dann schau dir mal Free Pascal an :zwinker:

[alcaeus]

Zitat:

Zitat von stefan2005

Das Problem an den WinAPI Funktionen ist, dass sie ohne Windows nicht laufen :wink:

Witzbold. Und jetzt willst du diese API-Funktionen rausnehmen, damit dein Programm unter Mac und Linux laeuft? Vergiss es, denn der Compiler erstellt dir eine Win32-exe, es wird also nie funktionieren.

Und weil ich so freundlich bin, schicke ich dir mal 6 aus fast 18000 Zeilen der system.pas:

Delphi-Quellcode:

{$IFDEF LINUX}
  //Do something
{$ENDIF}
{$IFDEF MSWINDOWS}
  //Do something else
{$ENDIF}

Die ganze Unit ist voll mit solchen conditional Defines. Kylix verwendet AFAIR naemlich sogar die selbe system-Unit ;)

Und wie gesagt, das Entfernen der API-Funktionen wird nicht bewirken, dass das Programm auf anderen Betriebssytemen laeuft. Wenn du einen Win-Emulator fuer Linux hast, wird es dort immer laufen, weil der Emulator was mit diesen APIs macht ;)

Greetz
alcaeus

[stefan2005]

hi,
nein, ich will auch nix mit/für Linux machen.

Aber zurück zu meiner Frage:
weiss es vielleicht jemand, bzw kennt sich jemand damit aus ?

cu,
stefan2005

[malo]

Erm, was willst du denn sonst mit deinen Delphi-Programmen machen? Willst du ein Betriebsystem schreiben, was ohne Windows nicht laufen würde? :shock:

Sorry, aber ich verstehe den Sinn deines Vorhabens nicht.

[stefan2005]

hi,
jo so ähnlich, ein OS.
Aber ich brauche immer noch einen Lösungsansatz o.ä. für mein Problem :wink:

cu,
stefan2005

[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? :roll: ....
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 :thumb:

...aenogym

ediT. andy war schneller^^

[stefan2005]

hi,
natürlich ist mir bewusst, dass ein OS nicht gerade einfach zu proggen ist :wink:
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:

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:

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:

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? :roll: (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 :-D )

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 :-D )

[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ß :mrgreen:

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

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

[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