Xref: utzoo comp.lang.c:23720 comp.unix.xenix:8535 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!usc!samsung!uunet!ateng!chip From: chip@ateng.com (Chip Salzenberg) Newsgroups: comp.lang.c,comp.unix.xenix Subject: Re: Separate data and function address spaces Message-ID: <25604050.26537@ateng.com> Date: 14 Nov 89 16:41:51 GMT References: <530@dftsrv.gsfc.nasa.gov> <225800239@uxe.cso.uiuc.edu> <2559F3AE.9260@ateng.com> <1989Nov10.123033.2494@virtech.uucp> Organization: A T Engineering, Tampa, FL Lines: 22 According to cpcahil@virtech.uucp (Conor P. Cahill): >According to chip@ateng.com (Chip Salzenberg): >> The '286 and '386 processors, in protected mode, do not permit >> program execution from any data segment. This restriction can be >> bypassed only by the subterfuge of pointing two segment descriptors >> at the same piece of memory. > >I don't know what unix you are using... Conor then proceeds to describe how "real" SysV for the '386 actually does perform the two-descriptors-pointing-at-the-same-memory trick. Unlike SysV, SCO Xenix/286 and Xenix/386 versions 2.2 and 2.3 create disjoint code and data segments. The exceptions are called "impure" binaries. I've never seen impure binaries except for the '286/186/8086, and such 16-bit binaries limit code and data to a total of 64K. Incidentally, Xenix/386 2.3 can execute COFF binaries without conversion. Perhaps Xenix would give them executable data... -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; or