• [Developers] Wildcat! v8.

    From Robert Wolfe@454:1/1 to All on Sun May 19 11:53:00 2019
    -------- Forwarded Message ---------
    Original: DATE..... 14 May 2019, 05:42p
    Original: FROM..... Developers@winserver.com
    Original: TO....... ROBERT WOLFE
    Original: SUBJECT.. [Developers] Wildcat! v8.0 Status Update --
    Door Developers
    Original: FORUM.... Private Email

    Wildcat! v8.0 is moving along and very soon we will be starting the
    final phase for v8.0 32 bit Update. The 64 bit version will come
    right after that. One snag I ran into in the past week was with
    the 64 bit Wildcat! Server with running WcDoor32-based doors, but
    in the end, WcCore.dll and WcDoor32.dll was updated to resolve a
    complex RPC 32/64 but address/context-handle marshallling issue.

    Lets talk about this, because this is for developers as well. I
    might have this documented somewhere, but this helps with review.
    WcDoor32.DLL (formerly Door32.Dll) has the API functions to allow
    door developers to communicate and interface with the node and
    logged in user session. They are:


    I only highlighted DoorInitialize() because the 64 bit WcServer snag
    was here. DoorInitialize is the first thing a 3rd party door
    developer calls to "Take Over" the current Wildcat! user session, so
    the user can type, display stuff to him, etc.

    DoorInitialize() does this by cloning the the user's session by
    obtaining the user's Context Handle stored in Environment Table by
    WCCORE.DLL when "Run a Door.Wcx" starts the door. Its really a
    thing of beauty.

    You prepare a wcDoor32 App in Wcconfig | Doors. When a user
    connects, a session context is created, WCH. If you wanted to see
    this context handle address, use the API function GetWildcatServerContextHandle() to display it. Callling Run A
    Door, via wccore.dll, this value is written to PreDoor.Bat:


    and then when the door exe starts, it calls DoorInitialize() which
    reads the environment string "WildcatServerContext" to get the
    handle "wch"

    DWORD wch = StringToNumber ( GetEnv("WildcatServerContext") )

    and passes that to the API function:

    WildcatServerCreateContextFromHandle(wch) // CLONE the

    to start the cloned session.

    The Snag with the 64-bit server, is it doesn't like the NUMBER wch
    passed it it. It is fine in 32 bit, but there is something we need
    look at more deeply because the last thing we want is to create incompatibility.

    Fortunately, Wildcat! API is a powerful beast!!

    Like Door32 which uses the Session's Context-Handle as a 32 bit
    NUMBER, we also have wcNavigator EXE apps that also needs to
    a user session and this uses the User Session's unique challenge
    String. You can see the session string for a user session by

    Print "Session Challenge String: "+GetChallengeString()

    Each Wildcat! session gets a new unique challenge string when the
    WildcatServerCreateContext() function is called by all the hosting
    servers. The session challenge string is also used by POP3, Radius
    and a few other Wildcat! client apps.

    So WcCore.DLL was updated to add the Challenge String to Predoor.Bat
    file, and WcDoor32.Dll was updated to read the challenge string and
    use the API:

    CString wch = GetEnv("WildcatServerChallenge")
    WildcatServerCreateContextFromChallenge(wch) // Clone session
    by Challenge String

    And it all works again using a 64 bit Wildcat! Server!!! But of
    couirse, we will try to see why using a 32 bit number with WildcatServerCreateContextFromHandle() is an issue with the RPC
    Client/Server Marshalling 32/64bit framework.

    *In short, there was a problem CLONING by number but no problem
    CLONING by string. *

    This is a deeply advanced concept and it takes a die-hard to keep at
    it. Wildcat! is pretty advanced with RPC and for the past 23 years,
    pretty solid INTER-PROCESS Communication framework, runs 24x7x360.
    Inter means it doesn't have to be the same machines. The server in
    one, the clients in others. That is why its called Remote Procedure
    Call - RPC.

    I've kept what is called the RPC WIRE the same between updates so
    the API would be backward compatible or forward compatible. But the
    bit version will demand more API functionality and compatibilities
    I think that is what the "Snag" is all about. Microsoft talks about
    all this here. Its interesting reading, also inspiring!!

    https://docs.microsoft.com/en-us/previous-versions/ms810720(v=msdn.1 0)#midl64b_i
    <https://docs.microsoft.com/en-us/previous-versions/ms810720%28v=msd n.10%29#midl

    Hector, Engineering & Technical Support
    Santronics Software, Inc.
    http://www.santronics.com (sales)
    http://www.winserver.com (support)
    http://www.winserver.com/AupInfo (Online AUP Help)
    Office: 305-248-3204

    To unsubscribe, send e-mail to wclistserve@winserver.com with
    UNSUBSCRIBE Developers in the message body on a line by itself.
    To contact the list admin, e-mail ListAdmin@winserver.com -!------------------------------------------------------------------

    fn:Hector Santos

    ----- End of Forwarded Message -----

    ... Platinum Xpress & Wildcat!..... Nice!!!!
    wcQWK 8.0 ILink Omicron Theta * Southaven MS * winserver.org

    --- QScan/PCB v1.20a / 01-0462
    * Origin: ILink: CFBBS | cfbbs.no-ip.com | 856-933-7096 (454:1/1)