- Sometimes when I run a few AMarquee sessions and then run 
  "Amiga System Probe" to check the state of the system out,
  the ASP window never opens, I can no longer use ARexx or
  open or close windows.  This may be a bug in AMarquee, or
  in ASP, I'm not sure.

- Despite the data-truncation facilities provided by
  the maxBytes arguments in various functions, evil people
  could still flood your data path, either by sending you
  lots of little messages or by sending messages with very
  long pathNames...

- An apparent bug in AmiTCP3.0b2 can cause the AMarquee daemon
  program to emit the following Enforce hits if it is transmitting
  a packet when the client closes the connection.  Miami does not 
  have this problem, and later versions of AmiTCP have not been
  tested.  The Enforcer hits look like:
                
   LONG-READ from 0000001C                        PC: 07BFA0E4
   USP:  07D9EE78 SR: 0000 SW: 0749  (U0)(-)(-)  TCB: 07D97198
   Name: "AMarquee [127.0.0.1]"  CLI: " "  
   BYTE-READ from 0000001B                        PC: 07BFA12A
   USP:  07D9EE78 SR: 0000 SW: 0751  (U0)(-)(-)  TCB: 07D97198
   Name: "AMarquee [127.0.0.1]"  CLI: " "  
   BYTE-WRITE to  0000001B        data=04         PC: 07BFA130
   USP:  07D9EE78 SR: 0004 SW: 0711  (U0)(-)(-)  TCB: 07D97198
   Name: "AMarquee [127.0.0.1]"  CLI: " "     

- AMarquee's "program name" based access control is insecure,
  since any program can log in with any login name.  (And, if
  the evil hackers are smart enough to be able to do packet
  hostname spoofing, than the "host name" based access control 
  becomes insecure too)  Since AMarqueed never reads from
  or writes to disk, and does sanity checks on the input 
  from TCP clients, this isn't quite as bad as it sounds...
  
- QNewServerSession() won't work with the inet225 version of
  amarquee.library.

- Support for INET225 was dropped from version 50 of amarquee.library.