Possible solutions:
1. Include Reaction.library in my libs/ dir and use ur reaction method.

2. Redefine the game as "Requires OS3.5+" blah
or "Requires AmikitOS" well The last coding I did was putting in hacks to work around bugs in AmikitOS so that I could release an AmikitOS version of the game.  So I don't mind releasing a new AmikitOS version.  AmikitOS seems to have EVERYTHING already installed so I would suddenly have access to Reaction (I think?) and P96 and etc.

#include !pragmas/bitmap_pragmas.h!
// Instead of ! use the less than & greater than brackets.

struct Library *BitMapBase;
struct Image *pCheckImage;

BitMapBase = OpenLibrary("Images/bitmap.image",0);

pScreen = ... // Need to use your screen pointer in this place.

pCheckImage = NewObject(BITMAP_GetClass()
  ,NULL
  ,BITMAP_SourceFile,"Gadgets/English/CheckmarkForMenus.iff"
  // ,BITMAP_Precision,PRECISION_EXACT
  ,BITMAP_Screen,pScreen
  ,BITMAP_Masking,TRUE
  ,TAG_DONE);

// Then you would set pCheckImage as the Window's menu checkmark.

To tidy up:

DisposeObject(pCheckImage);

CloseLibrary(BitMapBase);

Fairly easy once it is worked out but I will still try to roll out a custom class for you so that your OS 3.0 users can have this.

So anyway, how do I know if any given machine posesses Reaction?  I guess I will just go according to if the OpenLibrary("Images/bitmap.image") call works then assume that a full Reaction is installed.

Have a look on your System: drive and look in the "Classes/Images" drawer.
Is the file "bitmap.image" in there?

... cool you've done that already.
Usually the "Classes" drawer is part of the LIBS: assign so I'm surprised the compiler doesn't find it.  Anyhow.

Sorry, you should also include:

#include !images/bitmap.h!
// Replace the !s with the less than and greater than brackets.

in your program.

  #include 
  start.c 39 Error 3: file not found ""
  
  ====================
  #include 
  start.c 40 Error 3: file not found ""
  

@Gunanr
BUG REPORT: The forum sofware should not eat things inside of a [Code][/Code] blodk that are enclosed by lessthan greaterthan symbols.  In other words: do not try to parse HTML inside of a [Code] block.  Thanx.

"images/bitmap.h"
"pragmas/bitmap_pragmas.h"

Try creating a file called reaction.h in your files and stick the following text in the file and see if that does the job:

// From clib/bitmap_protos.h
Class * BITMAP_GetClass(VOID);
// From pragmas/bitmap_pragmas.h
#if defined(LATTICE) || defined(__SASC) || defined(_DCC)
#ifndef __CLIB_PRAGMA_LIBCALL
#define __CLIB_PRAGMA_LIBCALL
#endif /* __CLIB_PRAGMA_LIBCALL */
#else /* __MAXON__, __STORM__ or AZTEC_C */
#ifndef __CLIB_PRAGMA_AMICALL
#define __CLIB_PRAGMA_AMICALL
#endif /* __CLIB_PRAGMA_AMICALL */
#endif /* */
#if defined(__SASC) || defined(__STORM__)
#ifndef __CLIB_PRAGMA_TAGCALL
#define __CLIB_PRAGMA_TAGCALL
#endif /* __CLIB_PRAGMA_TAGCALL */
#endif /* __MAXON__, __STORM__ or AZTEC_C */
#ifdef __CLIB_PRAGMA_LIBCALL
  #pragma libcall BitMapBase BITMAP_GetClass 1e 00
#endif /* __CLIB_PRAGMA_LIBCALL */
#ifdef __CLIB_PRAGMA_AMICALL
  #pragma amicall(BitMapBase, 0x1e, BITMAP_GetClass())
#endif /* __CLIB_PRAGMA_AMICALL */
// From reaction/reaction.h
#ifndef REACTION_Dummy
#define REACTION_Dummy (TAG_USER + 0x5000000)
#endif
// From images/bitmap.h
#define BITMAP_Dummy     (REACTION_Dummy + 0x19000)
#define BITMAP_SourceFile        (BITMAP_Dummy + 1)
    /* (STRPTR) Filename of datatype object */
#define BITMAP_Screen            (BITMAP_Dummy + 2)
    /* (struct Screen *) Screen to remap the datatype image to */
#define BITMAP_Precision         (BITMAP_Dummy + 3)
    /* (ULONG) OBP_PRECISION to use in remapping */
#define BITMAP_Masking           (BITMAP_Dummy + 4)
    /* (BOOL) Mask image */

Let me know if it asks for anything else...

I assume you are using OS3.9 includes?

It says in each of the include files:

Includes release 44.1.

What OS version does that correspond to?

I'm using OS 3.X which is version 45 from the About... requester.
So I'm guessing version 44 is OS 3.9...

I was thinking that I should include the full real files, in case u or sum1 else wants to add other fancy BOOPSI code in the future?

Or will including the full files not work? (because then they will include MORE files that I don't have?)

At the moment the only advantage is to let you quickly (hopefully) see how much nicer it looks when the amiticks are backless.  It still doesn't solve things for earlier OS users.

Though, you could do what you were talking about and only have backless amiticks if the user is using OS 3.9 or later otherwise the user is stuck with black backed amiticks in their menus.

Ultimately I think the best thing will be to write a custom class.
But to be honest I don't know how to do this with the graphics system.
I wish I knew how the bitmap.image class was written to do this.
I've looked at the various drawing routines - Intution, Graphics Library, GELs system - and I can't see how it needs to be done.

So for the present if Images/bitmap.image is not openable as a library then maybe it is just a case of using the old approach and if it does open then those users can enjoy the nicer looking backless amiticks in their menus.

The OS 3.9 shouldn't otherwise be necessary for my menu system except for providing backless icons at the moment.  BOOPSI has been available since OS 2.0 and it is mainly that that I need.  If I can work out how to do backless icons then OS 3.9 won't be necessary at all.

Now when I quit the game I get a big flashing yellow box:
RECOVERABLE ALERT 0100 0008

Why am I getting that? All I did was create and then dispose of pCheckMark

hmmm now I can't reproduce the alert.  Geez just cause I am using 18 year old hw, that's no excuse for spurious errors 8D

  pCheckImage = NewObject(BITMAP_GetClass()
    ,NULL
    ,BITMAP_SourceFile,"Gadgets/English/CheckmarkForMenus.iff"
    // ,BITMAP_Precision,PRECISION_EXACT
    ,BITMAP_Screen,pScreen
    ,BITMAP_Masking,TRUE
    ,TAG_DONE); 

I have another solution that I'll work up for you.
It will use the BltMaskBitMapRastPort() function to draw the image.
Then it will be available to your OS 3.0 users as well.

I've already written planepick.image and I'll adapt it to your needs.

Would you prefer it to take a bitmap or an image structure as its source?
My preference is a bitmap but its up to you.

The main visible difference using my solution and the Reaction solution would be that you would have to load the amitick data yourself with my solution, which you do already anyway.

Apart from that it wouldn't be any different.

I could probably invest time in writing the loading aspect as well but not at the moment.

Also, I'm not completely happy with my solution because it entails having an extra plane or two if there are planeoffs & or planeons.  Which to me is wasted memory.  This is so that the Blt functions will work correctly.  I would like to know how the reaction class "Bitmap.image" implements its data and drawing.

If you are happy with the Reaction way I am happy too.
As you said you can check whether it is there at run time or go the old way if it's not.

I don't use Reaction at the moment so I can't say if it is leaky.
My menu system has a leak somewhere itself.
A case of doing too many additions without taking note of when the leak began unfortunately.
I think it began relatively early and has remained fairly much how big it was and still is.
Just one of the things on the list to squash one day!

For the moment - with you testing the Reaction way - I will go back to exploring further how the application will access my menu system.
I was thinking that it might be even cooler if the toggle ticks were your amiticks and the option ticks were boing balls.