Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #30838 > unrolled thread

Architektura aplikacji - powody wyłączania dll z exe

Back to article view | Back to pl.comp.programming

Contents

  Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-14 21:10 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 08:01 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-15 00:21 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 09:44 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-15 06:11 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-18 02:38 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 03:57 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:02 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:11 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-19 23:08 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:26 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:28 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-16 19:57 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-17 01:29 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:28 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 04:42 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:26 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:52 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-20 22:53 +0100
              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 14:57 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-21 04:35 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 08:17 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-21 22:21 +0100
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 17:02 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-22 06:33 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:20 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:56 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-23 02:55 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:18 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:52 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-23 22:52 +0100
                Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 23:05 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-22 09:45 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:35 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:26 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:57 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-23 09:10 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 14:04 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-27 09:57 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-27 04:20 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-30 01:16 +0100
                          Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-30 08:27 -0800
                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-01 01:22 +0100
                              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 04:21 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 07:42 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe Roman Tyczka <noemail@because.no> - 2017-12-01 20:14 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 15:11 -0800
                                    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 17:02 -0800
                                      Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:24 +0100
                                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:15 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:43 -0800
                                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:15 +0100
                                              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 07:26 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:12 +0100
                                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:15 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 08:59 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 06:23 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:35 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 09:11 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 18:29 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 04:21 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:31 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:56 -0800
          Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-22 21:09 +0100
            Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:44 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-29 22:09 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-22 12:09 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2018-09-12 10:55 -0700

Page 4 of 4 — ← Prev page 1 2 3 [4]

#30851

W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik szyk...@gmail.com napisał:
> Witam
> W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko wyłączania z exe całego kodu aplikacji.
> Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> 
> Moje domniemania:
> 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały exe jest przerzucany do dll?
> 2. Żeby używać w innych aplikacjach jako obiektu COM.
> 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod roboczy z testowym).
> 
> A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
> 
> z góry dzięki
> Szyk Cech

1)

z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da)) 
- co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale byc moze niektprzy chcą
lub muszą to robic (?)
(ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami importy ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie ejst zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)

2) 
dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic ktory z tych sposobow
dll czy mmap bylby lepszy /ogolniejszy)

(podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic miedzy procesami (instancjami) oraz czy o to moze tu chodzic)

jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej pierwszy niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na chacie nie jeden a kilka programow robiacych podobne rzeczy)

3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy kompilowac 
jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe

[toc] | [prev] | [next] | [standalone]

#30860

W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik szyk...@gmail.com napisał:
> > Witam
> > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko wyłączania z exe całego kodu aplikacji.
> > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> > 
> > Moje domniemania:
> > 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały exe jest przerzucany do dll?
> > 2. Żeby używać w innych aplikacjach jako obiektu COM.
> > 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod roboczy z testowym).
> > 
> > A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
> > 
> > z góry dzięki
> > Szyk Cech
> 
> 1)
> 
> z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da)) 
> - co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale byc moze niektprzy chcą
> lub muszą to robic (?)
> (ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami importy ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie ejst zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)
> 
> 2) 
> dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
> gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
> klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
> to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic ktory z tych sposobow
> dll czy mmap bylby lepszy /ogolniejszy)
> 
> (podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic miedzy procesami (instancjami) oraz czy o to moze tu chodzic)
> 
> jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej pierwszy niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na chacie nie jeden a kilka programow robiacych podobne rzeczy)
> 
> 3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy kompilowac 
> jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe

inna opcja to ew byc moze
4) program ktory sam siebie chialby aktualizowac (moden w ostatnich czasach): 
sciagnac z netu na dysk dllke z glownym programem, nawet nie kasowac starej tylko po sciagnieciu sprawdzic ktora jest najnowsza i ja zlinkowac i odpalic to wydaje sie
ravzej proste (sam tego co prawda nie robilem) - exe ktory sciagnal by swoja nowsza wersje musialby chyba albo sam przerenamowac czy skasowac stara wersje itd i ja pozatym odpalic i siebie zamknąć, 
(jesli nie przerenamowac to musialby jakos updatnac linki itd)
nie jestem pewien jak to sie robi w takich sytuacjach ale byc moze ta wersja z dll jest praktyczniejsza
(ale to moje spekulacje trzebaby poczytac )

[toc] | [prev] | [next] | [standalone]

#30869

On Monday, November 20, 2017 at 5:31:27 PM UTC+1, fir wrote:
> W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
> > W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik szyk...@gmail.com napisał:
> > > Witam
> > > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko wyłączania z exe całego kodu aplikacji.
> > > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> > > 
> > > Moje domniemania:
> > > 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały exe jest przerzucany do dll?
> > > 2. Żeby używać w innych aplikacjach jako obiektu COM.
> > > 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod roboczy z testowym).
> > > 
> > > A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
> > > 
> > > z góry dzięki
> > > Szyk Cech
> > 
> > 1)
> > 
> > z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da)) 
> > - co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale byc moze niektprzy chcą
> > lub muszą to robic (?)
> > (ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami importy ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie ejst zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)
> > 
> > 2) 
> > dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
> > gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
> > klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
> > to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic ktory z tych sposobow
> > dll czy mmap bylby lepszy /ogolniejszy)
> > 
> > (podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic miedzy procesami (instancjami) oraz czy o to moze tu chodzic)
> > 
> > jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej pierwszy niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na chacie nie jeden a kilka programow robiacych podobne rzeczy)
> > 
> > 3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy kompilowac 
> > jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe
> 
> inna opcja to ew byc moze
> 4) program ktory sam siebie chialby aktualizowac (moden w ostatnich czasach): 
> sciagnac z netu na dysk dllke z glownym programem,

To ma rację bytu tylko wtedy, gdy przewidzisz rozwój aplikacji i zaprojektujesz
dobre interfejsy komunikacyjne. W praktyce jest to najczęściej wykonywanie
pracy która potem utrudni rozwój aplikacji o nieprzewidziane cechy.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30876

> To ma rację bytu tylko wtedy, gdy przewidzisz rozwój aplikacji i zaprojektujesz
> dobre interfejsy komunikacyjne. W praktyce jest to najczęściej wykonywanie
> pracy która potem utrudni rozwój aplikacji o nieprzewidziane cechy.

Chyba żartujesz. Praca w zespole bez kontraktów, to jak taplanie się w 
błocie - wszyscy obrywają przy pracy jednego. Wraz z rozwojem aplikacji, 
pojawia się coraz więcej zalet trzymania się interfejsów. A jeżeli 
napotyka się "nieprzewidziane cechy", to z moich obserwacji tylko 
dlatego że ktoś w zespole nie do końca rozumie idee i albo napisał 
sztywny most albo ma się mini aplikację wewnątrz docelowej, a nie komponent.

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [next] | [standalone]

#30884

On Wednesday, November 22, 2017 at 9:09:02 PM UTC+1, Mateusz Bogusz wrote:
> > To ma rację bytu tylko wtedy, gdy przewidzisz rozwój aplikacji i zaprojektujesz
> > dobre interfejsy komunikacyjne. W praktyce jest to najczęściej wykonywanie
> > pracy która potem utrudni rozwój aplikacji o nieprzewidziane cechy.
> 
> Chyba żartujesz. 
Nie.


> Praca w zespole bez kontraktów, to jak taplanie się w 
> błocie - wszyscy obrywają przy pracy jednego.
Dlaczego?


> Wraz z rozwojem aplikacji, pojawia się coraz więcej zalet 
> trzymania się interfejsów. 
Z tego wnioskuję, że Ty masz na myśli większe aplikacje, a ja
mniejsze i dlatego pomyślałeś że żartuję. Tak, w większych 
aplikacjach na dłuższą metę opłaca się zaprojektowanie 
interfejsów i trzymanie się ich. 


> A jeżeli 
> napotyka się "nieprzewidziane cechy", to z moich obserwacji tylko 
> dlatego że ktoś w zespole nie do końca rozumie idee
Z moich wynika że nieprzewidziane cechy są po prostu nowymi
wytycznymi od klienta, albo tym, że na etapie projektowania 
nie przewidziano iż wytyczne są niejednoznaczne albo nawet 
sprzeczne.

> i albo napisał 
> sztywny most albo ma się mini aplikację wewnątrz 
> docelowej, a nie komponent.
Jakie są różnice pomiędzy mini aplikacją a komponentem?

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#30969

W dniu 23.11.2017 o 22:44, M.M. pisze:
>> i albo napisał
>> sztywny most albo ma się mini aplikację wewnątrz
>> docelowej, a nie komponent.
 >
> Jakie są różnice pomiędzy mini aplikacją a komponentem?

Np. takie że mini aplikacja ma swoje własne źródło konfiguracji (np. 
osobny plik) zamiast za pomocą DI zapytać o własną sekcję.

Albo implementuje własny sposób logowania i logi z całej aplikacji lecą 
w jedno miejsce, a tych z pseudo komponentu gdzieś indziej.

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [next] | [standalone]

#30877

W dniu niedziela, 19 listopada 2017 13:21:16 UTC+1 użytkownik fir napisał:
> 
> 1)
> 
> z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy i tak tego nie chcą robic (w tej chwili nie pamietam czy sie da)) 


przy okazji tak naprawde jest to dosyc wazna kwestia.. poszukalem i znalazlem wg tego linka sie (NA SZCZESCIE) da

https://stackoverflow.com/questions/24024227/can-a-standard-executable-have-an-export-table

czemu jest to wazne? otoz moge podac przyklad mojego eksperymentalnego projektu do programowania agentowego, mam tam program exe ktory jest jakby srodowisiem dla agentow (i ktory dalej bede chyba nazywal 'hostem') i dwie dllki dla dwu grup agentow roznych typow

przykladowy kod takiego agenta btw 
to 

#include <stdlib.h>
#include <stdio.h>

extern "C"
{
__declspec(dllexport)  int RunAgentBlack();
__declspec(dllimport)  int Move(int dx, int dy);

}

int RunAgentBlack()
{
   int dx = rand()%3 - 1;
   int dy = rand()%3 - 1;

  Move(dx, dy);

  return 0;
}


gdyby nie mozna bylo exportowac funkcji z ekse znaczy to ze musialbym pisac jakis starter.exe 
i host.dll po czym ciagac te wszystkie niebedne referencje miedzy dllkami (i tak nieststy w tym projakcie swoja droga robilem 
bo niedoczytalem ze sie ponoc jednak da) teraz chyab to przerobie na pojedynczy host.exe (bo mam lekka chec sie za to wziac) ktory bedzie exportowal ta metode move, and thatz all 

swoja droga ten projekt bedzie przykladem na to jak programowanie agentowe da sie robic praktycznie w
c przy pomocy c i dll-ek (byc moze
w przyszlosci sie przerzuce bardziej na taki agentowy design)

[toc] | [prev] | [next] | [standalone]

#31884

W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik szyk...@gmail.com napisał:
> Witam
> W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko wyłączania z exe całego kodu aplikacji.
> Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?

Z prostej przyczyny: Te aplikacje mają pluginy które korzystają z Api aplikacji. I żeby nie robić korowodów te aplikacje są przeniesione do dll/so.

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | pl.comp.programming

csiph-web