Hauptmenü

Hallo!

Ich weiss, es gibt noch nicht sehr viele User, aber irgendeiner muss ja anfangen.

Wo findet man informationen über SOM-Objekte? Wie funktionieren diese und wie könnte man diese in WDSiybl einbinden?

bye,
Wolfgang

Hallo Wolfgang,
wenn Deine Blickrichtung in Richtung WPS geht, dann könntest Du ja mal bei xworkplace.org hereinschauen.

Aber ist das wirklich die Mühe wert?

Hallo!

Glaube ich schon, denn SOM ist ein wichtiger Bestandteil von der WPS. Bei Windows gibt es ja auch so was ähnliches.

bye,
Wolfgang

Richtig, OS/2 hat SOM und Windows hat COM.
Es gibt/gab auch ein SOM für Windows (NT). Da SOM wohl aber nicht weiter entwickelt wird, kann man das vermutlich streichen.

Hier mal ein Link: http://en.wikip...Object_Model (Wikipedia zu SOM) und http://www.objs...x3h7/som.htm (SOM Einführung)

SOM-Support wäre aktuell ziemlich OS/2-Einseitig. Man kann natürlich versuchen beim Windows-Compiler COM anstatt SOM zu erzeugen, dann müßte man sich aber doch recht stark beschränken. COM unterstützt wohl z.B. keine Vererbung, auf der anderen Seite sind mir noch keine SOM-Controls, die man z.B. in Dialogen verwenden könnte untergekommen (was nicht heißt, daß das nicht ginge, ich kenne es nur nicht).

XWorkplace habe ich genannt, weil das Projekt sich leidlich aktuell mit den WPS SOM-Klassen beschäftigt hat.

Ich kann mir aktuell SOM nur für die Erstellung/Erweiterung von WPS Klassen vorstellen. Diese Anwendung würde sich auf der Windows-Seite aber nicht ergeben.

Ich betreue seit längeren eine Software, die per SOM-Klassen in die WPS "integriert" ist. Ich bin dadurch aber noch lange kein SOM-Spezialist. Eher vielleicht SOM-gezeichnet


Um die ursprüngliche Frage zu beantworten (mein Versuch). Wie läuft das nun ungefähr bei SOM ab?:

Zunächst sucht man sich ein SOM-Objekt aus, von dem man "Erben" möchte. Dabei muß man sich entscheiden, ob das Objekt persistent (in der Arbeitsoberfläche oder/und im Dateisystem quasi statisch verankert) oder transient (Objekt wird von einem anderen Objekt / Anwendung dynamisch erzeugt) ist.

Dann implementiert man seine Ableitung, und zwar nicht in der Objekt-Syntax der jeweiligen Sprache sondern (recht umständlich) in der Behelfs-Syntax mit der SOM in der Sprache abgebildet wird.

Dort definiert man im wesentlichen die Methoden und Attributzugriffe die man "überladen" möchte. Fügt ggf. neue Methoden und Attribute hinzu.

Dann definiert man die Schnittstelle (welche Klassen, Methoden, Attribute) noch einmal separat in einer .IDL Datei und erzeugt darüber in Verbindung mit dem Code eine Importbibliothek und letztlich aus dem Objekt eine DLL.

Das Makefile des Projektes erzeugt dann über ein "paar Umwege" eine DLL.
Bei persistenten Objekten kann man nun (z.B. mit Rexx-Calls) die Klasse registrieren (könnte dann im Schablonen-Ordner auftauchen) und ggf. auch gleich ein Objekt daraus erstellen. Bei transienten Objekten darf man meines Wissens zumindest auch die Klasse registrieren.

Beispiele gibts z.B. im XWorkplace Quellcode oder im OS/2 Toolkit z.B. im "Workplace Shell Programmers Guide".

Soviel zur groben Einordnung.

Als erstes Danke fuer die Erkärung. Ich werde mir die Links anschauen.

Zitat

Richtig, OS/2 hat SOM und Windows hat COM.
Es gibt/gab auch ein SOM für Windows (NT). Da SOM wohl aber nicht weiter entwickelt wird, kann man das vermutlich streichen.

Einerseits gebe ich Dir recht, dass SOM und viele andere Komponenten von OS/2 nicht weiterentwickelt werden, aber trotzdem wird es benutzt. Im prinzip sehe ich das auch bei OS/2. Auch wenn es eComStation gibt, ist es doch ein quasi "Aufsatz von OS2", aber im prinzip wird OS/2 nicht mehr von der IBM oder weiterentwickelt. Nach deiner Definition müsste man vermutlich OS/2 komplett streichen. Es gibt viele Leute die an was programmieren, an denen andere Leute sagen, dass dies sinnlos oder unnötig ist. Bei den meisten ist es doch ein Hobby bzw. interesse. Bei mir war es bei Sibyl auch so. Die Firma Speedsoft hat die Entwicklung von Sibyl eingestellt und hat nur einzelne Teile freigegeben. z.b. die Compiler wurden nicht veröffentlicht. Dadurch war das Produkt auch zu streichen bzw. es wäre nicht weiterentwickelbar gewesen. Doch mich hat es interessiert wie man eine IDE bzw. Compiler programmiert.
Jetzt ist es so, dass es 104 (stand 17.04.2007) downloads gibt. Ich denke mir, dass dies schon eine Menge ist. Überhaupt weil es auf einem System läuft, dass selber totgesagt wird/wurde. Ausserdem muss man auch bedenken, dass immer noch den Speedsoft-Pascal-Compiler meisstens verwendet wird.
Natürlich weiss ich nicht wieviele Leute WDSibyl wirklich installieren (das würde mich auch sehr interessieren), aber ich würde schätzen, dass es ca. die hälfte ist d.h. noch immer hin 52x.
So denke ich mir das auch bei SOM. Es ist egal ob es weiterentwickelt wird oder nicht, hauptsache es ist verwendbar, wenn man es braucht.
Selbst eine Weiterentwicklung von Komponenten und Programmen ist nicht das "gelbe vom Ei", denn es gibt viele Programme, die man verschlechtert hat durch die Weiterentwicklung. z.b WinWord. Die Version 2.0b war sehr gut und auch sehr brauchbar. Die nächste Version 6.0 (was dazwischen war, weiss keiner) war meiner Meinung nach eine Katastrophe.
Wie auch immer, wenn man bei SOM anfängt, dann muss auch sagen, dass das ganze komplette OS/2-System zu streichen ist. So wie ReactOS, diverse Linux-Derivate usw.

Im prinzip geht es mir nur darum, wie man mit WDSibyl ein SOM-DLL erzeugen kann. Denn ich kann mir nicht vorstellen, dass sich so eine SOM-DLL viel von einer normalen DLL unterscheidet. D.h. es muss öffentliche Funktionen geben und mit einer bestimmten Aufbau und diese kann man doch auch in WDSibyl nachbauen.

bye,
Wolfgang

Hallo Wolfgang

Holla, da haben wir aneinander vorbei geredet. Mein Satz "Dann kann man das vermutlich streichen" galt der im Vorsatz genannten Windows-Unterstützung von SOM.

Bezüglich des SOM DLL-Aufbaus, weiß ich nichts genaueres. Ich schau aber mal, ob sich etwas finden läßt.

Aktuell sieht es so aus, daß Yuri Prokushev dabei ist SOM für FreePascal zu implementieren.

Ich habe mir mal den FPC source von ftp://ftp.freep...fpcbuild.zip gezogen. Dort gibt es bereits eine Som-Unit (som.pas) welche wohl aber noch nicht funktionsfähig ist.

Außerdem wird wohl ein sogenannter "Emitter" benötigt, um SOM-Deklarationen (IDL) mit dem SOM-Compiler in ein Pascal-Kompatibles Format umzusetzen. Der Emitter selbst muß wohl in C/C++ implementiert werden. Dieser Emiter wird wohl auch aktuell von Yuri entwickelt. Ist aber wohl noch in einer frühen "Alpha-Phase".

Mehr zu SOM noch hier:
http://www.edm2...ndex.php/SOM

Aktuell würde ich sagen, abwarten. Wozu die Arbeit doppelt machen. Zumindest, wenn die Lizenz (FPC ist GPL) kompatibel ist.

Hallo!

Zitat

Holla, da haben wir aneinander vorbei geredet. Mein Satz "Dann kann man das vermutlich streichen" galt der im Vorsatz genannten Windows-Unterstützung von SOM.

Ahso, da haben wir wirklich vorbei gesprochen.

Zitat

Aktuell sieht es so aus, daß Yuri Prokushev dabei ist SOM für FreePascal zu implementieren
Ich habe mir mal den FPC source von ftp://ftp.freep...fpcbuild.zip gezogen. Dort gibt es bereits eine Som-Unit (som.pas) welche wohl aber noch nicht funktionsfähig ist.

Kannst Du mir bitte die SOM.PAS mal schicken. Dann versuche ich mal die Datei mit WDSibyl zu kompilieren. Wenn sie funktioniert, dann kann man sie gleich in den OS/2-Teil hineingeben.

Weiters habe ich mir mal kurz die Link von edm2 angeschaut.

Code

SOM_Scope void  SOMLINK sayDemoWord(Demo *somSelf, Environment *ev)
{
    DemoData *somThis = DemoGetData(somSelf);
    DemoMethodDebug("Demo","sayDemoWord");
    printf("Write %s\n",_get_DemoWord(somSelf, ev));
}

Mir sieht das ganze wie eine normale Funktion aus, die dann "exportiert" wird.

d.h. dieser "Emitter" ist in prinzip ein Compiler, der die IDL-Sprache in eine DLL-Pascal-Datei konvertiert und der Pascal-Compiler compiliert die Datei in eine DLL.

So was ähnliches macht auch der Help-Compiler von WDSibyl. Das Programm konvertiert die SHS-Datei in eine IPF-Datei. Die dann von dem IPF-Compiler compiliert wird und daraus entsteht dann die HLP-Datei.

.) Als erstes wäre es interessant ob man den oben genannten Code händisch so konvertiert, dass WDSibyl eine DLL erstellt und ob die DLL in die WPS einbindet.
.) Wenn das funktioniert, dann könnte man schauen ob man den "Emitter" so umbaut, dass WDSibyl diesen kompilieren kann. (als erstes in eine EXE-Datei)
.) Wenn dies auch geht, dann könnte man diese in die IDE einbinden. Da muss der "Emitter" eine DLL sein mit einer gewissen Struktur. (Aber das zu konvertieren ist meistens kein Problem)
.) Bei Windows muss man dann schauen, wie man das so umbaut, dass daraus eine COM-Objekt wird. Aber das muss man sich genau noch anschauen, ob das technisch möglich ist.

Damit könnte WDSibyl auch SOM-Objekte erstellen.
Vielleicht kann man später auch die IDE so anpassen, dass WDSibyl eine Oberfläche anbietet. Aber das ist nur ein "Zukunftsmusik".

bye,
Wolfgang

wdsibyl

d.h. dieser "Emitter" ist in prinzip ein Compiler, der die IDL-Sprache in eine DLL-Pascal-Datei konvertiert und der Pascal-Compiler compiliert die Datei in eine DLL.

Genau:
Der Emitter ist ein Compiler oder Filter je nachdem wie hoch man das Ansetzt. Er ist eine DLL die vom SOM-Compiler aufgerufen wird und erzeugt letztlich aus der IDL, pascal Quellcode.
Ich merk grad, der WPS-Prog-Guide erläutert das recht ausführlich:
http://www.warp...UIDE.INF+260

wdsibyl

.) Als erstes wäre es interessant ob man den oben genannten Code händisch so konvertiert, dass WDSibyl eine DLL erstellt und ob die DLL in die WPS einbindet.

Ja man müßte quasi das .XIH-Äquivalent erstellen und ggf. noch linker-optionen entsprechend definieren.

wdsibyl

.) Wenn das funktioniert, dann könnte man schauen ob man den "Emitter" so umbaut, dass WDSibyl diesen kompilieren kann. (als erstes in eine EXE-Datei)

Hmpf. der Emitter bekommt meines Wissens schon vorgekaute/geparste Kost vom SOM-Compiler (sc). Der SOM-Compiler bzw. das Toolkit ist meines Wissens derweil auch über Hobbes verfügbar. Stellt sich die Frage, ob man den nun wirklich auch gleich ersetzen will.

wdsibyl

(...)
.) Bei Windows muss man dann schauen, wie man das so umbaut, dass daraus eine COM-Objekt wird. Aber das muss man sich genau noch anschauen, ob das technisch möglich ist.

Ja, evtl. erstellt man zunächst mal "einfach" die "ollen" Windows SOM Objekte. Auch wenn die dort keiner haben will.

wdsibyl

Damit könnte WDSibyl auch SOM-Objekte erstellen.
Vielleicht kann man später auch die IDE so anpassen, dass WDSibyl eine Oberfläche anbietet. Aber das ist nur ein "Zukunftsmusik".

Nein, muß m.E. nicht, wirklich nicht. IDE reicht als PM-Anwendung. Spätestens wenn man im Zuge der WPS-Entwicklung selbige öfter mal neu startet bzw. momentan bis zur Fehlerkorrektur gar nicht mehr ...ist man froh, wenn die Entwicklungsumgebung nicht jedes Mal mit absemmelt.
... ups... vielleicht auch falsch verstanden. Du meinst evtl. auch Zusatzfunktionen/Dialoge für die SOM-Objekt-Erstellung?



editiert von: MichaelDonning, 17.04.2007, 18:13 Uhr

Hallo!

Ich werde mir das auch mal anschauen, wenn es nicht schon vorher ein andere gemacht hat. Momentan ist der Heap-Manager dran.

Es wäre nett, wenn Du weiterhin diverse Informationen über dieses Thema sammelst.

bye,
Wolfgang

Hallo Wolfgang,
ich werde ab und zu mal in das Thema reinschauen.
Auch mal ein minimal C Beispielprojekt zu Vergleichszwecken bei Gelegenheit erstellen.

Hallo!

Schön wäre es, wenn Du mir die SOM.PAS-Datei schickst. Ich werde mal schauen ob ich diese auch unter WDSibyl kompilieren kann.

Wenn Du das Miniprogramm fertig hast. Also da soll wirklich nicht viel tun. Nur z.b. ein Messagebox aufmachen, dann können wir versuchen diese dann in eine PAS-Datei umzuschreiben um daraus die DLL zu generieren.

bye,
Wolfgang

Die SOM.PAS hatte ich Dir doch schon geschickt.
Oder stimmt die chello-Adresse in Deinem Profil nicht mehr?

Oder Spam-Filter?

Hallo!

Es war im Spam-Filter.
Vielen Dank

Ergänzung:
Ich habe jetzt die Datei so umgeschrieben, dass diese mittels WDSibyl kompilierbar ist.

bye,
Wolfgang