Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alex7691

    ISAPI in Delphi 10.2,10.3 TranslateURI

    This is an old thread that was pointed out to me by an IntraWeb user. I'm adding some information for future readers. IntraWeb has it's own ISAPI classes and doesn't rely at all on Delphi's IsapiHTTP.pas (or any other Delphi Web.* namespace unit). Any bug in that area doesn't affect IntraWeb applications. Cheers,
  2. I've just tested his test application (without ICS, but the same issue will definitely happen). There is nothing wrong with IntraWeb. He's using an Indy-based IntraWeb server. He creates a window handle when his application is receiving an incoming request. The Indy HTTP server spawns a worker thread which is freed afterward. The window handle is released when the thread is destroyed. Then he tries to use the same window handle in a subsequent request, from another thread (there is no guarantee that the original thread which created the window handle hasn't been destroyed). This is documented here: https://docs.microsoft.com/en-us/windows/win32/procthread/terminating-a-thread BTW: his example works when using Http.sys-based IntraWeb application (not Indy) because the threads are obtained from a thread pool and recycled, so the windows created in one request will be still valid in a subsequent request (although I don't recommend his way of using it at all). Given that the application behavior is not only expected but also correct, your statement above is obviously false. Regards
  3. I did not mention ICS at all. I'm pointing at his test case application which does not use ICS. This is a standard AllocateHWnd RTL call and it won't work reliably. That's a fact. Once you mention that you patch AllocateHWnd from ICS code, are you 100% sure that your patch doesn't break anything else that IntraWeb relies on? After saying yourself that you know nothing about IntraWeb, this kind of statement is at least curious. Regards
  4. For future readers: AllocateHWnd is not thread safe and should never be used like that in any multi-threaded application (not only IntraWeb servers). I'll have a look at his example out of curiosity, but this code the way it is now is not recommended, not supported and definitely won't work reliably.
  5. Alex7691

    Debugging problem (multithreaded & Intraweb)

    Hi Arthur, Indeed, IntraWeb DCUs are built with debug info ON. Mainly because the built-in exception logger (Based on Jedi's JCLDebug code) requires the debug information to create an human readable call stack). Also, not sure how many IW developers add the source code to their build (or add them to the browsing path), but I believe it is a considerable number. The ideal is to have 2 sets of DCUs but it would just explode the size of the setup. We are trying different approaches with the build script and setup program. I will have more information about it soon. Unfortunately, Delphi doesn't have any option to filter out some units or paths from debugger. Personally I have other 3rd party libraries for other projects and it is painful to debug certain applications because of this. Cheers,
  6. Alex7691

    Minifing HTML

    Would you mind elaborating why you need it? In general it is not possible to effectively minify HTML content unless it contains heaps of comments. In that case, simple gzip compression for http(s) transmission is as effective as (if not more, i.e. the cost to compress it using gzip is less compared to the cost of minifying it + compressing it and the benefit is almost the same) Cheers
  7. Alex7691

    This implementation is Thread-safe?

    Contention yes, deadlock, no. Actually it is quite the contrary. Deadlocks only occur because more than one lock is used (or one which can't be called recursively, like Windows' SRWLock objects). This document is *really* wrong.