alen@crash.cts.com (Alen Shapiro) (10/25/90)
Did you know (and not a lot of people know this :-)) that...
You can't be in the MSWindows 3.0 environment and compile an
MSC 6.0 program so that you can remain in the environment
while you compile-debug your windows application (SDK).
The compiler runs out of heap space!!
nmake when run from a DOS-PROMPT within windows 3.0, hangs
my PS2/80 (4Mb RAM DOS3.3).
Microsoft will not deal with SDK questions over the phone
and on-line questions must go through Compuserve :-(
Looks like I've bought myself a cross compiler and will
have to run the compiles from another PC (on a shared disk)
if I intend to remain in windows for testing. WHAT A PAIN!!
Comments/hints suggestions on the above anyone?
--alen the Lisa Slayer (trying to turn a SPARC into a flame)
alen%shappy.uucp@crash.cts.com (a mac+ uucp host - what a concept!!)
alen@crash.cts.comakm@cs.uoregon.edu (Anant Kartik Mithal) (10/26/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... > >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! This hasn't happened to me as yet, though I will admit that I am still compiling the sample programs >nmake when run from a DOS-PROMPT within windows 3.0, hangs >my PS2/80 (4Mb RAM DOS3.3). I regularly run nmake, and, as I said before, haven't had a problem yet. I also run PWB from within windows without a problem. I have a clone, with 4MB and DOS 3.3. Perhaps it is more compatible??? :-) >Microsoft will not deal with SDK questions over the phone >and on-line questions must go through Compuserve :-( This I agree is lousy policy. >Looks like I've bought myself a cross compiler and will >have to run the compiles from another PC (on a shared disk) >if I intend to remain in windows for testing. WHAT A PAIN!! >Comments/hints suggestions on the above anyone? You could run everything in PWB... I'd check things like config.sys, TSRs and so on first. kartik -- Anant Kartik Mithal akm@cs.uoregon.edu Network Manager, (503)346-4408 (msgs) Department of Computer Science, (503)346-4156 (direct) University of Oregon, Eugene, OR 97403-1202
brianf@umd5.umd.edu (Brian Farmer) (10/26/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... > >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! > >nmake when run from a DOS-PROMPT within windows 3.0, hangs >my PS2/80 (4Mb RAM DOS3.3). Make programs have a habit of eating memory. Try the following makefile: hello: chkdsk After this finishes run chkdsk from the dos prompt. This difference will show you about how much memory is being eaten by Make. For me nmake ate about 118K. An expensive option might be polymake which is able to remove all but 4 or 5K from memory when it runs another program, I use this program for my making. Or you might be able to use the /N option to build a bat file which you run after nmake is finished.
goodearl@world.std.com (Robert Goodearl) (10/26/90)
In article <7471@umd5.umd.edu> brianf@umd5.umd.edu (Brian Farmer) writes: >In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >>Did you know (and not a lot of people know this :-)) that... >> >>You can't be in the MSWindows 3.0 environment and compile an >>MSC 6.0 program so that you can remain in the environment >>while you compile-debug your windows application (SDK). >>The compiler runs out of heap space!! >> >>nmake when run from a DOS-PROMPT within windows 3.0, hangs >>my PS2/80 (4Mb RAM DOS3.3). > >Make programs have a habit of eating memory... > > An expensive option might be polymake which is able to remove >all but 4 or 5K from memory when it runs another program, I use this >program for my making. A less expensive option is Opus Make, written by the same authors who wrote ndmake. It's a solid product and I've found that the dependency generator is (or at least was at the time I did an evaluation) better than PolyMake's. It too has the ability to swap most of itself out to disk so that only a 4-5k are used when compiling. Like PolyMake, it's knows about the revision dates inside PVCS log files (and a couple of other revision control systems as well.) Because of this, it can do builds that only check out sources when there have been updates to the branch of the source that is actually depended on. I can build all of a fairly large system (.5 meg of executable) from inside windows with the exception of the source created from a huge yacc script. Opus Software can be reached at 415-664-7901 (My only connection is as a satisfied customer.) As I write this (using Crosstalk for Windows), I've got a compile running in the background in another window. The only time I leave windows is when I'm forced to because of a crash. :-) -- Bob Goodearl -- goodearl@world.std.com
spolsky-joel@cs.yale.edu (Joel Spolsky) (10/26/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... > >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! Use "nmk", not "nmake", it takes up a lot less memory. I do it this way all the time and never had the compiler run out of heap space. Joel Spolsky spolsky@cs.yale.edu Silence = Death
mmshah@athena.mit.edu (Milan M Shah) (10/26/90)
WRT nmake / MSC 6.0 running out of heap space while running - I believe they package another make utility called nmk that does not require as much memory, but then again it isn't as smart as nmake. It is good enough for my purposes, and I *am* able to do a edit-make-debug cycle from within Win 3.0 running in 386 enh mode and using DOS windows. Milan .
jls@hsv3.UUCP (James Seidman) (10/26/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! > >nmake when run from a DOS-PROMPT within windows 3.0, hangs >my PS2/80 (4Mb RAM DOS3.3). Are you sure that this has anything to do with Windows? It's most likely that losing the few K that Windows steals from each DOS session is enough to push you over the edge into not having enough memory to use NMAKE. Even if I'm *not* running Windows, my 3+Open network drivers alone take up enough RAM to prevent me running NMAKE and the compiler simultaneously. (Incidentally, NMAKE and C 6.0 will work fine under Windows if you have almost no TSRs or drivers loaded. I've done it before.) >Microsoft will not deal with SDK questions over the phone >and on-line questions must go through Compuserve :-( Don't call it an SDK question. Call it a C 6.0 question, since it'll happen whether you're compiling a Windows app or not. Of course, they still probably won't be able to help you. >Looks like I've bought myself a cross compiler and will >have to run the compiles from another PC (on a shared disk) >if I intend to remain in windows for testing. WHAT A PAIN!! Better idea: I don't recall if C 6.0 comes with MAKE or not, but if so, use it instead. If you have a previous version of MSC, it'll have MAKE with it. (I think MASM comes with it too.) Alternatively, get one of the many alternative PD/shareware/commercial make-like programs. I don't understand why the NMAKE executable had to be so much larger than MAKE. We can hope that in 6.1 they'll manage to trim it down a bit. -- Jim Seidman (Drax), the accidental engineer. "There's a certain freedom to being completely screwed." - The Freshman UUCP: ames!vsi1!hsv3!jls Internet: hsv3.UUCP!jls@apple.com
gt3070b@prism.gatech.EDU (Jeff Watkins) (10/26/90)
It is interesting that you say you can not run msc6.0 under a dos window because you keep running out of heap space. The problem is not with windows. The problem is not with msc6.0 (though I would suggest zortech C++) the problem is with nmake. NMAKE IS TOO BIG! I have been compiling code from within windows since I have had windows (about May 1990) and have had the same problems until I trashed nmake and went back to Borlands make (which I happen to like better). Sometime soon, I hope to finish Builder's progression over to a full make environment, and then your troubles will be solved (probably). Until then I would suggest you use a smaller make program or get Zortech's compiler which will use XMS. :-) ciao jeff -- Jeff Watkins jwatkins@cadsun7.gatech.edu Convergent Media Systems (404) 315-0105 voice (404) 315-0231 data "I speak for no-one. AND NO-ONE SPEAKS FOR ME... oh, yes, _dear_...gotta go..."
garyk@ios.Convergent.COM (Gary Kipnis) (10/26/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... > >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! > I have been able to successfully compile win3 programs using msc6.0 from dos prompt, on a 286 in standard mode. gary
pkr@media01.UUCP (Peter Kriens) (10/26/90)
Buy a macintosh......
pkr@media01.UUCP (Peter Kriens) (10/26/90)
> make eating memory
The polytron make utility swaps itselfs out of memory. This allows
you to use all available memory - 4k. Works great, especially
when you use recursive make files.
Peter Kriensdmb@ns.network.com (Duane M. Butler) (10/26/90)
In article <1990Oct25.192322.18068@world.std.com> goodearl@world.std.com (Robert Goodearl) writes: >Opus Software can be reached at 415-664-7901 ^^^^^^^^^^^^ A more recent number is 1-800-248-OPUS (6787). I would also recommend this product. duane.
ckinsman@eecs.wsu.edu (Chris Kinsman - EE major) (10/28/90)
In article <5270@crash.cts.com> alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... > >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! > >nmake when run from a DOS-PROMPT within windows 3.0, hangs >my PS2/80 (4Mb RAM DOS3.3). > I do this. Just run an older version of Make. nmake likes to much heap. You could also run the .com version of nmake that comes with C 6.0. BTW MS doesn't answer SDK questions on Compuserve only Online. Chris
strobl@gmdzi.gmd.de (Wolfgang Strobl) (10/28/90)
alen@crash.cts.com (Alen Shapiro) writes: >Did you know (and not a lot of people know this :-)) that... No, but thanks for the info. What mode are you running Windows 3 in? >You can't be in the MSWindows 3.0 environment and compile an >MSC 6.0 program so that you can remain in the environment >while you compile-debug your windows application (SDK). >The compiler runs out of heap space!! ... > ... >Comments/hints suggestions on the above anyone? Try Zortech C++ (or C, it comes with C++) version 2.1. From one of the readme files which come with the compiler: "The Dos-Extender used in the Zortech C++ compiler and the Zortech C++ Workbench is compatible with Windows 3 and uses the DMPI standard. This means that large dos or Windows applications can be compiled from within the Windows environment. Zortech supplies two Windows 3 Icon files and example PIF files for the command line compiler and the C++ Workbench. The Icon files are ZTC.ICO and ZWB.ICO. ... NB. If you wish you can use the command line parameters option in the PIF file to set the Dos-Extended compilers as the default using the -br flag." I haven't tried to push it against the limits by compiling very large programs, but my programs aren't very small, either. I do all my work including editing and compiling Windows programs, from within the Windows environment. I don't use the Zortech Workbench, because I like my ad hoc collection of pif files and program groups better. I cannot compare the Zortech compiler to MSC 6, because we don't have it here, yet. Wolfgang Strobl #include <std.disclaimer.hpp>
strobl@gmdzi.gmd.de (Wolfgang Strobl) (10/28/90)
pkr@media01.UUCP (Peter Kriens) writes: >Buy a macintosh...... How do you compile Windows applications on a macintosh? Wolfgang Strobl
neil@kitty.ksu.ksu.edu (Neil Erdwien) (10/30/90)
In article <26929@cs.yale.edu> spolsky-joel@cs.yale.edu (Joel Spolsky) writes: >Use "nmk", not "nmake", it takes up a lot less memory. > Pre-windows 3.0, I always used nmk rather than nmake. However, in a window, nmk always gives me a FILE SHARING VIOLATION after each make. It also leaves temporary files in the directory pointed to by TMP. Nmake works OK. Both successfully run the compiler, linker, etc. -- Neil Erdwien Kansas State University neil@ksuvm.ksu.edu