I am doing a little proof of concept or prototype sample of a door for Synchronet. I have played with socket server examples under linux, and I am familiar with the concept of sockets as file handles. Winsock2 is supposed to be the same way. However, in linux, I can send() and recv() to/from the stdout, stdin, and stderr file handles. But that doesn't seem to be the case with WinSock2, even though I have read on MSDN that it should be.

I wanted to know maybe I was going about this ther wrong way. I was assuming that the drop file from Sunchronet, and any BBS really, would be passing the file handle of the connected socket, so I should just be able to take that handle and send/recv. Have I asumed correctly?

I've been at this too long for today so I am going to bed now. If there is any advice to be given (besides don't use winsock <G>) I am happy to hear it.

Thank you all, have a great&wonderful night!

... "In the constellation of Cygnus there lurks a mysterious, invisible force."

---
þ Synchronet þ The Time Portal - timeport.synchro.net:2112 - Celebrating the past from the futu

Egads, my typing skills are atrocious. My apologies to anyone reading that.

---
þ Synchronet þ The Time Portal - timeport.synchro.net:2112 - Celebrating the past from the futu

Re: need help with winsock2
By: Xucaen to All on Tue Nov 24 2015 11:49 pm

I am doing a little proof of concept or prototype sample of a door for Synchronet. I have played with socket server examples under linux, and I am familiar with the concept of sockets as file handles. Winsock2 is supposed to be the same way. However, in linux, I can send() and recv() to/from the stdout, stdin, and stderr file handles. But that doesn't seem to be the case with WinSock2, even though I have read on MSDN that it should be.

On Windows, send() and recv() as strictly for sockets (cannot be used on file descriptors).

I wanted to know maybe I was going about this ther wrong way. I was assuming that the drop file from Sunchronet, and any BBS really, would be passing the file handle of the connected socket, so I should just be able to take that handle and send/recv. Have I asumed correctly?

It's a socket descriptor, and yes, you can send/recv using it (the one provided in the door32.sys and xtrn.dat drop files and with the %h command-line specifier).

I've been at this too long for today so I am going to bed now. If there is any advice to be given (besides don't use winsock <G>) I am happy to hear it.

JavaScript makes all those headaches go away. You might consider writing your door in that instead of a native language, like C/C++. It's all the rage. :-)

digital man

Synchronet "Real Fact" #38:
Synchronet first supported Windows NT v6.x (a.k.a. Vista/Win7) w/v3.14a (2006). Norco, CA WX: 54.7øF, 83.0% humidity, 1 mph SSE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: need help with winsock2
By: Xucaen to All on Tue Nov 24 2015 11:49 pm

I am doing a little proof of concept or prototype sample of a door for Synchronet. I have played with socket server examples under linux, and I am
familiar with the concept of sockets as file handles. Winsock2 is supposed to be the same way. However, in linux, I can send() and recv() to/from the stdout, stdin, and stderr file handles. But that doesn't seem to be the case
with WinSock2, even though I have read on MSDN that it should be.

On Windows, send() and recv() as strictly for sockets (cannot be used on file >descriptors).

I had read on MSDN that WriteFile and ReadFile functions will work like send and recv except with file descriptors (including socket descriptors). The problem I am facing is I am trying to WriteFile to the stdout file descriptor and it is not working. My belief was that if I could get that to work, then I know WinSock2 is a viable solution and I can move on to my next step. But I've slept since then, so..

I wanted to know maybe I was going about this the wrong way. I was assuming that the drop file from Synchronet, and any BBS really, would be passing the
file handle of the connected socket, so I should just be able to take that handle and send/recv. Have I assumed correctly?

It's a socket descriptor, and yes, you can send/recv using it (the one provided
in the door32.sys and xtrn.dat drop files and with the %h command-line >specifier).

I think right now I am going to try this - and stop trying to get Windows to do things that Linux can do so easily. ;-) I decided to use door32.sys (only because it looked simpler to use). The first line is the type of connection. I'll check that and if the type is local I'll stream to cout. Probably what I should have done in the first place but I couldn't help attempting to be clever. (again with the sleep thing, I know better today) ;-)

I've been at this too long for today so I am going to bed now. If there is any advice to be given (besides don't use winsock <G>) I am happy to hear it.

JavaScript makes all those headaches go away. You might consider writing your >door in that instead of a native language, like C/C . It's all the rage. :-)

Well, it's a long story. My "game" is already written in c -as-a-better-c <g>, I'm just trying to send the output (programmatically) to the socket. Once I get this working, I have other ideas for another game I want to build from scratch.

---
þ Synchronet þ The Time Portal - timeport.synchro.net:2112 - Celebrating the past from the futu

Holy cow, I just noticed the "redirect i/o" option in Synchronet and it works! I can telnet in and play my game from the external games menu.

Thank you! Thank you! Thank you! Thank you!

---
þ Synchronet þ The Time Portal - timeport.synchro.net:2112 - Celebrating the past from the futu

Re: need help with winsock2
By: Xucaen to Digital Man on Wed Nov 25 2015 10:25 am

Re: need help with winsock2
By: Xucaen to All on Tue Nov 24 2015 11:49 pm

I am doing a little proof of concept or prototype sample of a door for Synchronet. I have played with socket server examples under linux, and I am
familiar with the concept of sockets as file handles. Winsock2 is supposed to be the same way. However, in linux, I can send() and recv() to/from the stdout, stdin, and stderr file handles. But that doesn't seem to be the case
with WinSock2, even though I have read on MSDN that it should be.

On Windows, send() and recv() as strictly for sockets (cannot be used on file >descriptors).

I had read on MSDN that WriteFile and ReadFile functions will work like send and recv except with file descriptors (including socket descriptors). The problem I am facing is I am trying to WriteFile to the stdout file descriptor and it is not working. My belief was that if I could get that to work, then I know WinSock2 is a viable solution and I can move on to my next step. But I've slept since then, so..

If this is for Synchronet, Synchronet also supports standard I/O doors (even on Windows), so you don't *have* to use socket I/O, but you do get some benefits from using socket I/O.

I wanted to know maybe I was going about this the wrong way. I was assuming that the drop file from Synchronet, and any BBS really, would be passing the
file handle of the connected socket, so I should just be able to take that handle and send/recv. Have I assumed correctly?

It's a socket descriptor, and yes, you can send/recv using it (the one provided
in the door32.sys and xtrn.dat drop files and with the %h command-line >specifier).

I think right now I am going to try this - and stop trying to get Windows to do things that Linux can do so easily. ;-) I decided to use door32.sys (only because it looked simpler to use).

door32.sys is just a drop file. The same information could be passed to the door program via command-line options or other drop-files.

The first line is the type of connection.
I'll check that and if the type is local I'll stream to cout.

On a Synchronet BBS, that line will only be local (0) if you have the program configured in SCFG to use intercepted standard I/O.

Probably what
I should have done in the first place but I couldn't help attempting to be clever. (again with the sleep thing, I know better today) ;-)

I don't really follow. If you want to see some examples of native (e.g. 32-bit) cross-platform socket I/O doors, see the xtrn/sdk and sbj directories.

I've been at this too long for today so I am going to bed now. If there is any advice to be given (besides don't use winsock <G>) I am happy to hear it.

JavaScript makes all those headaches go away. You might consider writing your >door in that instead of a native language, like C/C . It's all the rage. :-)

Well, it's a long story. My "game" is already written in c -as-a-better-c <g>, I'm just trying to send the output (programmatically) to the socket.

Using send() is the correct approach.

Once I get this working, I have other ideas for another game I want to build from scratch.

Cool. Speak up if you have more questions,

digital man

Synchronet "Real Fact" #41:
Rob Swindell was laughed out of a FidoNet Net103 (OC, Calif.) meeting in 1992. Norco, CA WX: 50.7øF, 67.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net