TZUTC: -0400   
   MSGID: 27.fido-pascalle@1:3634/12 23042ccf   
   REPLY: 15.fido-pascalle@3:633/410 2303cca8   
   PID: Synchronet 3.18a-Linux  Apr 12 2020 GCC 7.5.0   
   TID: SBBSecho 3.10-Linux r3.159 Apr 12 2020 GCC 7.5.0   
   CHRS: ASCII 1   
   NOTE: FSEditor.js v1.103   
     Re: Re: Still here   
     By: Tony Langdon to mark lewis on Tue Apr 21 2020 15:47:00   
      
      
    ml>> in fact, the delay routine is the one that lead to all the runtime   
    ml>> 200 errors because of the way they did the calibration loop and didn't   
    ml>> check if the result was zero before trying to divide it by the number   
    ml>> of seconds the calibration loop ran...   
      
    TL> Yeah I don't recall striking that in the TP days. Or is this   
    TL> a FP only bug?   
      
   it is absolutely a borland bug... it affects all of their languages that used   
   that form of delay calibration... nothing at all to do with FPC... it reared   
   its head when machines got fast enough for the calibration loop run to   
   completion within the same second... so they increased the loop count and got   
   bitten again when machines sped up again... i think they had one more round of   
   it before someone finally smartened up and finally figured out another way to   
   calibrate the delay routine...   
      
   the calibration loop? they were executing a certain number of NOOPs because   
   NOOPs had a known execution time that didn't vary... so they'd execute say   
   10000 of them and subtract the start time from the end time to figure out the   
   speed of the machine... when those NOOPs were all done in the same second, end   
   - start equaled zero but they didn't check for this before doing their   
   division and thus raising the RT 200 defect notification...   
      
    TL>>> And that's the part I need to learn. ;)  Reading FP documentation   
    TL>>> on network programming and using the libraries didn't help.   
      
    ml>> yeah, there's sample code for web available... i think they're in   
    ml>> lazarus... there are a couple of others, too, IIRC...   
      
    TL> I'm not interested in web for most of my applications.   
      
   the idea of my statement was to point to the existing working examples ;)   
      
    TL> TCP or UDP sessions are usually more useful to me, because I want   
   processes to be able to talk across the network plainly. :)   
      
   that can still be done even if using a so-called web-server/web-client setup ;)   
      
   client sends a request.   
   server sends some sort of response.   
   client does its thing.   
      
   the request could be some format you come up with or maybe it would be   
   something in JSON or using AJAX or something else... the response could be   
   similar, as well... it just depends on what you want done...   
      
   i can envision serving JAM message bases directly to a client without any   
   intervening format layering... maybe no binary by converting that to ASCII   
   text for the transmittal... having a client/server message reader like that   
   would be a first step toward doing a client/server BBS setup... sure, it would   
   be a dedicated client for the users but then maybe the client would reside   
   server side and convert to standard traditional terminal sequences so the   
   entire client/server thing is completely hidden from the users...   
      
      
   )\/(ark   
   --- SBBSecho 3.10-Linux   
    * Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)   
   SEEN-BY: 1/120 123 10/0 1 14/5 15/0 18/0 19/36 20/4609 90/1 102/401   
   SEEN-BY: 103/705 9999 106/201 116/18 116 120/331 340 601 123/0 25   
   SEEN-BY: 123/50 115 140 150 170 755 135/300 153/757 7715 154/10 203/0   
   SEEN-BY: 214/22 218/0 1 215 401 410 530 700 720 802 820 221/0 222/2   
   SEEN-BY: 226/16 30 227/114 229/101 426 452 616 1014 230/150 152 240/5832   
   SEEN-BY: 249/206 317 400 250/1 261/38 100 266/512 267/155 275/100   
   SEEN-BY: 280/464 5003 282/1031 1056 291/100 111 292/8125 317/3 320/119   
   SEEN-BY: 320/219 322/757 340/400 341/66 342/13 200 396/45 423/120   
   SEEN-BY: 633/280 640/1321 712/848 801/161 189 1502/119 2320/105 3634/0   
   SEEN-BY: 3634/12 15 27 50 119 5020/715 1042   
   PATH: 3634/12 261/38 218/700 103/705 280/464 229/426