Open Watcom 1.9 Release Candidate 5
Peter C. Chapin
contains three changes compared to RC4.
1. A fix to the linker that prevents a crash when processing certain
library files.
2. A fix to the Windows GUI tools so that they can launch the HTML help
files more reliably.
3. A fix to the implementation of _log that should only impact certain
DOS 386 users.
Because these changes do involve a modified linker it seemed appropriate
to go through a release candidate cycle. Unless the changes above broke
something it is my expectation that this RC will become the final
release. Please review the release candidate and post any questions or
problems to the contributor's newsgroup. If nothing comes up in a week
or so, I will lock down 1.9 for good. :)
Peter
Jonathan de Boyne Pollard
>
> I just posted RC5 for download and testing.
>
appear to have been built with too small a stack size. Compare the
stack sizes of those executables with the stack sizes of the C++
compilers. Any attempt to actually compile anything at all with the
OS/2-hosted C compilers results in a "Stack Overflow!" message.
Peter C. Chapin
> It's still buggy. The OS/2-hosted C compilers, wcc.exe and wcc386.exe,
> appear to have been built with too small a stack size. Compare the
> stack sizes of those executables with the stack sizes of the C++
> compilers. Any attempt to actually compile anything at all with the
> OS/2-hosted C compilers results in a "Stack Overflow!" message.
I'm sorry I missed your earlier comments on this issue. I will verify
this on my OS/2 machine later this weekend.
Can any other OS/2 users check this?
Peter
Peter C. Chapin
I tried RC4 on my OS/2 machine and was not able to reproduce this.
Specifically I have RC4 building the Open Watcom trunk now and it seems
to be going fine. Note that I'm actually using eCS 1.2R.
I did discover other problems. In particular the installer apparently
corrupts CONFIG.SYS. Specifically it rewrites the PATH like this
PATH C:\WATCOM... (etc)
when it should do
SET PATH=C:\WATCOM... (etc)
This causes the PATH to be ignored on boot which causes many other
problems that should not occur.
As an aside whenever I install Open Watcom I always use the "selective"
option. The OS/2 installer did not have anything preselected in that
case. I don't recall that being its behavior in the past. It may not be
a big deal.
Peter
Frank Beythien
<pe...@openwatcom.org> wrote:
> On 2010-04-30 06:25, Peter C. Chapin wrote:
>
> >> It's still buggy. The OS/2-hosted C compilers, wcc.exe and wcc386.exe,
> >> appear to have been built with too small a stack size. Compare the
> >> stack sizes of those executables with the stack sizes of the C++
> >> compilers. Any attempt to actually compile anything at all with the
> >> OS/2-hosted C compilers results in a "Stack Overflow!" message.
> >
> > I'm sorry I missed your earlier comments on this issue. I will verify
> > this on my OS/2 machine later this weekend.
> >
> > Can any other OS/2 users check this?
I can compile with RC5, though the stacksize as seen by wdump output
decreased from 0x12000 to 0x10000.
> I tried RC4 on my OS/2 machine and was not able to reproduce this.
> Specifically I have RC4 building the Open Watcom trunk now and it seems
> to be going fine. Note that I'm actually using eCS 1.2R.
>
> I did discover other problems. In particular the installer apparently
> corrupts CONFIG.SYS. Specifically it rewrites the PATH like this
>
> PATH C:\WATCOM... (etc)
>
> when it should do
>
> SET PATH=C:\WATCOM... (etc)
Confirmed. I did not notice as I did not let the installer modify
config.sys.
> This causes the PATH to be ignored on boot which causes many other
> problems that should not occur.
>
> As an aside whenever I install Open Watcom I always use the "selective"
> option. The OS/2 installer did not have anything preselected in that
> case. I don't recall that being its behavior in the past. It may not be
> a big deal.
This I don't see. My preselections are shown in "selective".
CU/2
--
Frank Beythien fBeythien AT gmx.de
Peter C. Chapin
> It's still buggy. The OS/2-hosted C compilers, wcc.exe and wcc386.exe,
> appear to have been built with too small a stack size. Compare the
> stack sizes of those executables with the stack sizes of the C++
> compilers. Any attempt to actually compile anything at all with the
> OS/2-hosted C compilers results in a "Stack Overflow!" message.
I'm not in a position where I can test RC5 on OS/2 until early next
week. However, I did install RC4 on my OS/2 machine (really eCS 1.2) and
use it to build the current trunk. I then ran the C regression test
using the freshly built compiler... which incorporates all the RC5
changes and some other (hopefully insignificant) changes. There was no
problem with the regression test.
Could this issue be related to differences in OS/2 versions?
Peter
Peter C. Chapin
> <p>I suggest looking at the stack size values of <code>wcc.exe</code>,
> <code>wcc386.exe</code>, <code>wpp.exe</code>, and <code>wpp386.exe</code>
> with <code>wdump</code>. They showed a consistent pattern when I
> did. The C++ compilers have 128KiB of stack, and work. The C
> compilers have 64KiB of stack, and don't work, complaining "Stack
> Overflow!". I cannot say that that's the definite cause of the
> message, but it's a prime candidate.<br>
> </p>
Michal is also not able to reproduce this problem. It would be nice to
understand what the difference is between your configuration and the
configuration of those who have been unable to reproduce this.
I understand you to say that you can't even compile a "Hello, World" program,
true?
Peter
Dave Yeo
>>
>> Could this issue be related to differences in OS/2 versions?
>>
> possible, but I don't see how.
Are you running Warp v4 or Warp v4.5 (fixpak 13+)? If v4 could this be a
high memory issue?
Dave
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
> <pre wrap="">[M:\Develop\misc\4]type main.c
> int main () { return 0 ; }
> [M:\Develop\misc\4]wcc main.c
> Open Watcom C16 Optimizing Compiler Version 1.9
> Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See <a class="moz-txt-link-freetext" href="http://www.openwatcom.org/">http://www.openwatcom.org/</a> for details.
> Stack Overflow!
Why don't you just run the 1.9 compiler under the 1.8 debugger. Even
without symbolic debug data it should be easy enough to locate the
__STK routine that outputs the Stack Overflow message, set a break
point and figure out why the overflow is occuring.
This might give you a hint as to what is triggering the overflow.
I assume you are running your 32-bit shell. Have you tried running
under cmd.exe, just because?
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Peter C. Chapin
> There's an elephant in this room: the stack sizes. I keep mentioning
> it. (-: I think elephants are better candidates than
straws. Straws
> are for grasping when we have eliminated all of the elephants.<br>
Are you in a position where you can rebuild the compiler with a larger stack
to see what happens?
Peter
tim_c
Alarm bell, just done some tests.
The elephant has been standing there for a long time. I have long been
puzzled over the lack of stack overflow detection working and plenty of
stack strangeness.
Doing a search of the OW source tree for -s and therein stack check
appears to be turned off. I wonder if anyone has fallen for -s which
with gcc means strip debug info? With OW it means disable stack check.
I've run out of stack in program I have done and I have never seen a
warning, error, nothing, just malfunction. Does it actually work?
Lets find out.
KISS principle, just C.
Compile and run the appended
1. with stack of eg. 256k
2. with stack of 32k
3. with stack of 32k and -s
(2) shows stack overflow
(3) no idea, here it terminates, no message, no OS message.
So at least some kind of overflow check is working but this does not
explain how come that programs needing a large stack crash or
malfunction, no overflow message when compiled with stack check on and
yet increase the stack size and all is well? Why? Is there something
else stack is used for or changing?
I've not noticed a speed problem with stack overflow check enabled so
unless there really is a hit, just leave it turned on for the OW suite.
C++? Graphics?
I assume this can panic out sanely and tell the user or log it somewhere.
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#define SMALL 1000
#define HUGE 10000
const char astr[]="Quick brown fox";
static void asub(int n)
{
char bstr[HUGE];
strcpy(bstr, astr);
printf("head %d %s\n", n, bstr);
if(n<50)
{
asub(n+1);
}
printf("Tail %d %s\n", n, bstr);
}
int main(int argc, char *argv[])
{
char s[SMALL];
int i=0;
strcpy(s, astr);
asub(i);
return 0;
}
Jonathan de Boyne Pollard
>
> Are you in a position where you can rebuild the compiler with a larger
> stack to see what happens?
>
of course the C compiler doesn't work. Blast! I had high hopes there
for a minute.
So: No.
Paul S. Person
<J.deBoynePoll...@NTLWorld.COM> wrote:
>
>
> Could this issue be related to differences in OS/2 versions?
>
>
>I've been racking my brains to think of a mechanism for that to be so. It's possible, but I don't see how.
>
>
>Are you running Warp v4 or Warp v4.5 (fixpak 13+)?
>
>
>Egad! I don't actually remember whether I applied any fixpacks to it at all, it has been so long since I applied one. I'm pretty certain that I never got around to 4.5. It's probably vanilla OS/2 Warp 4, or one of the early fixpack levels.
I had to experiment a bit, but this worked for me:
1. Open an OS/2 Window.
2. Run "syslevel".
You should eventually see an entry for "IBM OS/2 Base Operating
System". It will show the current CSD level. Mine shows XR0M015,
which, since I know I have applied FixPak 15 to it, appears to be the
current installed FixPak (when decoded).
Interestingly, it still shows the version as "4.00".
If you installed NetFinity, it can provide the same information in a
GUI format. But it /is/ the same information.
Note: "syslevel.exe" is in the OS2 directory, which should be in your
path. If step 2 does not work, move to the OS2 directory on the system
partition and try it there.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Dave Yeo
> I had to experiment a bit, but this worked for me:
>
> 1. Open an OS/2 Window.
>
> 2. Run "syslevel".
>
> You should eventually see an entry for "IBM OS/2 Base Operating
> System". It will show the current CSD level. Mine shows XR0M015,
> which, since I know I have applied FixPak 15 to it, appears to be the
> current installed FixPak (when decoded).
>
> Interestingly, it still shows the version as "4.00".
ver /r at a command prompt will show the correct version and kernel version.
Dave
Peter C. Chapin
Did you say that 1.8 works (does not generate the "Stack Overflow" message)?
Peter
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
Hi,
> <p>I've already run it under the 1.9.rc4 debugger. Yes, the bright
> idea of debugging the compiler with the compiler's debugger had already
> occurred to me. (-: I reported this earlier.<br>
Sorry about that. I must have missed this among all the html markup.
> <p>You might think that. In practice, <code>wd</code> doesn't know of
> a <code>__STK</code> symbol. I tried a breakpoint on <code>DOSWRITE</code>,
> a symbol that it does know of, and the breakpoint never triggered.
The compilers get build with one name and renamed when move the the
bin directorys. For wcc386, the map is
bld\cc\os2386.386\wcc386c.map
and on my local builds the locations are
74 : 0001:00000c25* __STK
77 : 0001:00000c44* __STKOVERFLOW_
and the code is in
bld\clib\startup\a\stko32.asm
The * marking does make me curious.
The message is output by
0001:00001910 __fatal_runtime_error_
which is in
bld\clib\startup\c\xmsgo32.c
Jonathan de Boyne Pollard
>>
>> I just tried it. Building the C compiler requires the C compiler. And
>> of course the C compiler doesn't work. Blast! I had high hopes there
>> for a minute.
>>
> Did you say that 1.8 works (does not generate the "Stack Overflow"
> message)?
>
and haven't used it for C work on OS/2. I only found this when I was
trying the release candidate. I've thrown a lot of C++ code and
assembly language at the 1.9.rc4 OS/2 C++ compiler, assembler, and
linker; and thought that I'd run a little test with the C compiler as well.
I'll dig around with some old versions. Hmm. I wonder whether I still
have version 10 somewhere ...
Peter C. Chapin
> <p>So whatever this problem is, it was introduced in OpenWatcom. I've
> been using Watcom C/C++ version 11 until very recently, when I finally
> bit the bullet. So I don't have any of the earlier 1.x OpenWatcom
> versions on hand to try. I'll look through the archive on the FTP site
> later, and try a couple. But first to try the debugger again ...<br>
> </p>
You can download 1.8 from the same place where you got 1.9RC4. In fact, the
1.8 installers should be sitting right alongside the 1.9RC installers.
If 1.8 works, then you can use it to compile a version of 1.9 with a larger
stack and see what difference that makes. If 1.8 does not work, then, while
clearly a problem, it is not a problem unique to 1.9 and thus won't block
1.9's release. Either way it would be a worthwhile experiment to run.
Peter
Matjaz
installation and clicked Next. Dialog window saying "Setup will now copy
any selected files" appeared. When I clicked Next in this dialog, a new
dialog window appeared, but this one was empty. No text, just an OK
button. When I clicked OK, the installer went back to the beginning - to
the license display.
The same problem appears in OW 1.8.
I used DOSBox 0.72.
Matjaz
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
Hi,
> <p>Well thank you for that. I set execute breakpoints on various
> places within that code, and none are being hit. I notice, however,
> that two OpenWatcom DLLs are loaded into the process, <code>WDSPLICE.DLL</code>
> and <code>WCCD386.DLL</code>.
My bad. I forgot that we default to the DLL version these days.
This should get you started
Module: d:\watcom/lib386/os2\clib3r.lib(stk)
0002:0006b815 __STK
0002:0006b805 __CHK
0002:0006b844* __GRO
0002:0006b834 __STKOVERFLOW_
and they are referenced, as I would expect.
Would you like a full copy of the map via private email?
If you could manage to convince your newsreader client to send replies
to me in plain text, it would be appreciated.
Peter C. Chapin
Thanks for the report. I don't think the DOS installer gets tested very
much. You might be the first person who has actually tried to run it. :)
Peter
Brian Havard
> On 2010-04-30 06:25, Peter C. Chapin wrote:
>
>>> It's still buggy. The OS/2-hosted C compilers, wcc.exe and wcc386.exe,
>>> appear to have been built with too small a stack size. Compare the
>>> stack sizes of those executables with the stack sizes of the C++
>>> compilers. Any attempt to actually compile anything at all with the
>>> OS/2-hosted C compilers results in a "Stack Overflow!" message.
>>
>> I'm sorry I missed your earlier comments on this issue. I will verify
>> this on my OS/2 machine later this weekend.
>>
>> Can any other OS/2 users check this?
>
> I tried RC4 on my OS/2 machine and was not able to reproduce this.
> Specifically I have RC4 building the Open Watcom trunk now and it seems
> to be going fine. Note that I'm actually using eCS 1.2R.
I'm using OS/2 WSeB 4.5 (SP2) and I've just tried 1.9RC5 and everything
worked fine.
Well, actually I got some new "implicit conversion of pointers to
integral types of same size" errors but they are legitimate. I assume
this was a deliberate tightening up of the rules. My C++ code was mixing
pointers/references to int and unsigned int which was previously allowed
without error or warning.
Peter C. Chapin
> I'm using OS/2 WSeB 4.5 (SP2) and I've just tried 1.9RC5 and everything
> worked fine.
Thanks for checking it out. Did you try the C compiler at all?
Peter
Brian Havard
Yes, the code I built has a mixture of C and C++.
Dave Yeo
>> like the above, report version 4.00 for OS/2 Warp 4, for example. However, the
>> /actual/ version numbers returned by the kernel itself on OS/2 Warp 4.0 are
>> 2.40.0 (major, minor, and revision numbers):
You sure they are made up and not the version of cmd.exe. If I run
version 1 of cmd.exe it reports itself as version 1 of OS/2 (even under NT)
>>
>> > [M:\Develop\misc\4]ver<http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/cmd/commands/ver.html>
>> > TEXTCMD 1.2.0 CMDAPI 1.0.0 OS/2 2.40.0
>> > [M:\Develop\misc\4]
>>
>> See the note in the documentation for the |VER| command. My programs don't make
>> the numbers up. (-:
Your numbers are correct but a lot of people consider ver 4 to be ver 4,
not 2.4 (or in my case 2.45). Blame Microsoft for taking version 3 and
up in the divorce.
>>
>> But all of this is largely beside the point. This is a problem with the
>> compiler, not the operating system. As just demonstrated, Watcom C/C++ versions
>> 10.5 and 11.0a /don't/ exhibit this behaviour on this version of OS/2 (which
>> appears, as I guessed earlier, to be vanilla OS/2 Warp 4, by the way). And the
>> message is � almost certainly by its text � coming from an OpenWatcom RTL stack
>> checking routine, /not/ from the operating system throwing an exception.
>>
I haven't got around to downloading this release candidate but everyone
running under 4.5+ doesn't have this problem which is why I wondering if
it acts differently under ver 4. Be interesting to try Warp v3 as well.
Dave
Steven Levine
Hi,
> You sure they are made up and not the version of cmd.exe. If I run
> version 1 of cmd.exe it reports itself as version 1 of OS/2 (even under NT)
It's not made up. It is based on hard coded values compiled into the
cmd.exe binary when it is built. For example
>cmd /c ver/r
The Operating System/2 Version is 4.50
Revision 14.097
This is formated with the following message table entries
The Operating System/2 Version is %1.%2
Revision %1.%2
Paul S. Person
wrote:
<snippo>
>I haven't got around to downloading this release candidate but everyone
>running under 4.5+ doesn't have this problem which is why I wondering if
>it acts differently under ver 4. Be interesting to try Warp v3 as well.
Since he first claimed to "not remember" which FixPaks, if any, he has
installed, and then side-stepped my suggestion to use syslevel to find
out, preferring instead to attack the IBM ver (suggested by someone
else, not myself) and tout his own version, I don't think we know what
version, if any, of OS/2 he is actually running.
Jonathan de Boyne Pollard
>
> This is formated with the following message table entries
>
> The Operating System/2 Version is %1.%2
> Revision %1.%2
>
SYS-1120, SYS-1534, SYS-1721, SYS-3002, SYS-3100, and SYS-3104. I
repeat, however, what I wrote a couple of messages back: This whole
digression is largely besides the point. The important question is why
the Watcom RTL stack overflow mechanism is triggering, on this version
of OS/2, and only with the C compilers.
Igor V. Krassikov
> On 2010-04-29 23:05, Jonathan de Boyne Pollard wrote:
>
>> It's still buggy. The OS/2-hosted C compilers, wcc.exe and wcc386.exe,
>> appear to have been built with too small a stack size.
> Can any other OS/2 users check this?
Hmm... Now I tried to compile a small project (binkd 0.9.5, total above
14000 lines - sorry, now I have not larger _c_ project on my computer) -
all is OK...
Oh, wait! SQLite shell using sqlite amalgamation - 106000 lines - all is
OK also.
Best regards,
I.K.
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
>This whole
> digression is largely besides the point.
I agree. I considered not responding.
> The important question is why
> the Watcom RTL stack overflow mechanism is triggering, on this version
> of OS/2, and only with the C compilers.
Agreed. The question is what is different about your setup. So far,
there are no obvious clues.
Steven
Steven Levine
<J.deBoynePoll...@NTLWorld.COM> wrote:
Hi,
> <p>A version of <code>wccd.dll</code> built with <code>-s</code>
> would be better. (-:<br>
This is a non-trivial request.
Adding
extra_c_flags_idedrv = -DSTATIC_LINKAGE
for the OS/2 builds does not appear to be sufficent.
If you don't have a copy of the openwatcom sources, you can browse the
c compiler code at
http://perforce.openwatcom.org:4000/@md=d&cd=//depot/openwatcom/bld/cc
/c/&po=h&c=0oE@//depot/openwatcom/bld/cc/c/?ac=83
and c++ compiler code at
http://perforce.openwatcom.org:4000/@md=d&cd=//depot/openwatcom/bld/pl
usplus/&po=h&c=CL3@//depot/openwatcom/bld/plusplus/c/?ac=83
Compare the two versions of maindrv.c.
It appears thta the c version does not include the code required to
support static linkage. The code could be updated to support static
linking, but that might still leave you with a problem. Wmake uses a
similar technique to dynamic load DLLs so you might only fix one of a
number stack overflows.
It might be easier to modify the DLL Init routine to eliminate the
stack overflow check or to modify the overflow checking logic to avoid
the spurious report.
I recommend you open a bugzilla ticket and explain how the overflow is
triggered. There might be other solutions.
BTW, just for the record, what versions of os2krnl and os2ldr are you
running?
Dave Yeo
> As I wrote immediately above, this is vanilla OS/2 Warp 4, it appears. So we
> /know/ that it acts differently. The important question is why. This discussion
> of version numbers has, as I said, been a diversion from that and is largely
> beside the point.
You could try adding fixpaks (#5, then #12, then #15) to see if it changes.
>
>> Be interesting to try Warp v3 as well.
>>
> Indeed. I don't have the time for such an experiment, myself.
>
Same thing, pre fixpak #17 vs post #17 would be interesting.
Dave
Jonathan de Boyne Pollard
>>
>> This whole digression is largely besides the point.
>>
> I agree. I considered not responding.
>
>> The important question is why the Watcom RTL stack overflow mechanism
>> is triggering, on this version of OS/2, and only with the C compilers.
>>
> Agreed. The question is what is different about your setup. So far,
> there are no obvious clues.
>
Well, as you should know by now, with the help of the debugger I've
nailed down why the RTL stack check routine in the DLL is going wrong.
Why vanilla OS/2 does what it does, I couldn't tell you. But it
definitely does. As mentioned in another message, I have suspicions
that it is a workaround for applications programmers that call
DosLoadModule() when the effective 16-bit stack space is far too small,
as it is in this case.
Leif Ekblad
pretty inefficient. Win32 also has the stack in the TIB, as does RDOS, since
it emulates the behavior of Win32 in this respect. Somebody should do
something about this for systems that have the thread stack limits in the
TIB.
Leif Ekblad
"Jonathan de Boyne Pollard" <J.deBoynePoll...@NTLWorld.COM> wrote
in news:IU.D20100508.T...@J.de.Boyne.Pollard.localhost...
It's not in the DLL init routine. It's in every function in the DLL. (This
is why I mentioned compiling with -s.) The RTL's secret copy of the stack
base pointer is set incorrectly by the DLL init code, because OS/2 decides
to call the init/term routine on an alternative stack that it sets up on the
fly for the duration of the routine. The DLL init code copies that
alternative stack base and then every __STK/__CHK call within the DLL, in
every function, checks the stack pointer against the wrong value and
erroneously thinks that there has been a stack overflow.
So yes, this is a general problem with more than just these executables, and
fundamentally it's a bug in the OpenWatcom stack checking routines. I was
going to point out that they are taking a quite inefficient approach to
stack checking, as a separate issue. There's no reason for them to use a
private copy of the current thread's stack base at all. Not only does it
cause exactly this sort of problem, when alternative stacks are used and the
TIB is maintained in synchronization with the alternative stack whereas
Watcom's secret RTL data structures are not (as will be the case with anyone
who has any sort of "fibres" library); but it's exceedingly inefficient
anyway for a function that is called in the prologue of every function in
the code. There's no reason for the RTL to secretly duplicate what the
operating system already provides outright. The value of the thread's stack
base is right there in the TIB, in [FS:0x4], and __STK could just grab it
directly. Instead, it goes all around the houses, calling
(*__GetThreadPtr)(), which goes off and does a whole load of stuff
(potentially locking and unlocking a big data structure with semaphores),
including referencing the TIB anyway to get the current thread ID, and
referencing a private, unsynchronized, copy of what is provided outright in
the TIB and accessible directly with about three machine instructions
(inclusive of adding 4096 to it).
So for a third way that this problem can be addressed, fix
startup\a\stko32.asm to just retrieve [FS:0x04] directly and add 4096 to it
instead of going all around the houses with (*__GetThreadPtr)()->__stklowP.
(-:
Andreas Kohl
Jonathan de Boyne Pollard schrieb:
>> Be interesting to try Warp v3 as well.
>>
> Indeed. I don't have the time for such an experiment, myself.
I installed OW 1.9 RC 5 on Warp 3 Connect (without any fixpaks, and on a
hard disk bigger than 4 GB) without any problems. But when running C
compiler
(wcc[386].exe, wcl[386].exe) I got "Stack overflow!".
--
Andreas
Peter C. Chapin
> Yes, this behavior also kind of confused me when I ported RDOS, and it seems
> pretty inefficient. Win32 also has the stack in the TIB, as does RDOS, since
> it emulates the behavior of Win32 in this respect. Somebody should do
> something about this for systems that have the thread stack limits in the
> TIB.
This should probably be added to Bugzilla.
Peter