---

Er der nogen der har erfaring med run-time load af en enkelt DLL der skal
deles mellem flere programmer?

Det viser sig at jeg har programmeret mig ind i en større redelighed, men
jeg skal prøve at beskrive min situation/frustration så præcist og
kortfattet som muligt.

Grundlæggende skal jeg bruge en enkelt system-hook i en DLL der overvåger
alle programmer og broadcaster data tilbage til hver tilmeldte instans af et
"host"-program via unikke mailslots. Problemet er at DLLen og system-hook'en
skal blive ved at køre indtil alle instanser af host-programmet er
afsluttet, og dette desværre ikke er muligt hvis den første instans af
host-programmet afsluttes imens de øvrige instanser stadig kører.

System
||
|| _,.- > Host 1
\/ ,.-~'´
Hook ---------- > Host 2
`'~-.,
`'~- > Host 3

Situation:
Trin 1)
En instans af host-programmet loader DLLen og kalder funktionen Start(...)
heri, hvorved system-hook'en startes og begynder at sende beskeder tilbage
til host-programmet via et navngivent mailslot (der er et unikt IPC-led til
hvert instans af host-programmet).
Trin 2)
Endnu en instans af host-programmet loader DLLen og kalder Start(...), men
da system-hook'en allerede kører oprettes blot endnu et navngivent mailsot
til den nye instans af host-programmet.
Trin 3)
En af instanserne af host-programmet skal ikke bruge mere data fra DLLen og
kalder derfor funktionen Stop(...) i DLLen der lukker mailslottet til denne
instans.
Trin 4)
Den sidste tilbageværende instans af host-programmet skal ikke bruge mere
data fra DLLen og kalder Stop(...). Da der nu ikke er nogle tilmeldte
instanser tilbage af host-programmet, stoppes system-hook'en og DLLen
unloades.


Dette virker upåklageligt sålænge den første instans af host-programmet
lukkes til sidst. Men lukkes den første instans imens de efterfølgende
kører, bliver system-hook'en stoppet og DLLen unloadet alligevel (jeg ved at
min programmering ikke forårsager dette direkte).
Jeg forestiller mig at DLLen bliver loadet ind i denne instans' virtuelle
memory (el. lign.?), og at de efterfølgende instanser også kalder DLLen
dette sted. Hvis den første instans bliver afsluttet, alsluttes DLLen altså
også, og de efterfølgende instanser får derfor ingen data mere.

Jeg har overvejet om løsningen er at skrive endnu et "loader"-program hvis
eneste formål er at loade en enkelt instans af DLLen, således at de
forskellige instanser af host-programmet kalder dette program således:

Trin 1) Første instans af host-programmet starter loader-programmet, og
kalder derefter funktionen Start(...) i DLLen
Trin 2) Endnu et instans af host-programmet kalder Start(...) i DLLen
Trin 3) En af host-instanserne kalder Stop(...) i DLLen
Trin 4) Den sidste tilbageværende instans af host-programmet kalder
Stop(...) i DLLen og lukker loader-programmet

Dette ville løse problemet, men det ser sgu ikke så godt ud med 3 led i
kæden, hvis man kun behøver 2 led...
Har I nogle idéer til hvordan jeg kan undgå at benytte et loader-program? Fx
at loade DLLen globalt i stedet for lokalt???


Al hjælp er værdsat... og nødvendig.

Christian

---

> Har I nogle idéer til hvordan jeg kan undgå at benytte et loader-program?
Fx
> at loade DLLen globalt i stedet for lokalt???

Kom lige i tanke om... kan man mon bruge rundll32.exe til at loade en
vilkensomhelst DLL i Windows9x ???
I så faldt: Er der nogen der ved hvordan?

Christian

---

oke
"Glinsvad" <glinsvad@email.dk> schreef in bericht
news:aqkj0d$5t5$1@sunsite.dk...
> > Har I nogle idéer til hvordan jeg kan undgå at benytte et
loader-program?
> Fx
> > at loade DLLen globalt i stedet for lokalt???
>
> Kom lige i tanke om... kan man mon bruge rundll32.exe til at loade en
> vilkensomhelst DLL i Windows9x ???
> I så faldt: Er der nogen der ved hvordan?
>
> Christian
>
>

---

"Christian Glinsvad" <glinsvad@email.dk> wrote in message
news:aqgnd1$gd3$1@sunsite.dk...
> Er der nogen der har erfaring med run-time load af en enkelt DLL der skal
> deles mellem flere programmer?

Jeg antager at du taler om Win32 programmering.

Som default deler forskellige processer ikke data som ligger i et DLL (jeg
ikke set tegn på at de deler kode-segment, når man bruger DLL).
DLL'et som fil, er delt mellem de forskellige processor - men der stopper
det almindeligvis også.

Jeg mener ikke at det spiller nogen rolle om DLL'et er implicit loaded (via
import libraries) eller explicit loaded (via kald til Win32 API funktionen
LoadLibrary) - hvis det er det du mener med "run-time load".

> Det viser sig at jeg har programmeret mig ind i en større redelighed, men
> jeg skal prøve at beskrive min situation/frustration så præcist og
> kortfattet som muligt.

Grundlæggende er det væsentligt at gøre sig klart at der er tale om IPC
(Inter-Processs Kommunikation).
Det vil sige at vi har med seperate adresse-rum og multi-tråd's
programmering at gøre.

>
> Grundlæggende skal jeg bruge en enkelt system-hook i en DLL der overvåger
> alle programmer og broadcaster data tilbage til hver tilmeldte instans af
et
> "host"-program via unikke mailslots. Problemet er at DLLen og
system-hook'en
> skal blive ved at køre indtil alle instanser af host-programmet er
> afsluttet, og dette desværre ikke er muligt hvis den første instans af
> host-programmet afsluttes imens de øvrige instanser stadig kører.

Hvordan broadcaster DLL'et data tilbage til hvert instans ?

Man er formodentlig nød til at bruge de IPC faciliteter som
operativ-systemet stiller til rådighed.
Det kan f.eks. være at hvert host program stiller en event-semaphor til
rådighed, som de hver især på en eller anden måde venter på.
Hver af disse semaphorer kan så registeres i DLL'et i SHARED memory (i en
memory-mapped file).
Når der så sker en hændelse, som skal broad-castes til hvert tilmeldt
instans af programmet, kan der signaleres på samtlige semaphorer, efter at
den nødvendige data er stillet til rådighed i SHARED memory .

Se f.eks. Microsoft artiklen "Using Shared Memory in a Dynamic-Link Library"
og følgende kode (ikke produktions-klar - der mangler lidt brug af Mutex)

<foo_dll.cpp>
#include <windows.h>
#include <iostream>

using namespace std;

namespace
{ // start of unnamed namespace

const size_t MAX_INSTANCES = 10; // Hard-coded !!!

int instance_index = -1;

struct instance_info
{
bool valid;
size_t index;
HINSTANCE hinst;
HANDLE shared_mem_file;
};

struct instance_register
{
unsigned instance_count;
instance_info instance_infos[];
};

instance_register* the_instance_register = 0;
instance_info* this_instance = 0;
HANDLE register_mutex = 0;

} // end of unnamed namespace

void __export foo()
{
cout << "foo called " << this_instance->index << endl;
}

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*
/*lpReserved*/)
{
switch(reason) {
case DLL_PROCESS_ATTACH: {
HANDLE shared_mem_file =
::CreateFileMapping(
INVALID_HANDLE_VALUE, // use paging file
NULL, // no security attributes
PAGE_READWRITE, // read/write access
0, // size: high 32-bits
sizeof(instance_register), // size: low 32-bits
"foo_project_shared_mem"); // name of map object
if(0 == shared_mem_file) {
return FALSE; // failed
}

const bool first_process = ERROR_ALREADY_EXISTS !=
::GetLastError();

the_instance_register = reinterpret_cast<instance_register*>(
::MapViewOfFile(
shared_mem_file, // object to map view of
FILE_MAP_WRITE, // read/write access
0, // high offset: map from
0, // low offset: beginning
0)); // default: map entire file

if(first_process) {
// Initialize the memory
the_instance_register->instance_count = 0;
for(size_t i = 0; MAX_INSTANCES != i; ++i) {
the_instance_register->instance_infos[i].valid = false;
}
}

if(the_instance_register->instance_count == MAX_INSTANCES) {
return FALSE; // failed
}

// find an empty slot to register this process
// This should be guarded by a named Mutex !!!
size_t i = 0;
for(; the_instance_register->instance_infos[i].valid; ++i);
// Use this slot
// Register information about the process
this_instance = &the_instance_register->instance_infos[i];
this_instance->valid = true;
this_instance->index = i;
this_instance->hinst = hinst;
this_instance->shared_mem_file = shared_mem_file;
++the_instance_register->instance_count;
}
break;

case DLL_PROCESS_DETACH: {
// This should be guarded by a named Mutex !!!
HANDLE shared_mem_file = this_instance->shared_mem_file;
this_instance->valid = false;
--the_instance_register->instance_count;

::UnmapViewOfFile(this_instance);
::CloseHandle(shared_mem_file);
}
break;
}
return TRUE;
}
</foo_dll.cpp>

med tilhørende test-driver program:

<foo.cpp>
#include <iostream>

using namespace std;

void foo();

int main(int /*argc*/, char* /*argv*/[])
{
cout << "Press x to exit" << endl;
for(;;) {
char c;
cin >> c;
if('x' == c) {
return 0;
}
foo();
}
}
</foo.cpp>

Hver gang man trykker en tast (og Enter) skriver programmet hvilket index
den har.
Man kan frit åbne og lukke programmerne i vilkårlig rækkefølge.

[8<8<8<]
> Dette ville løse problemet, men det ser sgu ikke så godt ud med 3 led i
> kæden, hvis man kun behøver 2 led...

Det burde bestemt ikke være nødvendigt.

> Har I nogle idéer til hvordan jeg kan undgå at benytte et loader-program?
Fx
> at loade DLLen globalt i stedet for lokalt???

Hvad mener du med at "loade DLL'et global" i stedet for "lokalt" ?

Har du overvejet at tage tungere, men vel også mere "renere" skyts, end
shared memory og semaphorer i brug ?
Det kunne f.eks. være CORBA og den EventService ?

> Al hjælp er værdsat... og nødvendig.

Håber det hjælper lidt.

Venlig hilsen

Mogens Hansen

---

Jeg er ikke så stiv i windows programmerein men kunne et COM objekt ikke
bruges.

mvh
JS
"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:aqm2ch$293e$1@news.cybercity.dk...
>
> "Christian Glinsvad" <glinsvad@email.dk> wrote in message
> news:aqgnd1$gd3$1@sunsite.dk...
> > Er der nogen der har erfaring med run-time load af en enkelt DLL der
skal
> > deles mellem flere programmer?
>
> Jeg antager at du taler om Win32 programmering.
>
> Som default deler forskellige processer ikke data som ligger i et DLL (jeg
> ikke set tegn på at de deler kode-segment, når man bruger DLL).
> DLL'et som fil, er delt mellem de forskellige processor - men der stopper
> det almindeligvis også.
>
> Jeg mener ikke at det spiller nogen rolle om DLL'et er implicit loaded
(via
> import libraries) eller explicit loaded (via kald til Win32 API funktionen
> LoadLibrary) - hvis det er det du mener med "run-time load".
>
> > Det viser sig at jeg har programmeret mig ind i en større redelighed,
men
> > jeg skal prøve at beskrive min situation/frustration så præcist og
> > kortfattet som muligt.
>
> Grundlæggende er det væsentligt at gøre sig klart at der er tale om IPC
> (Inter-Processs Kommunikation).
> Det vil sige at vi har med seperate adresse-rum og multi-tråd's
> programmering at gøre.
>
> >
> > Grundlæggende skal jeg bruge en enkelt system-hook i en DLL der
overvåger
> > alle programmer og broadcaster data tilbage til hver tilmeldte instans
af
> et
> > "host"-program via unikke mailslots. Problemet er at DLLen og
> system-hook'en
> > skal blive ved at køre indtil alle instanser af host-programmet er
> > afsluttet, og dette desværre ikke er muligt hvis den første instans af
> > host-programmet afsluttes imens de øvrige instanser stadig kører.
>
> Hvordan broadcaster DLL'et data tilbage til hvert instans ?
>
> Man er formodentlig nød til at bruge de IPC faciliteter som
> operativ-systemet stiller til rådighed.
> Det kan f.eks. være at hvert host program stiller en event-semaphor til
> rådighed, som de hver især på en eller anden måde venter på.
> Hver af disse semaphorer kan så registeres i DLL'et i SHARED memory (i en
> memory-mapped file).
> Når der så sker en hændelse, som skal broad-castes til hvert tilmeldt
> instans af programmet, kan der signaleres på samtlige semaphorer, efter at
> den nødvendige data er stillet til rådighed i SHARED memory .
>
> Se f.eks. Microsoft artiklen "Using Shared Memory in a Dynamic-Link
Library"
> og følgende kode (ikke produktions-klar - der mangler lidt brug af Mutex)
>
> <foo_dll.cpp>
> #include <windows.h>
> #include <iostream>
>
> using namespace std;
>
> namespace
> { // start of unnamed namespace
>
> const size_t MAX_INSTANCES = 10; // Hard-coded !!!
>
> int instance_index = -1;
>
> struct instance_info
> {
> bool valid;
> size_t index;
> HINSTANCE hinst;
> HANDLE shared_mem_file;
> };
>
> struct instance_register
> {
> unsigned instance_count;
> instance_info instance_infos[];
> };
>
> instance_register* the_instance_register = 0;
> instance_info* this_instance = 0;
> HANDLE register_mutex = 0;
>
> } // end of unnamed namespace
>
> void __export foo()
> {
> cout << "foo called " << this_instance->index << endl;
> }
>
> int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*
> /*lpReserved*/)
> {
> switch(reason) {
> case DLL_PROCESS_ATTACH: {
> HANDLE shared_mem_file =
> ::CreateFileMapping(
> INVALID_HANDLE_VALUE, // use paging file
> NULL, // no security attributes
> PAGE_READWRITE, // read/write access
> 0, // size: high 32-bits
> sizeof(instance_register), // size: low 32-bits
> "foo_project_shared_mem"); // name of map object
> if(0 == shared_mem_file) {
> return FALSE; // failed
> }
>
> const bool first_process = ERROR_ALREADY_EXISTS !=
> ::GetLastError();
>
> the_instance_register = reinterpret_cast<instance_register*>(
> ::MapViewOfFile(
> shared_mem_file, // object to map view of
> FILE_MAP_WRITE, // read/write access
> 0, // high offset: map from
> 0, // low offset: beginning
> 0)); // default: map entire file
>
> if(first_process) {
> // Initialize the memory
> the_instance_register->instance_count = 0;
> for(size_t i = 0; MAX_INSTANCES != i; ++i) {
> the_instance_register->instance_infos[i].valid = false;
> }
> }
>
> if(the_instance_register->instance_count == MAX_INSTANCES) {
> return FALSE; // failed
> }
>
> // find an empty slot to register this process
> // This should be guarded by a named Mutex !!!
> size_t i = 0;
> for(; the_instance_register->instance_infos[i].valid; ++i);
> // Use this slot
> // Register information about the process
> this_instance = &the_instance_register->instance_infos[i];
> this_instance->valid = true;
> this_instance->index = i;
> this_instance->hinst = hinst;
> this_instance->shared_mem_file = shared_mem_file;
> ++the_instance_register->instance_count;
> }
> break;
>
> case DLL_PROCESS_DETACH: {
> // This should be guarded by a named Mutex !!!
> HANDLE shared_mem_file = this_instance->shared_mem_file;
> this_instance->valid = false;
> --the_instance_register->instance_count;
>
> ::UnmapViewOfFile(this_instance);
> ::CloseHandle(shared_mem_file);
> }
> break;
> }
> return TRUE;
> }
> </foo_dll.cpp>
>
> med tilhørende test-driver program:
>
> <foo.cpp>
> #include <iostream>
>
> using namespace std;
>
> void foo();
>
> int main(int /*argc*/, char* /*argv*/[])
> {
> cout << "Press x to exit" << endl;
> for(;;) {
> char c;
> cin >> c;
> if('x' == c) {
> return 0;
> }
> foo();
> }
> }
> </foo.cpp>
>
> Hver gang man trykker en tast (og Enter) skriver programmet hvilket index
> den har.
> Man kan frit åbne og lukke programmerne i vilkårlig rækkefølge.
>
> [8<8<8<]
> > Dette ville løse problemet, men det ser sgu ikke så godt ud med 3 led i
> > kæden, hvis man kun behøver 2 led...
>
> Det burde bestemt ikke være nødvendigt.
>
> > Har I nogle idéer til hvordan jeg kan undgå at benytte et
loader-program?
> Fx
> > at loade DLLen globalt i stedet for lokalt???
>
> Hvad mener du med at "loade DLL'et global" i stedet for "lokalt" ?
>
> Har du overvejet at tage tungere, men vel også mere "renere" skyts, end
> shared memory og semaphorer i brug ?
> Det kunne f.eks. være CORBA og den EventService ?
>
> > Al hjælp er værdsat... og nødvendig.
>
> Håber det hjælper lidt.
>
> Venlig hilsen
>
> Mogens Hansen
>
>

---

"Jesper Sørensen" <m_burns@XXXkampsax.k-net.dk> wrote in message
news:aqmg8p$clp$1@eising.k-net.dk...
> Jeg er ikke så stiv i windows programmerein men kunne et COM objekt ikke
> bruges.

Jo.
COM har sin berettigelse når man skal krydse grænser på Win32:
* programmerssprog grænser
* processgrænser (herunder muligvis netværksgrænser)

COM objekter kan enten være in-process eller out-of-process.

In-process COM objekter er ikke andet end et almindeligt DLL, hvor
funktionaliteten er stillet til rådighed på en speciel måde - så det løser
ikke problemet.

Out-of-process COM objekter er en måde at lave inter-process kommunikation
på i MS-Windows.
I den konfiguration er COM en ORB (Object Request Broker) på samme måde som
CORBA er.
Man kan lave et selvstændigt server-program, der broadcaster til
COM-klienter der har abonneret på hændelser. Den server-process skal så leve
længere end alle klient-programmerne - hvilket også burde kunne lade sig
gøre.
Det er principielt ikke væsentligt forskelligt fra at anvende EventService i
CORBA.

Venlig hilsen

Mogens Hansen

---

Mogens Hansen skrev:
> Som default deler forskellige processer ikke data som ligger i et DLL (jeg
> ikke set tegn på at de deler kode-segment, når man bruger DLL).
> DLL'et som fil, er delt mellem de forskellige processor - men der stopper
> det almindeligvis også.

Lidt irrelevant, men jeg opsummerer... da jeg kun skal loade én DLL burde
det ikke være nødvendigt med delt hukommelse i DLLen, men fordi den
registreres som system-hook, injiceres (loades) DLLen ind i hver application
den overvåger. Dvs. at der kører en instans af DLLen for hvert program der
overvåges windows-beskeder fra/til.
Alt det fis har jeg løst for længst... CreateFileMapping() bruges til at
lave en midlertidig fil om til delt virtuel hukommelse.

> Hvordan broadcaster DLL'et data tilbage til hvert instans ?

Jeg tror egentlig broadcaster er en forkert betegnelse. DLLen poster én
besked til hver host via dennes named mailslot. Dette kører asynkront og
svarer præcist til windows' message-queue med SendMessage(hwnd...)
Igen: Alt dét pis virker perfekt.

> Glinsvad skrev:
> > Dette ville løse problemet, men det ser sgu ikke så godt ud med 3 led i
> > kæden, hvis man kun behøver 2 led...
>
> Det burde bestemt ikke være nødvendigt.

Desværre. Selvom når jeg har programmeret samtlige instanser af
host-programmet til at loade DLLen via LoadLibrary() så ender showet ved
afslutning af den instans af host-programmet der først loadede DLLen.
Selvom alle de andre host-instanser stadig kører, og ikke har kaldt
FreeLibrary(...)!!!

Det er tænkeligt at Windows stopper system-hooken når den instans af DLLen
den blev registreret i afsluttes, men det virker underligt for selve de
injicerede instanser som system-hooken kører i eksisterer stadigvæk...

Jeg HAR prøvet at kode DLLen/hostene til at genstarte system-hooken igen når
dette sker, men windows' veje er uransagelige. Heller ikke nogen god
løsning... alt for upålideligt til formålet.

> Hvad mener du med at "loade DLL'et global" i stedet for "lokalt" ?

At DLLen ikke mappes ind i host-programmets virtuelle hukommelse (lyder vist
rigtigt...), men i stedet køres uafhængigt; præcist som en executable.

> Har du overvejet at tage tungere, men vel også mere "renere" skyts, end
> shared memory og semaphorer i brug ?

Nej. Mit problem er udelukkende et Microsoft-/Win32-problem. Jeg vil have
DLLen og dens data-strøm til at være persistent sålænge den behøves af
mindst én host-instans (ligegyldigt hvilken), men det tillader hr. Gates
åbenbart ikke. De "renere skyts" du nævner skulle i så fald være et
ikke-Win32 OS.

For at citere Sgt. Bilko: "Make the bad man stop!"


Tak for hjælpen anyway

Christian Glinsvad

---

"Glinsvad" <glinsvad@email.dk> wrote in message
news:aqn6r1$afv$1@sunsite.dk...

> De "renere skyts" du nævner skulle i så fald være et
> ikke-Win32 OS.

Nej.
CORBA og dets Event-Service fungerer fint på Win32 - og en masse andre
systemer.

Venlig hilsen

Mogens Hansen

---

> CORBA og dets Event-Service fungerer fint på Win32 - og
> en masse andre systemer.

Det vil jeg bestemt overveje... tak for din og alle andres hjælp. Jeg ved
godt at mit problem er meget specifikt og at jeg sandsynligvis sætter
"fodspor" hvor kun få mennesker før har trådt. Vil bare lige sige at jeg
påskønner jeres hjælp, uanset hvor meget jeg egentlig har kunne bruge den
til at løse problemet.

Glinsvad

---

"Glinsvad" <glinsvad@email.dk> wrote in message
news:<aqn6r1$afv$1@sunsite.dk>...
> Mogens Hansen skrev:

[8<8<8<]
> Lidt irrelevant, men jeg opsummerer... da jeg kun skal loade én DLL
> burde det ikke være nødvendigt med delt hukommelse i DLLen, men fordi
> den registreres som system-hook, injiceres (loades) DLLen ind i hver
> application den overvåger. Dvs. at der kører en instans af DLLen for
> hvert program der overvåges windows-beskeder fra/til.

Det forekommer mig er der er lidt begrebsforvirring.
Et DLL kører ikke - det loades ind i en process. Det er processen som kører.
Een process, som bruger et DLL ved ikke om andre processer bruger samme DLL.

[8<8<8<]

Du har beskrevet 3 forskellige elementer i dit program:
* DLL
* mail-slot
* system-hook

Jeg mener at de 3 emner er uafhængige af hinanden.

Det betyder at det spiller ingen rolle om mailslot'ene og system-hook'ene
bliver oprettet og brugt i kode der ligger i et DLL eller i kode der ligger
direkte i en EXE-fil.

Der burde derfor være muligt at lave små test-programmer, der får een af
tingene til at virke af gangen.
F.eks. et lille program, der via mailslot kan broadcaste information til
alle instancer og som tillader at de kan startes og stoppes i vilkårlig
rækkefølge.
På den måde kan problemerne isoleres og løses een for een.

Venlig hilsen

Mogens Hansen

---

> Det forekommer mig er der er lidt begrebsforvirring.

Ja okay... men jeg ved selfølgelig at DLLer loades af processer der kører -
simpel fortalelse.

> Du har beskrevet 3 forskellige elementer i dit program:
> * DLL
> * mail-slot
> * system-hook
>
> Jeg mener at de 3 emner er uafhængige af hinanden.
>
> Det betyder at det spiller ingen rolle om mailslot'ene og system-hook'ene
> bliver oprettet og brugt i kode der ligger i et DLL eller i kode der
ligger
> direkte i en EXE-fil.

Her tar du alvorligt fejl. Grunden til at jeg overhovedet skriver en DLL er
at system-hooks SKAL registreres i DLLer (da de skal injiceres i de
processer der overvåges). Hvis jeg blot kunne skrive en EXE havde jeg gjort
det for længst.


> Der burde derfor være muligt at lave små test-programmer, der får een af
> tingene til at virke af gangen.
> F.eks. et lille program, der via mailslot kan broadcaste information til
> alle instancer og som tillader at de kan startes og stoppes i vilkårlig
> rækkefølge.


Igen: Det har jeg gjort for længst og det virker perfekt.
- Mailslottene virker og processer kan til-/frameldes uden problemer
- Har lavet ikke-system hooks i en EXE (lokal overvågning af én proces), og
også det virker
- Har skrevet DLLs før, så også det virker

Problemet er at Windows åbenhart anullerer system-hooks så snart den instans
af DLLen, hvor system-hooken blev registreret i, afsluttes. Dette sker
desværre uanset hvor mange andre instanser der stadig er loadet.

Løsningen er nok en loader-exe eller måske rundll32.exe - jeg prøver sgu...


Glinsvad