🚀 go-pugleaf

Thank you all for your swift replies! I recieved mail from:

	msaletni@Jade.Tufts.EDU (Michael J. Saletnik)
	courtney@data.rain.com (Courtney Meissen)
	heathh@cco.caltech.edu (Heath Ian Hunnicutt)
	magmy@modeld.no (Magne Myrtveit)
	poffen@sj.ate.slb.com  (Russ Poffenberger)
	raymondc@microsoft.com

which indicates that a wide variety of people are reading this newsgroup.
This is very encouraging. It appears that the solution is quite simple,
my problem was that i didn't understand what the AUX port had to do with
anything.  I will give you a flavour of the replies...

In summary, the situation is this:

"Since you are running the DEBUG kernel, it is attempting to log errors
and warnings to device AUX. This device can be an additional monitor,
CodeView, or the DBWin sample application included in the 3.1 SDK.
[ ... ]  [ie: Michael mentions \c700\bin\dbwin]" - msaletni.

"I get this when I run debug Windows with certain applications
(Actor, Toolbook), so I've gone back to retail Windows.  I believe
that Windows is trying to 'RIP' and send info out the com port
on an error that occurred.  [ ... ] " - courtney.


[The most amazing reply was from heathh, I hope heath doesn't mind me
 including his mail - i found it VERY entertaining - it brightens a dreary day!]

" There have been sporadic reports of the retail windows
  kernel trying to use a debug terminal when it is exceedingly stressed
  out, but the likelihood is that a misbehaving application is the true
  culprit.  
	
  You see, any program can write a string of debug output
  using the (aptly named) DebugOutput and OutputDebugString API
  calls.  For a good time, try the following code (in either
  retail or debug build of Windows):
	:
	:
	case WM_PAINT:
	   DebugOutput("Crash-o-rama!");
	:
	:

  You'll get another visit from the friendly double-plus-ungood
  system error dialog box.  MS left the code for DebugOutput in the
  retail version so that apps could retain debug code (which would
  have to be enabled via some sort of hidden mechanism).  Then, if your
  app goes nuts in the field, you just take a terminal to the 
  customer's site, turn on the debugging features via some hidden
  menu option (or whatever...) and rock-n-roll.

  Unfortunately, MS did not really stress in the SDK docs
  that DebugOutput() can lead to very bad times when used without
  an attatched terminal.

  There are other such utilities, notably OX.SYS,a device
  driver for DOS which traps the terminal output.  I forget
  who wrote it, but you can probably get it off of ftp.cica.indiana.edu.
" - heathh.


"It seems to me that you are running DBWIN.EXE with output to COM1.
See the DBWIN options menu." - Magne.


"When running the debugging kernel, it wants to send the debug output to the
AUX port (com 1) by default. The way around this with Windows 3.1 is to load
the dbwin sample application which re-directs the debug output how you choose."
- poffen.


"The debug version of Windows 3.1 uses COM1 (aka AUX) to communicate
with the programmer." - raymondc.


==================
AHA! Once again thank you all. I guess it was pretty simple, really.
It always is once you see the answer... :-)
ben.