Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 16 to 30 of 43

Thread: Geavanceerde Plugins

  1. #16
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Barry Staes View Post
    Dat staat toevallig op mijn todo list, en ik had gepland dat met (niet geregistreerde COM) interfaces te doen.
    Op mijn lijst staat nog altijd packages naar FPC brengen. Of althans er genoeg van te weten om te kunnen assisteren. (b.v. een eerste implementatie naar meerdere platformen brengen)

    wat vragen:
    * Wat doe je met strings (automatische types in het algemeen) en IS/AS ?
    * Sta je verschillende delphi versies toe?
    * hoe ga je met overige RTL state om (date format enz)

  2. #17
    Senior Member
    Join Date
    May 2011
    Location
    Oisterwijk
    Posts
    468
    Quote Originally Posted by marcov View Post
    Overigens gebruik ik typisch function-of-object methods met argumenten (en zelden echt tnotifyevent).
    Ditto. Maar als ik observers gebruik doe ik het zo:

    Nadat mijn Observer aangetikt wordt, haalt die (vaak bij de eigenaar van het Observable object) de benodigde argumenten op die jij/ik anders rechtstreeks had willen meegeven in een method.

    Soms een voordeel, als het opbouwen van een argument CPU intensief is maar niet altijd daadwerkelijk gebruikt wordt.

    -----
    Quote Originally Posted by marcov View Post
    wat vragen:
    * Wat doe je met strings (automatische types in het algemeen) en IS/AS ?
    (pas op hier volgt involledige leerstof / theorie zonder praktijktests :P)
    • Interfaces zijn net als Strings reference counted. Interfaces zijn volgens COM ook reference counted en dat zelfs volgens dezelfde specificatie die IUnknown heeft (dat is geen toeval), dus die kan ik normaal blijven gebruiken als ik het in C++ ook behandel zoals ik een "echte geregistreerde" COM interface zou behandelen. Denk ik.
    • Strings zijn in andere talen niet altijd reference counted. Die geef ik dus via stdcall procedures door als PWideChar() en gelukkig kan Delphi die heel netjes en makkelijk converteren voor me als ik die typecast doe. Denk ik.
    Ik moet me tzt nog eens inlezen in http://rvelthuis.de/articles/articles-cppobjs.html
    Een ander dingetje waar ik misschien rekening mee moet houden is dat ik moet proberen om bepaalde dingen niet als return value van een functie te gebruiken, omdat de stack (bijv.) tussen C++ en Delphi dan anders gevuld/gebruikt wordt en ik zo makkelijker kan debuggen/profilen.

    Ik wilde me nog verdiepen in http://rvelthuis.de/articles/articles-cppobjs.html
    * Sta je verschillende delphi versies toe?
    Ja en C++ of andere dingen/talen die stdcalls en COM Interfaces ondersteunen. Denk ik.
    * hoe ga je met overige RTL state om (date format enz)
    Niet. Elke DLL staat op zichzelf, en alle communicatie gaat gebeuren via Interfaces waarvan ik zelf alles bepaal wat erin/uit gaat. Zonodig zou ik via een gespecialiseerde interface ook het date format kunnen opvragen.
    De applicatie krijgt een Interface broker zodat elke plugin elke Interface (van een bepaald type) kan opvragen, of die nu van een plugin of van de applicatie zelf afkomstig is dat maakt niet uit. Gespecialiseerde interfaces zoals deze voor date format zouden dan door de applicatie zelf aangeleverd worden.
    Last edited by Barry Staes; 09-Nov-12 at 11:39.

  3. #18
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Ah, maar dan moeten beide elkaars type weten. En dat haalt nu net de ontkoppeling we.g

  4. #19
    Senior Member
    Join Date
    May 2011
    Location
    Oisterwijk
    Posts
    468
    Quote Originally Posted by marcov View Post
    Ah, maar dan moeten beide elkaars type weten. En dat haalt nu net de ontkoppeling we.g
    Ja ik leg gewoon vast hoe het zich moet gedragen met de Interface. Maar dat vind ik juist ontkoppeling, alles ligt toch duidelijk vast. Je kunt een OLE/ActiveX/OCX ding (feitelijk COM Interfaces) toch ook gebruiken vanuit elke taal, het type ligt gewoon vast daar hoef je niet meer naar te raden.

  5. #20
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Barry Staes View Post
    (pas op hier volgt involledige leerstof / theorie zonder praktijktests :P)

    Interfaces zijn net als Strings reference counted.
    In Delphi wel ja. in FPC heb je ook interfaces die IUnknown niet implementeren. (zg Corba interfaces, al is dat een slechte naam)

    Interfaces zijn volgens COM ook reference counted en dat zelfs volgens dezelfde specificatie die IUnknown heeft (dat is geen toeval), dus die kan ik normaal blijven gebruiken als ik het in C++ ook behandel zoals ik een "echte geregistreerde" COM interface zou behandelen.
    Klopt, maar dan kan je natuurlijk geen native delphi types in die interfaces gebruiken, en moet je je bij de originele strikte com types houden. (dus geen dynamische arrays, maar safe arrays enz)

    Strings zijn in andere talen niet altijd reference counted. Die geef ik dus via stdcall procedures door als PWideChar() en gelukkig kan Delphi die heel netjes en makkelijk converteren voor me als ik die typecast doe. Denk ik.
    Kijk daar mee uit. Als je dit aan de Delphi kant niet expliciet doet, kan het zijn dat je het adres van een tijdelijke variabele meegeeft. Dat kan, maar dan moet de andere kant _altijd_ de string kopieren, nooit de reference opslaan en voorbij de procedure call gebruiken.

    Het is overigens standaard gebruik om dat te doen, enkel en alleen voor de volledigheid.

    COM BWstrs (widestring) zouden geloof ik wel ref counted moeten zijn. Anders zouden ze niet in een olevariant gestopt kunnen worden. Dus als je toch op de Windows-only COM toer gaat, zou je dat kunnen doen.

    Ik moet me tzt nog eens inlezen in http://rvelthuis.de/articles/articles-cppobjs.html
    Een ander dingetje waar ik misschien rekening mee moet houden is dat ik moet proberen om bepaalde dingen niet als return value van een functie te gebruiken, omdat de stack (bijv.) tussen C++ en Delphi dan anders gevuld/gebruikt wordt en ik zo makkelijker kan debuggen/profilen.
    Complexe types (alles groter als native word size en met speciale attributen zoals ref counted) zou ik dan niet als return value gebruiken.

    int64 op 32-bit uitgezonderd misschien, dat is ABI compatible neem ik aan.

    Ik wilde me nog verdiepen in http://rvelthuis.de/articles/articles-cppobjs.html

    Ja en C++ of andere dingen/talen die stdcalls en COM Interfaces ondersteunen.
    Die url is wel bekend ja. Overigens voor het gros hoe in C++ relatief gewone COM dingen te doen, als mede wat linking details. C++ kent geen interface, maar wel meervoudige inheritance. Een abstracte baseclass meervoudig
    vererft komt dus dicht bij een interface.

    C++ ondersteunt natuurlijk niet iets Windows specifiek als COM interfaces. _declspec is een MS only escape voor MSVC/windows specifieke defines.

    Of dat erg is, is een tweede. Hetzelfde geldt natuurlijk voor stdcall, die is ook windows specifiek. Al zal Embacadero het op de mac wel naar cdecl vertalen. Maar dan moet je niet vergeten code in niet Embacadero compilers aan te passen.

    Denk ik.
    Niet. Elke DLL staat op zichzelf, en alle communicatie gaat gebeuren via Interfaces waarvan ik zelf alles bepaal wat erin/uit gaat. Zonodig zou ik via een gespecialiseerde interface ook het date format kunnen opvragen.
    De applicatie krijgt een Interface broker zodat elke plugin elke Interface (van een bepaald type) kan opvragen, of die nu van een plugin of van de applicatie zelf afkomstig is dat maakt niet uit. Gespecialiseerde interfaces zoals deze voor date format zouden dan door de applicatie zelf aangeleverd worden.
    Dat kan. Maar dit is dus rock bottom DIY. Aan de andere kant, als je meerdere talen en versies wil ondersteunen heb je niet veel keus, zolang je maar weet waar je de moeite voor doet.

    Ik zou overigens je eerste test opzet ook even op andere platformen en/of met andere compilers proberen te compileren. Dat werkt vaak verhelderend, en vermijdt dat je dadelijk hopen business code met MS specifieke __declspecs heb rondliggen terwijl een macrotje hier en daar dat soort troep geabstraheerd kon hebben.
    Last edited by marcov; 09-Nov-12 at 12:33.

  6. #21
    Senior Member
    Join Date
    May 2011
    Location
    Oisterwijk
    Posts
    468
    Quote Originally Posted by marcov View Post
    Ik zou overigens je eerste test opzet ook even op andere platformen en/of met andere compilers proberen te compileren. Dat werkt vaak verhelderend, en vermijdt dat je dadelijk hopen business code met MS specifieke __declspecs heb rondliggen terwijl een macrotje hier en daar dat soort troep geabstraheerd kon hebben.
    Ik zou heel graag weten of ik het (de Interface broker) zo kan maken dat later dezelfde code (niet de DLL) op Linux werkt, én/of in een andere taal zoals C++ geschreven is. Je hebt meer verstand van FreePascal en cross platform dan mij, wat denk je, kan het? Hoe opzetten? Is het in Windows dan geen DLL?

  7. #22
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Barry Staes View Post
    Ik zou heel graag weten of ik het (de Interface broker) zo kan maken dat later dezelfde code (niet de DLL) op Linux werkt, én/of in een andere taal zoals C++ geschreven is. Je hebt meer verstand van FreePascal en cross platform dan mij, wat denk je, kan het? Hoe opzetten? Is het in Windows dan geen DLL?
    Het staat niet voor niks op mijn todo list, ik moet er nog induiken.

    Zoals ik al aangaf, goed weten wat portable is van iedere taal, en wat niet. (een (mingw/)gcc installtje erbij hebben kan al veel schelen voor het C++ geval. Gebruik daarvoor niet BCB, die volgt MSVC te veel)

    wat tips:

    1. Beschouw calling conventions en decoratie/mangling als iets heel platform afhankelijks
    2. Idem voor record packing, al wordt dat meestal pas echt belangrijk als je van x86/x86_64 afgaat.
    3. ben heel precies met typering van apis e.d. Zie ook volgend punt
    4. Vermijdt aannames over handle types (THandle als universeel type is iets windows specifiek, bij de meeste OSes heeft elke API zijn eigen handle type, en ze zijn niet allemaal even groot of gelijk getypeerd).
    5. Voor FPC; vermijdt gebruik van Delphi versie conditionals (COMPILER_VERSION VER<X>) in de sourcecode


    Verder, meer specifiek voor plugin architecturen, Linux (en *BSD ook) hebben een zg vlakke linker structuur.

    Dat betekent dat er maar een namespace voor (geëxporteerde) C level symbolen is, en dus niet een per module (dll/exe) zoals bij Windows. (Dit is de reden waarom je bij een api declaratie (procedure xxx external somedll name 'xx'; ) onder windows ook de dll naam moet invullen, je selecteert daarmee de namespace van die DLL).

    Dit betekent _mogelijk_ dat je niet simpelweg al je modules een C funktie "GETINTERFACE" symbool kan geven om de plugin interface terug te geven. Een oplossing is mogelijk alle DLLs een symbool in het mainprogramma (of een shared lib die ze allemaal gebruiken) aan te roepen om een private symbool te registereren.

  8. #23
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Oftewel, hoe ga je een DLL gebaseerd plugin systeem inrichten zodat je het werkbaar houdt?
    Geen idee nog!
    Maar een bpl is denk ik niet werkbaar. Het is de bedoeling dat wie dan ook een plugin kan schrijven. En niet iedereen de wereld heeft Delphi XE2.
    Het is een hobby project (natuurlijk ik ben maar een hobbyist).

  9. #24
    Je zou eens naar sockets kunnen kijken voor de communicatie tussen je app en je plugins. Die kun je gebruiken onder windows en linux en mogelijk ook Mac. Bovendien werkt het in elke taal.

    Een andere optie waar je eens naar zou kunnen kijken zijn named pipes. Volgens mij heb je die ook onder windows en in linux kun je ze zeker gebruiken.

  10. #25
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Named pipes heb je in NT varianten. Niet portable naar win9x of wince, maar dat is minder een probleem tegenwoordig

  11. #26
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Het moet snel zijn en "simpel". Is het niet mogelijk dat de plugin (ga nu even uit van een DLL) een pointer naar een (groot) record krijgt - of kan opvragen - met beschikbare functies?

    <edit>
    Of is het mogelijk dat een exe functions exporteert net als een DLL?
    Last edited by Anoniem; 13-Nov-12 at 13:09. Reason: vraag verder uitgebreid

  12. #27
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,708
    Quote Originally Posted by EricLang View Post
    Of is het mogelijk dat een exe functions exporteert net als een DLL?
    Ja hoor, da's geen probleem (je houdt natuurlijk dezelde beperkingen als bij een
    "Normale" DLL zoals de welbekende string-problemen): gewoon een normale functie
    (dus geen function of object) exporteren met Export.

    Welke toegevoegde waarde deze opzet zou hebben zie ik alleen niet echt.

    Greetz,

    Peter.
    TMemoryLeak.Create(Nil);

  13. #28
    Dat kan wel, maar ik geloof niet dat de dll op die manier bij de geëxporteerde functies van de exe kan. Een record met functies teruggeven moet wel kunnen. Interfaces teruggeven kan trouwens ook. Volgens mij mag je elke COM compatible interface gewoon doorgeven aan een DLL, zodat deze daar methods van kan aanroepen. Voor een plugin-systeem is dat denk ik wel een handigste manier: De plugin exporteert een enkele functie die een PLuginInterface teruggeeft. De applicatie kan andersom een ApplicationInterface doorgeven aan de plugin.

    Overigens zijn WideStrings/BSTRs volgens mij juist niet reference counted. In tegenstelling tot de AnsiString implementatie van Delphi krijg je bij toekenning altijd een nieuwe string.
    1+1=b

  14. #29
    Senior Member
    Join Date
    May 2011
    Location
    Oisterwijk
    Posts
    468
    Quote Originally Posted by GolezTrol View Post
    krijg je bij toekenning altijd een nieuwe string.
    (afgezien dat alle *string types reference counted zijn met uitzondering van ShortString)

    Ik geloof dat je formulering ietwat ongelukkig is;
    Delphi geeft (mede ivm reference counting) dus altijd een nieuwe string teruggeeft als je er een wijzigt (strA := strB + 'c'; ) vanwege het "delayed copy on write" gedrag. En het geeft dezelfde string (zelfde plek in geheugen) terug als je een kopie maakt van een string (strA := strB; )

  15. #30
    Klopt. Maar volgens mij geldt dat dus expliciet niet voor WideString. Ik kan het mis hebben, hoor.

    [edit]
    Het stukje waar je naar linkt zegt het ook:

    Quote Originally Posted by artikel waar je naar linkt
    Wide String
    Wide strings are also dynamically allocated and managed, but they don't use reference counting or the copy-on-write semantics.
    1+1=b

Page 2 of 3 FirstFirst 1 2 3 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •