Subj : Re: Still here To : Tony Langdon From : mark lewis Date : Tue Apr 21 2020 09:35 am 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) .