DisNCord Community Wiki - User contributions [en]

Picotalk

2024-09-10T16:00:39Z

Waterpear: reserving page for future use

#REDIRECT [[Homebrew_OS_Development#picotalk]]

Homebrew OS Development

2024-09-07T01:07:12Z

Waterpear: /* picotalk */ status update on picotalk

[[Category:Projects]]
This is a general summary of what OSes are being developed on DisNCord.

=== Open Computing Kit (OCK) ===
A joint project between Elisia, Sadmac356, Griffin, Europa, and others, [https://github.com/open-computing-kit Open Computing Kit] is an operating system that aims to be as GNU-independent as possible, including a [https://github.com/open-computing-kit/ockernel kernel written in Rust] and its [https://github.com/open-computing-kit/OCKcore own set of coreutils]. It is presently in the very early stages of active development.
[[File:SeshOS3.png|thumb|SeshOS as of August 6th, 2024]]

=== SeshOS ===
Written by Mineman, SeshOS is one of the more esoteric OSes on DisNCord. As of 10/15/2022 it has a working malloc thanks to Krabs and Mathewnd.

SeshOS has support for one filesystem: tar ramfs.

Has very basic SMP setup, and has support for the PC Speaker.

Its source code is located at https://github.com/mine-man3000/SeshOS.

Techflash also rewrote the entire thing in C and ported bits of his OS to this.
=== Pics Of Bread Awful scRipting Interpreter System for Neat Architectures (POBARISNA) ===
Written by Krabs, POBARISNA is an operating system with a JavaScript-based microkernel design that currently only runs on PowerPC macs. There are prospective plans for ports to other "Neat Architectures" (which Krabs defines as "not a PC/BIOS/UEFI x86 system"), such as SPARC variants and ARM.

The project can be found on [https://gitlab.com/sarahcrowle/pobarisna GitLab].

The JavaScript interpreter used in POBARISNA is [https://duktape.org/ Duktape], an easily embeddable interpreter with a nice API. However, Duktape 2.x has some awkward tooling and a lack of solid control over execution. Therefore, there are plans to replace it with [https://gitlab.com/sarahcrowle/dorktape Dorktape], which will hopefully serve as a modernized fork of the engine.

Being that PowerPC OpenFirmware is a slightly under-documented platform, [[PowerPC OpenFirmware Implementation Details]] should serve as helpful to anyone looking to do something similar.
[[File:POBARISNA running duktape on bare metal.jpg|alt=An early screenshot of POBARISNA running Duktape in OpenFirmware|thumb|An early screenshot of POBARISNA running Duktape in OpenFirmware]]

=== picotalk ===
Written by Waterpear, picotalk is a Smalltalk interpreter that aims to be a bare-metal system for embedded use.

An early attempt to implement a system from scratch in C existed, but has been abandoned. Instead, the plan is to recreate the original Smalltalk-80 system, build an RPC layer to allow the development tools to operate over a serial link, and strip out features not needed for embedded systems such as the GUI. A "zeroth prototype" written in Python is in progress, and can run some of the Smalltalk development tools.

=== Rotom OS ===
Written by SED, [https://github.com/SED4906/rotomos Rotom OS] is an operating system with little information to glean from anything except for its code and a few images. It attempts to be as simple as possible, with ring 3 not yet being implemented.
[[File:RotomOS.png|thumb|Rotom OS]]

=== styx ===
Written by Sirocyl and others, styx is an operating system with many ideas, some of which will be listed here:
* Applications will be double-click to run, much like Windows or macOS.
* Libraries should live with their application in packaging, similar to Windows.
* Installation will be done through drag-and-drop, taken from macOS.
* The system will be as (trans)portable as possible, similar to Classic macOS.
* The word "styx" is not an acronym, nor will the operating system's governing body ever be comprised of one member.
* The system will be consent-first, something that flies in the face of traditional operating systems like Windows and macOS.
There are many more than are stated here in their Discord server, due to there being too many to list here effectively.

=== Astral ===
Written by Mathewnd, [https://github.com/Mathewnd/Astral Astral] is a monolithic kernel written in C. It is still at its early stages of development and has the beginnings of a userland.

It has a growing port collection with a few examples being Bash, Doom, Binutils, Coreutils and NASM.

Its current main goal is to have a usable command line interface while also having fun developing the system.
[[File:Astral neofetch.png|alt=Astral running Neofetch on Oct 11, 2022|thumb|Astral running Neofetch on Oct 11, 2022]]

=== Techflash OS (TFOS) ===
Written by Techflash, [https://github.com/techflashYT/Techflash-OS Techflash OS] is an operating system that is still very early in development.

It current has very little implemented except for the following:

* A basic boot procedure
* Enabling a few CPU features
* Support of a few basic interrupts, such as the [[wikipedia:Intel_8253|PIT]] and keyboard.
* A very basic framebuffer console
* Starts of an ELF loader
* Serial and Parallel support for logging

Homebrew OS Development

2024-09-07T00:58:20Z

Waterpear: /* Pics Of Bread Awful scRipting Interpreter System for Neat Architectures (POBARISNA) */ update link to dorktape

[[Category:Projects]]
This is a general summary of what OSes are being developed on DisNCord.

=== Open Computing Kit (OCK) ===
A joint project between Elisia, Sadmac356, Griffin, Europa, and others, [https://github.com/open-computing-kit Open Computing Kit] is an operating system that aims to be as GNU-independent as possible, including a [https://github.com/open-computing-kit/ockernel kernel written in Rust] and its [https://github.com/open-computing-kit/OCKcore own set of coreutils]. It is presently in the very early stages of active development.
[[File:SeshOS3.png|thumb|SeshOS as of August 6th, 2024]]

=== SeshOS ===
Written by Mineman, SeshOS is one of the more esoteric OSes on DisNCord. As of 10/15/2022 it has a working malloc thanks to Krabs and Mathewnd.

SeshOS has support for one filesystem: tar ramfs.

Has very basic SMP setup, and has support for the PC Speaker.

Its source code is located at https://github.com/mine-man3000/SeshOS.

Techflash also rewrote the entire thing in C and ported bits of his OS to this.
=== Pics Of Bread Awful scRipting Interpreter System for Neat Architectures (POBARISNA) ===
Written by Krabs, POBARISNA is an operating system with a JavaScript-based microkernel design that currently only runs on PowerPC macs. There are prospective plans for ports to other "Neat Architectures" (which Krabs defines as "not a PC/BIOS/UEFI x86 system"), such as SPARC variants and ARM.

The project can be found on [https://gitlab.com/sarahcrowle/pobarisna GitLab].

The JavaScript interpreter used in POBARISNA is [https://duktape.org/ Duktape], an easily embeddable interpreter with a nice API. However, Duktape 2.x has some awkward tooling and a lack of solid control over execution. Therefore, there are plans to replace it with [https://gitlab.com/sarahcrowle/dorktape Dorktape], which will hopefully serve as a modernized fork of the engine.

Being that PowerPC OpenFirmware is a slightly under-documented platform, [[PowerPC OpenFirmware Implementation Details]] should serve as helpful to anyone looking to do something similar.
[[File:POBARISNA running duktape on bare metal.jpg|alt=An early screenshot of POBARISNA running Duktape in OpenFirmware|thumb|An early screenshot of POBARISNA running Duktape in OpenFirmware]]

=== picotalk ===
Written by Waterpear, picotalk is a Smalltalk interpreter that aims to be a bare-metal system for embedded use. It is currently in a very limited state; only the base object model and a preliminary bytecode VM are operational.

=== Rotom OS ===
Written by SED, [https://github.com/SED4906/rotomos Rotom OS] is an operating system with little information to glean from anything except for its code and a few images. It attempts to be as simple as possible, with ring 3 not yet being implemented.
[[File:RotomOS.png|thumb|Rotom OS]]

=== styx ===
Written by Sirocyl and others, styx is an operating system with many ideas, some of which will be listed here:
* Applications will be double-click to run, much like Windows or macOS.
* Libraries should live with their application in packaging, similar to Windows.
* Installation will be done through drag-and-drop, taken from macOS.
* The system will be as (trans)portable as possible, similar to Classic macOS.
* The word "styx" is not an acronym, nor will the operating system's governing body ever be comprised of one member.
* The system will be consent-first, something that flies in the face of traditional operating systems like Windows and macOS.
There are many more than are stated here in their Discord server, due to there being too many to list here effectively.

=== Astral ===
Written by Mathewnd, [https://github.com/Mathewnd/Astral Astral] is a monolithic kernel written in C. It is still at its early stages of development and has the beginnings of a userland.

It has a growing port collection with a few examples being Bash, Doom, Binutils, Coreutils and NASM.

Its current main goal is to have a usable command line interface while also having fun developing the system.
[[File:Astral neofetch.png|alt=Astral running Neofetch on Oct 11, 2022|thumb|Astral running Neofetch on Oct 11, 2022]]

=== Techflash OS (TFOS) ===
Written by Techflash, [https://github.com/techflashYT/Techflash-OS Techflash OS] is an operating system that is still very early in development.

It current has very little implemented except for the following:

* A basic boot procedure
* Enabling a few CPU features
* Support of a few basic interrupts, such as the [[wikipedia:Intel_8253|PIT]] and keyboard.
* A very basic framebuffer console
* Starts of an ELF loader
* Serial and Parallel support for logging

Unix Windowing Systems

2024-04-13T23:36:28Z

Waterpear: /* Early Competitors and Predecessors */ quick note about X10R3 being included with 4.3BSD in new.tar

The phrase "windowing system for Unix" is nearly synonymous with X11 and, increasingly, Wayland. While X11 has dominated the Unix window system market for decades, it has coexisted with many others over the years. Some of them were early competitors that fell by the wayside, others filled niches that X was unable to, and still others are just fun little things someone made for fun or for a school project.

This project has three aims:
* Gather information about these alternative window systems
* Bring them up under emulation, where possible
* Preserve them by porting them to modern operating systems, where practical

== Early Competitors and Predecessors ==
* ManaGeR (MGR)
* SunView
* NeWS / OpenWindows
* NeXT Display PostScript
* PERQ PNX / Sapphire
* HP Windows/9000
* CMU Andrew Window Manager
* W (the predecessor to X)
* prior versions of X (I know andrew_w has run an Ultrix version X10R4 in emulation. The sources for X10R3 are in the 4.3BSD contrib area "new.tar" and there's a QVSS driver. It might be plausible to run it in simh too!)
* mpx and mux from Research Unix 8/9
* layers
* the UNIX PC window system

=== MGR ===

[[File:MGR on VSTa 800x600.png|thumb|MGR window system, running on VSTa, demonstrating the "clock2", "walk", and "stringart" clients, as well as a MicroEMACS session]]

MGR ("ManaGeR") was a window system written for the Sun-3 line of workstations. It saw some use as a lightweight alternative to SunView and X. It's notable in that the terminal emulator is located in the display server, and that graphics are accessed with terminal escape sequences. This means that it's well-suited for running a bunch of terminal windows, but graphics are slower<ref>https://hack.org/mc/mgr/</ref>.

It's also network transparent. Clients can be run through any sort of terminal/telnet/modem line. This resembles the Blit, and apparently the Blit terminal from Bell Labs inspired MGR<ref>https://utcc.utoronto.ca/~cks/space/blog/unix/MGRMemories</ref>.

MGR saw lots of ports. At one point or another, it ran on<ref>https://web.mit.edu/linux/redhat/redhat-4.0.0/i386/doc/HTML/ldp/MGR-HOWTO-2.html</ref>:

* Linux
* Sun-4 (SPARC) (both SunOS and, later, Solaris)
* Coherent
* Macintosh
* Atari ST (MiNT)
* Xenix
* Minix
* DECstation 3100 (Ultrix)
* AT&T UNIX PC
* OS-9
* Lynx

The MGR 0.69 distribution claims to have support for SunOS 4.1.2, Linux 0.99.14, HP-UX 8.07, Coherent 4.0, and FreeBSD 2.0. The 640x480 monochrome server and the clients build easily on Red Hat Linux 4 (not RHEL 4), but trying to specify any sort of Super VGA card or resolution seems to permanently break the build. FreeBSD 2.0 requires considerable massaging of the Makefiles, includes, and defines to produce a build of the server, so it isn't recommended.

Other ways to get this running:
* Emulating the original platform (Sun-3) is <i>possible</i> with TME, but it's a hassle to get TME running.
* There's MC Widerkrantz's Solaris port<ref>https://hack.org/mc/mgr/</ref>, which QEMU might be able to run.
* andrew_w on the Discord has a disk image with a VSTa port of MGR, which runs well in 86Box.
* There appears to be X support in this Github repo<ref>https://github.com/hyc/mgr</ref>.

Finally, given how portable MGR has proven to be, it might be feasible to forward-port it to the modern Linux framebuffer.

== Niche Window Systems ==
* Xynth/XFast
* QNX Windows
* QNX Photon
* QNX screen
* RockLyte Athene
* Maryland Windows
* BSD window(1)
* the A/UX window system

=== BSD window ===

window(1) is a terminal multiplexer that offers overlapping windows on ordinary character cell terminals. It was introduced in 4.3BSD, and survived long enough to make it into the modern BSD systems for a bit. All of them have since jettisoned it in favor of tmux. Its last appearance was in NetBSD 6.1<ref>https://man.netbsd.org/NetBSD-6.1.5/window.1</ref>.

The NetBSD version of window was archived into pkgsrc <ref>https://github.com/NetBSD/pkgsrc/tree/trunk/misc/window</ref>. The terminal emulation isn't ANSI-compliant, and there's no terminfo definition on non-NetBSD platforms (at least not on macOS). Compatibility with modern fancy shell prompts and TUI software is limited; Neofetch in particular emits sludge.

TODO: a good screenshot

TODO: build/install instructions for non-NetBSD (could probably make a fork/distribution with a terminfo definition)

== Novelties ==
* Twin
* Y Window System
* Orbital

== References ==
<references />

[[Category:Preservation and Documentation]]
[[Category:Projects]]

Unix Windowing Systems

2024-02-09T15:34:54Z

Waterpear: /* MGR */ better screenshot, update on Linux experience

The phrase "windowing system for Unix" is nearly synonymous with X11 and, increasingly, Wayland. While X11 has dominated the Unix window system market for decades, it has coexisted with many others over the years. Some of them were early competitors that fell by the wayside, others filled niches that X was unable to, and still others are just fun little things someone made for fun or for a school project.

This project has three aims:
* Gather information about these alternative window systems
* Bring them up under emulation, where possible
* Preserve them by porting them to modern operating systems, where practical

== Early Competitors and Predecessors ==
* ManaGeR (MGR)
* SunView
* NeWS / OpenWindows
* NeXT Display PostScript
* PERQ PNX / Sapphire
* HP Windows/9000
* CMU Andrew Window Manager
* W (the predecessor to X)
* prior versions of X (I'm aware X10R4 has been run in emulation)
* mpx and mux from Research Unix 8/9
* layers
* the UNIX PC window system

=== MGR ===

[[File:MGR on VSTa 800x600.png|thumb|MGR window system, running on VSTa, demonstrating the "clock2", "walk", and "stringart" clients, as well as a MicroEMACS session]]

MGR ("ManaGeR") was a window system written for the Sun-3 line of workstations. It saw some use as a lightweight alternative to SunView and X. It's notable in that the terminal emulator is located in the display server, and that graphics are accessed with terminal escape sequences. This means that it's well-suited for running a bunch of terminal windows, but graphics are slower<ref>https://hack.org/mc/mgr/</ref>.

It's also network transparent. Clients can be run through any sort of terminal/telnet/modem line. This resembles the Blit, and apparently the Blit terminal from Bell Labs inspired MGR<ref>https://utcc.utoronto.ca/~cks/space/blog/unix/MGRMemories</ref>.

MGR saw lots of ports. At one point or another, it ran on<ref>https://web.mit.edu/linux/redhat/redhat-4.0.0/i386/doc/HTML/ldp/MGR-HOWTO-2.html</ref>:

* Linux
* Sun-4 (SPARC) (both SunOS and, later, Solaris)
* Coherent
* Macintosh
* Atari ST (MiNT)
* Xenix
* Minix
* DECstation 3100 (Ultrix)
* AT&T UNIX PC
* OS-9
* Lynx

The MGR 0.69 distribution claims to have support for SunOS 4.1.2, Linux 0.99.14, HP-UX 8.07, Coherent 4.0, and FreeBSD 2.0. The 640x480 monochrome server and the clients build easily on Red Hat Linux 4 (not RHEL 4), but trying to specify any sort of Super VGA card or resolution seems to permanently break the build. FreeBSD 2.0 requires considerable massaging of the Makefiles, includes, and defines to produce a build of the server, so it isn't recommended.

Other ways to get this running:
* Emulating the original platform (Sun-3) is <i>possible</i> with TME, but it's a hassle to get TME running.
* There's MC Widerkrantz's Solaris port<ref>https://hack.org/mc/mgr/</ref>, which QEMU might be able to run.
* andrew_w on the Discord has a disk image with a VSTa port of MGR, which runs well in 86Box.
* There appears to be X support in this Github repo<ref>https://github.com/hyc/mgr</ref>.

Finally, given how portable MGR has proven to be, it might be feasible to forward-port it to the modern Linux framebuffer.

== Niche Window Systems ==
* Xynth/XFast
* QNX Windows
* QNX Photon
* QNX screen
* RockLyte Athene
* Maryland Windows
* BSD window(1)
* the A/UX window system

=== BSD window ===

window(1) is a terminal multiplexer that offers overlapping windows on ordinary character cell terminals. It was introduced in 4.3BSD, and survived long enough to make it into the modern BSD systems for a bit. All of them have since jettisoned it in favor of tmux. Its last appearance was in NetBSD 6.1<ref>https://man.netbsd.org/NetBSD-6.1.5/window.1</ref>.

The NetBSD version of window was archived into pkgsrc <ref>https://github.com/NetBSD/pkgsrc/tree/trunk/misc/window</ref>. The terminal emulation isn't ANSI-compliant, and there's no terminfo definition on non-NetBSD platforms (at least not on macOS). Compatibility with modern fancy shell prompts and TUI software is limited; Neofetch in particular emits sludge.

TODO: a good screenshot

TODO: build/install instructions for non-NetBSD (could probably make a fork/distribution with a terminfo definition)

== Novelties ==
* Twin
* Y Window System
* Orbital

== References ==
<references />

[[Category:Preservation and Documentation]]
[[Category:Projects]]

File:MGR on VSTa 800x600.png

2024-02-09T15:17:57Z

Waterpear: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=MGR window system, running on VSTa, demonstrating the "clock2", "walk", and "stringart" clients, as well as a MicroEMACS session}}
|date=2024-02-09
|source={{own}}
|author=[[User:Waterpear|Waterpear]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshots]]

Unix Windowing Systems

2024-02-08T03:36:22Z

Waterpear: /* MGR */ add screenshot and mention that the FreeBSD build kinda sorta works

The phrase "windowing system for Unix" is nearly synonymous with X11 and, increasingly, Wayland. While X11 has dominated the Unix window system market for decades, it has coexisted with many others over the years. Some of them were early competitors that fell by the wayside, others filled niches that X was unable to, and still others are just fun little things someone made for fun or for a school project.

This project has three aims:
* Gather information about these alternative window systems
* Bring them up under emulation, where possible
* Preserve them by porting them to modern operating systems, where practical

== Early Competitors and Predecessors ==
* ManaGeR (MGR)
* SunView
* NeWS / OpenWindows
* NeXT Display PostScript
* PERQ PNX / Sapphire
* HP Windows/9000
* CMU Andrew Window Manager
* W (the predecessor to X)
* prior versions of X (I'm aware X10R4 has been run in emulation)
* mpx and mux from Research Unix 8/9
* layers
* the UNIX PC window system

=== MGR ===

[[File:MGR-vgamono-freebsd2.png|thumb|Screenshot of the MGR window system, showing vi and a shell session, running in 640x480 monochrome mode]]

MGR ("ManaGeR") was a window system written for the Sun-3 (68k machines). It saw some use as a lightweight alternative to SunView and X. It's notable in that the terminal emulator is located in the display server, and that graphics are accessed with terminal escape sequences. This means that it's well-suited for running a bunch of terminal windows, but not for animations or video. <ref>https://hack.org/mc/mgr/</ref>

It's also network transparent; clients can be run through any sort of terminal/telnet/modem line. This resembles the Blit, and apparently the Blit terminal from Bell Labs inspired MGR <ref>https://utcc.utoronto.ca/~cks/space/blog/unix/MGRMemories</ref>.

MGR apparently saw lots of ports<ref>https://web.mit.edu/linux/redhat/redhat-4.0.0/i386/doc/HTML/ldp/MGR-HOWTO-2.html</ref>:

* Linux
* Sun-4 (SPARC) (both SunOS and, later, Solaris)
* Coherent
* Macintosh
* Atari ST (MiNT)
* Xenix
* Minix
* DECstation 3100 (Ultrix)
* AT&T UNIX PC
* OS-9
* Lynx

The MGR 0.69 distribution claims to have support for SunOS 4.1.2, Linux 0.99.14, HP-UX 8.07, Coherent 4.0, and FreeBSD 2.0. With considerable massaging of the Makefiles, includes, and defines, the 640x480 monochrome VGA server builds and runs on FreeBSD 2.0. (The clients don't build, but MGR is useful without them.) Higher resolutions would probably be easier to attain in Linux. 800x600 is also known to work in VSTa.

Other ways to get this running:
* Emulating the original platform (Sun-3) is *possible* with TME, but that's a hassle.
* There's MC Widerkrantz's Solaris port<ref>https://hack.org/mc/mgr/</ref>, which QEMU might be able to run.
* andrew_w on the Discord has a disk image with a VSTa port of MGR, which apparently runs well in 86Box
* Someone ported MGR to run on top of X a decade ago<ref>https://github.com/hyc/mgr</ref>. Practical but boring.

Finally, given how portable MGR has proven to be, it might be feasible to forward-port it to the modern Linux framebuffer.

== Niche Window Systems ==
* Xynth/XFast
* QNX Windows
* QNX Photon
* QNX screen
* RockLyte Athene
* Maryland Windows
* BSD window(1)
* the A/UX window system

=== BSD window ===

window(1) is a terminal multiplexer that offers overlapping windows on ordinary character cell terminals. It was introduced in 4.3BSD, and survived long enough to make it into the modern BSD systems for a bit. All of them have since jettisoned it in favor of tmux. Its last appearance was in NetBSD 6.1<ref>https://man.netbsd.org/NetBSD-6.1.5/window.1</ref>.

The NetBSD version of window was archived into pkgsrc <ref>https://github.com/NetBSD/pkgsrc/tree/trunk/misc/window</ref>. The terminal emulation isn't ANSI-compliant, and there's no terminfo definition on non-NetBSD platforms (at least not on macOS). Compatibility with modern fancy shell prompts and TUI software is limited; Neofetch in particular emits sludge.

TODO: a good screenshot

TODO: build/install instructions for non-NetBSD (could probably make a fork/distribution with a terminfo definition)

== Novelties ==
* Twin
* Y Window System
* Orbital

== References ==
<references />

[[Category:Preservation and Documentation]]
[[Category:Projects]]

File:MGR-vgamono-freebsd2.png

2024-02-08T03:27:10Z

Waterpear: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Screenshot of the MGR window system, showing vi and a shell session, running in 640x480 monochrome mode}}
|date=2024-02-07
|source={{own}}
|author=[[User:Waterpear|Waterpear]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshots]]

Unix Windowing Systems

2024-02-05T16:55:05Z

Waterpear: preliminary write-up of MGR

The phrase "windowing system for Unix" is nearly synonymous with X11 and, increasingly, Wayland. While X11 has dominated the Unix window system market for decades, it has coexisted with many others over the years. Some of them were early competitors that fell by the wayside, others filled niches that X was unable to, and still others are just fun little things someone made for fun or for a school project.

This project has three aims:
* Gather information about these alternative window systems
* Bring them up under emulation, where possible
* Preserve them by porting them to modern operating systems, where practical

== Early Competitors and Predecessors ==
* ManaGeR (MGR)
* SunView
* NeWS / OpenWindows
* NeXT Display PostScript
* PERQ PNX / Sapphire
* HP Windows/9000
* CMU Andrew Window Manager
* W (the predecessor to X)
* prior versions of X (I'm aware X10R4 has been run in emulation)
* mpx and mux from Research Unix 8/9
* layers
* the UNIX PC window system

=== MGR ===

MGR ("ManaGeR") was a window system written for the Sun-3 (68k machines). It saw some use as a lightweight alternative to SunView and X. It's notable in that the terminal emulator is located in the display server, and that graphics are accessed with terminal escape sequences. This means that it's well-suited for running a bunch of terminal windows, but not for animations or video. <ref>https://hack.org/mc/mgr/</ref>

It's also network transparent; clients can be run through any sort of terminal/telnet/modem line. This resembles the Blit, and apparently the Blit terminal from Bell Labs inspired MGR <ref>https://utcc.utoronto.ca/~cks/space/blog/unix/MGRMemories</ref>.

MGR apparently saw lots of ports<ref>https://web.mit.edu/linux/redhat/redhat-4.0.0/i386/doc/HTML/ldp/MGR-HOWTO-2.html</ref>:

* Linux
* Sun-4 (SPARC) (both SunOS and, later, Solaris)
* Coherent
* Macintosh
* Atari ST (MiNT)
* Xenix
* Minix
* DECstation 3100 (Ultrix)
* AT&T UNIX PC
* OS-9
* Lynx

Ways to get this running:
* Emulating the original platform (Sun-3) is *possible* with TME, but that's a hassle.
* There's MC Widerkrantz's Solaris port<ref>https://hack.org/mc/mgr/</ref>, which QEMU might be able to run.
* andrew_w on the Discord has a disk image with a VSTa port of MGR, though it doesn't handle well in modern versions of QEMU.
* Someone ported MGR to run on top of X a decade ago<ref>https://github.com/hyc/mgr</ref>. Practical but boring.

It might also be feasible to forward-port this to the modern Linux framebuffer.

== Niche Window Systems ==
* Xynth/XFast
* QNX Windows
* QNX Photon
* QNX screen
* RockLyte Athene
* Maryland Windows
* BSD window(1)
* the A/UX window system

=== BSD window ===

window(1) is a terminal multiplexer that offers overlapping windows on ordinary character cell terminals. It was introduced in 4.3BSD, and survived long enough to make it into the modern BSD systems for a bit. All of them have since jettisoned it in favor of tmux. Its last appearance was in NetBSD 6.1<ref>https://man.netbsd.org/NetBSD-6.1.5/window.1</ref>.

The NetBSD version of window was archived into pkgsrc <ref>https://github.com/NetBSD/pkgsrc/tree/trunk/misc/window</ref>. The terminal emulation isn't ANSI-compliant, and there's no terminfo definition on non-NetBSD platforms (at least not on macOS). Compatibility with modern fancy shell prompts and TUI software is limited; Neofetch in particular emits sludge.

TODO: a good screenshot

TODO: build/install instructions for non-NetBSD (could probably make a fork/distribution with a terminfo definition)

== Novelties ==
* Twin
* Y Window System
* Orbital

== References ==
<references />

[[Category:Preservation and Documentation]]
[[Category:Projects]]

Unix Windowing Systems

2024-02-04T16:08:49Z

Waterpear: quick WIP writeup on window

Unix Windowing Systems

2024-02-04T15:47:46Z

Waterpear: create skeleton: list and categorize

NT POSIX subsystem

2024-02-04T15:21:27Z

Waterpear: The subsystem is forward compatible with XP to an extent. Also, pax.exe and BSD make are POSIX apps

[[Category:Preservation and Documentation]]
The '''NT POSIX subsystem''', officially known as '''Microsoft POSIX subsystem''', is a subsystem for Windows NT, shipped from Windows NT 3.1 to Windows 2000. It implements an early version of the POSIX standard called POSIX.1, codified as IEEE Std 1003.1-1988, ISO/IEC 9945-1:1990 and FIPS 151-2. This topic was explored in an [https://www.youtube.com/watch?v=UZ4zpfNn2dI NCommander stream], from which a video is in progress.

The standard includes process creation and control, signal handling, filesystem IO and the standard C library. The NT POSIX subsystem implements a bare minimum of what is needed for compliance. Windows NT 3.5, 3.51 and 4.0 are officially FIPS 151-2 compliant<ref>https://social.technet.microsoft.com/wiki/contents/articles/10224.posix-and-unix-support-in-windows.aspx</ref>.

The NT POSIX subsystem was removed in Windows XP, being replaced with Windows Services for Unix, a product based on Interix, Unix compatibiliy software developed by Softway Systems and later bought by Microsoft. (However, if the subsystem files from Windows 2000 are copied to an 32-bit Windows XP or Server 2003 installation, the subsystem will start, though this hasn't been fully tested beyond loading pax.exe.)

== NCommander's Investigations ==
NCommander's original investigations were done on Twitter, and are available as a PDF [[File:POSIX Subsystem Notes.pdf]]. These notes should be cleaned up and integrated here (along with photos as relevant).

== Runtime ==
The core of the POSIX subsystem is PSXSS.EXE, a Win32 binary that is one of the default NT subsystems alongside CSRSS.EXE and OS2SS.EXE. This can be seen under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Session Manager\SubSystems. NT applications won't run without the subsystem proper running.

There are two more binaries that handle communication of POSIX applications with the OS. PSXDLL.DLL is an NT POSIX dynamic library that handles calling into the POSIX subsystem, similarly to what KERNEL32.DLL, USER32.DLL etc. do for the Win32 subsystem. Finally, there is POSIX.EXE, providing integration with the standard Windows UI, that is displaying an interactive console window. This is very similar to the role of OS2.EXE in the OS/2 subsystem.

== Functionality ==
The full list of features can be found in the POSIX.1 standard. As of features unusual on Windows NT, the subsystem includes an implementation of fork, case-sensitive files and Unix permissions.

== Development ==
Windows SDK includes libcpsx.lib, psxdll.lib and psxrtl.lib, libraries used for linking binaries using the POSIX subsystem, as well as an incomplete copy of header files (e.g. stdio.h is missing). The rest of the header files are shipped with Microsoft Visual C++<ref>https://open-watcom.github.io/open-watcom-v2-wikidocs/pguide.html#NT__Creating_Windows_NT_POSIX_Applications</ref>.

Open Watcom and Microsoft Visual C++ both support building POSIX binaries. Microsoft also ships a buggy cc wrapper, allowing to call Visual C++ from a POSIX environment, however it was shown on the NCommander stream that its practical usability is very limited.

== Applications ==
The Windows NT base installation includes pax.exe. This is an implementation of the official POSIX archive utility<ref>https://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html</ref>, able to handle both tar and cpio files. pax.exe is the sole POSIX application included with Windows.

Windows NT 4.0 Resource Kit ships with a few applications for the POSIX subsystem. These are cat, chmod, chown, cp, find, grep, ln, ls, mkdir, mv, rm, rmdir, sh, touch, vi, and wc.

The Windows NT SDK includes source code for most of those, plus source-only releases for a few other tools. Most notably, these include the aforementioned cc wrapper, as well as a port of BSD make.

==References==
<references />

OS/2 Versions And History

2023-01-10T16:52:23Z

Waterpear: /* Installation */ confirm 86Box compatibility, mention how to fix "bad or missing command interpreter"

[[Category:OS/2]]
This is a list, chronologically sorted, of OS/2 versions, related products, and historic dates.

== IBM PC DOS 3.1 (1984) ==

== Multitasking DOS 4 ==
[[File:DOS 4.0 multitasking demo.png|thumb|DOS 4.0 running several processes.]]

Officially called just MS-DOS 4.00, Multitasking DOS 4 was the intended successor of DOS 2.x and later 3.x, initially developed between January 1983<ref>http://www.os2museum.com/wp/multitasking-ms-dos-4-0-lives/</ref> and November 1985. It has many features later appearing in both OS/2 and Windows, including:

* the [[New Executable]] format
* an OS/2-style per-task data area (PTDA) replacing the MS-DOS program segment prefix (PSP)
* system calls using dynamically linked functions in a built-in module named DOSCALLS
* the concept of processes along with related system calls
* the use of a higher-level language (C) for writing parts of the operating system.

However, unlike any version of OS/2 released to the public (TODO: check for 1986 ADOS 5.0), both earlier MS-DOS COM and MZ executables and MS-DOS interrupts are supported on Multitasking DOS 4, and there are even improvements to these APIs (some of which break compatibility with older DOS versions). New apps use both the legacy (<code>int 21h</code>) and new dynamically linked APIs, perhaps suggesting the old API was deprecated or in the process of being replaced.

It was originally called DOS 3.0, which is referenced by older binaries checking for DOS 3.0 to 4.0; later the release number was pushed to 4.0 with the release of 3.0.

This version of DOS supports pre-emptive multitasking, but its usability is limited by the 640kB memory limit, with no swapping because of lack of necessary hardware support. For this reason, it was only released to certain OEMs, opting to wait with the public release for its protected mode successor<ref>https://virtuallyfun.com/2013/03/17/european-ms-dos-4-00-aka-multitasking-dos/</ref>.

=== Preserved Copies ===

There are two versions of Multitasking DOS 4 that were preserved. The first one is a two-floppy set, originally uploaded to the now defunct JSMachines.net website. It does not contain any branding and its kernel (IBMDOS.COM) identifies itself as internal revision 6.7, 85/11/26, which is consistent with the creation date of the files. The internal revision identification is cut off with an end of string sign, possibly indicating it was manually edited after the build; together with the fact IBM branding is used, it hints that this is actually a pre-release version. Floppy 1 contains the operating system and a few basic utilities, including FDISK and FORMAT; floppy 2 contains additional utilities, commands, a copy of the 8086 New Executable linker (LINK4.EXE), a PIF editor (PIFEDIT.EXE), and EDLIN.

The second version is an OEM release by SMT Goupil, a French company, for their Goupil G4 computer, featuring an 80186 clocked at 8 MHz. It was originally a two-floppy set, but the only preserved version is a single 720kB floppy. Based on timestamps, it was built on 15 May 1986, and possibly assembled into a single floppy on 20 March 1997. The kernel is renamed to MSDOS.SYS and IO.SYS, like it is common on MS-DOS (strings inside IO.SYS reveal the source was still named IBMBIO.ASM), and the internal revision string is not present. In addition to what is the first version, it contains a Unix-like PS.EXE utility, revealing some internals about the OS, a kernel debugger (DEBUGDD.SYS), a networking driver (NET.SYS), and DOSSIZE.EXE, an utility printing used and available memory. Strangely, the session manager (SM.EXE) is missing<ref>http://www.os2museum.com/wp/multitasking-ms-dos-4-0-goupil-oem/</ref>.

=== Installation ===

For the media, WinWorld has [https://winworldpc.com/product/multitasking-ms-dos-/400 a copy of the Microsoft version], and OS/2 museum has [http://www.os2museum.com/files/msdos4m-goupil.zip a copy of the Goupil version]. VirtualBox is confirmed to be compatible with Multitasking DOS 4. 86Box is also compatible, though 3½ inch floppy drives do not seem to work (this means you have to use the Microsoft release). For best results, try the Phoenix AT clone (under 80286 CPU).

To get Multitasking DOS 4 up and running, create a VM with a floppy drive and an IDE hard drive no larger than 32 MB. Boot from floppy 1, run FDISK and do the usual procedure of partitioning the hard drive. After reboot, run FORMAT C: /S to format the hard drive and install DOS, then you can reboot into the base system. (If you get the "bad or missing command interpreter" trying to boot from hard drive at this point, then boot from the first floppy and run these steps from there.)

There is no installation program, hence to complete the installation process, the files from the floppy have to be manually copied to the hard drive:

<pre>
C:
COPY A:*.*
MD BIN
CD BIN
COPY A:\BIN\*.*
</pre>

If installing the Goupil version, the file copying is over now. If installing the Microsoft version, swap to the second floppy, stay in the BIN directory, and run again:

<pre>
COPY A:*.*
</pre>

Before rebooting, AUTOEXEC.BAT and CONFIG.SYS have to be modified to point to the hard drive instead of the floppy. Failure to do this will result in a "bad or missing command interpreter" error on boot. EDLIN.EXE is shipped with the system and can be used to do the necessary changes:

<pre>
EDLIN C:\AUTOEXEC.BAT
*5
5:*PATH C:\BIN
*E
EDLIN C:\CONFIG.SYS
*3
3:*C:\BIN\SM.EXE C:\COMMAND.COM
*E
</pre>

Then you can remove your boot floppy and reboot into the full Multitasking DOS 4.0 system, now running from a hard drive:

<pre>
Command v. 4.00
Copyright (C) 1981,1985 Microsoft Corp.

[4.0 C:\]
</pre>

=== Tips and Tricks ===

The Alt key starts the Session Manager menu, from which you can create a new session and switch between existing sessions. Each session has a memory limit that can be viewed by the MEMSET command (default is 128kB). Keep in mind that legacy DOS applications (i.e. non-New Executable ones) take the entire space up to the limit, so you probably don't want to set it to maximum. For legacy applications switching between several programs, like Microsoft C 4.0's CL.EXE (calling C1.EXE), the right amount has to be fine-tuned in order to allow both binaries to run (in the case of MSC 4.0, 200kB works, 128kB is too little for C1.EXE to load, 640kB causes CL.EXE to take all the space, leaving none to C1.EXE).

If you installed the Microsoft version, it is recommended to install DOSSIZE.EXE and PS.EXE tools from the Goupil version; if you installed the Goupil version and want the Session Manager (for switching between processes), you have to copy SM.EXE over from the Microsoft version.

=== Development ===
[[File:MDOS4 Native Hello world build.png|thumb|Native New Executable Hello world application built using MASM and LINK4 on Multitasking DOS 4.0]]

No toolchain directly targeting Multitasking DOS 4 was preserved, however, the aforementioned distributions contain an [[New Executable]] linker (LINK4.EXE), which can be used together with a suitable assembler or compiler to create NE binaries that will run on Multitasking DOS 4.

MASM 4.0 can be used to assemble a simple program on Multitasking DOS 4. In order to be successfully linked with LINK4.EXE, the program must contain a DGROUP declaration, which is also called Automatic Data Segment in the NE specification. Here's an example implementation of Hello world:
<pre>
data segment public 'DATA'
assume ds:data
hello db "Hello world$"
db 512 dup(0)
data ends

dgroup group DATA

code segment public 'CODE'
assume cs:code
start:
mov ax, DATA
mov ds, ax
mov dx, offset HELLO
mov ah, 09h
int 21h
mov ah, 4ch
int 21h
code ends
end start

stack segment public 'STACK'
stack ends
</pre>
Note the 512 zeroes in the data section, without these, the program doesn't work for some currently unknown reasons. This quirk is not shared by Windows 1.0, which runs the Hello world program fine without the zeroes.

An effort to get Microsoft C working is happening on DisNCord. There are two challenges: the lack of a C runtime for Multitasking DOS 4, and Microsoft C compilers being prone to running out of memory on Multitasking DOS 4.

== OS/2 Pre-Betas ==

''These need to be sorted by date''
== IBM OS/2 1.0 ==

== MS OS/2 1.0 ==

== IBM OS/2 1.1 ==

== MSOS/2 1.2 ==

== References ==

OS/2 Research Outline

2023-01-10T16:31:19Z

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

This is a set of wiki pages dedicated to researching the rise and fall of OS/2, with the intent on creating a larger record of the 16-bit and early 32-bit era of IBM's ill fated operating system, with stream ideas, research notes, discussion and more.

This is an effort to fundamental answer is to document the reasons as to why despite IBM's best efforts, OS/2 failed in the marketplace in favor of Windows 3.0, an operating system that is technically inferior in almost all regards.

== Goals Of This Project ==
The fundamental goal of this project is to create a pretty definitive guide to the early history of OS/2, including showing how it worked, functioned, and more as a primary source, and should interest remain, the creation of multiple realtime videos and/or documentaries to document one of the more pivotal moments of the late 1980s, and early 1990s.

This wiki page should use citations for all major facts and statements, as they will be cited in any video. It's expected that each top level section will become its own "realtime video" at some point.

== Overview of the 16-bit Era of OS/2 ==
Because the level of general knowledge of OS/2 is so low, a basic understanding has to be established about the 16-bit era needs to be established. The closest thing to a canonical document on this era exists at the [https://www.os2museum.com/wp/ OS/2 Museum], but setting up usable and working systems with native apps is essential ...

=== Understanding The Pricing Of Equipment for OS/2 ===
OS/2 runs decently on maxed out equipment, but that's easily going into five figures or more. We need to figure out what was acceptable for a developer system in this era ...

'''It should be important to research what hardware each version of OS/2 may have run on. For example, CGA cards on the AT were pretty common. Understand how OS/2 behaved on low end hardware vs. Windows of the era.'''

Another important note is that OS/2 was created as a replacement to Microsoft's Xenix (a licensed port of AT&T). The chronology here should be determined to understand more factors of the OS/2 mess.

Things to research:
* OS/2-Xenix chronology
* Typical low, medium, and high end PC hardware of the era
* What, besides DOS, was actively used in this time period

=== 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]]
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?

It's known that Microsoft offered a $3,000 SDK and training materials which had basically everything you could want and more in a single box<ref>https://www.os2museum.com/wp/os2-history/os2-beginnings/</ref>, but IBM based material is somewhat scant ...

Topics to be researched:
* Descriptions of OS/2 (or ADOS) as found in early programming reference manuals
* Comparison of early alpha versions of OS/2
* Relationship of early OS/2 to European DOS 4.0
* In-depth reading and review of the manual and more

Questions to be answered:
* What were the stated goals of OS/2?
* What was actually provided out of the box in 1.0?
* IBM marked OS/2 as a server - understanding the relationship here is important

=== OS/2 Editions ===
[[File:IBM OS2 1.00 - Install.png|thumb|OS/2 1.0 Splash Description Page]]
[[File:Microsoft OS2 Splash Screen.png|thumb|Microsoft OS/2 Splash Screen Startup]]

In general, OS/2 was first created for IBM hardware, and then by Microsoft, resold for other PC compatible vendors. OS/2 was also available directly from Microsoft as an upgrade. There are known code and behavior differences between the two editions, as well as significant differences in documentation. However, all editions of OS/2 should be able to run the same binaries.

In general, IBM branded versions only ran properly on IBM machines or extremely compatible clones, while Microsoft versions were, for the most part, more forgiving.

==== IBM Edition ====
IBM editions are generally considered the "canonical" branch of OS/2, as they were developed for and used on IBM's PS/2 line of machines, which were generally the highest end machines with microchannel architecture support. If you were going to shell out the money for a MCA system in the late 1980s, you almost certainly were running either OS/2 or Xenix.

The question is, what did OS/2 specifically bring to the table for power users of this session. The canonical answer would be "Presentation Manager", but is PM actually that good?

==== Microsoft Edition ====
Similar to DOS of the era, Microsoft sub-licensed OS/2 to any OEM who wanted it, creating things like "Nokia OS/2" and "Intel OS/2". There are some code changes, possibly for compatibility reasons. It's likely that OS/2 was at least available for licensing for non-IBM compatible PCs, and may have had an actual OEM adoption kit, similar to the Windows 2/3 OAKs. While unlikely to ever turn up, a good look at the differences between editions is warrented. IBM OS/2 for instances uses the undocumented but highly commonly used 286 LOADALL instruction.<ref>https://www.os2museum.com/wp/more-on-loadall-and-os2/</ref>

==== IBM Extended Edition ====
Although not sold to end-users, IBM also offered an special version of OS/2 to its partners and vendors, which included applications for use in big business, and more importantly, talking to expensive IBM hardware of the era. This had three essential components<ref>https://www.os2museum.com/wp/os2-history/os2-16-bit-server/</ref>

* Communications Manager - allows interfacing to various IBM mainframes
* Database Manager - A SQL database that was later ported to UNIX as a non-mainframe version of DB/2
* LAN Requester - Client for accessing LAN Server/Manager and NetBIOS shares on the network. May not have been in OS/2 1.0 (need to check)

IBM OS/2 1.2 Extended Edition was also the first version to include REXX, before it became a part of every release starting with OS/2 1.3 (for both IBM and Microsoft)<ref>https://www.rexxla.info/links/IBM_historical_pages/rexxos2.html</ref>.

==== LAN Manager ====
OS/2 was also a very popular server platform, completing with Novell NetWare, and UNIX systems of the era, and was in use well into the NT era. Microsoft sold their LAN Manager package as an add-on instead as a dedicated edition. Included were the following components:

* OS/2 LAN Manager Server
* OS/2 LAN Manager Workstation (or Requester in IBM parlance)
* DOS LAN Manager client software
* HPFS386 filesystem for OS/2
* Novell NetWare interoperability tools
* DOS and OS/2 Drivers for a number of NICs

It's unclear how much DNA is shared between IBM products and Microsoft ones.

=== OS/2 as a Server ===
One of the biggest roles of OS/2 in the 90s was its use as an application server, both for handling file and printer sharing, and was essentially the upsale from IBM PC LAN products of this time period. OS/2 was likely more suited as an application server than NetWare at the time, due to NetWare being monolithically linked, and only having "value addon packages", vs. the NLMs that came with NetWare 2.x.

Was the PC network of this era essentially just NetBIOS shares, or were there more functional aspects to it like using databases and more, and how did this interact with software of the era ...

== Understanding the OS/2 Development Environment ==
=== Hello World and Example Applications on OS/2 1.0-1.3 ===
The simplest application for a given platform is "Hello World", something I've documented extensively on both Windows, UNIX, and Linux in the past. OS/2's Hello World program has evolved as IBM replaced the toolchain (and tools) several time throughout the lifespan of the platform. Originally, IBM used Microsoft licensed tools, before replacing it with versions of CSet++ and Visual Age.

It's worth looking at the built in example applications from the varoius SDKs over the years to understand the full evolution of OS/2 from start to finish, especially in the era between IBM and Microsoft, as well as 3rd party toolkits that were commonly used such as Watcom.

=== Executable Format ===
16-bit OS/2 code uses [[New Executable]] (with e_lfanew value NE), a format shared with 16-bit Windows and multitasking MS-DOS. Note that OS/2 is numbered 1 in the OS field of the NE format (0 is unknown), suggesting the format was originally developed for OS/2, despite it being introduced with Windows 1.0 in 1985, two years before the first release of OS/2.

32-bit OS/2 code uses a new format called [[Linear Executable]]. Again, for maximum confusion, there are two incompatible versions of this format. The first one, with e_lfanew value LE, is used in pre-release versions of OS/2 2.0 (TODO: in which?), as well as in 386 version of Windows for native drivers. In OS/2 2.0 RTM, LE support was dropped, and the second version (with e_lfanew value LX) was introduced. This continued to be the format for 32-bit OS/2 executables up to Warp 4.52.

NE, LE, and LX executables all support dynamic linking, and all start with an MZ DOS stub that can run on DOS. A DOS version of the application can be put into the stub, most commonly, it just displays a message saying the program requires OS/2.

=== Comparison to DOS and Creating Family Mode applications ===
OS/2, especially in its earlier forms of ADOS or CP/DOS, was intended as a successor of DOS. Migration facilities like the DOS window were intended to make it possible to migrate over time to OS/2, and there's support for what are known as "Family Mode" applications, which are OS/2 binaries that use a subset of system calls (documented in the IBM OS/2 Technical Reference), and can also be run on a DOS system.

This is different than the DOS stub in NE and PE headers (https://en.wikipedia.org/wiki/New_Executable). In the case of a family mode binary, the binary ran the same on both platforms, with a specialized stub being provided that implemented the OS/2 functions on DOS. When a family mode binary was executed under DOS, the stub linked the NE executable against its own DOS implementation of the Family Mode API and ran it. Because of this, startup of family mode binaries under DOS is slower than for native DOS binaries.

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 FORCEDOS command is used.

=== GDI vs GPI (and other API differences) ===
One of the largest differences between OS/2 and Windows is that the graphics API was entirely replaced. Presentation Manager (OS/2's GUI), was at least in part based on Windows 2.x, and shared many similar features. However, one important difference deals with the graphics API. Windows uses the "Graphic Device Interface" or GDI which is a device independent way of displaying graphics. It originally dates to Windows 1.0, and is still present in Windows 11. OS/2, among other things, replaced with GPI, or "Graphics Precision Interface", and moved the location of 0,0 to the upper left most corner.

There are other differences in OS/2 applications, such as how functions and other parameters that it might be beneficial to go through and at least document at least some of the differences, and try and understand why they may exist.

=== Windows Libraries for OS/2 ===
''This section had a full wiki page [[Windows Libraries for OS/2]] for more information''

[[User:Dr. Shuppet|Dr. Shuppet]] has done an amazing job at writing up the history and backstory of [[Windows Libraries for OS/2|WLO]], which is a port of Windows libraries running under Presentation Manager. WLO was several compatibility solutions, such as Micrograx Mirrors. Microsoft shipped ports of the Windows 3.0 accessories as a WLO demo, and several OS/2 native binaries, such as Word and Excel for Windows use WLO or similar technologies to bridge the gap between Presentation Manager and the Win16 API.

WLO was obviously intended as a transition technology when Windows started gaining momentium in the 2.x and 3.x days, but before the IBM-Microsoft divorce was finalized, and should be categorizes in the great timeline of events.

=== 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).

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 ...

=== Limits of Preemptive Multitasking ===
OS/2 is a natively preemptively multitasking system; it shouldn't be possible for a single application to hang the system. However, this isn't true in practice. For what were presumably performance reasons, OS/2 Presentation Manager applications share what is known as the Single Input Queue (also written as Single Event Queue), which is a message pump shared between all applications, and is inherited from Win16 programming.

The fundamental end result of the SIQ means that one crashed Presentation Manager application can hang the entire UI with startling ease. A partial fix for this, the async SIQ wasn't released until OS/2 Warp 4, which was near the end of OS/2's commercial life span. While it is possible to disable Presentation Manager through editing CONFIG.SYS, or even use the OS/2 1.0 TSHELL.EXE, this doesn't appear to have ever been officially supported by IBM.

In theory, OS/2 should be fully capable of process and thread based multitasking similar to Windows NT, but documenting the full limitations is important. It's also worth checking (with a kernel/ICE debugger if necessary) if the the 286's task segment selector (TSS) is used in this process at all ...

== Capabilities and Limitations of OS/2 ==
There's a lot that's been written that tries to determine why OS/2 failed on a technical level, but it's difficult to determine if this was justified in fact or fiction. Some parts of this are people who are familiar with other operating systems, combined with relatively sparse documentation may cause people to have a lot of mistaken assumptions. Some of the major points to be researched and discussed follows.

=== How Hamstrung was OS/2 By the 286 ===
One of the largest repeated beliefs is that OS/2 was hamstrung by the design of the 286. There's certainly reason to believe this, since NT was intended as "Portable OS/2", and the system remained a mismatch of 16-bit and 32-bit code to it's end. However the 386 was fully supported with MVDM by 1992, when OS/2 2.0 first shipped. In practice, the 16-bit versions of OS/2 seem very similar in capability to the 16-bit versions of Windows, and are arguably closer to Windows 9x than they are DOS.

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.

=== HPFS ===
HPFS was intended as a replacement for the aging FAT (file allocation table) filesystem. Standing for High Performance File System, HPFS brought support for long filenames, and extended attributes to OS/2 1.2, and is required for many OS/2 applications to function properly. HPFS was also supported on NT 3.1 and 3.5, and later versions through the PINBALL driver. From what I know, NTFS is essentially an extension of HPFS, with similar data structures and more, but this should be looked more into by comparing the NTFS and HPFS drivers in the Linux kernel.

=== 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>.

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
* Multiplan
* 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 ===
Although mostly unknown by home users, both DOS and OS/2 supported network operations, leading to the term network redirector. From reading in the Windows NT Resource Kit, and other places, communication between applications happened in the form of named pipes, and IPC process namespaces. Its worth looking more in-depth how NetBIOS related networking works, as possibly part of a larger series on the value of the network. In many ways, OS/2 pioneered much of what would be the NT network stack, including being the home of domains and more.

Furthermore, NetWare Client for OS/2 1.1<ref>https://www.os2museum.com/wp/1989-networking-os-2-netware-requester-1-1/</ref> has recently turned up, and a beta of NetWare for OS/2 1.0<ref>https://www.os2museum.com/wp/1988-networking-netware-os-2-requester/</ref> has also recently shown up, so it might be worth taking these systems out for a spin.

=== DOS/Windows Compatibility ===
One of the largest criticisms was horrid backwards compatibility with DOS and Windows. The 16-bit versions of OS/2 could only run one DOS application at a time in what commonly became known as the penalty box, which was a DOS session that was constantly running. This is due to how the 80286 didn't provide any support for virtualizing real mode applications, and delays involving OS/2 2.x meant that 386 support didn't ship until 1991-92, well past Windows/386 and Windows 3.0.

There's a known prototype of OS/2 1.0 for the 386 called FOOTBALL which is archived on [http://pcjs.org pcjs.org] which does have multiple DOS applications, running through virtual 8088 mode. The notes included show that it was an internal demo meant to be shown to Bill Gates. There were relatively few native applications for OS/2, especially as compared to Windows, so compatibility was definitively something to be mindful of, as stores would have no or limited stock of OS/2 applications.

== Later OS/2 Era Stuff Worth Researching ==
This is just a list of notes of things that should be researched as time permits, but is somewhat out of scope for the things planned.

* OS/2 on PowerPC
* Embedded OS/2 such as on the New York City Subway
* eCommStation and AcraOS
* IBM's use of OS/2 as the system controller for its mainframes well into the 2000s.
* The creation of VirtualBox due to the difficulty of running OS/2 inside of other emulation/virtualization software.

Anyone should feel free to contribute to this (or any other page) relating to OS/2 history.

== References ==

OS/2 Research Outline

2023-01-10T16:26:27Z

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

This is a set of wiki pages dedicated to researching the rise and fall of OS/2, with the intent on creating a larger record of the 16-bit and early 32-bit era of IBM's ill fated operating system, with stream ideas, research notes, discussion and more.

This is an effort to fundamental answer is to document the reasons as to why despite IBM's best efforts, OS/2 failed in the marketplace in favor of Windows 3.0, an operating system that is technically inferior in almost all regards.

== Goals Of This Project ==
The fundamental goal of this project is to create a pretty definitive guide to the early history of OS/2, including showing how it worked, functioned, and more as a primary source, and should interest remain, the creation of multiple realtime videos and/or documentaries to document one of the more pivotal moments of the late 1980s, and early 1990s.

This wiki page should use citations for all major facts and statements, as they will be cited in any video. It's expected that each top level section will become its own "realtime video" at some point.

== Overview of the 16-bit Era of OS/2 ==
Because the level of general knowledge of OS/2 is so low, a basic understanding has to be established about the 16-bit era needs to be established. The closest thing to a canonical document on this era exists at the [https://www.os2museum.com/wp/ OS/2 Museum], but setting up usable and working systems with native apps is essential ...

=== Understanding The Pricing Of Equipment for OS/2 ===
OS/2 runs decently on maxed out equipment, but that's easily going into five figures or more. We need to figure out what was acceptable for a developer system in this era ...

'''It should be important to research what hardware each version of OS/2 may have run on. For example, CGA cards on the AT were pretty common. Understand how OS/2 behaved on low end hardware vs. Windows of the era.'''

Another important note is that OS/2 was created as a replacement to Microsoft's Xenix (a licensed port of AT&T). The chronology here should be determined to understand more factors of the OS/2 mess.

Things to research:
* OS/2-Xenix chronology
* Typical low, medium, and high end PC hardware of the era
* What, besides DOS, was actively used in this time period

=== 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]]
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?

It's known that Microsoft offered a $3,000 SDK and training materials which had basically everything you could want and more in a single box<ref>https://www.os2museum.com/wp/os2-history/os2-beginnings/</ref>, but IBM based material is somewhat scant ...

Topics to be researched:
* Descriptions of OS/2 (or ADOS) as found in early programming reference manuals
* Comparison of early alpha versions of OS/2
* Relationship of early OS/2 to European DOS 4.0
* In-depth reading and review of the manual and more

Questions to be answered:
* What were the stated goals of OS/2?
* What was actually provided out of the box in 1.0?
* IBM marked OS/2 as a server - understanding the relationship here is important

=== OS/2 Editions ===
[[File:IBM OS2 1.00 - Install.png|thumb|OS/2 1.0 Splash Description Page]]
[[File:Microsoft OS2 Splash Screen.png|thumb|Microsoft OS/2 Splash Screen Startup]]

In general, OS/2 was first created for IBM hardware, and then by Microsoft, resold for other PC compatible vendors. OS/2 was also available directly from Microsoft as an upgrade. There are known code and behavior differences between the two editions, as well as significant differences in documentation. However, all editions of OS/2 should be able to run the same binaries.

In general, IBM branded versions only ran properly on IBM machines or extremely compatible clones, while Microsoft versions were, for the most part, more forgiving.

==== IBM Edition ====
IBM editions are generally considered the "canonical" branch of OS/2, as they were developed for and used on IBM's PS/2 line of machines, which were generally the highest end machines with microchannel architecture support. If you were going to shell out the money for a MCA system in the late 1980s, you almost certainly were running either OS/2 or Xenix.

The question is, what did OS/2 specifically bring to the table for power users of this session. The canonical answer would be "Presentation Manager", but is PM actually that good?

==== Microsoft Edition ====
Similar to DOS of the era, Microsoft sub-licensed OS/2 to any OEM who wanted it, creating things like "Nokia OS/2" and "Intel OS/2". There are some code changes, possibly for compatibility reasons. It's likely that OS/2 was at least available for licensing for non-IBM compatible PCs, and may have had an actual OEM adoption kit, similar to the Windows 2/3 OAKs. While unlikely to ever turn up, a good look at the differences between editions is warrented. IBM OS/2 for instances uses the undocumented but highly commonly used 286 LOADALL instruction.<ref>https://www.os2museum.com/wp/more-on-loadall-and-os2/</ref>

==== IBM Extended Edition ====
Although not sold to end-users, IBM also offered an special version of OS/2 to its partners and vendors, which included applications for use in big business, and more importantly, talking to expensive IBM hardware of the era. This had three essential components<ref>https://www.os2museum.com/wp/os2-history/os2-16-bit-server/</ref>

* Communications Manager - allows interfacing to various IBM mainframes
* Database Manager - A SQL database that was later ported to UNIX as a non-mainframe version of DB/2
* LAN Requester - Client for accessing LAN Server/Manager and NetBIOS shares on the network. May not have been in OS/2 1.0 (need to check)

IBM OS/2 1.2 Extended Edition was also the first version to include REXX, before it became a part of every release starting with OS/2 1.3 (for both IBM and Microsoft)<ref>https://www.rexxla.info/links/IBM_historical_pages/rexxos2.html</ref>.

==== LAN Manager ====
OS/2 was also a very popular server platform, completing with Novell NetWare, and UNIX systems of the era, and was in use well into the NT era. Microsoft sold their LAN Manager package as an add-on instead as a dedicated edition. Included were the following components:

* OS/2 LAN Manager Server
* OS/2 LAN Manager Workstation (or Requester in IBM parlance)
* DOS LAN Manager client software
* HPFS386 filesystem for OS/2
* Novell NetWare interoperability tools
* DOS and OS/2 Drivers for a number of NICs

It's unclear how much DNA is shared between IBM products and Microsoft ones.

=== OS/2 as a Server ===
One of the biggest roles of OS/2 in the 90s was its use as an application server, both for handling file and printer sharing, and was essentially the upsale from IBM PC LAN products of this time period. OS/2 was likely more suited as an application server than NetWare at the time, due to NetWare being monolithically linked, and only having "value addon packages", vs. the NLMs that came with NetWare 2.x.

Was the PC network of this era essentially just NetBIOS shares, or were there more functional aspects to it like using databases and more, and how did this interact with software of the era ...

== Understanding the OS/2 Development Environment ==
=== Hello World and Example Applications on OS/2 1.0-1.3 ===
The simplest application for a given platform is "Hello World", something I've documented extensively on both Windows, UNIX, and Linux in the past. OS/2's Hello World program has evolved as IBM replaced the toolchain (and tools) several time throughout the lifespan of the platform. Originally, IBM used Microsoft licensed tools, before replacing it with versions of CSet++ and Visual Age.

It's worth looking at the built in example applications from the varoius SDKs over the years to understand the full evolution of OS/2 from start to finish, especially in the era between IBM and Microsoft, as well as 3rd party toolkits that were commonly used such as Watcom.

=== Executable Format ===
16-bit OS/2 code uses [[New Executable]] (with e_lfanew value NE), a format shared with 16-bit Windows and multitasking MS-DOS. Note that OS/2 is numbered 1 in the OS field of the NE format (0 is unknown), suggesting the format was originally developed for OS/2, despite it being introduced with Windows 1.0 in 1985, two years before the first release of OS/2.

32-bit OS/2 code uses a new format called [[Linear Executable]]. Again, for maximum confusion, there are two incompatible versions of this format. The first one, with e_lfanew value LE, is used in pre-release versions of OS/2 2.0 (TODO: in which?), as well as in 386 version of Windows for native drivers. In OS/2 2.0 RTM, LE support was dropped, and the second version (with e_lfanew value LX) was introduced. This continued to be the format for 32-bit OS/2 executables up to Warp 4.52.

NE, LE, and LX executables all support dynamic linking, and all start with an MZ DOS stub that can run on DOS. A DOS version of the application can be put into the stub, most commonly, it just displays a message saying the program requires OS/2.

=== Comparison to DOS and Creating Family Mode applications ===
OS/2, especially in its earlier forms of ADOS or CP/DOS, was intended as a successor of DOS. Migration facilities like the DOS window were intended to make it possible to migrate over time to OS/2, and there's support for what are known as "Family Mode" applications, which are OS/2 binaries that use a subset of system calls (documented in the IBM OS/2 Technical Reference), and can also be run on a DOS system.

This is different than the DOS stub in NE and PE headers (https://en.wikipedia.org/wiki/New_Executable). In the case of a family mode binary, the binary ran the same on both platforms, with a specialized stub being provided that implemented the OS/2 functions on DOS. When a family mode binary was executed under DOS, the stub linked the NE executable against its own DOS implementation of the Family Mode API and ran it. Because of this, startup of family mode binaries under DOS is slower than for native DOS binaries.

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 FORCEDOS command is used.

=== GDI vs GPI (and other API differences) ===
One of the largest differences between OS/2 and Windows is that the graphics API was entirely replaced. Presentation Manager (OS/2's GUI), was at least in part based on Windows 2.x, and shared many similar features. However, one important difference deals with the graphics API. Windows uses the "Graphic Device Interface" or GDI which is a device independent way of displaying graphics. It originally dates to Windows 1.0, and is still present in Windows 11. OS/2, among other things, replaced with GPI, or "Graphics Precision Interface", and moved the location of 0,0 to the upper left most corner.

There are other differences in OS/2 applications, such as how functions and other parameters that it might be beneficial to go through and at least document at least some of the differences, and try and understand why they may exist.

=== Windows Libraries for OS/2 ===
''This section had a full wiki page [[Windows Libraries for OS/2]] for more information''

[[User:Dr. Shuppet|Dr. Shuppet]] has done an amazing job at writing up the history and backstory of [[Windows Libraries for OS/2|WLO]], which is a port of Windows libraries running under Presentation Manager. WLO was several compatibility solutions, such as Micrograx Mirrors. Microsoft shipped ports of the Windows 3.0 accessories as a WLO demo, and several OS/2 native binaries, such as Word and Excel for Windows use WLO or similar technologies to bridge the gap between Presentation Manager and the Win16 API.

WLO was obviously intended as a transition technology when Windows started gaining momentium in the 2.x and 3.x days, but before the IBM-Microsoft divorce was finalized, and should be categorizes in the great timeline of events.

=== 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).

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 ...

=== Limits of Preemptive Multitasking ===
OS/2 is a natively preemptively multitasking system; it shouldn't be possible for a single application to hang the system. However, this isn't true in practice. For what were presumably performance reasons, OS/2 Presentation Manager applications share what is known as the Single Input Queue (also written as Single Event Queue), which is a message pump shared between all applications, and is inherited from Win16 programming.

The fundamental end result of the SIQ means that one crashed Presentation Manager application can hang the entire UI with startling ease. A partial fix for this, the async SIQ wasn't released until OS/2 Warp 4, which was near the end of OS/2's commercial life span. While it is possible to disable Presentation Manager through editing CONFIG.SYS, or even use the OS/2 1.0 TSHELL.EXE, this doesn't appear to have ever been officially supported by IBM.

In theory, OS/2 should be fully capable of process and thread based multitasking similar to Windows NT, but documenting the full limitations is important. It's also worth checking (with a kernel/ICE debugger if necessary) if the the 286's task segment selector (TSS) is used in this process at all ...

== Capabilities and Limitations of OS/2 ==
There's a lot that's been written that tries to determine why OS/2 failed on a technical level, but it's difficult to determine if this was justified in fact or fiction. Some parts of this are people who are familiar with other operating systems, combined with relatively sparse documentation may cause people to have a lot of mistaken assumptions. Some of the major points to be researched and discussed follows.

=== How Hamstrung was OS/2 By the 286 ===
One of the largest repeated beliefs is that OS/2 was hamstrung by the design of the 286. There's certainly reason to believe this, since NT was intended as "Portable OS/2", and the system remained a mismatch of 16-bit and 32-bit code to it's end. However the 386 was fully supported with MVDM by 1992, when OS/2 2.0 first shipped. In practice, the 16-bit versions of OS/2 seem very similar in capability to the 16-bit versions of Windows, and are arguably closer to Windows 9x than they are DOS.

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.

=== HPFS ===
HPFS was intended as a replacement for the aging FAT (file allocation table) filesystem. Standing for High Performance File System, HPFS brought support for long filenames, and extended attributes to OS/2 1.2, and is required for many OS/2 applications to function properly. HPFS was also supported on NT 3.1 and 3.5, and later versions through the PINBALL driver. From what I know, NTFS is essentially an extension of HPFS, with similar data structures and more, but this should be looked more into by comparing the NTFS and HPFS drivers in the Linux kernel.

=== 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>.

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 ===
Although mostly unknown by home users, both DOS and OS/2 supported network operations, leading to the term network redirector. From reading in the Windows NT Resource Kit, and other places, communication between applications happened in the form of named pipes, and IPC process namespaces. Its worth looking more in-depth how NetBIOS related networking works, as possibly part of a larger series on the value of the network. In many ways, OS/2 pioneered much of what would be the NT network stack, including being the home of domains and more.

Furthermore, NetWare Client for OS/2 1.1<ref>https://www.os2museum.com/wp/1989-networking-os-2-netware-requester-1-1/</ref> has recently turned up, and a beta of NetWare for OS/2 1.0<ref>https://www.os2museum.com/wp/1988-networking-netware-os-2-requester/</ref> has also recently shown up, so it might be worth taking these systems out for a spin.

=== DOS/Windows Compatibility ===
One of the largest criticisms was horrid backwards compatibility with DOS and Windows. The 16-bit versions of OS/2 could only run one DOS application at a time in what commonly became known as the penalty box, which was a DOS session that was constantly running. This is due to how the 80286 didn't provide any support for virtualizing real mode applications, and delays involving OS/2 2.x meant that 386 support didn't ship until 1991-92, well past Windows/386 and Windows 3.0.

There's a known prototype of OS/2 1.0 for the 386 called FOOTBALL which is archived on [http://pcjs.org pcjs.org] which does have multiple DOS applications, running through virtual 8088 mode. The notes included show that it was an internal demo meant to be shown to Bill Gates. There were relatively few native applications for OS/2, especially as compared to Windows, so compatibility was definitively something to be mindful of, as stores would have no or limited stock of OS/2 applications.

== Later OS/2 Era Stuff Worth Researching ==
This is just a list of notes of things that should be researched as time permits, but is somewhat out of scope for the things planned.

* OS/2 on PowerPC
* Embedded OS/2 such as on the New York City Subway
* eCommStation and AcraOS
* IBM's use of OS/2 as the system controller for its mainframes well into the 2000s.
* The creation of VirtualBox due to the difficulty of running OS/2 inside of other emulation/virtualization software.

Anyone should feel free to contribute to this (or any other page) relating to OS/2 history.

== References ==

OS/2 Research Outline

2023-01-10T15:21:34Z

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

This is a set of wiki pages dedicated to researching the rise and fall of OS/2, with the intent on creating a larger record of the 16-bit and early 32-bit era of IBM's ill fated operating system, with stream ideas, research notes, discussion and more.

This is an effort to fundamental answer is to document the reasons as to why despite IBM's best efforts, OS/2 failed in the marketplace in favor of Windows 3.0, an operating system that is technically inferior in almost all regards.

== Goals Of This Project ==
The fundamental goal of this project is to create a pretty definitive guide to the early history of OS/2, including showing how it worked, functioned, and more as a primary source, and should interest remain, the creation of multiple realtime videos and/or documentaries to document one of the more pivotal moments of the late 1980s, and early 1990s.

This wiki page should use citations for all major facts and statements, as they will be cited in any video. It's expected that each top level section will become its own "realtime video" at some point.

== Overview of the 16-bit Era of OS/2 ==
Because the level of general knowledge of OS/2 is so low, a basic understanding has to be established about the 16-bit era needs to be established. The closest thing to a canonical document on this era exists at the [https://www.os2museum.com/wp/ OS/2 Museum], but setting up usable and working systems with native apps is essential ...

=== Understanding The Pricing Of Equipment for OS/2 ===
OS/2 runs decently on maxed out equipment, but that's easily going into five figures or more. We need to figure out what was acceptable for a developer system in this era ...

'''It should be important to research what hardware each version of OS/2 may have run on. For example, CGA cards on the AT were pretty common. Understand how OS/2 behaved on low end hardware vs. Windows of the era.'''

Another important note is that OS/2 was created as a replacement to Microsoft's Xenix (a licensed port of AT&T). The chronology here should be determined to understand more factors of the OS/2 mess.

Things to research:
* OS/2-Xenix chronology
* Typical low, medium, and high end PC hardware of the era
* What, besides DOS, was actively used in this time period

=== 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]]
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?

It's known that Microsoft offered a $3,000 SDK and training materials which had basically everything you could want and more in a single box<ref>https://www.os2museum.com/wp/os2-history/os2-beginnings/</ref>, but IBM based material is somewhat scant ...

Topics to be researched:
* Descriptions of OS/2 (or ADOS) as found in early programming reference manuals
* Comparison of early alpha versions of OS/2
* Relationship of early OS/2 to European DOS 4.0
* In-depth reading and review of the manual and more

Questions to be answered:
* What were the stated goals of OS/2?
* What was actually provided out of the box in 1.0?
* IBM marked OS/2 as a server - understanding the relationship here is important

=== OS/2 Editions ===
[[File:IBM OS2 1.00 - Install.png|thumb|OS/2 1.0 Splash Description Page]]
[[File:Microsoft OS2 Splash Screen.png|thumb|Microsoft OS/2 Splash Screen Startup]]

In general, OS/2 was first created for IBM hardware, and then by Microsoft, resold for other PC compatible vendors. OS/2 was also available directly from Microsoft as an upgrade. There are known code and behavior differences between the two editions, as well as significant differences in documentation. However, all editions of OS/2 should be able to run the same binaries.

In general, IBM branded versions only ran properly on IBM machines or extremely compatible clones, while Microsoft versions were, for the most part, more forgiving.

==== IBM Edition ====
IBM editions are generally considered the "canonical" branch of OS/2, as they were developed for and used on IBM's PS/2 line of machines, which were generally the highest end machines with microchannel architecture support. If you were going to shell out the money for a MCA system in the late 1980s, you almost certainly were running either OS/2 or Xenix.

The question is, what did OS/2 specifically bring to the table for power users of this session. The canonical answer would be "Presentation Manager", but is PM actually that good?

==== Microsoft Edition ====
Similar to DOS of the era, Microsoft sub-licensed OS/2 to any OEM who wanted it, creating things like "Nokia OS/2" and "Intel OS/2". There are some code changes, possibly for compatibility reasons. It's likely that OS/2 was at least available for licensing for non-IBM compatible PCs, and may have had an actual OEM adoption kit, similar to the Windows 2/3 OAKs. While unlikely to ever turn up, a good look at the differences between editions is warrented. IBM OS/2 for instances uses the undocumented but highly commonly used 286 LOADALL instruction.<ref>https://www.os2museum.com/wp/more-on-loadall-and-os2/</ref>

==== IBM Extended Edition ====
Although not sold to end-users, IBM also offered an special version of OS/2 to its partners and vendors, which included applications for use in big business, and more importantly, talking to expensive IBM hardware of the era. This had three essential components<ref>https://www.os2museum.com/wp/os2-history/os2-16-bit-server/</ref>

* Communications Manager - allows interfacing to various IBM mainframes
* Database Manager - A SQL database that was later ported to UNIX as a non-mainframe version of DB/2
* LAN Requester - Client for accessing LAN Server/Manager and NetBIOS shares on the network. May not have been in OS/2 1.0 (need to check)

IBM OS/2 1.2 Extended Edition was also the first version to include REXX, before it became a part of every release starting with OS/2 1.3 (for both IBM and Microsoft)<ref>https://www.rexxla.info/links/IBM_historical_pages/rexxos2.html</ref>.

==== LAN Manager ====
OS/2 was also a very popular server platform, completing with Novell NetWare, and UNIX systems of the era, and was in use well into the NT era. Microsoft sold their LAN Manager package as an add-on instead as a dedicated edition. Included were the following components:

* OS/2 LAN Manager Server
* OS/2 LAN Manager Workstation (or Requester in IBM parlance)
* DOS LAN Manager client software
* HPFS386 filesystem for OS/2
* Novell NetWare interoperability tools
* DOS and OS/2 Drivers for a number of NICs

It's unclear how much DNA is shared between IBM products and Microsoft ones.

=== OS/2 as a Server ===
One of the biggest roles of OS/2 in the 90s was its use as an application server, both for handling file and printer sharing, and was essentially the upsale from IBM PC LAN products of this time period. OS/2 was likely more suited as an application server than NetWare at the time, due to NetWare being monolithically linked, and only having "value addon packages", vs. the NLMs that came with NetWare 2.x.

Was the PC network of this era essentially just NetBIOS shares, or were there more functional aspects to it like using databases and more, and how did this interact with software of the era ...

== Understanding the OS/2 Development Environment ==
=== Hello World and Example Applications on OS/2 1.0-1.3 ===
The simplest application for a given platform is "Hello World", something I've documented extensively on both Windows, UNIX, and Linux in the past. OS/2's Hello World program has evolved as IBM replaced the toolchain (and tools) several time throughout the lifespan of the platform. Originally, IBM used Microsoft licensed tools, before replacing it with versions of CSet++ and Visual Age.

It's worth looking at the built in example applications from the varoius SDKs over the years to understand the full evolution of OS/2 from start to finish, especially in the era between IBM and Microsoft, as well as 3rd party toolkits that were commonly used such as Watcom.

=== Executable Format ===
16-bit OS/2 code uses [[New Executable]] (with e_lfanew value NE), a format shared with 16-bit Windows and multitasking MS-DOS. Note that OS/2 is numbered 1 in the OS field of the NE format (0 is unknown), suggesting the format was originally developed for OS/2, despite it being introduced with Windows 1.0 in 1985, two years before the first release of OS/2.

32-bit OS/2 code uses a new format called [[Linear Executable]]. Again, for maximum confusion, there are two incompatible versions of this format. The first one, with e_lfanew value LE, is used in pre-release versions of OS/2 2.0 (TODO: in which?), as well as in 386 version of Windows for native drivers. In OS/2 2.0 RTM, LE support was dropped, and the second version (with e_lfanew value LX) was introduced. This continued to be the format for 32-bit OS/2 executables up to Warp 4.52.

NE, LE, and LX executables all support dynamic linking, and all start with an MZ DOS stub that can run on DOS. A DOS version of the application can be put into the stub, most commonly, it just displays a message saying the program requires OS/2.

=== Comparison to DOS and Creating Family Mode applications ===
OS/2, especially in its earlier forms of ADOS or CP/DOS, was intended as a successor of DOS. Migration facilities like the DOS window were intended to make it possible to migrate over time to OS/2, and there's support for what are known as "Family Mode" applications, which are OS/2 binaries that use a subset of system calls (documented in the IBM OS/2 Technical Reference), and can also be run on a DOS system.

This is different than the DOS stub in NE and PE headers (https://en.wikipedia.org/wiki/New_Executable). In the case of a family mode binary, the binary ran the same on both platforms, with a specialized stub being provided that implemented the OS/2 functions on DOS. When a family mode binary was executed under DOS, the stub linked the NE executable against its own DOS implementation of the Family Mode API and ran it. Because of this, startup of family mode binaries under DOS is slower than for native DOS binaries.

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 FORCEDOS command is used.

=== GDI vs GPI (and other API differences) ===
One of the largest differences between OS/2 and Windows is that the graphics API was entirely replaced. Presentation Manager (OS/2's GUI), was at least in part based on Windows 2.x, and shared many similar features. However, one important difference deals with the graphics API. Windows uses the "Graphic Device Interface" or GDI which is a device independent way of displaying graphics. It originally dates to Windows 1.0, and is still present in Windows 11. OS/2, among other things, replaced with GPI, or "Graphics Precision Interface", and moved the location of 0,0 to the upper left most corner.

There are other differences in OS/2 applications, such as how functions and other parameters that it might be beneficial to go through and at least document at least some of the differences, and try and understand why they may exist.

=== Windows Libraries for OS/2 ===
''This section had a full wiki page [[Windows Libraries for OS/2]] for more information''

[[User:Dr. Shuppet|Dr. Shuppet]] has done an amazing job at writing up the history and backstory of [[Windows Libraries for OS/2|WLO]], which is a port of Windows libraries running under Presentation Manager. WLO was several compatibility solutions, such as Micrograx Mirrors. Microsoft shipped ports of the Windows 3.0 accessories as a WLO demo, and several OS/2 native binaries, such as Word and Excel for Windows use WLO or similar technologies to bridge the gap between Presentation Manager and the Win16 API.

WLO was obviously intended as a transition technology when Windows started gaining momentium in the 2.x and 3.x days, but before the IBM-Microsoft divorce was finalized, and should be categorizes in the great timeline of events.

=== 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).

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 ...

=== Limits of Preemptive Multitasking ===
OS/2 is a natively preemptively multitasking system; it shouldn't be possible for a single application to hang the system. However, this isn't true in practice. For what were presumably performance reasons, OS/2 Presentation Manager applications share what is known as the Single Input Queue (also written as Single Event Queue), which is a message pump shared between all applications, and is inherited from Win16 programming.

The fundamental end result of the SIQ means that one crashed Presentation Manager application can hang the entire UI with startling ease. A partial fix for this, the async SIQ wasn't released until OS/2 Warp 4, which was near the end of OS/2's commercial life span. While it is possible to disable Presentation Manager through editing CONFIG.SYS, or even use the OS/2 1.0 TSHELL.EXE, this doesn't appear to have ever been officially supported by IBM.

In theory, OS/2 should be fully capable of process and thread based multitasking similar to Windows NT, but documenting the full limitations is important. It's also worth checking (with a kernel/ICE debugger if necessary) if the the 286's task segment selector (TSS) is used in this process at all ...

== Capabilities and Limitations of OS/2 ==
There's a lot that's been written that tries to determine why OS/2 failed on a technical level, but it's difficult to determine if this was justified in fact or fiction. Some parts of this are people who are familiar with other operating systems, combined with relatively sparse documentation may cause people to have a lot of mistaken assumptions. Some of the major points to be researched and discussed follows.

=== How Hamstrung was OS/2 By the 286 ===
One of the largest repeated beliefs is that OS/2 was hamstrung by the design of the 286. There's certainly reason to believe this, since NT was intended as "Portable OS/2", and the system remained a mismatch of 16-bit and 32-bit code to it's end. However the 386 was fully supported with MVDM by 1992, when OS/2 2.0 first shipped. In practice, the 16-bit versions of OS/2 seem very similar in capability to the 16-bit versions of Windows, and are arguably closer to Windows 9x than they are DOS.

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.

=== HPFS ===
HPFS was intended as a replacement for the aging FAT (file allocation table) filesystem. Standing for High Performance File System, HPFS brought support for long filenames, and extended attributes to OS/2 1.2, and is required for many OS/2 applications to function properly. HPFS was also supported on NT 3.1 and 3.5, and later versions through the PINBALL driver. From what I know, NTFS is essentially an extension of HPFS, with similar data structures and more, but this should be looked more into by comparing the NTFS and HPFS drivers in the Linux kernel.

=== 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.

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.

=== Networking with NetWare/LAN Server/LAN Manager ===
Although mostly unknown by home users, both DOS and OS/2 supported network operations, leading to the term network redirector. From reading in the Windows NT Resource Kit, and other places, communication between applications happened in the form of named pipes, and IPC process namespaces. Its worth looking more in-depth how NetBIOS related networking works, as possibly part of a larger series on the value of the network. In many ways, OS/2 pioneered much of what would be the NT network stack, including being the home of domains and more.

Furthermore, NetWare Client for OS/2 1.1<ref>https://www.os2museum.com/wp/1989-networking-os-2-netware-requester-1-1/</ref> has recently turned up, and a beta of NetWare for OS/2 1.0<ref>https://www.os2museum.com/wp/1988-networking-netware-os-2-requester/</ref> has also recently shown up, so it might be worth taking these systems out for a spin.

=== DOS/Windows Compatibility ===
One of the largest criticisms was horrid backwards compatibility with DOS and Windows. The 16-bit versions of OS/2 could only run one DOS application at a time in what commonly became known as the penalty box, which was a DOS session that was constantly running. This is due to how the 80286 didn't provide any support for virtualizing real mode applications, and delays involving OS/2 2.x meant that 386 support didn't ship until 1991-92, well past Windows/386 and Windows 3.0.

There's a known prototype of OS/2 1.0 for the 386 called FOOTBALL which is archived on [http://pcjs.org pcjs.org] which does have multiple DOS applications, running through virtual 8088 mode. The notes included show that it was an internal demo meant to be shown to Bill Gates. There were relatively few native applications for OS/2, especially as compared to Windows, so compatibility was definitively something to be mindful of, as stores would have no or limited stock of OS/2 applications.

== Later OS/2 Era Stuff Worth Researching ==
This is just a list of notes of things that should be researched as time permits, but is somewhat out of scope for the things planned.

* OS/2 on PowerPC
* Embedded OS/2 such as on the New York City Subway
* eCommStation and AcraOS
* IBM's use of OS/2 as the system controller for its mainframes well into the 2000s.
* The creation of VirtualBox due to the difficulty of running OS/2 inside of other emulation/virtualization software.

Anyone should feel free to contribute to this (or any other page) relating to OS/2 history.

== References ==

Research Stream: OS/2 1.0 Explorations

2023-01-07T23:30:10Z

Waterpear: /* Questions To Answer */ submit question about comparison to Xenix

[[Category:Projects]][[Category:Streams]][[Category:OS/2]]
This is an upcoming set of streams to document the early versions of OS/2 including the IBM, Microsoft, and Extended Edition. The goal is to create a baseline summary of everything OS/2 is and was intended to be. Unfortunately, there's relatively little surviving from the OS/2 1.x era, and even less of the 16-bit console era.

== Exploring OS/2 1.0 ==
As Microsoft (and likely IBM) strongly believed in dog-fooding, the goal is to create example environments representing what is known about how they used. Microsoft originally made OS/2's software development kit available to

=== Microsoft Developer on OS/2 ===
Microsoft used OS/2 fairly extensively in-house as it was an early adopter of the 80286, and OS/2 was used to develop itself, and Windows NT, as well as several well known applications such as Word for Windows. In effect, OS/2 is a fairly solid development platform, and provides a lot more flexibility and customization than DOS of the era.

The goal is to create an example VM with the following components
* Microsoft OS/2 1.0 running on a 80286
* Microsoft Word
* Microsoft Multiplan
* Microsoft Mail (either native OS/2 or DOS version)
* Microsoft C Programmers Workbench
* OS/2 SDK 1.0

Internally, among other things, Microsoft used the M editor, originally for DOS, with an OS/2 port being made as SDKED, which is important since OS/2 1.0 doesn't ship with an editor. SDKED should be on the SDK, but even a DOS copy of MEP should be used if needed.

For good measure of the following third-party applications. These should be 8088 based, and period correct from 1985-1988ish.
* WordStar for DOS
* Rogue

=== IBM Powered Business ===
While Microsoft saw OS/2 as the future, IBM wanted it as a more advanced operating system for the 286. While IBM intended it for use on their own line of PCs, they did sell Extended Edition to partners that included two, and then three major apps.

* IBM SQL Server (which is used as the basis for non-mainframe DB2 today)
* Communication Manager, for interfacing with other IBM machines
* LAN Server, which was a NetBIOS server, and domain master - It wasn't in 1.0, but check when it was added.

By and large, OS/2 was a very threadbare environment, with the most advanced built in app being the E editor, and very few third party applications. OS/2 had very high system requirements for that time period, and while it needs to be backed with research, it stands to reason that IBM was mostly catering to very high end power users, as well the small and middle business groups who were on the IBM PC already.

== Questions To Answer ==
* What was OS/2 1.0 like to use?
* Was OS/2 a decent development platform?
* Is this an upgrade from DOS (especially Multiuser DOS 4)?
* How does this compare to Xenix, or other PC Unix and Unix-likes of the time?
* What problems were visible here that were only obvious with hindsight?

DisNCord Rules

2022-12-27T17:07:47Z

Waterpear: /* Channel Descriptions */ fill in descriptions for most of the channels

This is an ongoing discussion to create a server overview, and description of all channels, as well as an effort at revising and clarification of the rules.

== Server Description ==
DisNCord is NCommander's personal Discord server, which has taken many forms in the two years it has existed. At the moment, it's a combination of a social group, a center of preservation and retrocomputing, a place of acceptance, healing and understanding, and much more. It's expected that DisNCord will constantly shift and change throughout its existence both as its residents, and its owner changes. This is a living document intended to outline its core tenants and values.

== Rules ==
# Treat everyone with respect. Absolutely no harassment, witch hunting, sexism, racism, or hate speech will be tolerated.
# No NSFW or obscene content. This includes text, images, or links featuring nudity, sex, hard violence, or other graphically disturbing content.
# No spam or self-promotion (server invites, advertisements, etc) without permission from a staff member. This includes DMing fellow members.
# This server is focused around retro-technology, and the history of computing but there are no hard and fast rules on topics.
# Posting links to proprietary information (such as copyrighted, or classified material) is prohibited.
# Excessive negativity, doomsaying, lashing out, and similar behaviors is prohibited.
# Venting is fine (we have a dedicated forum), but try to remember the other human.
# Violations of the rules may be reported via the ticket reporting system
# Transparency and accountability are the keys to a long running server.
# The Discord ToS supersedes all server rules, and shall be upheld by all moderators
# Come by and have a good time.

To prevent excessive rule lawyering, a general statement of what each rule means is provided for some of the more open ended ones. Moderators have final authority in determining what is and isn't acceptable, but, at the same time, moderators are humans too, and it should be understood that mistakes can and will happen.

=== Respecting Others ===

=== NSFW and Adult Topics ===

=== What Constitutes Spam ===

=== Proprietary Information ===
The term proprietary information is an overarching term that essentially refers to anything that isn't intended for publication. This also includes information that would be covered under a signed limited disclosure agreement or NDA, trade secrets, or classified material. The standard line to use here is similar to that of [https://en.wikipedia.org/wiki/Clean_room_design clean room design] (sometimes known as the Chinese wall technique), where you can discuss things learned, but not directly link to such information. The very simple example is as follows: Linking to a news article is fine, linking to leaked docs, not so much.

Moderators will handle this on a case by case basis.

=== Accountability and Transparency ===

=== Special: The Discord ToS And Other Unique Circumstances ===

== The Responsibilities of Staff ==
Staff, which include both moderators, and those who've taken up a volunteer role such as Wiki Editor are responsible for helping create DisNCord (and this wiki) what they are, as well as upholding the server's values and roles.

At the time of writing (2022-12-26), moderators are organized in a flat structure, with NCommander being the final arbitrator.

At the time of writing (2022-12-26), wiki volunteers are organized in a flat structure, with a wiki admin group being created in the near future.

Server moderators have the "Resident Madfolks" role, and a gold name in chat. Moderators uphold the chat rules, and are trusted to timeout, kick, or ban on their own cognition. Server moderators are considered volunteers.

== The Importance of Volunteers ==
Volunteers are recognized with a distinctive purple color and icon in chat representing where they are interested in working. While volunteers are always welcome, by becoming one, you also accept the responsibility of being a representative of the server, and thus should be expected to be held to a higher standard than a normal member might be.

As DisNCord expands, it is important that we always remember the people who make it possible, and more defined benefits and responsibilities will be laid down as we expand further.

== Warnings Are Not Threats ==

== Transparency and Accountability ==

== Supporter Roles Are Not Rule Exempt ==
This server accepts both NCommander's Patreon, and its own Discord Supporter payments, and collects funds towards both helping its creator, and funding it's own internal projects, such as this wiki, and Mastodon servers. Unfortunately, there are who believe that one can simply buy their way out. As an official policy, supporter status shall not be considered when a moderation decision is made. At NCommander's discretion, Patreon perks may also be blocked for especially egregious conduct.

Discord Nitro Boosters are considered a supporter role, although at this time, they do not gain any access to perks.

== Reporting System ==

== Archival Policy ==

== Quotes and Wiki Policy ==

== Channel Descriptions ==

=== Announcements ===
Channels used to broadcast announcements, proclamations, or other information to all server users.

==== #rules ====
The rules of the server, posted for quick reference.

==== #role-select ====
Lets users toggle pronoun and ping roles.

==== #content ====
Announces when new NCommander content is available. 🎊

==== #changelog ====
Changes and other updates to the server will be announced here

=== Supporters ===
These channels are only visible to premium supporters (Seeker Supporters and Tip Jar Supporters) as a membership perk.

==== #the-lounge ====
General discussion for supporters. Help yourself to the cookies on the table. (note: the cookies are fictional)

==== #supporter-content ====
Announces when new NCommander content is available to premium supporters for early access.

=== Discussion Tracks ===

==== Discussion Track Channels: #general-pi and #belgium ====
These are the general discussion channels, for any sort of discussion. There are two of them so users can start a conversation without getting trampled by the conversation already in progress.

(TODO: explain belgium)

==== #off-topic ====
Overflow channel for talking about things that aren't necessarily computer related. There's a thread here just for memes.

Topics better suited for the "no place of honor" channels should go there instead.

=== Voice Channels ===
Want to hang out and talk about stuff? Want to livestream your installation of CDE on an air fryer? Then you want the voice channels.

==== #voice-text ====
Lets people who can't or won't use a mic participate in a voice chat conversation. (This channel predates Discord's own text subchannel feature.)

==== Voice Discussion Channels ====
Voice chats for voice communication, video chat, or streaming.

=== Breakout Tracks ===
These channels are for relevant sub-topics

==== #amateur-radio ====
Discuss amateur radio ("ham radio")

==== #cursed-computing ====
This is where you post cursed ideas that won't leave your head, or share an abomination against computing that you found somewhere.

Please don't ask N (or anyone, really) to do a video on a specific idea; they already have plenty of videos planned.

==== #tech-support ====
Provide or request technical assistance. Sort of the opposite of #cursed-computing.

(No one is obligated to provide support.)

==== #oddware-finds ====
This channel is dedicated for people posting interesting eBay finds.

Please put notes if you just want info on an item, or if its free to bid on. Unmarked items are assumed to be fair game.

==== #photos ====
Post neat photos you took.

=== Acceptance Corner ===
These channels center acceptance, a core value here at DisNCord.

==== #express-yourself ====
Express yourself in ways we can all see

==== #coming-out ====
Discussion related to LGBTIQA+, including coming out, questioning, and acceptance

==== #help-and-venting ====
We all need to vent sometimes.

==== #good-vibes ====
Post things that give us good vibes. For example, cat. 🐈‍⬛

=== Paint Drying ===
Channels for the paint drying competition, also known as [[Slow Computing Speedruning|Slow Computing Speedrunning]].

==== #paint-drying-competition ====
General discussion for the concept.

==== #milestone-drips ====
Lets participants announce achievements to the world.

==== #wet-paint ====
Forum with threads for the individual attempts.

==== Paint Drying Streams ====
You can actually watch a computer from the early 90s compile distressingly recent software in real time!

=== No Place Of Honor ===
This is [[wikipedia:Long-term_nuclear_waste_warning_messages|not a place of honor]]. No great deeds are commemorated here. What is here is dangerous and repulsive to us.

==== #politics ====
Political discussion goes here. It is on slow-mode, as a reminder to think before you type and treat everyone with respect.

==== #no-great-deeds ====
This channel is to denote all the horseshit on the Internet. Incel crap, alpha male crap, and well, things that make the world a worse place. If it sucks, put it here.

==== #blockchain-of-fools ====
The cryptocurrency carnival. Bitcoin, Web3, metaverse, NFTs--if it sucks ''on the blockchain'', put it here.

=== Restless Systems ===
Discussion and documentation of Restless Systems' attempts to make its mark on the world

==== #fedi-discuss ====
Discuss Fediverse things, including our Mastodon instance.

==== #wiki-bootstrap ====
Discussion of this very wiki!

==== #wiki-changes ====
Automated changelog of wiki edits.

=== Projects ===
Document and discuss the major tech projects the community is involved in.

==== #project-monterey ====
Discord forum for the effort to get the Project Monterey OS up and running. See: [[AIX on Itanium]].

==== #banyan-resurrection ====
Channel for the [[Banyan VINES resurrection]] work.

==== #osdev ====
A channel for the community's [[Homebrew OS Development]] scene.

This channel predates Discord forums, so most discussion happens in the threads.

=== Meta ===

==== #welcome ====
👋 Discord's automatic announcements for new users appear here

==== #botworld ====
Experiment with the Discord bots here without fear of trampling conversation

==== #discord-improvements ====
Suggest improvements for the Discord server here

=== Staff Lounge ===
Private channels for server staff.

==== #mod-discussion ====
==== #mod-sysadmin ====
==== #mod-social ====
==== #enforcement-action ====
==== #mod-botworld ====
==== #mod-voice ====

=== The Lost Worlds ===
==== #minecraft ====

=== Archives ===
These channels are no longer active for whatever reason, but the messages are kept in the archives just in case useful information

==== #8086-detector ====
The [[8086 Detector]] was an attempt to identify the various 8086-compatible CPUs in software

==== #games-server-thoughts ====
Discussed setting up a Minecraft server or some other game server for the community.

==== #rms-fsf-response ====
Discussed Richard Stallman's conduct, leading up to NCommander's video on the subject.

==== #video-production ====
NCommander talks video production

==== #stuff-youtube-says ====
This was meant as a #no-great-deeds specifically for YouTube comments

==== #wiki-changelog ====
This was originally intended to document updates to the wiki's configuration.

=== A Note On Private Channels ===
A small number of private channels have been used in the past to hold discussion between server admins, as well as handle time sensitive topics. These are generally all inactive, and only exist for archival purposes.

== Server Roles ==

=== Administration Roles ===
==== Server Administrators ====

==== Endless Seeker ====

==== Bot Wrestler ====

==== Resident Madfolks ====

=== Volunteer Roles ===
==== Wiki Volunteers ====

=== Supporter Roles ===

==== Seeker Supporter ====

==== Tip Jar Supporter ====

==== Discord Nitro (Cool Folks) ====

=== Self-Selected Roles ===

==== Pronoun Roles ====
Pronoun roles exist for easy identification of folks. Roles are self-selected through a bot (or for more rarely used roles, filing a a ticket and requesting it). At the moment, roles are colored differently, and ordered in such a way to help increase diversity on the server.

In the past, the pronouns all shared an orange color, which stood out against the white generic color; the diversity in colors also helps allow those who don't have roles selected from not feel forced to take one.

Colors and ordering may change in the future

* She/Her (Cyan)
* He/Him (Red)
* They/Them (Purple)
* Any/Any (dark gray)
* It/Its (gray)
* Fey/Fey (gray)

==== N's Life ====

==== Drip Reports ====

=== Other Roles ===
==== Minecraft ====

==== Bot Roles ====
== Things To Be Written ==
* [[Reporting/Ticket Handling Guide]]
* [[Incident Response Guide (ICS Primer)]]
* [[Improvement Proposal Guide]]

Homebrew OS Development

2022-09-20T15:27:11Z

Waterpear: more accurate description of picotalk

This is a general summary of what OSes are being developed on DisNCord.

=== Open Computing Kit (OCK) ===
A joint project between Elisia, Sadmac356, Griffin, Europa, and others, [https://github.com/open-computing-kit Open Computing Kit] is an operating system that aims to be as GNU-independent as possible, including a [https://github.com/open-computing-kit/ockernel kernel written in Rust] and its [https://github.com/open-computing-kit/OCKcore own set of coreutils]. It is presently in the very early stages of active development.

=== SeshOS ===
Written by Mineman, SeshOS is one of the more esoteric OSes on DisNCord. It has the beginnings of a GUI and shell in the kernel, but no memory management.

SeshOS has support for one filesystem: tar ramfs.

Its source code is located at https://github.com/mine-man3000/SeshOS.
[[File:SeshOS2.png|thumb|SeshOS in its current state as of September 1st, 2022]]

=== Pics Of Bread Awful scRipting Interpreter System for Neat Architectures (POBARISNA) ===
Written by Krabs, POBARISNA is an operating system with a JavaScript-based microkernel design that currently only runs on PowerPC macs. There are prospective plans for ports to other "Neat Architectures" (which Krabs defines as "not a PC/BIOS/UEFI x86 system"), such as SPARC variants and ARM.

The project can be found on [https://gitlab.com/christiancrowle/pobarisna GitLab].

The JavaScript interpreter used in POBARISNA is [https://duktape.org/ Duktape], an easily embeddable interpreter with a nice API. However, Duktape 2.x has some awkward tooling and a lack of solid control over execution. Therefore, there are plans to replace it with [https://gitlab.com/christiancrowle/dorktape Dorktape], which will hopefully serve as a modernized fork of the engine.

Being that PowerPC OpenFirmware is a slightly under-documented platform, [[PowerPC OpenFirmware Implementation Details]] should serve as helpful to anyone looking to do something similar.
[[File:POBARISNA running duktape on bare metal.jpg|alt=An early screenshot of POBARISNA running Duktape in OpenFirmware|thumb|An early screenshot of POBARISNA running Duktape in OpenFirmware]]

=== picotalk ===
Written by Waterpear, picotalk is a Smalltalk interpreter that aims to be a bare-metal system for embedded use. It is currently in a very limited state; only the base object model and a preliminary bytecode VM are operational.

=== Rotom OS ===
Written by SED, [https://github.com/SED4906/rotomos Rotom OS] is an operating system with little information to glean from anything except for its code and a few images. It attempts to be as simple as possible, with ring 3 not yet being implemented.
[[File:RotomOS.png|thumb|Rotom OS]]

=== styx ===
Written by Sirocyl and others, styx is an operating system with many ideas, some of which will be listed here:
* Applications will be double-click to run, much like Windows or macOS.
* Libraries should live with their application in packaging, similar to Windows.
* Installation will be done through drag-and-drop, taken from macOS.
* The system will be as (trans)portable as possible, similar to Classic macOS.
* The word "styx" is not an acronym, nor will the operating system's governing body ever be comprised of one member.
* The system will be consent-first, something that flies in the face of traditional operating systems like Windows and macOS.
There are many more than are stated here in their Discord server, due to there being too many to list here effectively.

=== Astral ===
Written by Mathewnd, [https://github.com/Mathewnd/Astral Astral] is a monolithic kernel written in C. It is still at its early stages of development and has the beginnings of a userland.

It is currently capable of running Bash and work is being done to get it to run other programs.

[[File:Astral running Bash.png|thumb|alt=Astral running Bash builtins on Sept 11, 2022|Astral running Bash builtins on Sept 11, 2022]]

=== Techflash OS (TFOS) ===
Written by Techflash, [https://github.com/techflashYT/Techflash-OS Techflash OS] is an operating system that is still very early in development.

It current has very little implemented except for the following:

* A basic boot procedure
* Enabling a few CPU features
* (broken) support of a few basic interrupts, such as the [[wikipedia:Intel_8253|PIT]]
* A very basic framebuffer console