About MacFire

MacFire is an implementation of the Xfire network protocol for Mac OS X. It is made possible, in part, by the work previously done for XBlaze, XfireLib, and OpenFire. XBlaze uses XFireLib, and has been my default Xfire client for a while now. OpenFire does not work on Mac OS X, but the source is available, and the author reached the same conclusions as I did about the structure of the Xfire protocol.

History

I began trying to understand the Xfire network protocol entirely for my own edification in my free time back around October of 2007. I didn't seriously entertain the notion of writing an Xfire client until I learned that some people have problems using XBlaze and AdiumX. I had some thoughts as to why that may be, and, since I couldn't find any other clients for Mac OS X, I decided to embark on writing my own full client using the knowledge I had.

Project Goal

The goal of the MacFire project is to implement a stable client that integrates closely with Mac OS X and exposes the unique features of the Xfire network. When I began this project, no other available application could fully perform either function. I don't intend to fully implement an application that behaves identically to the official Xfire client. Such an undertaking would be very difficult. Instead, I hope to implement as many functions as are feasible on Mac OS X.

Limitations (Overview)

The following is a list of features that I do not plan to implement any time soon, if ever. These are features supported by the official Xfire client. Descriptions of the technical reasons for some of them are below.

Limitations - In Game Support

The most unique features of the official Xfire client on Windows are its in-game capabilities. It does this, as I understand it, by injecting itself into running games. Doing so allows the Xfire client to obtain access to the screen and user inputs (the keyboard and mouse), even when the game is being run full-screen.

MacFire will not support any in-game capabilities any time soon. The following is a somewhat technical explanation for why this is the case. If someone can point me to straightforward ways to accomplish these tasks, please post or send me (Archon) a personal message on the forum.

Injecting code into another application is not straightforward. Doing so is a potential security risk, so OS X doesn't make it easy. I believe in-game support on Windows requires administrator access. The equivalent on OS X would be Super-user or Root access. In other words, if it's possible, it would likely require the user enter their password whenever they wanted to do so. I think there may be utilities that can do so, but they sometimes have to use undocumented programming interfaces in OS X, which can break from release to release.

So, assuming you could find a way to inject code into another running application, the second major roadblock would be to display something onto the screen. When most games run full screen, they lock out anything else from being displayed. So, MacFire would have to inject itself into the game and somehow get a handle on the main graphics context (likely OpenGL, but not necessarily). Then it would need to add additional drawing commands onto after the game's existing drawing commands (to avoid corrupting the contents of the game's screen). As of this writing, I am not aware of any APIs in OS X that could do that.

The last major roadblock is probably the hardest (as if the others weren't hard enough). Unfortunately, Mac OS X does not provide a collected input API like Microsoft does with DirectX. The mechanism that many games (probably) use is to use what's called the HID Manager. In simple terms, games hook at a low level into the USB driver interfaces. While it may be possible to intercept key presses (again, assuming MacFire is injected into a running game) to use for chat functions, I don't know how you would prevent the game from also seeing those key presses. You would probably have to inject code into the OS X kernel in the driver stack to do so.

These are the three major roadblocks (perhaps four if you include kernel code) that I see for implementing in-game support for MacFire.

Limitations - Skins

The official Xfire client supports skinning. It does this as far as I can tell by providing a number of hooks that the skin definitions use to lay out the window and set up unique looks. While this is a feasible task, it is really beyond the scope of the MacFire charter. It would also be a significant amount of work.

Limitations - Downloads

Xfire includes a substantive download system that users can use to download game updates, Xfire client updates, and other things. Most of those are unique to Windows, and would serve no purpose for Mac users. I am not aware of any mechanism for users to submit their own files, so adding Mac files is probably not possible.

I would like to implement support for retrieving updated game description files and new game icons, which are updated regularly by the Xfire team.

Limitations - Screenshots and Movies

Xfire can take screenshots in-game and upload them to the Xfire servers for you to share with other Xfire users. As of Xfire client version 1.86, they added limited support for in-game video capture. I have no plans to implement either screenshot or movie capture. If there is sufficient interest in the future, I may add the ability to upload arbitrary files that are taken with built-in Mac OS X screen capture or other utilities like Snapz Pro.

Limitations - Sending Server/Port Info

This would vary from game to game. I am unaware of a way to do this in a general manner. I'm not certain how the Xfire client does this; I know many Windows games support command line arguments. I have not explored this in detail, so it's possible this could be done easily. I was unable to figure it out using Halo, so I did not look further.

Last Updated 2008-01-26, 3:13 PM CST by Archon