Xref: utzoo rec.games.hack:9369 comp.windows.ms:4474
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!mcdchg!chinet!patrickd
From: patrickd@chinet.chi.il.us (Patrick Deupree)
Newsgroups: rec.games.hack,comp.windows.ms
Subject: Re: nethack and mswindows
Message-ID: <1990Aug22.210108.8638@chinet.chi.il.us>
Date: 22 Aug 90 21:01:08 GMT
References: <14@ncuug.UUCP> <1990Aug14.200428.18097@world.std.com> <1990Aug15.121256.9912@specialix.co.uk>
Organization: The Whitewater Group, Evanston, IL
Lines: 23

In article <1990Aug15.121256.9912@specialix.co.uk> jonb@specialix.co.uk (Jon Brawn) writes:
>Not if he's assuming all he's going to change is the GUI.
>
>HOWEVER having said which, it would be possible to flatten out MS Windows
>programs so that the application once more thought it was in control by
>adding in yet another layer of functions that interface the application
>to the windows, but it wouldn't be quick & would probably be dastardly
>to debug, and certainly wouldn't be in the MS Windows style of doing
>things. But don't let me put you off.....

On first glance things look good.  Well, sorta good.  I've got two choices for
methods to handle I/O and Windows message processing, neither of which is
pretty but both of which are functional.  As for memory management, luckily
it appears that all strcpy, strcat, etc functions are redefined based on
the environment that one is running in, so it's no problem for me to 
substitute the lstrcpy, lstrcat, etc functions.

This should be interesting now that I've finally got all the code.
-- 
"Organized fandom is composed of a bunch of nitpickers with a thing for
 trivial pursuit."  -Harlan Ellison

Patrick Deupree ->	patrickd@chinet.chi.il.us