DLLentrypoint в Delphi

[Horus92]

а с потоками можно как то повтор сделать

[Stilet]

Ну а че нет?
Просто зацикли поток, и в нем sleep поставь

[Horus92]

шото типа цикла с условием которое никогда не выполниться? а оно не сильно будет нагружать с задержкой память?
типа такого

begin
i:=1;
sleep(50000);
while i>1 do procedurename;
end;

[JTG]

Низя _____

You should never perform the following tasks from within DllMain:
• Call LoadLibrary or LoadLibraryEx (either directly or indirectly). This can cause a deadlock or a crash.
• Synchronize with other threads. This can cause a deadlock.
• Acquire a synchronization object that is owned by code that is waiting to acquire the loader lock. This can cause a deadlock.
• Initialize COM threads by using CoInitializeEx. Under certain conditions, this function can call LoadLibraryEx.
• Call the registry functions. These functions are implemented in Advapi32.dll. If Advapi32.dll is not initialized before your DLL, the DLL can access uninitialized memory and cause the process to crash.
• Call CreateProces. Creating a process can load another DLL.
• Call ExitThread. Exiting a thread during DLL detach can cause the loader lock to be acquired again, causing a deadlock or a crash.
• Call CreateThread. Creating a thread can work if you do not synchronize with other threads, but it is risky.
• Create a named pipe or other named object (Windows 2000 only). In Windows 2000, named objects are provided by the Terminal Services DLL. If this DLL is not initialized, calls to the DLL can cause the process to crash.
• Use the memory management function from the dynamic C Run-Time (CRT). If the CRT DLL is not initialized, calls to these functions can cause the process to crash.
• Call functions in User32.dll or Gdi32.dll. Some functions load another DLL, which may not be initialized.
• Use managed code.

Horus92, исходники dll у тебя есть или нет?

[Horus92]

исходники dll есть

[JTG]

Ну так в чём проблема? Уже после инициализации dll (вне DLLentrypoint)

procedure TimerCallback(wnd:HWND; msg, event, time:DWORD); stdcall;
begin
  //...
end;

SetTimer(0,1,1000*60,@TimerCallback);

[Horus92]

Процедура не выполняеться если через SetTimer.если я правильно понял что SetTimer(0,1,1000*60,@TimerCallback ); пишеться в Dllentrypoint допутим на событие DLL_PROCESS_ATTACH если нет то как оно будет выполняться без задания точки входа.

Вроде бы как сделал через поток через while и sleep проверка процедура повторяеться но из-за не нельзя нормально (допустим я для проверки поставил showmessage и sleep так вот оно та переходит на showmessage но после нажатия на ок программа как бы заблокирована для деиствий опять проходит следующий sleep и опять showmessage) так вот я не пойму почему вроде бы DLL_THREAD_ATTACH это создание нового потока но почему то всё выполняеться в одном потоке с программой

Вот код

const

DLL_PROCESS_DETACH = 0;

 DLL_PROCESS_ATTACH = 1;

 DLL_THREAD_ATTACH = 2;

 DLL_THREAD_DETACH = 3;

var b:boolean=true;

procedure DLLEntryPoint(Reason: Word);
begin
case Reason of DLL_THREAD_ATTACH:
  begin
   while  b do begin sleep(10000); showmessage('11111111');
  end;
end;
DLL_THREAD_DETACH:b:=false;
end;
end;   exports  DLLEntryPoint;

begin
DLLProc := @DLLEntryPoint;
DLLEntryPoint(DLL_THREAD_ATTACH);
end.

[BOBAH13]

case Reason of DLL_THREAD_ATTACH:
  begin
   while  b do begin sleep(10000); showmessage('11111111');
  end;

Слава богу что это не хук глобальный, а то бы Windows не устаял бы перед таким

Вам было сказано, либо
1. Таймер
2. Sleep но при этом создать отдельный поток, а не в главном буйствовать

p.s. а потом говорят, Windows - "плохая система", а Билл Гейтса яйцами закидать.

[JTG]

Да уж, это точно. Horus92, попробуй убрать showmessage и загрузить библиотеку из другого приложения через LoadLibrary Вообще внутри dllmain нельзя вызывать любые функции, кроме экспортруемых kernel32, т.к. винда не гарантирует, что в момент инициализации другие библиотеки уже будут загружены - на одной машине это будет работать, на другой нет.

С таймером пробелемка, даже с колбэком он отказывается работать без цикла GetMessage/DispatchMessage, кроме того в DLL на делфях код в initialization и между begin/end выполняется фиг-знает где (но выполняется). Остаётся выбрать из двух зол самое меньшее, и повесить на DLL_PROCESS_ATTACH/DLL_PROCESS_DETACH Create/TerminateThread соответственно, по крайней мере это точно не станет причиной deadlock'а

During DLL initialization routines, new threads can be created, but they do not begin execution until DLL initialization is done for the process

library project1;

uses Windows;

var foo : DWord;
    thread : Thandle;

Procedure ThreadProc;
begin
  while true do
  begin
    //do something
    sleep(1000*60);
  end;
end;

procedure DllMain(reason: integer);
begin
  case reason of
    //"Only one thread in a process can be in a DLL initialization or detach routine at a time."
    DLL_PROCESS_ATTACH: thread := CreateThread(nil, 0, @ThreadProc, nil, 0, foo);
    //"TerminateThread is a dangerous function that should only be used in the most extreme cases" :)
    DLL_PROCESS_DETACH: TerminateThread(thread, 0); 
  end;
end;

begin
  DllProc := @DllMain;
  DllProc(DLL_PROCESS_ATTACH);
end.

[Horus92]

Последний пост как раз то что мне надо только опять при проверке тот же showmessage пишет ошибку неизвестное исключение.
вот код

const

DLL_PROCESS_DETACH = 0;

 DLL_PROCESS_ATTACH = 1;

 DLL_THREAD_ATTACH = 2;

 DLL_THREAD_DETACH = 3;


var foo : DWord;
    thread : Thandle;

Procedure ThreadProc;
begin
 while true do
  begin
    showmessage('1111111111');
    sleep(1000*60);
  end;
end;

procedure DLLEntryPoint(Reason: Word);

begin
case Reason of

DLL_THREAD_ATTACH:
thread:=CreateThread(nil,0,@ThreadProc,nil,0,foo);

end;

end;   exports  DLLEntryPoint;

begin
DLLProc := @DLLEntryPoint;
DLLEntryPoint(DLL_PROCESS_ATTACH);

end.