No announcement yet.

ISAPI instead of ASP?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Knuth Konrad
    Try a forum search for Lothar Pink. He has done a lot with ISAPI and has developed an ISAPI SDK for PB:

    The download link doesn't work anymore. I've still got the download package on disk, send me a PM, if you'd like me to send you a copy.

    Leave a comment:

  • Mike Doty
    The dd_isapi,inc file at
    is not the same as the one on the PowerBASIC site.
    The one on PowerBASIC compiles fine and has the GetCookies function.
    Compiled to a DLL and called over the internet using the htm code below.
    Get error 405 Method not allowed.
    Using Abyss Web Server and DLL is the default extension.

    <HEAD><title>ISAPI Test Page</title></HEAD>
    <CENTER><H2>ISAPI Test Page</H2></CENTER><BR><HR>
    This tests the POST method of the isapi interface. It tries to
    call the function in istest32.dll. Currently, this dll must be
    in the /docs directory if you're running the <A href="[URL][/URL]">
    Sambar Server</A>. I can't seem to make it work if it's anywhere
    else. I don't use IIS, so I don't know where the dll needs to bin
    with that system. If you're using omnihttpd, the DLL goes in the httpd\ISAPI
    directory. There is a configuration option to specify directories where ISAPI
    dlls may be. I have tested this on Sambar and OmniHTTPd.
    The dll was written in pb-dll6 and based on a sample from
    Dave Navarro of Power Basic. 
    <FORM method="POST" action="istest32.dll">
    Company Name <INPUT type=text name=company>
    Your Name    <INPUT type=text name=contact>
                 <INPUT type=submit>

    Leave a comment:

  • jeroen brouwers
    Hi Mike, just checked the forum... bit late. You will get a lot of problems on the forum but of course, that's what it's for, no?

    To get you started (I couldn't find nice links right away) as Don, Eric and others have done for me:

    Search for Don, since he contributed quite some good internet stuff.

    I made my own variation on details which might help:

    ' get incoming
        RequestMethode = LCASE$(TRIM$([email protected]))
        SELECT CASE RequestMethode
            CASE "get"
                QueryString = TRIM$([email protected])
            CASE "post"
                QueryString = TRIM$(isapiPostData(ECB))
            CASE ELSE
                txtOutput = $ERROR_QUERYSTRING_ANSWER
                GOTO SendOutput
        END SELECT

    Remember though, you're in multithreaded mode, so be carefull with global, files IO and the like. You need to use CriticalSection (or another serialization mechanisme; CS is the simple light weight variant) for all things that are shared between threads in the same process. A simple set-up I use for all kinds of stuff that needs to be serialized, is in the code below:

        CSEntered& = 0
        TGP& = 0
        DO WHILE NOT %TRUE = %FAlse
            IF TryEnterCriticalSection( GSC1 ) > 0 THEN
                CSEntered& = 1
                ' do serialized stuff here
                LeaveCriticalSection GSC1
                CSEntered& = 0
                EXIT DO
                ' prevent endless loop
                INCR TGP&
                IF TGP& = 500 THEN FUNCTION = -1: EXIT FUNCTION
            END IF
        IF CSEntered& = 1 THEN LeaveCriticalSection GSC1

    Logging: debugging is a bit harder since it's a dll in memory if iis (or another webservice). Good tip I got: use the event log! Stress testing in IIS and logging to harddisk do not go well together (or at least it takes time to create a decent multithreaded-proof logging function.

    search for parts of this:

        lLogAPIRetVal = RegisterEventSource(BYVAL %NULL, BYCOPY $EVENTLOG_APP_NAME)
        IF lLogAPIRetVal <> %NULL THEN
            lPointer = STRPTR(sMessage)
            lReturnX = ReportEvent(lLogAPIRetVal, hErrSeverity, 0, 255, BYVAL 0&, 1, 0&, BYCOPY lPointer, BYVAL %NULL)
                ' all is mapped to 255: custom message!! (use hEventID for predefined messages)
            IF lReturnX = %NULL THEN
                lReturn = GetLastError()
            END IF
            DeregisterEventSource lLogAPIRetVal
        END IF
    Since the ISAPI is in IIS, even the ProcessID is the same.

    For IIS, keep in mind that there are application pools (from v5?) which can be tricky: each app pool is isolated, eg has it's own memory and handles. This means that your isapi is loaded once for each pool and there's no way to share memory or handles or what soever (I've tried).
    So start with 1 Apppool, stress test that first, then upgrade to multiple and work your way through.

    One more: if you are going to use the isapi as an internet wrapper to your 'real' dll and you're going to use SQL Tools in this dll, remember this (it took me a while):

    1) create a thread from the isapi to your dll (so, pass a ptr to a UDT to your underlying dll to pass the info). THe thread (of course) is created in your isapi on a function in the isapi, which in turn just calls your real dll entry function.

    2) use the Libmain\process attach to handle all global / init stuff (like SQL_Init)
    3) use SQL_THREAD %THREAD_Start at the entry function as one of the first things you do (or at least don't do sql stuff yet)
    4) get your thread unique statement number(s) by keeping a global array (protected access from the thread can be archieved by the basic function above).
    5) do you functions and try to keep variables local as much as possible.
    6) use SQL_THREAD %THREAD_Stop at the entry function as the last thing you do.

    Good thing: since the thread are all in the same process, you can keep your databases connections opened (which saves a considerable amount of time).

    Happy programming. I hope this helps a bit.


    Leave a comment:

  • Mike Doty
    I'll search again for ISAPI and see if I can find that template.
    Found postings where people gave up after many years.
    Fastcgi is easy, but I'll look again.
    Any link would be appreciated.

    Leave a comment:

  • jeroen brouwers
    I've learned ISAPI many years ago and it's great: go get rid of an extra layer (an asp or page) which handles the incoming requests of users and puts it throught to your application. Thus, all libraries which are loaded to support asp(.net) are not activate. Hence, you gain tremendous speed!

    imo, CGI is fine but loads an exe upon each request which can overload your server when it gets busy. Eg, it's not multithreaded.

    Which bring me to the downside: ISAPI is multithreaded and you have yo manage the threads and be carefull with global memory. It's a bit more work this way but for me, the amount of control you get and the speed improvements are well worth it.

    Check out the ISAPI template. that'll get you started.


    Leave a comment:

  • Mike Doty
    I'm using fastcgi. Cgi is fine, but was looking for some more speed.

    Leave a comment:

  • Shawn Anderson
    I heard ASP (not .net) will no longer be supported in an upcoming version of IIS.

    I use CGI a lot (I wouldn't use anything else) and I'm wondering if it's some other issue causing your slowdown, like the database itself or perhaps a permissions problem in IIS. There is no shortage of work with CGI and AJAX.

    Leave a comment:

  • Edwin Knoppert
    ASP seems obsolete to me, unless you meant ASP.NET?

    If you don't do both ISAPI can be great since you will be able to manage all content as desired.
    And of course with PowerBASIC

    ISAPI this way will be light-weight, ASP.NET is also a learning curve but you won't need to invent the basic functionality.

    If there wasn't ASP.NET and i was forced to write html stuff, ISAPI would be my choice i guess.
    Forget CGI..

    Leave a comment:

  • Mike Doty
    started a topic ISAPI instead of ASP?

    ISAPI instead of ASP?

    Is it worth it to learn ISAPI instead of using ASP?
    Anyone used ISAPI with Abyss?
    Would it be better to use IIS than Abyss?
    Would it be better to use fastcgi (which Abyss supports?)
    Trying to increase performance over cgi database access.