Member Discussions

Hello,

I gather the more avid readers of these fora will know what I'm working on, but it really doesn't matter in this respect, so I'll skip right to the point (even if it's very taxing on me).

- I'm downloading cygwin and will be using it to run the code I'm writing - to see if it runs like it's supposed to - but can I be certain that it'll run just the same on the server that it'll eventually be running from?

- I've been using bloodshed's Dev-cpp to write, read and compile code, and that's a windows application. Has anyone experienced problems with compiling in windows and running the code in *nix environments?
(I haven't yet, but those were all very simple programs).

- Lastly, my confused newb mind has been trying to grasp what, exactly, the usual method of building the code is. That is, do you normally build the code on your own machine, test it, and then port it to the remote server - or do you code 'inside' the server, while online?

Massaria

PS: Another question: How about making a poll on the front page? I've often thought it would be nice to have some statistics on prefered code bases, servers, compilers, how long players play per session, how many sessions per week, what their primary requirements are to features etc. etc.
Just set up a small square somewhere, post a question and have 3-5 answers/buttons to chose from.
I think it could provide an excellent tool for admins to improve on their muds.

I use Bloodshed's Dev-C++ as well. I'm not the biggest fan of Cygwin myself, so end up porting my code over to windows for testing purposes. Changing the code to work under Dev-C++ follows a lot of the same steps as porting it for MSVC++ 6.0.

You could find one of those and get it to run with little to no fiddling, or use it as a basis for changing your own code over. Check out comm.c and merc.h/mud.h for the differences in most Merc derivatives. There are some changes. Mostly in the networking parts of the code so you could also do it if you know some things about socket programming.

I would never advise actually running a mud from windows, even with cygwin. A lot of people give the reasoning that *nixes arre generally better for this type of application. Some disagree. The best reason that I see for not running a mud in windows full time is that most codebases are writen with *nixes in mind. The original program was never intended to run in windows. It's one thing to port a copy over to windows for testing purposes. It's another to run a program full-time in an operating system it wasn't intended for without having a full understanding of the program.

I normally port all my code to windows because there are a few things that I can't do in my linux partition. I like working on code, and testing it then, so this works for me. I go and test it on linux afterwards though as well. Then it goes to the server where I do a clean compile, and fix any errors that crop up there. Just because I have linux on my computer, and the server is running linux, doesn't mean they will always compile the same anywyas.

Thanks Nym, if you'll permit me to further encroach on your time, I'd appreciate elaboration on a few points. I'm a total newb Nym, I need it spoonfed slowly and in manageable portions ;-)

You could find one of those and get it to run with little to no fiddling, or use it as a basis for changing your own code over.

Those being MSVC++? As far as I can tell it's a tool for debugging graphical code. Why would I need that?

Just because I have linux on my computer, and the server is running linux, doesn't mean they will always compile the same anywyas.


Why? What does the compatibility depend on?
When you say errors, what severity of errors are we talkling about - renaming libs or major changes in many lines?

Thanks in advance,
Massaria.

Those being MSVC++? As far as I can tell it's a tool for debugging graphical code. Why would I need that?

No it's Microsoft's C/C++ compiler. No more Visual or graphical than Dev C++ or GCC.

Cygwin is a posix emulator. If you write C/C++ on cygwin you can expect it to compile cleanly on a Unix, Linux, OS X or BSD system if you stick to Ansi and Posix calls. There'll probably be a minor change, a headr missing, a library located in a diffeent directory, a particular function missing; nothing major.

I stress compile above because in reading your first post I have a suspicion that maybe you think the compiled executables are compatible. That's definately not the case in Cygwin executables, and sometime not the case between OS X/BSD and Linuxes.

Dev C++, MSVC++, Borland C/C++, Intel C/C++, Digital Mars C/C++, LCC are windows compilers. They target the Windows API, which means that many changes might be needed porting beteen them and Linux/BSD. Most of these changes are in networking/sockets code, and in process control. Many of the C runtime libraries (MSVC RTL and Borland runtime I'm most familiar with) have posix or very close to posix APIs though.

You can write C and C++ code that is very compatible with minimal changes following a few simple rules. Prefer ANSI functions over Posix, prefer Posix functions over the OS API. When in doubt check the man pages the information is there. It's also in the MSVC and Borland help files. I believe LCC also has documented this about their runtime in their help files.

I myself have in the past compiled my code on my home machine and ftp'ed the executables up. This works only if you have a similar OS as the host or if you have a cross-compiler.

Tyche's right. Cygwin should be compatible with any *nix system. There might be slight changes as he said. My server runs linux, and I test and compile my code on my linux partition. I normally get the exact same results when I compile on the server as on my linux partition. I could probably just upload my executable and data files such as the areas and player files if I really wanted to. I guess I really just do it out of habit.

I try to limit myself to ansi code wherever I can. I'll separate out parts of the code by system if I can't though. Most things can be done in ansi though, so the whole source won't look all cut up or anything. Comm.c can end up looking quite messy though. A solution could be having two copies of comm.c, one for windows, and one for linux. This isn't really a concern if you use cygwin though.

Use cygwin if you want. It really is a great program that is an option for people who either don't have an extra computer, or don't want to partition off a section of their hard drive to linux. I just personally don't care for it and don't mind putting in the extra work to get code that will work in both windows, and *nixes. I haven't used Cygwin a whole lot myself, so someone with more experience, such as Tyche, would be a lot better at informing people of what all it is capable of. I would consider what he says. He generally gives great advice and knows what he's talking about.

The best solution to me though is a Linux partition. The second option is just have a server where you can compile and edit files. That will be where the code will be running from anyways, so this option might work nicely for you. After that I would go with what you are familiar with. For me that was windows and MSVC++. I have a fairly old copy (Both the 16 and 32 bit editions of 1.0) that I started with, and am cheap so I now use Dev-C++. I could very easily see where someone with *nix experience would favor Cygwin. I thought it might help if you knew the whys behind my use of Dev-C++ so you could better decide for yourself.

This thread reminded me of some stuff I was working on. I did a number of mud ports and just bundled them up and released them. I posted this in another thread, but you might want to check out oldinterface.c in the tinymud 1.5.2 port and comm.c and modify.c in the diku-alfa port, and my global-hackish os.h and os.c files which attempt to bring most of platform and compiler differences into one place.