stripes@eng.umd.edu (Joshua Osborne) (02/06/90)
In article <9001301848.AA06945@xenon.lcs.mit.edu> keith@EXPO.LCS.MIT.EDU (Keith Packard) writes: [...] >With the occasional exception of MIT-SHM (the SYSV-specific shared memory >extension), these extensions are supported on every platform which runs >the MIT sample server. The MIT's X11R4 server under SunOS claims to have MIT-SHM, I am assumeing that it is a way for clients to talk to the X server & that Xlib takes care of using it. If that's true when does Xlib decide to use it? On connections to "unix:0", or to ":0" (well "unix:N[.M]", etc)? Is it faster then UDS, or is it just for SysV's without UDS? (UDS=Unix Domain Sockets) Also what is included in MIT-SUNDRY-NONSTANDARD, it includes the MIT-COOKIE-1 auth. protocall, does it have anything else? I'm willing to RTFM for all of this, but I can't find a FM for this stuff... > >Keith Packard >MIT X Consortium -- stripes@wam.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood Who needs friends when you can sit alone in your room and drink?
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/06/90)
The MIT's X11R4 server under SunOS claims to have MIT-SHM, I am assumeing that
it is a way for clients to talk to the X server & that Xlib takes care of using
it.
Not quite. MIT-SHM is not a general-purpose shared-memory transport, it's an
experimental extension to support shared-memory pixmaps and Get/PutImage.
Also what is included in MIT-SUNDRY-NONSTANDARD, it includes the MIT-COOKIE-1
auth. protocall, does it have anything else?
It does not include MIT-COOKIE-1 (that doesn't require an extension), it only
includes requests to support "xset [-]bc". Not very interesting.
I'm willing to RTFM for all of this, but I can't find a FM for this stuff...
These are both experimental, we didn't get around to writing documentation,
sorry. Use the Source, Luke. It's usually pretty obvious from the Xlib
interface routines.