Współdzielenie biblioteki

[yonami]

Witam Serdecznie

Chciałem zapytać się Was, czy wiecie jak zaprogramować bibliotekę, która
współdzielona jest przez więcej niż jedną aplikację. Chodzi mi aby tylko jedna
kopia takiej biblioteki była w pamięci operacyjnej.

W zasadzie, tak dokładnie rzecz ujmując, potrzebuje napisać bibliotekę, która
będzie silnikiem malowania kontrolek. W każdej chwili może nastąpić zmiana
silnika, na inny. Tak więc wydzieliłem kontrolki do biblioteki dynamicznej
podpiananej w run-timie, ale z niej muszę wywoływać funkcje samego malowania.
Te właśnie funkcje mają być w tej jednej bibliotece.

Ma ktoś pomysł?

[alsor]

Nie ma tu nawet o czym gadać - zwykły dll, i tyle.

[yonami]

Nie zykły DLL, bo ta jedna biblioteka jako jeden proces ma obsługiwać na wątkach
inne aplikacje.

Więc nie jest to zwykła biblioteka, którą sobie każda aplikacja odpala jako
kopię dla siebie.

[alsor]

Popatsz sobie jak są zrobione standardowe okienka: edit, static, listbox...
siedzi to wszystko w jednym dll - user.
albo tzw. common controls: listview, tolltip, treeview... wszystko jest w commctl32

Aplikacja dostaje komunikat rysowania i rysuje - to wszystko odbywa się w jednym
wątku, w tym który utworzył okno.

Ten jeden centralny proces już jest - proces systemu operacyjnego.
Jest on jednak lepiej skonstruowany, bo nie robi niepotrzebnie osobnych wątków
dla każdego wątku z oknami.

[negevmc]

Chyba rozumiem o co Ci chodzi choć bardzo zawile to tłumaczysz.
Na pierwszy rzut oka zrozumiałem Twój problem tak jak alsor i tak jak on
proponowałbym zwykły DLL.
Rozumiem jednak, że Ty potrzebujesz mechanizm, który kontrolowałby
wszystkie działające w danym momencie aplikacje.
Innymi słowy gdy w jednej chwili zmieniasz parametry silnika - kontrolki
wszystkich aplikacji to zauważają i zachowują sie inaczej.
Jeśli tak, to jest to sytuacja dokładnie odwrotna i potrzbujesz klasycznej
aplikacji client-server.
Jeśli wszystkie aplikacje klienci mają działać na tej samej samej maszynie
bez wysiłku możesz posłużyć się funkcja SendMessage aby powiadomić ich o
zmianie silnika.
Jeśli na różnych ale dzielących wspólne zasoby dyskowe możesz pokusić się
o wspólny zbiór z aktualnymi parametrami a klienci muszą czytac go co jakiś
czas i weryfikować swoje zachowanie. Szybkość "reakcji" na taką zmiane
zależy jak często będziesz sprawdzal parametry.
Wreszcie trzecia metoda - najefektywniejsza ale najbardziej pracochłonna
to stworzenie 2 aplikacji: serwera i klienta. Klient zapala Twoje kontrolki ale
tylko w sposób w jaki pozwala (czy każe) mu serwer. Wysyła do niego "zapytanie"
a otrzymuje "odpowiedź" i .. robi z nią co należy.
Pisanie aplikacji client-serwer nie jest proste ale np. Delphi czy C++ Builder
dysponują narzędziami upraszczającymi cały proces oraz dostarczają "wbudowane"
sposoby komunikacji między aplikacjami.