OS/2 Research Outline - Revision history

Dr. Shuppet: /* Added note about AMD and Intel lawsuits about the 386 */

2023-01-25T20:13:14Z

Added note about AMD and Intel lawsuits about the 386

← Older revision		Revision as of 20:13, 25 January 2023
Line 138:		Line 138:

	The largest problem appears to not so much the protected mode of the 286, but the lack of a way to virtualize DOS (see below). The FOOTBALL demo, which uses V8088 mode on a 386 to provide DOS multitasking was available in 1986-87, although 386 systems would have been extremely rare at the time. OS/2 1.2 was essentially the feature complete release of the 1.x family, with 1.3 being more of a bug release, and parting of ways for Microsoft. Need to research this into a timeline.		The largest problem appears to not so much the protected mode of the 286, but the lack of a way to virtualize DOS (see below). The FOOTBALL demo, which uses V8088 mode on a 386 to provide DOS multitasking was available in 1986-87, although 386 systems would have been extremely rare at the time. OS/2 1.2 was essentially the feature complete release of the 1.x family, with 1.3 being more of a bug release, and parting of ways for Microsoft. Need to research this into a timeline.

			It can be speculated that CPU license issues were behind the delayed release of the 386 version of OS/2. Allegedly, IBM did not want to rely on a single CPU vendor, which limited the possibility of adopting the 386, AMD's rights to which were subject to lawsuits that were only resoled in 1991.

	=== HPFS ===		=== HPFS ===

NCommander: NCommander moved page OS/2 Research and Discovery Documentary to OS/2 Research Outline without leaving a redirect: Need a better landing page

2023-01-13T19:09:34Z

NCommander moved page OS/2 Research and Discovery Documentary to OS/2 Research Outline without leaving a redirect: Need a better landing page

← Older revision		Revision as of 19:09, 13 January 2023
(No difference)

Dr. Shuppet: /* Improved IOPL description */

2023-01-10T17:16:01Z

Improved IOPL description

← Older revision		Revision as of 17:16, 10 January 2023
Line 143:		Line 143:

	=== Use of Segmentation in Protected Mode (such as IOPL) ===		=== Use of Segmentation in Protected Mode (such as IOPL) ===
	OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file ~~that some (how many?)~~ of their code segments ~~had~~ IOPL (I/O privilege level). ~~If the line "~~IOPL=YES~~" was in~~ the ~~user's CONFIG.SYS file (set by~~ default ~~in MS~~ OS/2, not ~~by default in IBM OS/2~~)~~, then the code in that segment would run in ring 2, and thus would be allowed to access hardware directly~~ <ref>http://www.edm2.com/index.php/Introduction_to_IOPL_programming#Overview_of_IOPL_and_the_80x86_protection_mechanism</ref>.		OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file which of their code segments are IOPL segments (I/O privilege level). Additionally, CONFIG.SYS contains an IOPL directive that limits which applications allowed to use IOPL. IOPL=YES and IOPL=NO are used to enable or disable IOPL for all applications; the former is default on some versions of Microsoft OS/2 (TODO: which version? Seems to include 1.0, but not 1.3.)<ref>http://www.edm2.com/index.php/Introduction_to_IOPL_programming#Overview_of_IOPL_and_the_80x86_protection_mechanism</ref>.

	This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.		This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.

Waterpear: /* Use of Segmentation in Protected Mode (such as IOPL) */ multiplan does use IOPL

2023-01-10T16:31:19Z

Use of Segmentation in Protected Mode (such as IOPL): multiplan does use IOPL

← Older revision		Revision as of 16:31, 10 January 2023
Line 143:		Line 143:

	=== Use of Segmentation in Protected Mode (such as IOPL) ===		=== Use of Segmentation in Protected Mode (such as IOPL) ===
	OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file that some (how many?) of their code segments had IOPL (I/O privilege level). If the line "IOPL=YES" was in the user's CONFIG.SYS file, then the code in that segment would run in ring 2, and thus would be allowed to access hardware directly <ref>http://www.edm2.com/index.php/Introduction_to_IOPL_programming#Overview_of_IOPL_and_the_80x86_protection_mechanism</ref>.		OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file that some (how many?) of their code segments had IOPL (I/O privilege level). If the line "IOPL=YES" was in the user's CONFIG.SYS file (set by default in MS OS/2, not by default in IBM OS/2), then the code in that segment would run in ring 2, and thus would be allowed to access hardware directly <ref>http://www.edm2.com/index.php/Introduction_to_IOPL_programming#Overview_of_IOPL_and_the_80x86_protection_mechanism</ref>.

	This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.		This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.
Line 154:		Line 154:

	* Word for Windows provides DE.EXE, as part of its UI designer that requires IOPL=yes to be enabled in CONFIG.SYS		* Word for Windows provides DE.EXE, as part of its UI designer that requires IOPL=yes to be enabled in CONFIG.SYS
	* ~~The README for~~ Multiplan ~~claims it needs IOPL=YES to be set, but it appears to start without it. (It's possible that only certain features use IOPL and the app would crash when those features are used.)~~		* Multiplan
	* other applications can do similar based on their manifest (although I need to check the LX format documentation)		* other applications can do similar based on their manifest (although I need to check the LX format documentation)

Waterpear: /* Use of Segmentation in Protected Mode (such as IOPL) */ explain how segmentation and ring 2 combine to create the "IOPL segment" concept; document Multiplan's ostensible use of IOPL

2023-01-10T16:26:27Z

Use of Segmentation in Protected Mode (such as IOPL): explain how segmentation and ring 2 combine to create the "IOPL segment" concept; document Multiplan's ostensible use of IOPL

← Older revision		Revision as of 16:26, 10 January 2023
Line 143:		Line 143:

	=== Use of Segmentation in Protected Mode (such as IOPL) ===		=== Use of Segmentation in Protected Mode (such as IOPL) ===
	~~One notable feature of~~ OS/2 ~~was its use~~ of the ~~x86~~'s protection ~~rings~~. It's one of the ~~few known examples that use~~ ring ~~1 and~~ 2, ~~and the IO privilege separation levels of the 286 and later. Word~~ for ~~Windows provides DE~~.~~EXE~~, ~~as part~~ of ~~its UI designer that requires~~ IOPL=~~yes to be enabled~~ in CONFIG.SYS, ~~and other applications can do similar based on their manifest (although I need to check~~ the ~~LX format documentation). This also meant~~ that ~~OS/~~2 ~~could, at least theoretically, support features like no eXecute on the 286~~, and ~~more, providing a level of application hardening that didn't exist until decades later~~.		OS/2 is notable for being one the few operating systems to take advantage of the 286's segmentation-based memory protection model. It's one of the rare users of protection ring 2, which subsequent operating systems such as Windows NT chose to ignore for portability reasons. When being linked, applications could declare in the module .DEF file that some (how many?) of their code segments had IOPL (I/O privilege level). If the line "IOPL=YES" was in the user's CONFIG.SYS file, then the code in that segment would run in ring 2, and thus would be allowed to access hardware directly <ref>http://www.edm2.com/index.php/Introduction_to_IOPL_programming#Overview_of_IOPL_and_the_80x86_protection_mechanism</ref>.

	Unfortunately, as a single user operating system, ~~it also had~~ limits on how much ~~this~~ could ~~actually help things~~. Perhaps research into this design decision is warranted, especially in places where user authentication is used.		This had several benefits. If applications separated IOPL code correctly, bugs in the non-IOPL segments wouldn't cause wayward I/O accesses. The design of the 286 encouraged this; calling the IOPL segment required applications to define call gates, which encouraged the use of a well-defined interface between ordinary ring 3 code and IOPL code. Also, since the IOPL segment ran in ring 2 and not in ring 0 (kernel mode,) it was still subject to memory protection and was not allowed to access memory that its process could not normally access. This includes kernel memory.

			OS/2's use of segmentation could have, at least theoretically, let it support features like NX (No eXecute) on the 286, which would have provided a level of application hardening that didn't exist until decades later.

			Unfortunately, as OS/2 was a single user operating system, there were limits on how much security could be obtained using segmentation. Perhaps research into this design decision is warranted, especially in places where user authentication is used.

			Noteworthy uses of IOPL include:

			* Word for Windows provides DE.EXE, as part of its UI designer that requires IOPL=yes to be enabled in CONFIG.SYS
			* The README for Multiplan claims it needs IOPL=YES to be set, but it appears to start without it. (It's possible that only certain features use IOPL and the app would crash when those features are used.)
			* other applications can do similar based on their manifest (although I need to check the LX format documentation)

	=== Networking with NetWare/LAN Server/LAN Manager ===		=== Networking with NetWare/LAN Server/LAN Manager ===

Waterpear: /* Comparison to DOS and Creating Family Mode applications */ remove stray nowiki tag template message

2023-01-10T15:21:34Z

Comparison to DOS and Creating Family Mode applications: remove stray nowiki tag template message

← Older revision		Revision as of 15:21, 10 January 2023
Line 103:		Line 103:
	To create a family mode binary, a regular OS/2 binary is created first, then the BIND utility (shipped with Microsoft C) is applied, which adds the necessary DOS stub. If the binary contains calls not supported in family mode, BIND will exit with an error specifying the calls.		To create a family mode binary, a regular OS/2 binary is created first, then the BIND utility (shipped with Microsoft C) is applied, which adds the necessary DOS stub. If the binary contains calls not supported in family mode, BIND will exit with an error specifying the calls.

	Family mode binaries were fairly rare, but Windows NT will always default to using a OS/2 mode binary over a DOS binary unless the ~~FORCEDOSInsert non-formatted text here~~ command is used.		Family mode binaries were fairly rare, but Windows NT will always default to using a OS/2 mode binary over a DOS binary unless the FORCEDOS command is used.

	=== GDI vs GPI (and other API differences) ===		=== GDI vs GPI (and other API differences) ===

Dr. Shuppet: /* Changed broken link to IBM's OS/2 application list to a reference */

2023-01-08T17:49:32Z

Changed broken link to IBM's OS/2 application list to a reference

← Older revision		Revision as of 17:49, 8 January 2023
Line 120:		Line 120:
	While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).		While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).

	IBM created a list of applications for OS/2, which is now ~~[http:~~/~~/stored~~ https://www.os2world.com/wiki/index.php/IBMs_list_of_all_16-bit_OS/2_applications~~] at OS~~/~~2 World Wiki~~.		IBM created a list of applications for OS/2, which is now stored at OS/2 World Wiki<ref>https://www.os2world.com/wiki/index.php/IBMs_list_of_all_16-bit_OS/2_applications</ref>.

	By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...		By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...

Dr. Shuppet at 17:48, 8 January 2023

2023-01-08T17:48:29Z

← Older revision		Revision as of 17:48, 8 January 2023
Line 120:		Line 120:
	While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).		While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).

	IBM created a list of applications for OS/2, which is now [[stored\|https://www.os2world.com/wiki/index.php/IBMs_list_of_all_16-bit_OS/2_applications]] at OS/2 World Wiki.		IBM created a list of applications for OS/2, which is now [http://stored https://www.os2world.com/wiki/index.php/IBMs_list_of_all_16-bit_OS/2_applications] at OS/2 World Wiki.

	By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...		By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...

Dr. Shuppet: /* Added link to IBM's list of OS/2 applications */

2023-01-08T17:47:58Z

Added link to IBM's list of OS/2 applications

← Older revision		Revision as of 17:47, 8 January 2023
Line 119:		Line 119:
	=== Exploring Native OS/2 Apps ===		=== Exploring Native OS/2 Apps ===
	While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).		While OS/2 didn't have a lot of apps, it did have decent first party support from Microsoft in its early days, as well as a couple of dedicated apps such as the DeScribe word processor and more. By and large, OS/2 had a small set of productivity apps, and some DOS and Windows ports, but was relatively sparse. Furthermore, due the the inherent problems of Presentation Manager, Win-OS/2 apps were sometimes preferable since they couldn't deadlock the system like native PM apps could due to the Single Input Queue (SIQ).

			IBM created a list of applications for OS/2, which is now [[stored\|https://www.os2world.com/wiki/index.php/IBMs_list_of_all_16-bit_OS/2_applications]] at OS/2 World Wiki.

	By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...		By and large, IBM did define the Common User Access Guidelines throughout this era, which was similar to Apple's Human Interface Guidelines, so it's generally expected that OS/2 native applications may have a more consistent look and feel. At the time of writing, it's unknown if there were any good frameworks like MFC or OWL for OS/2 ...

Dr. Shuppet: /* Added link to OS/2 history page */

2023-01-07T11:34:15Z

Added link to OS/2 history page

← Older revision		Revision as of 11:34, 7 January 2023
Line 24:		Line 24:

	=== OS/2 Pre-alphas and 1.0 ===		=== OS/2 Pre-alphas and 1.0 ===
			''The [[OS/2 Versions And History]] page contains additional information to this topic''
	[[File:1987-05-11-InfoWorld-p13.png\|thumb\|x300px\|Scan of page InfoWorld 1987]]		[[File:1987-05-11-InfoWorld-p13.png\|thumb\|x300px\|Scan of page InfoWorld 1987]]
	What was the actual intended goals of OS/2? It's often cited that OS/2 was intended to deal with the shortcomings of DOS, namely lack of multitasking and memory restrictions, but is this actually true?		What was the actual intended goals of OS/2? It's often cited that OS/2 was intended to deal with the shortcomings of DOS, namely lack of multitasking and memory restrictions, but is this actually true?