From: brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill)
Subject: Re: OS/2 vs NT features list, Revision 1.4
Date: 4 Sep 92 17:26:00 MDT
Organization: University of Utah CS Dept

In article <1992Sep04.213040.17845@ans.net> db3l@ans.net (David Bolen) writes:
>In article <1992Sep4.150448.7799@hellgate.utah.edu> brian%jaguar.cs.utah.edu@cs.utah.edu (Brian Sturgill) writes:
>
>>Sigh, I have the following from somebody inside IBM who should know.
>>They told me that thread 1 simply cannot stack expand beyond the limit
>>you set at compile time, and further that the pages are committed when
>>the program starts.  This is (supposedly) a part of the executables format
>>so I don't understand how it could be different with emx+gcc.
>
>I think they were basically talking about how OS/2 loads an executable.  From
>the OS/2 loader, an application's thread 1 gets a fully committed stack based
>on the size specified in the executable (from compile time).  This is
>definitely true.
>
>So - thread 1 cannot expand it's *default* stack beyond the point allocated at
>compile time and committed during initial executable load.  But there is
>nothing stopping anyone from writing code simply to move the stack pointer
>to a different location in memory.  This is true for any thread.  So, say
>you just move the stack pointer from within thread 1 to point to a dynamically
>allocated memory object.  From that point on, you'll have a dynamic stack
>for thread 1.
>
>That's (my belief) how EMX handles the dynamic stack for an application,
>even for thread 1.  It builds an extra, uncomitted, large memory object into
>each executable, and I'd bet one of the first things the startup code does
>is switch the stack pointer to that object.
>
>>Are you saying that you know 100% for certain that this is wrong?
>>(I realize you do gcc compiler work, so perhaps you do know...)
>>All I know is that is not what IBM has told me, and that under
>>C Set/2 things don't work that way.
>
>Again - I think your friend at IBM is completely correct, but what he says
>doesn't preclude the sort of operation I am talking about.
>
>I agree about ICC - it definitely doesn't bother playing with the stack
>for thread 1.  Although I suppose someone could write a simple function that
>anyone could call from their main() to switch the stack, and get the same
>dynamic stack in an ICC program.  Ideally you'd like the C Set/2 folks to

Hmmm... Ideally I'd like the C Set/2 folks to do it?... not really...
Ideally I'd like the gcc folks do C Set/2, then I would not have all these
problems. 1/2 :-)


>do it, since they could easily tie into the code they already have for
>managing dynamic stacks for other threads.

Ah... I'm betting you've got the story now... sigh... I'll reopen it and
mail the person that gave me the other info and see what they say.

Local IBM office security, get out you're stun guns, I'm
coming down with my WorkSet/2 and some matches. :-)
(Really! I'm just kidding!!! But I would like to do it! Augggggggggh!!!)

>-- David


(Wimpering, while sitting under my desk)

Brian

P.S.
Anybody know the status of DLL creation in gcc?  I would switch if gcc
could do DLL's.  Unfortunately my package HAS to have DLL's. It would be
too big otherwise. (I'd get C++ then, too!!!)

BTW, Ian Ameline... I still do not have that CSD for WorkSet/2. :-(

People sometimes send me mail asking why I prefer developing for a "buggy"
NT SDK rather than a "finished" OS/2 2.0 GA... Do you still need to ask?
I swear... buggy though the NT SDK may be... it's much easier to deal with.
-- 
C. Brian Sturgill                       *** OS/2 2.0 is for YOU! ***
University of Utah                  Microsoft needs some competition, but
Center for Software Science        -I- want to be one of the many using NT.
brian@cs.utah.edu; CIS: 70363,1373           :-) :-) :-)