Author: Robert Hyatt
Date: 19:20:00 02/04/99
Go up one level in this thread
On February 04, 1999 at 17:21:18, Christophe Theron wrote: >On February 03, 1999 at 21:31:08, Robert Hyatt wrote: > >>On February 03, 1999 at 20:15:16, Christophe Theron wrote: > >(snip) > >>>In case of the Auto232 driver, I would bet that a bug in this piece of software >>>will never touch any byte in extended memory. It can screw itself by misusing a >>>segment register for example, but this way it will only overwrite something in >>>the first megabyte (known as "DOS memory"). >> >>first, extended memory is a 'side issue' here... the chess engine executable >>is almost guaranteed to be loaded into low memory, and the auto232 driver >>certainly is, because it catches interrupts from the serial port that connects >>the two machines. And it can do most anything it wants. I'd suspect that _if_ >>it does a "wild store" it will zap something in the first 10 segments, but that >>is enough to make a chess engine behave strangely, of course... > > >Extended memory is a way to avoid the problem. I adviced Ed to write a DOS >program that would allocate all DOS memory for itself, and then start Rebel by a >system() call. > >This way, the DOS extender Ed uses will be forced to load Rebel.exe into >extended memory (above the first megabyte), thus protecting it from memory >overwrites by the Auto232 driver. > >This is not perfect, because of course any TSR program can also access extended >memory. But it is unlikely to happen accidentally in this case. > >The bad case would be that the driver overwrites the BIOS or DOS memory area. In >this case there is nothing to do. But at least the program's code can be >protected (unperfectly I know) by forcing the system to load it above the first >megabyte. > > the only problem with the 'executable' sitting above 1M is that the thing has to use a 'bounce buffer' to work when you do _any_ I/O at all. Which is not efficient at all. Because you can't pass addresses above 1M to DOS, you have to copy from the local buffer to something in the first 1M, then do the I/O, then copy the results back, and so forth. No I/O and it works well. But if you update the screen quite a bit, it can wreck havoc.. > >>>I would say that a program loaded into extended memory (after the first >>>megabyte) will almost never suffer of a memory overwrite by Auto232. The problem >>>is that DOS can be touched by a bug in Auto232, which is of course another >>>story... >>> >>> >>> >>>>>>>Rebel10.0c (with auto232) is currently running on 2 autoplayer pairs >>>>>>>under Win98 and a third autoplayer pair is running under Win95. No >>>>>>>incompatible problems noticed sofar. >>>>> >>>>> >>>>>>I assume your autoplayer 'bug' was not under windows? Because if it was, >>>>>>then this changes things. The only thing that can access your memory is part >>>>>>of _your_ program (including the auto232 driver code you include, of course, >>>>>>but 'other programs/processes' can't touch you in win98. Only things that are >>>>>>part of your code.. >>>>> >>>>>No. I always have tested outside Windows using a clean boot without >>>>>any memory managers. Now I have started auto232 from the DOS-box >>>>>within Win98. I wonder if this is good enough to be safe as I know >>>>>HIMEM.SYS behaves different in the DOS-box than if you launch a >>>>>program from the desktop. >>>>> >>>>>Ed >>>> >>>> >>>>That I don't know. The only windows 'box' I use is the box it came in where >>>>it stays and never makes it onto my hard drive. :) >>> >>> >>>And I confirm that this way you save yourself a lot of trouble. >>> >>>I hope someday users will be wise enough to understand that Windows is a counter >>>productive OS and eventually demand some reliability. >>> >>>Current users only demand to be able to change the screen colors. Looks like >>>they don't mind loosing a day of two of hard work because of a bug in their >>>favorite software. But if they cannot change the colors or the background image, >>>they ask for a refund. >>> >>>We will provide Windows software, but I still hope that one day users open their >>>eyes and ask for a real, robust, reliable operating system. Not a toy. >>> >>> >>> Christophe >> >> >>NT isn't bad at all, but windows 95/98 is basically trash. And even NT >>has serious problems when put in a networking environment... our secretaries >>are happy if their machines stay up for a whole work-day without needing a >>reboot. >> >>My unix/linux/solaris boxes stay up until hardware breaks or I upgrade the >>software. And _never_ crash... > > >I would like to see this kind of OS on every computer. > > > > Christophe
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.