Documentation: Replace remaining references of OpenBeOS with Haiku

Fixes #19335

Change-Id: I8458431be907e3f59165c7e9cf43d715e904af3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8826
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>

docs/develop/file_systems/node_monitoring.rst

@@ -8,7 +8,7 @@ Author(s): Axel Dörfler
 This document describes the feature of the BeOS kernel to monitor nodes.
 First, there is an explanation of what kind of functionality we have to
 reproduce (along with the higher level API), then we will present the
-implementation in OpenBeOS.
+implementation in Haiku.
 
 Requirements - Exported Functionality in BeOS
 ---------------------------------------------
@@ -95,7 +95,7 @@ use any application kit services.
 
 | 
 
-Meeting the Requirements in an Optimal Way - Implementation in OpenBeOS
+Meeting the Requirements in an Optimal Way - Implementation in Haiku
 -----------------------------------------------------------------------
 
 If you assume that every file operation could trigger a notification
@@ -189,17 +189,17 @@ implementation, there are some notable differences between the two.
 
 BeOS reserves a certain number of slots for calls to ``watch_node()`` -
 each call to that function will use one slot, even if you call it twice
-for the same node. OpenBeOS, however, will always use one slot per node
+for the same node. Haiku, however, will always use one slot per node
 - you could call ``watch_node()`` several times, but you would waste
 only one slot.
 
 While this is an implementational detail, it also causes a change in
 behaviour for applications; in BeOS, applications will get one message
-for every ``watch_node()`` call, in OpenBeOS, you'll get only one
+for every ``watch_node()`` call, in Haiku, you'll get only one
 message per node. If an application relies on this strange behaviour of
 the BeOS kernel, it will no longer work correctly.
 
-The other difference is that OpenBeOS exports its node monitoring
+The other difference is that Haiku exports its node monitoring
 functionality to kernel modules as well, and provides an extra plain C
 API for them to use.
 
@@ -250,4 +250,4 @@ is much larger then - but for applications like Tracker, the complexity
 would be removed from the application without extra cost.
 
 However, none of the discussed feature extensions have been implemented
-for the currently developed version R1 of OpenBeOS.
+for the currently developed version R1 of Haiku.

docs/develop/kits/app/usecases/BMessageQueueUseCases.html

@@ -139,7 +139,7 @@ elements in the list will be high.</P>
 <P>Because the BMessageQueue uses the link pointer which is a private part of the BMessage class,
 the BMessageQueue must be a friend class of BMessage.  Checking the headers, this is in fact the
 case in Be's implementation.  Although friendship in classes can cause some pretty serious long
-term headaches if abused (and I am not convinced that this is an abuse), the OpenBeOS 
+term headaches if abused (and I am not convinced that this is an abuse), the Haiku
 implementation will follow the same implementation for now.</P>
 
 

docs/develop/kits/app/usecases/BPropertyInfoUseCases.html

@@ -131,7 +131,7 @@ properties.</P></LI>
 
 <A NAME="implement"></A><H2>BPropertyInfo Implementation:</H2>
 
-<P>There is a key difference between the OpenBeOS BPropertyInfo class and the Be implementation
+<P>There is a key difference between the Haiku BPropertyInfo class and the Be implementation
 is support for BeOS R3 compiled executables.  The elements in the property_info structure changed
 in R4 versus the one which was used in R3.  Be did the following to handle this:</P>
 
@@ -146,7 +146,7 @@ constructor would be called because the old one was made private.</LI>
 R3 based BPropertyInfo instances.  I have not done serious checking on this however.</LI>
 </UL>
 
-<P>For the OpenBeOS implementation, we have decided not to implement this R3 compatibility at
+<P>For the Haiku implementation, we have decided not to implement this R3 compatibility at
 this time but we are not going to rule it out.  The header file for BPropertyInfo will be changed
 to "remove" the R3 compatibility interfaces using an "ifdef R3_compatible".   The interfaces will
 still appear to the human reader but not be there as far as the compiler is concerned.  If we
@@ -154,15 +154,15 @@ revise out decision in the future, it will be a simple matter of removing the if
 these R3 compatibility interfaces.  For now, we have decided not to do this because:</P>
 
 <UL>
-<LI>There is no binary compatibility between R3 and R4 of BeOS Intel.  The ability for OpenBeOS
+<LI>There is no binary compatibility between R3 and R4 of BeOS Intel.  The ability for Haiku
 to be binary compatible with these old R3 interfaces buys us nothing on Intel.</LI>
 <LI>There is binary compatibility with R3 with R4 and R5 on BeOS PPC.  Without these interfaces
 implemented, it may not be possible for R3 compiled binaries for PPC to operate against the
-OpenBeOS implementation.  However, there are no specific plans to support PPC.  Also, the informal
+Haiku implementation.  However, there are no specific plans to support PPC.  Also, the informal
 PPC ports that have been discussed were considering using the gcc toolset which I believe precludes
 any backward compatibility, even with R5 binaries.</LI>
 <LI>There is some risk that a flattened BPropertyInfo instance on someone's hard disk was created
-against the old R3 implementation.  The OpenBeOS implementation may not be able to read this
+against the old R3 implementation.  The Haiku implementation may not be able to read this
 flattened BPropertyInfo.  However, we believe the chance of this happening to be very low and
 not worth the cost of the implementation.</LI>
 </UL>

docs/develop/kits/interface/BPicture_specifications.html

@@ -6,7 +6,7 @@
  content="text/html; charset=ISO-8859-1">
   <meta name="author" content="Marc Flerackers(mflerackers@androme.be)">
   <meta name="description"
- content="BPicture specifications for OpenBeOS">
+ content="BPicture specifications for Haiku">
 </head>
 <body>
 <span style="font-weight: bold; text-decoration: underline;"></span>Author:

docs/develop/media/codec_mapping

@@ -1,5 +1,5 @@
 # This file belongs into /boot/home/config/settings/Media and is called codec_mapping 
-# It contains codec assignments for the new OpenBeOS media kit
+# It contains codec assignments for the new Haiku media kit
 #
 # WARNIG! This format is experimental and will possibly be changed!
 #

docs/develop/midi/design.rst

@@ -5,7 +5,7 @@ The Midi Kit consists of the midi_server and two shared libraries,
 libmidi2.so and libmidi.so. The latter is the "old" pre-R5 Midi Kit and
 has been re-implemented using the facilities from libmidi2, which makes
 it fully compatible with the new kit. This document describes the design
-and implementation of the OpenBeOS midi_server and libmidi2.so.
+and implementation of the Haiku midi_server and libmidi2.so.
 
 The midi_server has two jobs: it keeps track of the endpoints that the
 client apps have created, and it publishes endpoints for the devices

docs/develop/midi/midi1.rst

@@ -36,7 +36,7 @@ do, while it is likely that no applications use them anyway. However,
 problems.
 
 ``BSamples`` doesn't do anything; its functions are mostly empty. In
-other words, with the OpenBeOS Midi Kit you cannot push waveform data
+other words, with the Haiku Midi Kit you cannot push waveform data
 into the output of the softsynth.
 
 For simplicity's sake, ``BMidiSynthFile`` is implemented using

docs/develop/midi/oldprotocol.rst

@@ -1,7 +1,7 @@
 The BeOS R5 Midi Kit protocol
 =============================
 
-In the course of writing the OpenBeOS Midi Kit, I spent some time
+In the course of writing the Haiku Midi Kit, I spent some time
 looking at how BeOS R5's libmidi2.so and midi_server communicate. Not
 out of a compulsion to clone this protocol, but to learn from it. After
 all, the Be engineers spent a lot of time thinking about this already,
@@ -358,7 +358,7 @@ has a zero refcount, libmidi still sends out the 'Mdel' message. It also
 drops you into the debugger. (I think it should return an error code
 instead, it already has a status_t.) However, if you Release() proxies a
 few times too many, your app does not jump into the debugger. (Again, I
-think the return result should be an error code here -- for OpenBeOS R1
+think the return result should be an error code here -- for Haiku R1
 I think we should jump into the debugger just like with local objects).
 Hmm, actually, whether you end up in the debugger depends on the
 contents of memory after the object is deleted, because you perform the

docs/develop/midi/testing.rst

@@ -1,7 +1,7 @@
 Testing the Midi Kit
 ====================
 
-Most of the OpenBeOS source code has unit tests in the current/src/tests
+Most of the Haiku source code has unit tests in the current/src/tests
 directory. I looked into building CppUnit tests for the midi2 kit, but
 decided that it doesn't really make much sense. Unit tests work best if
 you can test something in isolation, but in the case of the midi2 kit

docs/develop/servers/app_server/AppServer.rst

@@ -135,7 +135,7 @@ Attached Data:
 GET_SCREEN_MODE
 ---------------
 
-Received from the OpenBeOS Input Server when requesting the current
+Received from the Haiku Input Server when requesting the current
 screen settings via synchronous PortLink messaging. This is a
 temporary solution which will be deprecated as soon as the BScreen
 class is complete.

docs/develop/servers/app_server/Decorator.rst

@@ -212,7 +212,7 @@ void \_SetFocus(void)
 
 This hook function is primarily used to change colors used when a
 window changes focus states and is called immediately after the state
-is changed. If, for example, a decorator does not use OpenBeOS' GUI
+is changed. If, for example, a decorator does not use Haiku' GUI
 color set, it would change its drawing colors to reflect the change in
 focus.
 

docs/user/book.dox

@@ -388,7 +388,7 @@ snooze_until(time - Latency(), B_SYSTEM_TIMEBASE);
 	of events from more than one producer to one consumer at the same time.
 
 	The article Introduction to MIDI, Part 2 in <A
-	HREF="https://open-beos.sourceforge.net/nsl.php?mode=display&id=36">OpenBeOS
+	HREF="https://www.haiku-os.org/legacy-docs/openbeosnewsletter/nsl36.html">OpenBeOS
 	Newsletter 36</A> describes this problem in more detail, and provides a
 	solution. Go read it now!
 

docs/user/midi2/MidiEndpoint.dox

@@ -292,8 +292,8 @@ if (endpoint->GetProperties(&props) == B_OK)
 	<TR><TD>field type</TD><TD>'MICN'</TD></TR>
 	</TABLE>
 
-	The MidiUtil package (downloadable from the OpenBeOS website) contains a
-	number of convenient functions to associate icons with endpoints, so you
+	The MidiUtil package (downloadable from https://www.haiku-os.org/files/MidiUtil-1_0.zip)
+	contains a number of convenient functions to associate icons with endpoints, so you
 	don't have to write that code all over again.
 
 	\sa GetProperties()

docs/user/midi2/midi2intro.dox

@@ -244,7 +244,7 @@ connected to the same consumer, it is nearly impossible to sort this all out
 than one producer to one consumer at the same time.
 
 The article Introduction to MIDI, Part 2 in <A 
-HREF="http://open-beos.sourceforge.net/nsl.php?mode=display&id=36">OpenBeOS 
+HREF="https://www.haiku-os.org/legacy-docs/openbeosnewsletter/nsl36.html">OpenBeOS
 Newsletter 36</A> describes this problem in more detail, and provides a 
 solution. Go read it now!