I don't think this would work.
Just two reasons:
- a PC is more than just a processor and memory. there's the BIOS,
PCI-adapters, and, not the least: floppy/hard disks... these cannot be
shared without the OSes knowing about it. And they aren't duplicated in a
dual-processor PC
- DOS/Windows memory allocation schemes are REALLY REALLY different. It's
not trivial to find out the physical location of memory allocated in
Windows. Also, Windows may move the physical memory position without notice
(e.g. swapping). You'd probably need a device driver to get around this.
- How should the windows app tell the DOS app where the shared memory is, if
they don't have a commonications channel yet?
- How do you tell windows that it should leave the 640k 'DOS' memory alone?
I'm pretty confident it'll use those at least while booting.
- I don't know if this is true for all multiprocessor systems, but mine
immediatly restarts when both processors access the same memory are at the
same point of time (write access). You wouldn't have any synchronization
methods.
But the real question is not if this could be done, but why?
A DOS program that does nothing but dumping output into some memory area
isn't very hard to port. Make it a 32-bit windows executable (e.g. a console
application). Schedule it for Processor II and give it real-time priority.
Use any windows communication methods you like (memory-mapped files it you
need a memory block that's accessible from both sides, or named pipes,
synchronization objects).
After that, look if this is really slower than running your program under
plain DOS.
(If there is a significant difference, I would appreciate if you post your
results)
Greetings
Niki
"AK" <kettner9000@yahoo.com> schrieb im Newsbeitrag
news:b8a52d6b.0307011122.7a9ed9e1@posting.google.c om...
