Folks, in case anyone's looking, I've implemented most of the Get* functions of ip helper API included in Windows NT4 or Windows 98. I'm not planning to implement functions added in Win2K or XP at this time.
Email me if interested. No, it's not vaporware, it's just not as well tested as I'd like.
I'm hoping to tackle reducing code duplication in this DLL, wsock32, and netapi, and also remove wsock32's dependency on the UNIX socket includes. This has all been discussed before here in this thread: http://www.winehq.com/hypermail/wine-devel/2001/09/0042.html
For interface enumeration and address (IP and MAC) getting, I use ioctls. This should aid portability (I've tested the ioctls on Linux, FreeBSD, and Solaris). Stats I still read from /proc. All this stuff is in its own file to keep less-portable code together.
Cheers, --Juan
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
On Wed, 30 Apr 2003, Juan Lang wrote:
Email me if interested. No, it's not vaporware, it's just not as well tested as I'd like.
Just send it over to wine-devel for comments, or wine-patches for inclusion into the tree.
I've got iphlpapi.dll working reasonably well. The platform-specific functions I put in a new file, ipshared.c. I compile this into iphlpapi.dll, and I'm trying to compile it into wsock32, also.
Problem is, when I call ioctl from ipshared.c compiled into wsock32, the ioctl that gets called is the winsock one, not the UNIX one. I could use ioctlsocket, but not every DLL that might compile ipshared.c uses this hack. (wsock32 does, ws_2 does not, netapi does not)
I could export private functions from some DLL or other, but goes against the recent cleanup work that's been going on.
Suggestions, anyone? Thanks, --Juan
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
On Wed, 30 Apr 2003, Juan Lang wrote:
Email me if interested. No, it's not vaporware,
it's
just not as well tested as I'd like.
Just send it over to wine-devel for comments, or wine-patches for inclusion into the tree.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Prev guess about wrong ioctl being called was wrong. Looks like some kind of stack corruption, only when called from wsock32. iphlpapi works fine.
I tried to trace what's up with some printouts. I have a stack variable ndx, and with code like: FIXME("ndx is %d, at %x\n", ndx, &ndx); ndx += 4; FIXME("ndx is %d, at %x\n", ndx, &ndx);
I see output like: ndx is 0, at 40670b80 ndx is 101683072, at 40670b80
Umm.. anyone have any clues what's special about wsock32?
I'll post code shortly for some kind soul to play with. --Juan
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
On Wed, 30 Apr 2003, Juan Lang wrote:
Email me if interested. No, it's not vaporware,
it's
just not as well tested as I'd like.
Just send it over to wine-devel for comments, or wine-patches for inclusion into the tree.
-- Dimi.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Okay, here's the promised source for some kind soul to help with. There are two new files, misc/ipshared.c and include/wine/ipshared.h, that implement the platform-specific stuff shared by iphlpapi, wsock32, winsock, and netapi32. There's also a patch to wsock32/socket.c that shows the great gobs of code that get removed.
But, like I said, I'm having troubles testing with winipcfg.exe. The getNumInterfaces() function I wrote returns some bogus number. Yet when I call it from netapi32 or from iphlpapi, no problems.
Any wild-ass guesses appreciated! --Juan
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
-
Dimitrie O. Paun -
Juan Lang