Shelxtl XP on a Mac

Shelxtl XP, written by George Sheldrick, used to work very well under OSX 10.4. With the X11 version that comes with OSX 10.5 and 10.6, however, performance is unpredictable at best. With PROJ, rotation of small structures is painfully slow, but for larger structures and extended atom lists, such as what you get after GROW or MGEN, rotation can be fine. The official explanation is that the slow down is caused by "many layers of inefficient code", but because large atom lists seem to rotate quite well in PROJ, I suspect the official diagnosis is not right. If that were the reason, then why did it work so well under OS X 10.4, and why does performance bog down only for small atom lists ? I've also noticed that PROJ rotation on my newer 64 bit linux boxes can be choppy and unpredictable. Maybe it's a 64bit vs 32bit issue, or a race condition or similar nonsense. Either way, I bet a fresh compile would solve the problem, but there's no way to tell because the source code is not available.

Note: This fix works up until OSX 10.6.8. It does not work on OSX 10.9 "Mavericks", and probably doesn't work on either 10.7.x or 10.8.x (I haven't tried). I have a new, simple workaround that does not require installation of an older version of X11, and does work with OSX 10.9. Instructions are given here.

This workaround installs the version of X11 from OSX 10.4. The way the older and newer X11 versions are organized in OSX, it is possible to have them running concurrently. The process is straightforward enough, and it is definitely worth doing. On my flaptop (15" 2.66GHz i7, 8GB, OSX 10.6.8), I have both versions of X11 installed, and they run fine simultaneously. Here's a list of instructions with some explanatory notes. It looks like a lot of steps, but really it isn't. It assumes that you will be downloading the needed files to the Desktop. This is just for convenience, it doesn't matter where you put them.

The '.pkg' package format is really just a sort of glorified folder. The regular installer senses that this package is too old for OSX 10.5 or 10.6 and does not let you install it. To get at the files inside the '.pkg', you can use unpkg 4.0. All you have to do is ...

This should give you a folder called X11_Legacy-1.1.4.1 on your desktop (or wherever you downloaded it). Inside this folder there are three other folders, named "Applications", "private", and "usr". Inside "Applications" there is a folder called "Utilities", and inside this is the old X11 app, entitled "X11_Legacy.app". Inside "usr" there is a folder called "X11R6" that contains the full X11 distribution. All you need to do is to move these two things to the appropriate places. You can ignore the "private" folder.

You need to move the X11R6 folder to the right place, which is the system-wide /usr directory. To do this, first make a '.tar' archive out of it, as follows:

You have now moved the whole of the 'X11R6.tar' to the regular system-wide /usr directory, and you have changed directory into /usr. If you take a look at the contents of the /usr directory:

You should see a few files and directories. One of them is a directory called X11, which contains the official version of X11. There is also an entry X11R6, but it is just a symbolic link to the X11 directory. You need to replace this symbolic link with the old version ( i.e. X11R6), which is contained within the 'X11R6.tar' file that you just moved in step 8 above. To ensure that you can resurrect the 'official' set up, it's best to rename the symbolic link rather than just write over it, something like this (you can call it whatever you like) is ok:

Now all you have to do is extract the 'X11R6.tar' file:

That's pretty much it. You can start an old-version xterm by clicking on the X11_Legacy.app icon. I have old and new versions of the X11 application dragged to the dock because I use them both so much.

In the official version, any program that tried to use the old version of X11 (i.e. X11R6) would get shunted automatically to the new version (X11) by the symbolic link. By replacing that link with the actual X11R6 files of the older version, you ensure that older programs will get to use the older version. Any newer program would use the files in the X11 directory rather than X11R6, and that is why they can both run at the same time.

You can restore the official version by renaming the link (mv X11R6_old_link X11R6), but I doubt you'll want to go back. You may also want to set up your own .xinitrc file, which will enable you to automatically start a customized xterm, but for the moment, the default global xinitrc will work fine. I have mine set up so that the X11_Legacy.app spawns two xterm windows - one yellow-on-black and one black-on-white for XP and XPREP respectively.

Probably the hardest part is getting past the feeling that you will screw something up. That's possible of course, but if you follow the above instructions properly, I don't think it is very likely. Having said that, I know of one instance in which a subsequent upgrade from OS X 10.6.3 to 10.6.4 appears to have killed an old version of X11. I'm not sure how or why that could have happened, but I'm told their official version of X11 still functions properly.

Update: 2010 Nov. 20^th: Update to OS X 10.6.5 did not affect my installation of the old X11.
Update: 2010 Dec. 21^st: The SHELXTL executables need to be located somewhere in your PATH. You can either alter the PATH (e.g. in .cshrc or .bashrc etc.), or place the executables somewhere that is already in your PATH. Thanks to Aaron Finke for this reminder.
Update: 2011 Jan. 4^th: For XPREP on the Mac you need to get a fresh copy of the executable from George Sheldrick's AXS server every January. You need to contact Bruker AXS (or George) for details on how to access the server. Thanks again to Aaron Finke for this reminder.
Update: 2011 Jun. 27^th: Update to OS X 10.6.8 did not affect my installation of the old X11.
Update: 2011 Jul. 6^th: There appears to be an updated version of unpkg (v4.5) available. It should also work fine.
Update: 2013 May 07^th: If you compile your own executables of platon, it might be necessary to use the following:
gfortran -o platon platon.f xdrvr.c -L/usr/X11/lib -lX11