Indeed, this was a problem as the code that reads / writes thread state uses
a 10-byte float-type. I think this is why the pad was there.
I fixed it by using OWs xreal type instead. Turns out that the x86 FPU state
is already defined with xreal type.
OTOH, in order to use xreal type, I had to include machtype.h, which outside
OW build environment doesn't work as machtype.h is not exported, and it
additionally uses watcom.h and some other files that are not available
the build environment. I fixed this by extracting the type definition
the dependencies, and then I placed this file in RDOS repository.
Linking with mathlib should be no problem as RDOS newer requires the FPU
emulator (when it runs on 386 or other processors without FPU it emulates
the FPU so the application have no idea if the FPU exist or not).
Post by Jiri Malak
With regards to reported "Trap build error" problem I checked what happend.
During investigation I found out potential problem in Tss structure
definition for RDOS.
long double st;
Be careful because long double is in OW same as double by default.
Also use of FP type links mathlib into application even if it is not
Probably best will be to change definition of FPU registers in Fss to be
unsigned char b;