Organization ideas for the source code / projects

[alkrun]

This is just a suggestion, sort of a high-level organizational setup.

I've written an NT/2K/XP service that will launch the minilogin, world, and zone servers in the context of an NT Service. It helps cut down on desktop clutter from running 7 console apps at once and makes it easier to run eqemu on an NT machine where you might not always be logged on.

Anyhow, I just had some suggestions I wanted to get feedback on. Spawning processes is a bit ugly in a service, you can't gracefully handle errors that might happen, there's no exception handling and the apps you spawn will just display an error box and that can hang the service, causing you to be unable to stop/start it.

What I'd like to see is to take the world and zone server projects and turn them into simple DLLs that wrap up their functionality in DllMain and could (later) export some other functions and variables to get status about zone servers, launch more on demand etc...

Then, we could create a new subproject, eqemu which would be the single application that the user runs to start up their server. This single process could manage login, world, and zone servers. We could also add the ability to launch this app as a service on supported platforms. This app would use a configuration file or the registry to store information about what kind of servers it should launch and how many zone servers, ports etc...

Anyway, that's my suggestion, I could handle a lot of those changes, but I just wanted to get everyone's feedback before starting so I didn't waste my time if nobody else was interested.

[alkrun]

Also, with a setup like this, it would be possible to just distribute a working login.dll server and not distribute the source code for security reasons etc...

[Pyrotek]

We've tossed around this idea before. It would definately be an improvement, but we've focused on in-game functionality.

[alkrun]

Well I wouldn't mind doing this while I get familiar with the code, as long as it's something people would like to see or have some interest in.

[Zeitgeist]

For the record if anyone cares I've known Alk for some time and having seen his work before he is fast and does solid work. I, for one, would scream for joy if you would take this on (thanks for letting me be your guinea pig!). I think this would be a wonderful way to do it, especially considering the full login could be released in a form that doesnt tread on security issues. =)

[Ztaar]

I am strongly against this idea. It might be a reasonable thing to do if the servers were meant to run on Windows, but it is not. It is meant to run on Linux too, which means that we would probably have to have 2 different source-trees.
Besides, it's true that spawning processes and exception handling are a pain on Windows, but why do you think Verant runs their servers on UNIX ? ;)

[alkrun]

Ztaar, this process could be adapted to shared libraries on *nix platforms. No need to split up the source, just use a few more #ifdefs.

But I think I'll put this idea on hold for now. I'll get the service wrapper running with the executables and just use redirected input for the child processes. If something comes up later maybe we can take another look at this.

[Timothius]

Just a correction and a comment. I am pretty sure (95%) that verant runs on a NT based OS, Ive asked several sources and gotten the same reply, NT not sure what version.

As far as the linux builds go, I dont even think the current build 0.2.0 is compiling correctly without some modification to the source(Correction, it does compile, but the source had to be modified). And a good majority of our users are windows based, I would hate to see good initiatives like this go away. I would personally love to see zone and world go dll and maybe some day have some sort of management front end to control them.

Timothius

PS - Again, this is just my opinion, I do not claim to be a coder, or part of the Dev Team. Just adding my 2cp to the discussion.

[Raptor]

Oh, wait a moment.

The corrections on the 0.2.0 tree are fairly minor and easy to make. It would be somewhat hilarious to concentrate on Windooze support, when Unix support is already built in.
I'm seeing that most of the users are Win Users NOW, but everyone knows, that 90% of the Gameservers out there are based on Linux/*BSD.

Just my 2 cents and keep the flames low ;)

[Pyrotek]

I don't know if you new guys are aware of this, but our project originated on linux. We moved to Windows after several releases due to the majority of our userbase being win32. The source is nearly 100% cross-platform. An issue arose with threading the zone server, but as you can see others have contributed in that respect.

With the current state of the code, I find the most stable setup to be a *nix SQL server with win2k World/Zone binaries.

Oh and Verant hosts EQLive from win32 boxes...

[Zeitgeist]

I don't see why the service wrapper would cause such a problem. This is starting to sound like a religious debate. I'm a longtime user of both Windoze (gods help me!) and various *nix flavors and I'm all for making the project easier and more stable on both platforms. Alk's wrapper will not require drastic source changes and as Pyro pointed out for those who weren't here, this all started on Linux.

[Raptor]

First of all: I'm new here and didn't know it started on *nix.

But I didnt want to start a holy war here, since thats fairly useless (*nix or windooze, Linux or BSD, OpenBSD or FreeBSD... who cares??!?)

I'm writing this from a Win client, since its more comfortable than Linux (dont have to switch OS to play sth), but my servers are running Linux.

I appreciate the idea of a wrapper for Win Servers, since theres no startproc/nohup/screen whatsoever in Windooze :)

I just wanted to mention, that this should not be done by sacrifying cross-plattform devel. (especially if there would be a precompiled .dll or .so)

[Pyrotek]

It would be handled with #ifdefs just like the other code differences.

[Vassar]

I would love to see this myself..

[Psyruss420]

I would also love to see this. Excellent idea !:D

[Zeitgeist]

Raptor-- I was a little cranky there, I assumed that you were barreling down a path that you weren't. I see exactly where you are coming from and as Pyro and Alk say no need to worry about sacrificing code compatibility. =)