rich@bvax.UUCP (Rich Chahley) (06/22/87)
Further to my posting on June 4, I have received numerous requests for info
on GKS. For the benefit of all, the packages we are using are listed below:
GKS/C Ver 2.3 (for SCO XENIX)
Prior Data Sciences
240 Michael Cowpland Drive
KANATA, Ontario Canada K2M 1P6
+1 613-591-7235
INFORMIX C-ISAM Ver 3.1 (for SCO XENIX)
Informix Software
4100 Bohannon Drive
MENLO PARK, CA USA 94025
+1 415-322-4100
As posted before, we are currently experiencing problems when using the
multiscreen feature with XENIX (where <Alt>-<Function key> brings up a new
screen). This is somehow related to GKS.
We also ran into a mitful of problems when GKS, INFORMIX C-ISAM is linked
together with our application software developed in-house. The problem is
with the stack space for the "near data segment" in XENIX. Apparantly the
near data segment includes the uninitialized data and string constants and
cannot exceed 64k.
The quick work-around is to move the string constants from the application
software out of the d-segment. I'm not sure what the long term fix will be
(according to SCO, a long term fix is somewhat messy and $$$).
I will post any other findings as they become known. In the meantime, I would
appreciate any feedback or comments (if any) on the above.
Richard Chahley
Corporate Engineering (Planning & Standards)
Bell Canada
{ihnp4, allegra, watmath, decvax} !utzoo!bnr-vpa!bnrnuns!ngpt!richjfh@killer.UUCP (John Haugh) (06/25/87)
In article <241@bvax.UUCP>, rich@bvax.UUCP (Rich Chahley) writes: > We also ran into a mitful of problems when GKS, INFORMIX C-ISAM is linked > together with our application software developed in-house. The problem is > with the stack space for the "near data segment" in XENIX. Apparantly the > near data segment includes the uninitialized data and string constants and > cannot exceed 64k. > > The quick work-around is to move the string constants from the application > software out of the d-segment. I'm not sure what the long term fix will be > (according to SCO, a long term fix is somewhat messy and $$$). > > Richard Chahley This used to be a problem with PDP-11's. The entire program can only be 64K period. (Unless you use separate I&D) Some programs would move some of the strings into the text segment to cut down on the amount of space that was used for all of those multiple copies of the program. By putting the string constants into the text segment, if the program ran shared text, you could save a lot of memory. I believe this was done with the shell for exactly this reason. Well, that or speeding up forks. But then I digress because of the old inews problem. Write a sed script to change all of the .data's to .text's in whatever file you keep your string constants in. - John. "90% of everything is crap." -- From your local fortune program.
jamescb@sco.UUCP (James Bohem) (07/02/87)
In article <1043@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: >In article <241@bvax.UUCP>, rich@bvax.UUCP (Rich Chahley) writes: >> We also ran into a mitful of problems when GKS, INFORMIX C-ISAM is linked >> together with our application software developed in-house. The problem is >> with the stack space for the "near data segment" in XENIX. Apparantly the >> near data segment includes the uninitialized data and string constants and >> cannot exceed 64k. >> ::: > >This used to be a problem with PDP-11's. The entire program can only be >64K period. (Unless you use separate I&D) Some programs would move some ::: etc. Not quite the same on an Intel 80286 (please no segmented architecture flames, I hate it too): In this case, Informix is a medium model program (1 64K data segment, multiple text segments); The 64K limitation is small model on the 8086/80286, just like PDP's, and just like PDP's, the -i option to cc will give you 64K of each text and data. Informix, and its libraries for C program development still have a data space limitation of 64K, but not a text limitation. Note that on the 286 you can use the brkctl() call to allocate > 64K using **far** pointers (but be reeeal careful). This helps with overall data requirements but NOT with initialised data. But by making most of your data access a far segment, you can hopefully find space in the first data segment for the initialised data. Remember that your stack comes out of that first data segment too, so leave room for it.