Are there any alternatives to using Cygwin to compile my rom2.4 mud on my windows PC?

I've heard of a program called Code-Blocks.. am I able to compile and boot up locally on my PC with that program?

My advice is to look into a program like andLinux. These are actual linux installations instead of emulation that you can access straight out of windows. I've had success in particular with andLinux in the past.

Code-Blocks is an IDE that apparently installs and uses the Min/GW compiler which is yet another version of GCC.
There are many freely available compilers you can use on Windows… Digital Mars, Logitech, Borland, Visual C++.
I use Visual C++ myself pretty much exclusively these days.
As far as IDE's go there are dozens of them. I just use make files and my favorite editor to edit and build things.

Afaik, andLinux does not come with gcc or cpp installed out-of-the-box. (Same with cygwin).

However you can install gcc on both cygwin and andLinux*.

*NB note the ubuntu forum, andLinux is ubuntu-inside.

EDIT: hmm I think I misread the original post, alternatives to cygwin… I suppose andLinux is an alternative, but it's not an IDE. But because andLinux is Ubuntu, you can use any ubuntu cpp IDES out there, including code::blocks.

In my experience, there are limitations imposed when you are using some other
operating system's compiler on Windows. I suggest using a native Windows compiler
for generating native windows executables. I believe MS actually makes one of
them freely available, something or other "express".

-Crat
http://lpmuds.net

Yup, Visual C++ Express is a free download.

I have a code-base which is developed on Windows and targeted at a Ubuntu Linux server I have access it to.

I develop it in one place using Cygwin, and with Visual Studio Express at another. Finally, if anything goes wrong when it finally gets transferred to the target server, I have a VirtualBox Ubuntu setup (which is better than developing on a command prompt on a server a couple of hundred miles away) for correcting that.

This setup assures me that I'm developing in a reasonably platform-neutral way.

I personally use Cygwin on windows for commodity (as I use an old laptop and do not want to use Linux as a desktop) but you need to compile and run on the final target from time to time (either on the server or a virtual image that I use too, as valgrind only runs on linux)
Just know that Cygwin does not handle the memory the same way than on Linux, so your program could run fine under Cygwin but segfault on Linux.
In those case, running Valgrind usually show the problem right away. It is only hidden on Windows.

I don't think so. A test case showing this would be nice.

I can not send you a 'simple' test case as it was the result of my whole code running, but I have seen it enough to know it is not due to another parameter.
Memory management is not the same on Windows and Linux, and it leads to differences in how memory is initialized.
So where on Linux it would segfault right away , you could wait a long time before viewing the problem on Windows, because it will choose another memory segment that is free before using memory that was allocated previously.
And I did see it with same GCC version. And as I say, Valgrind showed me the problem right away. Like any memory problem, it depends a lot on what happens on the computer at the same time)
It is 'like' Cygwin on Windows was using calloc instead of malloc (I do not say it is the real reason, but it was the resulting behaviour, on Windows the memory used was 'clean' hence no real problem, on Linux it was using a segment that was filled with garbage).
I am just saying:do NOT think Cygwin will run the progam the same way, it will not concerning memory, and those bugs are already hard to find, so detecting them the sooner the better)

Debug builds on many platforms often fill uninitialised memory with recognisable values. Visual C++, for instance, fills with 0xCD, creating a potent red flag when viewed in the debugger. It's entirely possible that your version of gcc for cygwin fills uninitialised memory with zeroes (a quick test later – it appears that cygwin actually does this. Initeresting (sic)), creating a situation where your code will just happen to work.

The real problem, though, is that you were reading uninitialised memory and thus invoking undefined behaviour. One possible outcome – some would say the worst possible outcome – of undefined behaviour is that it looks like it's working. In any case, it is not the Linux or Cygwin platforms that are at fault; it is the program.

You can expect random garbage in memory returned by malloc() on Cygwin as well. It just so happens that new pages are allocated by VirtualAlloc() which does initialize memory to zeros, however repeated freeing and allocation of storage will return memory containing random data. It doesn't run the program any differently.

Right.

Yeah exactly what I was saying in : 'In those case, running Valgrind usually show the problem right away. It is only hidden on Windows.'

Its not hidden at all on windows; suggesting otherwise is misinformation. Visual Studio and most othe Windows progamming tools have integrated debuggers.

Maya/Rudha

Sigh…as you wish…guess I do not have the same definition of hide than you.

I always suggest that people just use vmware's vmplayer and downlaod a pre-installed linux vm. Set your networking to be bridged, and as long as your windows machine doesn't crash, it's just as stable as a stand-alone linux box, and works 100% the same way. IE: If you move to a real linux machine, you don't have to relearn how things work again.