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)
|
