02 Jul, 2014, Amun wrote in the 1st comment:
Votes: 0
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.
02 Jul, 2014, quixadhal wrote in the 2nd comment:
Votes: 0
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. :)
02 Jul, 2014, Sharmair wrote in the 3rd comment:
Votes: 0
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.
02 Jul, 2014, Tyche wrote in the 4th comment:
Votes: 0
Grab a copy of my windows porting routines. You'll find opendir, readdir and other things like crypt, gettimeofday.
[link=file]685[/link]
03 Jul, 2014, Amun wrote in the 5th comment:
Votes: 0
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.
03 Jul, 2014, quixadhal wrote in the 6th comment:
Votes: 0
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. :)
03 Jul, 2014, Tyche wrote in the 7th comment:
Votes: 0
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.
04 Jul, 2014, Rarva.Riendf wrote in the 8th comment:
Votes: 0
>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.
04 Jul, 2014, quixadhal wrote in the 9th comment:
Votes: 0
Since the OP is using Windows, I'm not sure the glibc2 is going to be useful for him.
04 Jul, 2014, Rarva.Riendf wrote in the 10th comment:
Votes: 0
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.
05 Jul, 2014, quixadhal wrote in the 11th comment:
Votes: 0
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.
05 Jul, 2014, Rarva.Riendf wrote in the 12th comment:
Votes: 0
>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.
05 Jul, 2014, quixadhal wrote in the 13th comment:
Votes: 0
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*
09 Jul, 2014, Amun wrote in the 14th comment:
Votes: 0
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.
09 Jul, 2014, Tyche wrote in the 15th comment:
Votes: 0
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.
Random Picks
0.0/15