From: db3l@ans.net (David Bolen)
Subject: Re: OS/2 vs NT features list, Revision 1.2
Date: Tue, 1 Sep 1992 13:04:32 GMT
	<1992Sep1.000214.29640@hellgate.utah.edu>
	<1992Sep1.071831.12626@cs.brown.edu>
	<1992Sep1.014744.11140@hellgate.utah.edu>
Organization: Advanced Network & Services, Inc. - Elmsford, NY

In article <1992Sep1.014744.11140@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:

>I think you misunderstand what has happened here... I did run the program
>I sent out and it does indeed do as I say.. I USED ICC (part of
>WorkSet/2), you used emx... this is VERY INTERESTING... maybe OS/2
>really does have dynamic stack expansion... and the C Set/2 compiler defeats
>it.  Seriously... can someone at IBM clear this up for us?
>I won't mind being wrong at all... in fact I'd be quite happy... these
>stack limits have been driving me nuts.
>(And they say reading the advocacy group isn't useful! Hmmph!)

I think it's because C Set/2 doesn't do anything special for thread 1 of
a process.  If you used beginthread with a large maximum size (ala one of
your recent posts), you'd see the dynamic expansion.

I've been interested in how EMX works too - so I took a look at one of the
headers of an EMX executable (temacs.exe).  What it looks like is happening is
that EMX executables are created with a static 16K stack (ala other OS/2
applications, including those created with C Set/2), but that they also
contain an unallocated automatic memory object that's 0x02000000 (32MB) in
size.  Thus, when such an executable loads, the stack pointer points to the
end of the 16K object, but there's an allocated (but not committed) 32MB
memory object available. 

Now it's possible that for the particular test program, GCC did some sort of
automatic optimization of the recursion which allowed it to run within the 16K
stack, but what seems more likely (given things other people have said about
EMX programs) is that the EMX startup code commits the first page or first few
pages of the 32MB memory object, sets up a guard page, and then switches the
stack for the first thread over to this memory object.

So at least from my view, both ICC and EMX/GCC are doing basically the same
thing, only EMX does a bit more underneath the covers.

I'm not actually sure which I prefer.  The EMX method seems to waste 16K of
memory for each executable loaded, but it's easier on the programmer than
manually creating a thread as ICC would require.  Also, creating the thread
under ICC would still "waste" whatever stack the first thread has, as well
as now using 2 threads, where EMX just uses 1. (as long as the only reason
for creating thread 2 was to get a growable stack).  

Hmmm - guess I think I like the EMX approach a little better :-)  I can
definitely understand why it's required if the concern is porting Unix-based
programs that may require the growing stack.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/
Newsgroups: comp.os.os2.advocacy