EQEmu source for FreeBSD 4.5-STABLE

[crept]

So far the code base with my (very) small changes compiles and runs on these "release" platforms:

OpenBSD 3.0-RELEASE - does not exhibit the 100% cpu utilization problem that my test with FreeBSD did. I'm guessing the problem was with my particular build of FreeBSD (4.5-STABLE from 2/8/02)
FreeBSD4.x-RELEASE - Both 4.4 and 4.5 have an issue where the world and each zone server try to hog the cpu to themselves.

Does not compile on:
NetBSD 1.5.2 - The compiler used in this version (egcs 1.1.2) does not understand the -pthread option. While it still compiles, it chokes when trying to find the pthread headers.
FreeBSD3.x - The compiler used in this version (gcc 2.7.2.3) chokes on some syntax.

Please note that these are fresh installs of the respective operating systems, with mysql-client installed. No other tweaking was done (in other words, it might still be possible to get this code to compile on those platforms)

Nice work folks =)

I'll update this post as I test more platforms.

I made some modifications to the source to get it to compile on freebsd. It may compile on other UNIXes as well but I have yet to test them (I have access to FreeBSD, OpenBSD, and Solaris/SPARC 8, and can whip up a NetBSD box easily). I'll see how that goes and post an update.

Brief overview of the changes:

- Since make for Linux and BSD are different (gmake vs pmake (I think?)) A slight change had to be made to the Makefiles in world/ and zone/.
- Some headers had to be added to some of the source files. They were stdarg.h and sys/types.h.
- "_NP" had to be removed from some PTHREAD constants since they are not in FreeBSD's pthread.h.
- "#include <mysql.h>" had to be changed to "#include <mysql/mysql.h>".

To compile you need to have mysql-client from ports installed (at the minimum), for libmysqlclient.so and mysql.h.

Once you have it compiled and running, you will probably find each server process (the one world and each zone process) will try to use 100% CPU. I've been told this doesn't happen in linux. I am still narrowing down the problem, but I believe it has something to do either with the loops which call accept() to see if a connection has been made, or the Sleep(x) aka usleep(1000x) functions. I have tried changing some of the accept() loops to select() calls, and that seemed to help some although the bins seemed to become less stable as a result. This is the first time I've tried network programming, so this is sort of a crash course for me =). I'll keep banging away at it though. These changes ARE NOT in the included tarball, since they cause instability. The tarball is just the release source modified so that it compiles on FreeBSD (as well as all the carriage returns stripped out =))

I was able to log in and play with just minilogin running in windows, and the world, mysql, and zone servers running in freebsd. Everything seemed to run as well as when they were all on the windows box.

I was going to attach the entire tarball, but it is too big so I am just attaching the diff file. This diff was made against a source tree that has had all carriage returns removed (which, by default, were not stripped when I unzipped it in freebsd) so keep that in mind when trying to patch it.

Please let me know if you have any comments or suggestions =)

[Windcatcher]

Isn't OSX based on BSD UNIX?

EQEmu on a Mac...now there's a thought...

[DeletedUser]

the byte order is different on the Mac Processors. It seems Intel type processors are small endian, while the rest of the computing world is big endian. Without someone porting the packet structures to be universal in the packing the byte order, it wont run on anything but intel.

I have a sparc/linux box Im waiting to run it on, but no idea how to redo it myself so it will.

[theCoder]

Endian-ness would probably be a big barrier to porting to non-x86 architectures. I think that the Internet has a standard endian (probably big) and there are OS functions that on little endian machines flip the bits around. But I doubt the EMU uses those functions since it was derived mainly by packet sniffing.

One thing that could be done would be to encapsulate the necessary constants in a macro like ENDIAN_CORRECT. That macro could be defined like so:

#ifdef X86_ARCH
// little endian -- leave the same
#define ENDIAN_CORRECT(a) (a)
#else
// big endian -- flip the bytes
#define ENDIAN_CORRECT(a) \
(((a & 0x000000FF) << 24) | \
((a & 0x0000FF00) << 8) | \
((a & 0x00FF0000) >> 8) | \
((a & 0xFF000000) >> 24))
#endif


Of course, that macro would only work for 32 bit integers, but the compiler would take care of actually computing the new value instead of it being done at run time.

The trick would be making sure that every instance of a constant like this is put inside the macro, which would take a while. And I'd imagine that there are probably places in the code that assume little endian-ness that wouldn't necessairly be easy to spot.

[crept]

Mac OS/X, as I understand it, is actually a fancy-pants proprietary X/Server (designed by Apple) sitting on top of Darwin (http://www.darwin.org). Darwin is based on FreeBSD 3.5.1. Even though OS/X encompasses both Darwin and the X/Server, Darwin is available separately and free from the Darwin website.

[Lyenu X`Arie]

Someone was explaining to me one day how to standardize the sizes of them to all be "small-endian". So if I can figure that out I'll add it in for you guys =/

[ti1t]

Well since it needs done I'm going to work on the big endian compile issues. An ultra-sparc platform running linux will be my test bed and if anyone else is interested in working on this let me know mitch@usvoicedata.com.

[DeletedUser]

I'll help test, I have a SMP SS20 sitting here (yes, I know it isn't an ultra, but blah!). hehe

[ti1t]

Ah people still use those ? Think I have one sitting in my closet still, nice little web servers.