On May 24, 2011 07:42pm, Sean Dennis wrote to Matt Munson:

Hello, Matt.

Tuesday May 24 2011 at 13:59, you wrote to David Collins:

But is 32 bit backwards compatable with 64 bit windows?

A 64-bit Windows system can run 32-bit programs, yes. I'm not sure
about 32-bit BBS doors though. I did write 32-bit BBS doors before but
I couldn't get anyone to test them for me, so I quit writing them.

You can run 32 bit on a 64 bit system... but older 16 bit doors will not run
on a 64 bit system but sometimes will run on a 32 but. If they werew written in Turbo Pascal there's a patch that may or may not slow them down enough to work properly.

Allen

... Buckle up; it makes it harder for the aliens to suck you out of the car. --- Platinum Xpress/Win/WINServer v3.0pr5
* Origin: Derby City LiveWire - Louisville, KY - livewirebbs.dy (1:2320/100)

09 May 16 00:06, you wrote to Sean Dennis:

You can run 32 bit on a 64 bit system... but older 16 bit doors will
not run on a 64 bit system but sometimes will run on a 32 but. If
they werew written in Turbo Pascal there's a patch that may or may not slow them down enough to work properly.

are you thinking of the Runtime Error 200 patches? if so, they don't "slow them
down enough"... they adjust the way the timing is done for the DELAY function... i have my own patch for the CRT library but it is more of a replacement routine since i also have the sources to the CRT lib... i simply replaced the DELAY routine with one of my own and recompiled it... existing binary files need binary patching in the same way though... that is what all the various patching programs take care of...

the original problem is that they decided that since they knew how long a NOP instruction took, they would execute X number of them and it should equal the time passed on the clock... as machines got faster, they executed all the NOPs in the same time increment and the result between the starting time reading and
the ending one was zero... when that was fed, without checking if the result was zero, to the division routine to figure out the proper DELAY synchronizer value, the result was the Divide by Zero Runtime Error 200... even if they had checked for the result being zero before the division there wasn't much they could do other than to run the NOP loops again... different patches handle this
different ways... ones that i'm familiar with simply replace the DELAY routine and skip the calibration routine...

)\/(ark

Always Mount a Scratch Monkey

... We don't do no dups!
---
* Origin: (1:3634/12.73)

Allen Prunty wrote to Sean Dennis <=-

You can run 32 bit on a 64 bit system... but older 16 bit doors will
not run on a 64 bit system but sometimes will run on a 32 but. If they werew written in Turbo Pascal there's a patch that may or may not slow them down enough to work properly.

If there's no support for 16-bit DOS in the operating system, no patch will help that. What you're talking about is the old "divide by zero" problem
which none of my DOS doors suffer from. My new doors are written using Free Pascal using its "TP compatibility" mode.

--Sean

--- MultiMail/Linux
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)