Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    WILDCAT!_SUPPORT    |    Support for the Wildcat BBS software    |    1,697 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 867 of 1,697    |
|    Robert Wolfe to All    |
|    [Developers] Wildcat! v8.0 Status Update    |
|    19 May 19 11:53:52    |
   
   TID: PX/Win v7.0 PX28-1176M   
   MSGID: 1:116/17 2E95F2B4   
   TZUTC: -0500   
    -------- 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:   
      
   *DoorInitialize*   
   DoorCharReady   
   DoorEvent   
   DoorGetAvailableEventHandle   
   DoorGetOfflineEventHandle   
   DoorHangUp   
   DoorRead   
   DoorReadPeek   
   DoorShutdown   
   DoorWrite   
      
   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:   
      
    WriteToPreDoor("Set   
   WildcatServerContext="+GetWildcatServerContextHandle())   
      
   and then when the door exe starts, it calls DoorInitialize() which   
   reads the environment string "WildcatServerContext" to get the   
   context   
   handle "wch"   
      
    DWORD wch = StringToNumber ( GetEnv("WildcatServerContext") )   
      
   and passes that to the API function:   
      
    WildcatServerCreateContextFromHandle(wch) // CLONE the   
   session   
   BY NUMBER   
      
   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   
   to   
   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   
   "Clone"   
   a user session and this uses the User Session's unique challenge   
   String. You can see the session string for a user session by   
   calling:   
      
    Print "Session Challenge String: "+GetChallengeString()   
      
   Each Wildcat! session gets a new unique challenge string when the   
   API   
   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,   
   a   
   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   
   that   
   the API would be backward compatible or forward compatible. But the   
   64   
   bit version will demand more API functionality and compatibilities   
   and   
   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   
   ntro   
   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca