diff --git a/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png b/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png
new file mode 100644
index 00000000..e508ccfb
Binary files /dev/null and b/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png differ
diff --git a/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png.data b/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png.data
new file mode 100644
index 00000000..145d3688
--- /dev/null
+++ b/documentation/current/platform-specifics/_images/EiffelRibbon_application_01.png.data
@@ -0,0 +1,3 @@
+title=EiffelRibbon application 01
+author=halw
+path=content/eiffelribbon-application-01
diff --git a/documentation/current/platform-specifics/microsoft-windows/eiffelribbon/index.wiki b/documentation/current/platform-specifics/microsoft-windows/eiffelribbon/index.wiki
index 9a1669ae..7a817f35 100644
--- a/documentation/current/platform-specifics/microsoft-windows/eiffelribbon/index.wiki
+++ b/documentation/current/platform-specifics/microsoft-windows/eiffelribbon/index.wiki
@@ -94,7 +94,13 @@ So, here again, if you are familiar with EiffelVision 2, then EiffelRibbon shoul
 
 When you build an application with the EiffelRibbon tool, it generates classes for you. These classes are often clients or heirs to classes in the EiffelRibbon library. The classes generated for the objects on your ribbon should look familiar to you as well. For example, as with EiffelBuild, for each ribbon object, say a button, there will be a class ending with the suffix "<code>_IMP</code>" which will get regenerated each time you request the EiffelRibbon tool to generate classes. Also generated is an heir to that class with a name that does not include the suffix. This class you are free to edit, as it will not be regenerated. It is in these editable classes that you provide the action sequences for your ribbon objects' behaviors.
 
-The class shown in the Edit pane of Figure 3 is part of a generated class <code>BUTTON_CHANGE_SMALL_IMAGE</code>, representing a ribbon button, from one of the EiffelRibbon examples. <code>BUTTON_CHANGE_SMALL_IMAGE</code> is a heir to <code>BUTTON_CHANGE_SMALL_IMAGE_IMP</code>. You can see that in the redefined version of <code>create_interface_objects</code> code has been added to add an agent to the <code>select_actions</code> for the ribbon button. In this case, it's an inline agent that will toggle the associated image back and forth between two different images.
+The class shown in the Edit pane of EiffelStudio in Figure 3 is a portion of a generated class <code>BUTTON_CHANGE_SMALL_IMAGE</code>, representing a ribbon button, from one of the EiffelRibbon examples. <code>BUTTON_CHANGE_SMALL_IMAGE</code> is a heir to <code>BUTTON_CHANGE_SMALL_IMAGE_IMP</code>. You can see that in the redefined version of <code>create_interface_objects</code> code has been added to add an agent to the <code>select_actions</code> for the ribbon button. In this case, it's an inline agent that will toggle the associated image back and forth between two different images.
+
+
+[[Image:EiffelRibbon application 01|An EiffelRibbon application in EiffelStudio.]]
+
+Figure 3.
+
 
  
 
diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
index ea3d048e..be10725c 100644
--- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
@@ -13,7 +13,31 @@ In other ways, particularly for early versions, the EiffelStudio implementation
 The differences between the EiffelStudio implementation of SCOOP and current and previous definitions of the SCOOP model are shown below.
 
 
-=The Wait Rule=
+=Known restrictions=
+
+==Separate anchored types==
+
+Applicable to version 6.8, prior to revision number 86657. 
+
+Separate status for anchored types is not supported properly. So declarations of the form:
+
+<code>
+            my_entity: separate like my_query
+</code>
+ 
+and
+
+<code>
+            my_entity: separate like Current
+</code>
+
+should be used only if you are using revision 86657 or later. 
+
+
+
+=Implementation dependent behavior=
+
+==The Wait Rule==
 
 The [[Concurrent Eiffel with SCOOP#Access to shared resources|Wait Rule]] says: ''A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine.''