After a couple of days, they came back to me and announced they'd found the problem. It turns out that the trace on the motherboard for the PC speaker was too close to the trace on the motherboard for the CPU reset line. When you played a specific sound on the PC speaker, EMF emissions from the speaker trace would cause the CPU reset to go high, which caused the CPU to reboot.
Eher für Programmierer interessant:
von http://blogs.msdn.com/larryosterman/arc ... 54108.aspx
The other thing I realized was that the MS-DOS PSP (Program Segment Prefix, the equivalent of a task in MS-DOS) contained 128 bytes of OS stuff, and 128 bytes of command line (this is where Raymond starts cringing). Since the redirector didn't use the command line, I figured I could re-use that 128 bytes of memory for my stub to enable the high memory area. And that's what I did - I used the 128ish bytes of command line to hold the interrupt dispatch routines for all the entrypoints to the redirector (there were about 4 of them), and pointers to the corresponding routines in the high memory area, and the code to enable (and disable) the HMA.
And voila, I had a 0 footprint redirector. The only negative that came from this was that applications that enumerated the "running" processes didn't handle the "code-in-the-command-line" thing.
Da die Blog-Engine offensichtlich einen Fehler hat und man die Resultatseite der Suche in der URL selbst eintragen muß, hier die Links zu Artikeln, die den Begriff DOS enthalten:
http://blogs.msdn.com/larryosterman/sea ... ?q=dos&p=1
http://blogs.msdn.com/larryosterman/sea ... ?q=dos&p=2
http://blogs.msdn.com/larryosterman/sea ... ?q=dos&p=3