-------- Forwarded Message ---------
Original: DATE..... 14 May 2019,  05:42p
Original: FROM..... evelopers@winserver.com">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-ver...
0)#midl64b_i
ntro
<https://docs.microsoft.com/en-us/previous-ver...
n.10%29#midl
64b_intro>



--
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
-!------------------------------------------------------------------
-


begin:vcard
fn:Hector Santos
n:Santos;Hector
email;internet:winserver.support@winserver.com
tel;work:305-248-3204
version:2.1
end:vcard

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

... Platinum Xpress & Wildcat!..... Nice!!!!
--- Platinum Xpress/Win/WINServer v7.0
 * Origin: MicroNet: Omicrn Theta * Southaven MS * winserver.org (618:100/15)