Browse Prior Art Database

Sixteen to Thirty-two Bit Operating System Compatibility Method for Personal Computers

IP.com Disclosure Number: IPCOM000121725D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 4 page(s) / 152K

Publishing Venue

IBM

Related People

Gruse, GG: AUTHOR [+2]

Abstract

Described is a personal computer memory management facility that allows a 16-bit operating system (OS) architecture to be compatible with a 32-bit. The method allows segmented memory architecture of 16-bit OS to be overlayed on top of the flat memory architecture of 32-bit OS, thereby enabling 16-bit applications to coexist with 32-bit applications and subsystems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Sixteen to Thirty-two Bit Operating System Compatibility Method for
Personal Computers

      Described is a personal computer memory management
facility that allows a 16-bit operating system (OS) architecture to
be compatible with a 32-bit. The method allows segmented memory
architecture of 16-bit OS to be overlayed on top of the flat memory
architecture of 32-bit OS, thereby enabling 16-bit applications to
coexist with 32-bit applications and subsystems.

      Typically, applications and subsystems written for a 16-bit OS
adhere to a 16-16 segmented memory model.  The 32-bit OS memory model
is the flat model, also called 0:32. Since the memory models of both
types of systems are quite different, the linkage conventions and
functionalities to provide 16-bit OS compatibility is the prime
objective of the concept described herein.

      To support both 0:32 and 16-16 addressing formats in the same
process requires the ability to translate a 0:32 address into a 16:16
address and vice versa.  In the 32-bit OS memory model, a 0:32
address is the same as the linear address.  Therefore, converting a
16:16 address to a 0:32 is accomplished by obtaining the segment's
base linear address from the descriptor table entry specified by the
selector and adding the offset to it.  Translating from 0:32 to
16:16, conversely, requires the existence of a descriptor table entry
that maps the appropriate region of the linear address space.  A
32-bit OS could provide application programming interfaces (APIs) to
perform these translations. The use of an API, however, would be
difficult to implement and would require a descriptor to be allocated
and initialized.  The system would also have to provide another API
to destroy the mapping when it was no longer needed.

      In a 16-bit OS, the maximum amount of memory a process can own
is limited by the amount of memory its local descriptor table (LDT)
can map.  An LDT can have 8192 descriptors, each mapping up to 64Kb
of memory.  Therefore, the maximum amount of memory an application
can have is 8192 x 64 or 512Mbytes.  This amount excludes the
system-owned memory mapped by the global descriptor table (GDT), but
includes all shared memory allocated by processes in the system.  In
a 32-bit OS, this limit will be retained for each process in order to
have one-to- one mapping between the two addressing formats.  For
segmented applications, the base address of every segment will be
equal to the thirteen high-order bits of the selector, which is the
index of the corresponding descriptor in the LDT, times 64K.  The low
three bits in a selector determine the table and ring protection
levels and are not indicative of distinct memory addresses.
Therefore, conversion from a 16:16 (selector:offset) address to a
0:32 address (linaddr) is performed by way of the following formula:
          linaddr = (selector >> 3)  << 16 + offset
When a 0:32 application allocates an object, either statical...