bert@helix.nih.gov (Bert Tyler) (10/24/90)
> When running Fractint for Windows-Vers 1.00(FFW) with a DOS > window opened and QEMM for my XMS, windows quits working and I am left > out in DOS. FFW will work fine if no DOS window is opened, and it > will work for a while when a DOS window is opened. > ... > At this point I am flung out of windows and back into DOS. If I > I go back to himem.sys for XMS the problem disappears. > ... > 2) Where do you think the problem is? FFW? Windows? QEMM? other? Well, as the author of FFW, I would guess that FFW is probably at least partly responsible. There is lots of code in there that just flat-out assumes that Windows isn't going to come back with an error message and probably heads off to WinApp heaven if that happens. Of course, given that a WinApp running in protected mode isn't supposed to be *able* to fling you out of Windows and back into DOS, I suppose that you are looking at some sort of co-operative effort in the bug department <grin>. We just shipped version 2.0 of FFW *with* source, so perhaps the Windows Wizards can help me out with this stuff (after they get over the hysterical laughter, of course - "did you see how he tries to do *this*?"). Version 2.0 is on Compuserve in Lib 2 ("New Uploads") of the COMART forum, and on BIX in the GRAPHIC.DISP/LISTINGS area as WINFRA.ZIP (EXE and auxiliary files) and WINSRC.ZIP (full source). The files are visible on CIS as I type this - they'll probsbly be visible on BIX by tomorrow. Freeware as usual. I would appreciate it if one of you netters with access to FTP and one of these sources would upload it to the appropriate places. Bert Tyler bert@helix.nih.gov tub@nihcu.bitnet 73477.433@compuserve.com
ed@odi.com (Ed Schwalenberg) (10/24/90)
In article <568@nih-csl.nih.gov> bert@helix.nih.gov (Bert Tyler) writes:
Of course,
given that a WinApp running in protected mode isn't supposed to be
*able* to fling you out of Windows and back into DOS, I suppose that
you are looking at some sort of co-operative effort in the bug
department <grin>.
It depends on what you mean by "isn't supposed to." Since all Windows
applications share a common address space, it's possible (and quite probable)
that a wild pointer can clobber any other application, including the kernel
routines themselves. Less probable, but still possible, a protected-mode
application can modify any memory location, by modifying system data
structures like the LDT, which are not protected from application access.
So a buggy or malicious program can do anything it pleases, such as crashing
Windows, DOS, or locking up your machine.
Operating systems are "supposed to" prohibit applications from clobbering
one another. Windows 3.0 doesn't try very hard. There are strong hints in
the SDK and DDK documentation that future releases will try harder, though.