Path: utzoo!attcan!uunet!wuarchive!usc!cs.utexas.edu!rutgers!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.windows.ms
Subject: Re: Some basic windows/386 programming questions
Summary: Windows development tools
Keywords: MS Windows
Message-ID: <3673@rtifs1.UUCP>
Date: 20 Mar 90 16:39:30 GMT
References: <6132@crdgw1.crd.ge.com>
Organization: Research Triangle Institute, RTP, NC
Lines: 59

In article <6132@crdgw1.crd.ge.com>, dixon@sagittarius.crd.ge.com (walt dixon) writes:
> (1) After I start up windows/386,  I run command.com.  When I try to make
>     an application,  I usually get a msc (5.1) error saying that the far
>     heap is exhausted.  Is this normal or do I have something improperly
>     configured?

You will need to modify the WIN.INI file entry for MSC or your PIF file 
for the compiler (wherever you declared the compiler) to give it more
memory.  

> (2) Is there a preferred way to build the resource (.rc) file?  All the
>     examples I've seen manually build dialogs,  etc.  and include their
>     definition directly in the .rc file.  I want to use the available
>     utilities (dialog editor, etc).

*gack* >choke< The dialog editor is a good idea, it is pretty easy to
create dialog boxes with it.  But its .rc output is nearly unuseable (as
you are finding out).  I usually build the dialog boxes manually with
a text editor;  it is more trouble than using the dialog editor but
not that bad once you've done it a few times (and have a number of
dialog boxes to use as starting points).

I believe there are numerous commercial products out there that
provide better solutions than you get with the SDK, but I don't
have any experience with them so I can't recommend any.

> (3) Is there an alternative to the icon editor?  I'm not real impressed
>     with the way a 64x64 bit may gets shrunk to 64X32.  The bits are too
>     small and the pencil cursor is too big.

(you seem to be finding all the weak points in the SDK!).  Using the
icon editor to create a lot of bitmaps is a recipe for going blind.
It's not too bad if you are only making one or two (though even then
it's rather painful).

You can use the Clipboard to move images between Paint and the icon
editor;  Paint is a >much< nicer bitmap editor than the icon editor,
you just don't get to see the compressed icon as you are editing;  but
I find it isn't too bad, and you can easily move bitmaps back into the
icon editor to see how they'll get compressed.  The major drawback is
that it is awkward to create 3- or 4- color icon bitmaps from Paint,
but relatively few icons have many colors.

As for the bitmap getting shrunk, as far as I know all display drivers
shrink the icon bitmaps, though possibly a few high-resolution displays
(such as the 8514) don't do so.  There's no way to stop it.  If you are
talking about how non-icon bitmaps get shrunk with the StretchBlt 
function, there are some modifications you can make to the algorithm
by calling the SetStretchBltMode function;  but if you aren't happy
with any of the possibilities that function allows then you will have 
to write your own.

For what it's worth, the rumor mill has it that the SDK for Windows
V3.0 solves many of these problems.  No, I haven't seen it, and have
no firm info.

Good luck -

						Bruce C. Wright