Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    MYSTIC    |    Mystic support echo    |    16,010 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 13,526 of 16,010    |
|    LEE WESTLAKE to g00r00    |
|    Re: Door32.sys development    |
|    14 Jun 21 12:58:57    |
      TID: Mystic BBS 1.12 A46       MSGID: 2:250/6 58c82183       REPLY: 1:129/215 f92eca2d       TZUTC: 0000       Hi g00r00,              Thank you for taking the time to address each of the points raised; your       comprehensive response is very much appreciated.               g0> Blocking               g0> The only standard that I know of that ever attempted to define anything        g0> was Mystic's DOOR32 and that uses blocking sockets. I assume you'd        g0> probably get blocking from most BBSes then by default, but I can't say        g0> for sure what other software does.               g0> I think it'd be a good practice to do this.               g0> The original intention was that the socket should be duplicated before        g0> being passed to the door, but I think in practice that didn't end up        g0> being guarenteed or even done at all because of variations in operating        g0> systems (and if I am not mistaken some OSes specifically said that        g0> sockets should not be duplicated).              I've decided to do the extra legwork and write comm routines which work       transparently for either blocking or non-blocking sockets - as winsock       doesn't detect socket mode reliably, this solution removes the headache of       socket mode altogether.               g0> It *might* be safe to call only when it drops but I can't say for sure        g0> without experimentation.                g0> If I remember correctly calling WSACleanup is a Windows specific thing        g0> and it invalidates any socket handles used by the process. For that        g0> reason I think it was not called in any case within D32 doors. Instead        g0> it let the BBS detect the connection loss and do what it does.                g0> Things may behave differently depending of if/when the socket was        g0> duplicated by the BBS before being passed, but I would        g0> operate on the assumption that the socket is not duplicated.              Further testing appears to corroborate this: from what I can tell, WSACleanup       is best left to the BBS.              Again, thank you ever so much for taking the time to address these issues.              Best Regards              |01°|09²²²²² |01³|09 Lee Westlake |01(aka TALIADON)       °|09²|01°|09²|01°|09² |01³|09 TALIADON BBS |01(taliadon.ddns.net)        °|09²|01 ³ E-Mail: taliadon-bbs@mail.com        °|09²²²|01 ³ fsxNet: 21:3/138 ù FidoNet: 2:250/6       --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)        * Origin: TALIADON BBS (2:250/6)       SEEN-BY: 1/123 25/0 21 30/0 90/1 103/705 105/81 120/340 123/131 129/305       SEEN-BY: 154/10 218/700 221/1 6 226/30 227/114 702 229/101 424 426       SEEN-BY: 229/452 550 700 981 1016 1017 240/1120 5832 249/206 307 317       SEEN-BY: 249/400 250/0 1 2 3 4 5 6 7 8 10 261/38 263/0 280/464 282/464       SEEN-BY: 282/1038 292/854 301/0 1 101 113 317/3 322/757 335/364 341/66       SEEN-BY: 342/200 633/280 712/848 920/1 5020/1042 5058/104       PATH: 250/6 1 301/1 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca