Furcadia WM_COPYDATA Interprocess Commands

Furcadia seems to use a single command to transfer information between the various programs, so far I've only semi-figured out a few of them. There's still the need to deal with how the client and dream editor transfer information to each other. Part of my assumption is that the system is using DWORD's for the transfer. Some details on the data transfer first.

Window Message WM_COPYDATA

lResult = SendMessage(	// returns LRESULT in lResult
(HWND) hWndControl,	// handle to destination control
(UINT) WM_COPYDATA,	// message ID
(WPARAM) wParam,	// = (WPARAM) () wParam;
(LPARAM) lParam	// = (LPARAM) () lParam;
);

Parameters

wParam

Handle to the window passing the data.

lParam

Pointer to a COPYDATASTRUCT structure that contains the data to be passed.

Return Value

If the receiving application processes this message, it should return TRUE; otherwise, it should return FALSE.

Remarks

The data being passed must not contain pointers or other references to objects not accessible to the application receiving the data.

While this message is being sent, the referenced data must not be changed by another thread of the sending process.

The receiving application should consider the data read-only. The lParam parameter is valid only during the processing of the message. The receiving application should not free the memory referenced by lParam. If the receiving application must access the data after SendMessage returns, it must copy the data into a local buffer.

The above message includes the handle to the window which sent it, so it's also possible to get the name of the Alt which sent the message via an inverse lookup to get the title of the window and then extract the name from the title. This is assuming that you started the capture after the client starts, when a client starts, it logs into Pounce with a specific message. At which point you can add the window handle to the list of clients which are logged into pounce. A notation, when pounce starts, it does a top level search of all windows and broadcasts itself as running to all of them, at which point clients can broadcast back that they are running.

COPYDATASTRUCT Structure

The COPYDATASTRUCT structure contains data to be passed to another application by the WM_COPYDATA message.

Syntax

typedef struct tagCOPYDATASTRUCT {
    ULONG_PTR dwData;
    DWORD cbData;
    PVOID lpData;
} COPYDATASTRUCT, *PCOPYDATASTRUCT;

Members

• dwData
  • Specifies data to be passed to the receiving application.
• cbData
  • Specifies the size, in bytes, of the data pointed to by the lpData member.
• lpData
  • Pointer to data to be passed to the receiving application. This member can be NULL.

In the case of Furcadia messages, dwData is generally 0x0, while cbData is the length of the message, as per specs, and lpData points to the data structure which is being passed. The structure of messages generally seems to follow the format of:

FURCDATASTRUCT Structure

Syntax

typedef struct tagFURCDATASTRUCT {
    DWORD dwMagic;
    DWORD fcCmd;
    DWORD fcLength;
    PCHAR fcData[]; 
} FURCDATASTRUCT, *PFURCDATASTRUCT;

Members

• dwMagic
  • Magic to positively inform the Furcadia component that this is a valid message from another component of Furcadia, generally is fc10 (0x30316366).
• fcCmd
  • The command that is being sent.
• fcLength
  • A repeat of the length of the data segment, includes this header
• PCHAR[]
  • The rest of the message.

The message can contain more than just ASCII characters, and is generally not NULL terminated. Some exceptions exist, currently, for example, when Pounce sends the FDL command to the client, the name of the target Alt is first in the overall block and is NULL terminated, along with the target dream FDL in the form of furc://dreamname/.

Furcadia -> Pounce messages.

• CASE 2001 (0x07D1) [%SpotOnline]
  • Client seems to send this message when it spots someone online that Pounce has notified the client exists in the list and has notified the client that the target went offline.
• CASE 2003 (0x07D3) [%UpdateWhisperInfo]
  • Sent whenever the client gets a whisper, the PCHAR data of the message is in the from or whisper from whisper to with there being a distinct space between the two names, both names are in shortname format.
• CASE 2004 (0x07D4) [%ClientLogsIn]
  • Sent when a client logs into the server, and hence Pounce, the name part is in Full Name format.
• CASE 2005 (0x07D5) [%ClientLogsOut]
  • Sent when a client window is closed, and hence is logging out of pounce, the name is in shortname format.
• CASE 2006 (0x07D6) [%FurreWhispers]
  • Sent whenever a client initially receives a whisper. Can be either listed in pounce or not, doesn't matter.
• CASE 2007 (0x07D7) [%AddFurreToPounce]
  • Message from the client that the name, in shortname form, is to be added to the Online List.
• CASE 2011 (0x07DB) [%FurreSpeaks]
  • Message from Furcadia whenever someone speaks, this is what causes them Logged In / Logged Out messages on the test server when the other party is not logged in the main server.
• CASE 2012 (0x07DC) [%RightClickWhisper]
  • Sent whenever you right click on someone and select whisper, the name is temp added to Pounce, if it does not exist already in the online list. The terminology is confusing but valid as far as I'm concerned.
• CASE 2014 (0x07DE) [%AddDreamToPounce]
  • Message from the client to add a dream to the list, sent currently via the Add Dream button.
• CASE 2015 (0x07DF) [%AddVisitedDream]
  • Sent whenever you enter a dream and the FDL is fetched by the client. This event happens when the client gets the ]C command from the server, for example ]C0furc://vinca/. The terminology is confusing because if the name is already in the list, it's just tagged as being online.

Pounce -> Furcadia messages

• CASE 2 (0x02) [%JumpIntoDream]
  • Message sent to the client when the right click GoTo is used from pounce on a dream name. The format is that the name of the alt is a NULL terminated string in shortname format starting at offset 12 and the FDL is also a NULL terminated string starting at offset 140.
• CASE 1001 (0x03E9) [%PounceStartUp]
  • Sent to inform clients that Pounce is now running.
• CASE 4002 (0x0FA2) [%PounceShutDown]
  • Sent to inform clients that Pounce is shutting down.
• CASE 1004 (0x03EC) [%WhisperToWho]
  • Whisper Who as Whom when selected from the right click menu in pounce, offset 12 is whom you're whispering in the shortname format as a NULL terminated string, and who you're whispering is at offset 140, also as a NULL terminated string.
• CASE 2001 (0x07D1) [%NotifyOnline]
  • Someone in the list came online, the name starts at offset 13, with offset 12 being used to inform the client whether or not the name is a permanent online listed name. If it's Zero (ascii 0x030) then it's a temporary name.
• CASE 2002 (0x07D2) [%NotifyOffline]
  • Someone in the list went offline, see above for formatting.
• CASE 2016 (0x07E0) [%NotifyUploaded]
  • A listed dream is now online, dream name starts at offset 13 with offset 12 being using like the name message above.
• CASE 2017 (0x07E1) [%NotifyUnloaded]
  • A listed dream is now offline, see above for formatting.
• CASE 1005 (0x03ED] [%IgnoreFurre]

Other -> Furcadia messages

A couple of other messages, not fully investigated, but listed here anyway.

• CASE 1 (0x01)
  • This is from FurEd to indicate that the client should load the colors and specifications set. Unsure as to the exact format of the structure, but this message is sent specifically to the client which contains the name of the alt file being edited.
• CASE 3 (0x03)
  • This is from Config to indicate that the client needs to reload the settings. The setting appear to be embedded in the data chunk, but the exact layout of the contents is unknown.
• CASE 32769 (0x08001)
  • Dreamed sez Meow! Literally, that's the contents of the message. I've observed occasions where it only sends Meo instead of the full Meow!<bh:10> so this may be a bug, and yes, the message includes an extra character at the end consisting of a linefeed (0x010).