Reading through the discussion on this subject, I'm inclined towards the view that some people are unclear as to the benefits of multithreading. The only advantage to be gained from having a Zip/Unzip DLL that is thread-safe is that it can be safely called simultaneously from two or more threads in a single process. As Eric said previously, very few people are likely to require this. You can use the standard DLLs within a multithreaded program provided only one thread ever accesses the DLL at a time (typically the main thread). Using thread-safe DLLs will in no way make a program that uses a single thread more responsive (unless something very clever has been added). If a program appears to become unresponsive whilst the DLLs are active it is because the DLLs are failing to check for and dispatch messages (something they probably should do if called from the process's main thread). However, there is no point checking for messages unless the DLL also checks for such things as an abort flag being set in response to a button click. Of course, failing to check for messages during any long operation will cause a program to become unresponsive - it makes no difference if the relevant program code is in a DLL or in the main executable program. In a Delphi application, checking for messages involves periodically* calling Application.ProcessMessages. In a DLL, the best that can be done (so far as I am aware) is to periodically* call a procedure like the one below. procedure CheckMessages; var Msg : TMsg; begin while PeekMessage(Msg,0,0,0,PM_REMOVE) do begin TranslateMessage(Msg); DispatchMessage (Msg); end; end; *In the context of zip/unzip operations, periodically might mean on every buffer flush operation. Also, you can check for messages in response to the OnProgress event. I hope this clears up (what seems to be) some confusion. -- James Turner www.skaro.net