Date: Wed, 15 Dec 93 13:33:18 JST
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Cc: sandmann AT clio DOT rice DOT edu
Subject: GO32, GNU Make 3.69, and DV/X: report and questions

Charles Sandmann suggested that my problem was probably that nested
executions caused a memory shortage, so I decided to check that.  The
easiest thing to do was to let make execute mem, which showed

     275824 largest executable program size

in contrast to execution from the command line, with

     427280 largest executable program size

That is, GO32, its associated tables, and exec()'s bookeeping take up
about 151456 bytes of conventional memory.  So make can only spawn one
level of programs in a DOS window under DV/X.  Since GCC needs to
spawn another level, *crash!* (or, when I'm lucky, a "not enough
breathing space, exiting" message from GO32).
    Executing with the '-v' flag, it reported reading the specs and
that it was gcc version 2.5.4, tried to execute .../cpp.exe with the
usual flags, then reported "Error: not enough memory to run go32!",
cleaned up the temporary files, and exited with make error 1.
    I tried using the real-mode version of GCC, but that didn't help.
The behavior was identical, except that the real-mode version of GCC
claims to be version 2.5.5, despite the name of the .zip file, and the
versions of everything else in the compiler suite.
    Also incidentally, I managed to find the conditions under which
DV/X tends to crash.  It turns out that if I open a KTerm window and
an Emacs window from my mail host, GO32 exits due to memory shortage;
while if KTerm and Emacs aren't present, GO32 doesn't exit politely,
but crashes DV/X.  (The real-mode gcc has not yet crashed DV/X, but
presumably that's due to different amounts of memory available to the
GO32 invoked by cpp.exe, not due to the behavior of gcc.exe.)
    Doesn't GO32 know how much conventional memory it is going to use?
I thought that the code, page tables, etc, were all of fixed size.
Obviously, there's something less simple than pure memory shortage
here, since DV/X apparently cares what other windows are open.  (I am
surprised that having the network connection active makes GO32 better
behaved! although perhaps there's somewhat less memory available and
it knows it's restricted.)
    I may be able to get the amount of memory available to make up to
about 460 KB.  But this strategy seems rather risky if there are
circumstances under which spawns would be nested more than two deep
below make (or if sometimes GO32 takes more than 150KB).  Does anyone
know if there are such circumstances?  (Of course, this would fail on
most DOS machines, since few will have 150KB x 4 = 600KB available.
But it's more likely to be catastrophic when multitasking!)
    The "better solution" would be a reentrant GO32 acting as a
server.  I'd offer to help, but I'm way out of my depth at that point.
Maybe this is coming with 2.0 :-)

+-----------------------------------------------------------------------+
|                           Stephen Turnbull                            |
|     University of Tsukuba, Institute of Socio-Economic Planning       |
|          Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN            |
|        Phone:  +81 (298) 53-5091     Fax:  +81 (298) 55-3849          |
|               Email:  turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp                 |
|                                                                       |
|                Founder and CEO, Skinny Boy Associates                 |
|               Mechanism Design and Social Engineering                 |
| REAL solutions to REAL problems of REAL people in REAL time!  REALLY. |
|                      Phone:  +81 (298) 56-2703                        |
+-----------------------------------------------------------------------+


rom djgpp-bounces  Fri Jan  7 12:20:21 1994
Received: by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA07512; Sat, 18 Dec 93 08:32:29 EST
Return-Path: <buyukisik_osman AT ae DOT ge DOT com>
Received: from crdems.ge.com by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA07508; Sat, 18 Dec 93 08:32:26 EST
Received:  from c0228.ae.ge.com by crdems.ge.com (5.65/GE 1.73) id AA23463; Sat, 18 Dec 93 08:29:32 -0500
Message-Id:  <9312181329 DOT AA23463 AT crdems DOT ge DOT com>
Received: from c0230.ae.ge.com by c0228.ae.ge.com with SMTP(1.37.187.4/15.6) id AA00402; Sat, 18 Dec 93 08:32:17 -0500
Received: by c0230.ae.ge.com(1.37.187.4/16.2) id AA29895; Sat, 18 Dec 93 08:33:09 -0500
Date: Sat, 18 Dec 93 08:33:09 -0500
From: U-E59264-Osman Buyukisik <buyukisik_osman AT ae DOT ge DOT com>
To: kato AT cats DOT ucsc DOT edu
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
In-Reply-To: <199312180905 DOT BAA01715 AT am DOT ucsc DOT edu> (kato%cats DOT ucsc DOT edu AT c0228 DOT ae DOT ge DOT com)
Subject: Re: gcc 2.5.7, go32 1.11.maint1

>>>>> "Kathy" =From djgpp-bounces  Fri Jan  7 13:17:27 1994
Received: by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA00552; Fri, 7 Jan 94 12:26:36 EST
Return-Path: <astor AT alkymi DOT unit DOT no>
Received: from ild.alkymi.unit.no by sun.soe.clarkson.edu (4.1/SMI-4.1)
	id AA00529; Fri, 7 Jan 94 12:26:19 EST
Received: by ild.alkymi.unit.no id AA08664
  (5.65c/IDA-1.4.4 for djgpp AT sun DOT soe DOT clarkson DOT edu); Fri, 7 Jan 1994 18:24:17 +0100
From: Alexander S A Kjeldaas <astor AT alkymi DOT unit DOT no>
Message-Id: <199401071724 DOT AA08664 AT ild DOT alkymi DOT unit DOT no>
Subject: What is the address of the code?
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Fri, 7 Jan 1994 18:24:17 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 323       

I use have written some assembly routines in TASM that I want to port and use with DJGPP. Some of the code is self-modifying, so I need to know where the address of the routine is. Now, where is the code located and do I have write access to this memory area?

A small (4-5 lines) AS example would be nice.

Thanks,
  Alex