pcb@usl.usl.edu (Peter C. Bahrs) (09/19/88)
Just wanted to remark on recent news re MS Windows.
DEV AUX: Initially I thought that the DEV AUX was a 'generic' error message
similar to a UNIX core dump.
The debugging kernel of MS Windows is looking for a terminal
to dump debugging info to. You should really hook up the second trace
terminal as some important (although sometimes confusing) trace info
is displayed here.
The dialog box editor and heapwalk program with the SDK seem to periodically
generate a a call to dump debugging information. The second terminal must
be installed or a DEV AUX crashes the system.
Normal versions of windows run applications 'normally', so the extra terminal
and DEV AUX are not need and avoided respectively.
GLOBAL MEMORY: Allocate it, lock it, use it, unlock it and free it; just like
it says in the Petzhold (excuse spelling) text. It works great. Please
do not fix memory blocks for the sake of other applications. (Fixing memory
may be ok if your application remains in house and is the major task executed
in the MS Windows environment.)
C++: MS Windows has a high learning curve, similar to C++. But after a
rigorous development experience, further application development is
facilitated due to code reusability and 'once you program a message
based system (windows systems), they are all pretty similar' with some level
of abstraction. Structurally, I think that ms window objects should become
smarter in there inheritance , encapsulation and messaging protocol.
The idea of only one message buffer (Clipboard) for interprocess (task)
communication is primitive and time consuming.
|| Processing:10 386 PCs networked together via ethernet and windows still
uses one processor! We are looking into design specifications for an MS
Windows environment (PC based) to take advantage of the remaining 386
processors and the 9 transputers in one of the boxes. (Tales of X)
Has anyone heard of current research in this are, namely in the
transputer interface environments?