So I'm running a codebase based off of… Some version of Smaug 1.4a, and I'm compiling it with Visual Studio 2010. Most stuff works fine, but… Readdir seems not to be working. This affects a few things - loading the building list, loading corpses, and building the wizlist.

typedef struct dirent
{
    char *	d_name;
};

typedef struct  
{
    HANDLE		hDirectory;
    WIN32_FIND_DATA	Win32FindData;
    struct dirent	dirinfo;
    char		sDirName[MAX_PATH];
} DIR;


DIR *opendir(char * sDirName);
struct dirent *readdir (DIR * dp);
void closedir(DIR * dp);

DIR * opendir (char * sDirName)
{
    DIR * dp = malloc (sizeof (DIR));

    dp->hDirectory = 0;      /* if zero, we must do a FindFirstFile */
    strcpy (dp->sDirName, sDirName);  /* remember for FindFirstFile */
    return dp;
}

struct dirent * readdir (DIR * dp)
{

    /* either read the first entry, or the next entry */
    do
    {
	if (dp->hDirectory == 0)
	{
	    dp->hDirectory = FindFirstFile (dp->sDirName, &dp->Win32FindData);
	    if (dp->hDirectory == INVALID_HANDLE_VALUE)
			return NULL;
	}
	else
	if (!FindNextFile (dp->hDirectory, &dp->Win32FindData))
	    return NULL;

	/* skip directories */

    } while (dp->Win32FindData.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY);

    /* make a copy of the name string */
    dp->dirinfo.d_name = dp->Win32FindData.cFileName;

/* return a pointer to the DIR structure */

    return &dp->dirinfo;
}

void closedir(DIR * dp)
{
    if (dp->hDirectory)
	FindClose (dp->hDirectory);
    free (dp);
}

And, finally, the application;

dp = opendir( GOD_DIR );

  ilevel = 0;
  dentry = readdir( dp );

  while ( dentry )
  {

It simply skips the while loop. I checked the error code on readdir and it gave me this:

readdir(): No such file or directory

GOD_DIR is the default "../gods/"

I have tried putting the argument directly into the call, I've tried putting the entire directory path in there… I don't really know what to do. I searched around but I couldn't find much.

opendir/readdir are POSIX things from unixland. I suspect you have to do something funky to make Visual Studio use the posix versions instead of some other windows native version.

Haven't really used visual studio with unix-origin code though, so I'm just guessing. :)

Yes, this was a bug in the stock code. FindFirstFile() takes a pointer to the name of file to search for.
The current opendir() function in the code I work with:

DIR* opendir(const char* sDirName){
    DIR* dp = (DIR*)malloc(sizeof(DIR));

    dp->hDirectory = 0;/* if zero, we must do a FindFirstFile */
    strcpy(dp->sDirName, sDirName);/* remember for FindFirstFile */
    strcat(dp->sDirName, "*");
    return dp;
}

The fix was done about 15 years ago, but the only part of how this differs from yours
that is needed for the fix is the strcat() line.

Grab a copy of my windows porting routines. You'll find opendir, readdir and other things like crypt, gettimeofday.
[link=file]685[/link]

Thanks for the help, you guys!

Visual Studio's compiler doesn't have direct iterations of these functions, so the best you could do would be to simulate it like Nick did in this snippet. Also, I'll check out that file, Tyche, I've been feeling a little irresponsible as a host/owner not having crypt enabled, which was disabled for windows on my game's version of smaug.

Just as a suggestion… I highly recommend not using crypt(), and instead just grabbing a sha256 implementation that you can compile directly into your MUD. The one I used was from a BSD distribution so the license is compatible, and that way you never have to worry about player passwords being "lost" because your host doesn't have crypt, or implements it differently, or whatever reason springs up in a few years. :)

The crypt() I used for my the Windows ports matched the ones in use on the platforms I tested which were FreeBSD, Redhat, Ubuntu, Debian, Suse, and Cygwin.
The nice thing about including and compiling the crypt() source itself (or another algorithm) with the mud, is that you can use it on all platforms instead
of relying on whatever algorithm a system's crypt() happens to be using.

>I highly recommend not using crypt(), and instead just grabbing a sha256 implementation

http://linux.die.net/man/3/crypt

The glibc2 version of this function supports additional encryption algorithms.

If salt is a character string starting with the characters "$id$" followed by a string terminated by "$":
$id$salt$encrypted
then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password string is interpreted. The following values of id are supported:
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.

Since the OP is using Windows, I'm not sure the glibc2 is going to be useful for him.

Well it is more a Visual Studio problem than a Windows one then, when developping my own mud I was using Cygwin under Windows (through Eclipse) (nowadays I just use a Virtual Machine as my computer is fast enough)
Since I never used Visual Studio, I don't know it is implied you cannot use cygwin to compile.

Using cygwin would defeat the only valid reason (IMHO) of running a MUD on windows… namely, the ability to have a real IDE with useful live debugging and refactoring tools. If you were to hook a different compiler into the interface, you would lose so many of the things that make the IDE worthwhile, you might as well just be using a plain text editor. And then, there's no reason to use cygwin, when it's just as easy to run a VM and use native linux tools.

YMMV, of course.

>namely, the ability to have a real IDE with useful live debugging and refactoring tools. If

Heh I guess you are not putting Eclipse in this category then :) Fair enough.

>And then, there's no reason to use cygwin, when it's just as easy to run a VM and use native linux tools.

Yep as I said, it was ony because my computer was not powerful enough at that time to run one (so running cygwin in Windows was my solution of keeping a 'linux' toolchain without the sucky desktop attached to it)

But I was jsut saying that cypt() can do sha-256, just depends on where and how you use it. Using your own implementation is somehow dangerous, unless you are 100% sure it works.

Agreed. That's why I suggested using the one provided by the FreeBSD/OpenBSD projects, since it's used in lots of systems, and is BSD licensed, not GNU licensed. We all know the issue of Dikurivatives and GNU licenses. *eyeroll*

Quix hit the nail on the head with why I'm running with VS. Live debugging with it is very smooth, at least for me. I've used cygwin and a virtual machine both on past projects and found neither to leave as pleasant a taste in my mouth.

There are many addins that allow you to use other compilers and debuggers from Visual Studio. Like WinGDB and
VisualGdb. However, they only work with the VS commercial versions.