

                             #11000-#GEM Bug List

      #: 11020 S2/GEM Support 04-Sep-86 01:13:17

    Fm: Tom Jeffries 73717,2261       To: SYSOP*Dave Groves 76703,4223
      Here's a bug for which I still  need a solution.  GEM does not always
    seem to report the release of a mouse button.  I've tried evnt_multi(),
    vq_mouse(), a  routine  that  steals  the  mouse  interrupt  and checks
    the buttons before handing   things   back   to  GEM,  and  a few other
    things and  in  all  instances  the  status   returned   is  not always
    correct.  It is correct if you move the mouse, which  leads me to think
    that the mouse packet doesn't always get sent (which, of  course, would
    not be a GEM bug).  John Feagans at  Atari said they were not aware  of
    this  problem;  however,  several  other  developers  on  the Atari BBS
    reported the same thing.   It  happens  on  the  Desktop sometimes: you
    click on an option  but  nothing   happens  until  you  move the mouse.
    I hope someone has solved this one.

      #: 11023 S2/GEM Support 04-Sep-86 01:21:46

     Fm: Tom Jeffries 73717,2261       To: SYSOP*Dave Groves 76703,4223
      Evnt_timer()  doesn't  always  happen.   I've never tried to find out
    any details,  but  sometimes   you   just  don't  get a noticeable time
    delay when you call the function.

      #: 11041 S2/GEM Support 04-Sep-86 03:39:23

     Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
      We've  run into several symptoms that  appear to be manifestations of
    this (mouse  state  change   not   being   reported back properly).  In
    particular, we discovered  that   vq_mouse   often  reports  an out-of-
    date error status,  while  evnt_multi   and  evnt_mkstate  "go into the
    tank" for a noticeable  time  (approx.  1-2   seconds,  perhaps  a  bit
    less)  before  returning correct status.   This  applies  even when the
    "number of clicks" parameter is set  to  one (not looking for  multiple
    clicks), and even if the mouse is  instantly moved outside of the mouse
    click dither range.  We reported the latter to DRI at their GEM seminar
    in  April  of 1985, but the problem  still exists in version 1.2 of IBM
    PC GEM, as well as on the ST.  -- Corey

      #: 11048 S2/GEM Support 04-Sep-86 10:37:13

     Fm: Quack Computer Co.,NM 75426,3451 To: SYSOP*Dave Groves 76703,4223
      A  GEM bug :  If  a  virtual  floppy  disk  is installed after system
    start-up, the   system   bombs   when   required  to  do  virtual  disk
    swapping.  Disk swapping works fine  if  the  floppies are installed on
    start-up, though.

      #: 11053 S2/GEM Support 04-Sep-86 12:59:39

     Fm: Dan Moore 74035,243       To: Tom Jeffries 73717,2261
      I can confirm the mouse packet DOES get sent since I have played with
    the packet  handler.   I  think  the  "missed" release is in GEM or the
    GEM packet handler.

      #: 11075 S2/GEM Support 04-Sep-86 23:06:47

     Fm: Tom Jeffries 73717,2261       To: Dan Moore 74035,243
      Very  interesting.  That  means  it  would  be  worth  writing my own
    interrupt routine and avoiding GEM.   I've  been  holding off because I
    thought it might be in the hardware.  Thanks! Tom Jeffries

      #: 11041 S2/GEM Support 04-Sep-86 03:39:23

     Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
      We've  run into several symptoms that  appear to be manifestations of
    this (mouse  state  change   not   being   reported back properly).  In
    particular, we discovered  that   vq_mouse   often  reports  an out-of-
    date error status,  while  evnt_multi   and  evnt_mkstate  "go into the
    tank" for a noticeable  time  (approx.  1-2   seconds,  perhaps  a  bit
    less)  before  returning correct status.   This  applies  even when the
    "number of clicks" parameter is set  to  one (not looking for  multiple
    clicks), and even if the mouse is  instantly moved outside of the mouse
    click dither range.  We reported the latter to DRI at their GEM seminar
    in  April  of 1985, but the problem  still exists in version 1.2 of IBM
    PC GEM, as well as on the ST.  -- Corey

      #: 11073 S2/GEM Support 04-Sep-86 23:04:18

     Fm: Tom Jeffries 73717,2261       To: Corey Cole 76224,66
      Thanks, Corey.  If you ever find  a  solution  please let me know.  I
    have a situation  where  I'd   like   some   text  to keep scrolling as
    long as the mouse button  is   held   down   in a certain location, but
    because of this bug it will  sometimes  keep scrolling after the button
    is released.  Not good.  Tom

      #: 11068 S2/GEM Support 04-Sep-86 22:36:34

     Fm: Christopher F.  Chabris 73277,305 To: SYSOP*Dave Groves 76703,4223
      Just to put in my two cents worth: I suggested to Tim Oren a few days
    ago that  the  compendium  that we  are now compiling include all types
    of ST bugs, not just GEM ones.   Accordingly, I suggest that the GEMDOS
    bugs that have been  responsibly   documented   by  Atari in the GEMDOS
    spec in DL7 be  included  here  for   the   benefit  of  non-registered
    developers who do not have access  to  the manual.  Each function given
    there has a list of zero or more  known bugs which should be put in the
    list.-- Chris Chabris

      #: 11061 S2/GEM Support 04-Sep-86 20:34:09

     Fm: Mark McCulley 72337,3500       To: Tim Oren
      I  seem  to  remember  some   discussion   here   a  while back about
    nested event_multi()  problems  and   problems  that  can  occur if the
    message buffer is  not   cleared.    I   don't   remember   if  the two
    problems  were  related.   Anybody   remember   the   essence  of  that
    discussion?

      What happens if you just ignore messages (assuming the event_multi is
    NOT waiting on a message)?

      #: 11063 S2/GEM Support 04-Sep-86 21:29:34

     Fm: Tim Oren 76703,202       To: CHUCK WALBOURN 73537,527
      Chuck, first of all I don't  have  anything  to do with RCS any more,
    having left  DRI over a year ago.  As to Pascal, version 2.0 which will
    EVENTUALLY be released   by   DRI/Atari  does  have  hooks  for Pascal,
    Fortran, and BASIC.  I put them   in  before  I  left.   Unknown  trees
    are mainly  used  when  a  resource  is  opened   and  there  isn't any
    definition file - then you retype them  to whatever you  want.  Or, you
    can make a tree an UNKNOWN if you  want  to leave a reminder that it is
    odd in some way, and shouldn't normally be altered.  - Tim

      #: 11105 S2/GEM Support 05-Sep-86 20:21:54

     Fm: Anker Berg-Sonne 72337,3211       To: SYSOP*Dave Groves 76703,4223
      I  have  been  battling a  really  weird  problem  in EAS and VDI for
    quite a while.   First  the  scenario.  I'm writing an editor that used
    GEM windows to look  into  several disk files and use v_text() to write
    the text.  Everything  works   just  fine  until  I  resize  the window
    manually with the mouse.   If  I  make  the   window  smaller  on  both
    axes text doesn't appear in the  box  until  I do another  resize  that
    makes one of  the  axes  larger!  Clearly  there's  a  solution  to the
    problem, since 1stword can handle that case.  I have tried all kinds of
    tricks,  but   to   no   avail.    The   problem   is   easy  enough to
    reproduce with apskel.c  by inserting a  call  to v_text in the routine
    that does the painting. I'm at my wit's end HHHHEEEEELLLLLLPPPPP!

      #: 11106 S2/GEM Support 05-Sep-86 20:24:35

     Fm: Anker Berg-Sonne 72337,3211       To: Anker Berg-Sonne 72337,3211
     Of course I meant v_gtext() where I wrote v_text().

      #: 11113 S2/GEM Support 05-Sep-86 23:34:54

     Fm: Alan Page 72227,3507       To: Anker Berg-Sonne 72337,3211
      GEM  doesn't seem to send  redraw  messages  if  you shrink a window,
    just if you  enlarge  it.   My  solution  was  to check the size change
    when I get  the  WM_SIZED   message,   and   if  neither  axis is being
    increased then send  myself  a  redraw   message   as   in  Tim  Oren's
    self_redraw code in the GEM tutorials.

      #: 11111 S2/GEM Support 05-Sep-86 22:47:28

     Fm: NEIL R LINCOLN 73267,2265       To: Tim Oren 76703,202
      An  obvious  but  maybe  gentle  reminder.  Before submitting bugs to
    the compendium it would be helpful  for  contributors to check that the
    'bugs' still exist  in the  current  environments.   "Bugs" that I have
    catalogued in  my  system  have   disappeared   over  time  as  various
    upgrades in software etc have  occurred here.   Unfortunately  my  aged
    memory  plays  tricks on me and  I  find myself avoiding nonexistent or
    antiquated pitfalls.

      #: 11116 S2/GEM Support 06-Sep-86 00:16:28

     Fm: Corey Cole 76224,66       To: Tom Jeffries 73717,2261
      We have  a  kludgey  solution  --  depending  on  one  of  our  state
    variables,  we  either    use   vq_mouse   or   graf_mkstate  (the  AES
    equivalent).  I have no idea why vq_mouse  works  at some times and not
    at others, which makes me very nervous! Fortunately,  at  least so far,
    the situations in which vq_mouse can't be used are  also those in which
    response time is not critical.   You  should stick with graf_mkstate if
    you can handle the slow "feel".

      #: 11108 S0/General 05-Sep-86 20:25:17

     Fm: OZZIE BOESHANS 73157,2672       To: [F0] SYSOP 76703,2010
      If  I  have a dialog  box  with  a  button  in  it  and the button is
    defined as an  EXIT  button  but  not selectable, should pointing at it
    and clicking cause form_do to want to be able to have a big button that
    I can click on and exit  from   form_do  but  I don't want it turned to
    reverse video when it is selected. I  have found that unless the button
    is defined as EXIT and  SELECTABLE  form_do  does   not  exit  when the
    button it clicked.  Any ideas? Thanks in advance for any help!

      #: 11120 S2/GEM Support 06-Sep-86 03:27:52

     Fm: Don Curtis 76703,4321       To: SYSOP*Dave Groves 76703,4223
      Dave, evnt_button(etc....)  locks  you  in  never-never land IF while
    waiting for the  button  event,  you  move  the  mouse  into  the  menu
    bar.   There is a work-around,   you  do  an evnt_multi(etc...) looking
    for both the button event AND   the   timer  event with a time value of
    1ms.  The C code for the workaround goes like this:

      while(evnt_multi(MU_BUTTON | MU_TIMER, .etc...) == MU_TIMER);

      As  you can see, you will only  exit this routine when the button has
    been pressed.  Moving into the  menu  bar  will  not lock you with this
    work-around.

      #: 11121 S2/GEM Support 06-Sep-86 05:07:00

     Fm: Dan Rhea 71777,2337       To: SYSOP*Dave Groves 76703,4223
      Well  here's  one that has bothered me  for a long time though it may
    be a feature  rather  than  a  bug.    When  using a file selector box,
    and you have selected a file at the  bottom of the list (the slider has
    been moved down from the  top).  You  select  the file and all is well.
    Now you call up the selector again  but  this time you are sent back to
    the top of the selector and  need  to  go  searching for where you left
    off.  Is it possible for a  selector  box (even optionally), to be able
    to remember its previous state.  Dan Rhea, 71777,2337

      #: 11128 S2/GEM Support 06-Sep-86 12:30:24

     Fm: Stephen Mehalek 73277,2557       To: SYSOP*Dave Groves 76703,4223
      The  modulus  operator that comes  with VDIBIND library is incorrect.
    The lrem.o object module  contains  144  bytes  and produces results of
    zero when it is used  to   give   the  remainder of long integers.  The
    fix is to take the lrem.o  module   from  the GEMLIB object modules and
    move it to the VDIBIND libraries. Use  the  AR^ AR68 utility routine to
    do this.  This bug  is  not  a  GEM  bug,  but  most  people owning the
    developers package should know about this.

      #: 11137 S2/GEM Support 06-Sep-86 18:30:21

     Fm: OZZIE BOESHANS 73157,2672       To: 76703,4224
      Is there any way to keep a button  in a DIALOG box from going reverse
    video when it is selected? Also,  is  there   a way to set the state of
    the mouse buttons.  I have an  application  that for some reason thinks
    the button is still down after a press and release sometimes.  Pressing
    and releasing the button clears the  condition.  What happens is that I
    select an option that causes a  dialog  box  to  appear and once  in  a
    while when I move the  mouse  to  a  button  the button becomes reverse
    video  before  I  even  click.  If I move to a different button the new
    button doesn't  turn  reverse  video but  if  I go back to the original
    it goes reverse video.   If  I  click  anywhere  else on the screen and
    then re-enter the first button   it   no  longer  goes  reverse  video.
    This really has me frustrated. Thanks for any help that is given.

      #: 11166 S2/GEM Support 07-Sep-86 21:01:48

     Fm: David Beckemeyer 74236,625       To: Corey Cole 76224,66
      I've  noticed  that the lines between  when  you should (can) use VDI
    calls and  when to  use  AES  are  somewhat  fuzzy.  Is this documented
    anywhere that you know of?

      #: 11173 S2/GEM Support 07-Sep-86 22:32:42

     Fm: Corey Cole 76224,66       To: David Beckemeyer 74236,625
      I  don't  know of any  documentation  on  [when  to  use VDI vs.  AES
    calls]. In  general,  any display  operation can use either/both, while
    input should be restricted to one or  the  other (if the AES is used at
    all, your program should  only   do   input   with   AES  calls).   The
    catch is that AES is frequently  less efficient than VDI, sometimes (as
    with graf_mkstate) by major amounts.

      #: 11167 S0/General 07-Sep-86 21:13:31

     Fm: David Beckemeyer 74236,625       To: Ric Clayton 73317,1350
      Ric,  assuming   there  isn't  a  simpler,  plain  old  bug,  in your
    program, it looks  like   you  may  be  running  up against the classic
    GEMDOS getting confused bug.  I   have   seen   this   sort of problem,
    (GEMDOS unable to open, or create a file for no apparent reason), and I
    have traced it some internal data  structure handling  bugs  in GEMDOS.
    It seems than GEMDOS keeps a  copy  of  the directory tree structure of
    each disk, and as you access directories continually adds to this  data
    structure.   The  idea is  to  make  file  accesses  faster by avoiding
    reading each directory in the tree  of  a  file spec whenever a file is
    accessed.

      So far so good, but under some circumstances, which seem to relate to
    the number  of  directories accessed  (across  all drives), and I think
    also related to  floppy disk  media  changes, this internal GEMDOS data
    structure gets messed up,  and   GEMDOS  doesn't  know where to put the
    next link in its structure, and goes out to lunch forever.

      I don't know the whole solution to this problem, but I have been able
    to reduce  its  frequency   by   making  an  undocumented  BIOS call at
    certain times, which  seems  to  force   GEMDOS  to  free some internal
    memory.  I found it by catching the desktop making BIOS calls.  I don't
    have the code in front of  me,  but   maybe  John Feagans @ Atari could
    help? If not, I'll look it up and leave you a message.  - david

      #: 11026 S0/General 04-Sep-86 01:31:42

     Fm: Ric Clayton 73317,1350       To: All
      Hi there, I have written a program  to backup files from my hard disk
    to a floppy  disk  and  have  run  into   a problem I can't seem to get
    around.  The program  is rather  simple;  it  just  copies files from a
    source directory to the same  directory   on a designated floppy drive,
    creating directories as  needed,  using  GEMDOS  calls.  Nothing fancy,
    just regular DOS type file copies.  So the program goes chugging alone,
    happily copying files and all of  a  sudden  gets an "file  not  found"
    error  (-33)  when  it  tries   to  open  the  Source file for reading,
    the  name  of  which  it  just  got  from  a directory scan! After this
    occurs,  GEMDOS  seems  to  be   completely   dorked and strange things
    start to happen,  requiring  a   re-boot   to   restore it to normalcy.
    It doesn't always happen,  and   when  it  does  it's not always in the
    same place.  Sometimes I can get  through a whole 5MB partition with no
    mishap.  Sometimes I can't even  get  through   the   files in the root
    directory.  I have gone over  and  over  the  code  and  can't find any
    error that would cause this.  However, I'm  new to both the ST  and 'C'
    programming environments and may have  made  some false assumptions, so
    I'm  asking  for any help I  can  get.   I  would be glad to upload the
    source code  if  anyone  would   like  to  give  it the once over.  The
    program doesn't use GEM,  just  gemDOS (or is it TOS?).  (I've compiled
    it with Megamax-C and Mark Williams C and get the same error.  Though I
    haven't tried Alcyon-C yet.)  Thanks in advance for your help.

      #: 11196 S2/GEM Support 08-Sep-86 12:30:21

     Fm: Jim Needhan, DRI 76703,1064       To: Corey Cole 76224,66
      I  assume  the  confusion  is with "mouse" calls and the such...  The
    AES should  always be used  rather  than  the  VDI when making mouse or
    other hardware calls.   I have heard  the  complaints about speed but I
    do not fully agree with  those   programmer's  with  the  concerns.   I
    do realize that there  is  a  speed  "hit"   but   what  is gained is a
    program that is more reliable  and  more  portable. The AES cannot keep
    track of what the VDI is doing so by going through the AES the "system"
    is aware of what is going on.

      Of  course,  you  may  write   directly  to  the  VDI and in graphics
    display calls  etc, it is the  correct  path, but, for windowing, mouse
    control, etc. it is better from the DRI point of view to go through the
    AES.

      Portability?  There  will  be  GEM  available for other environments,
    and announcements   will   be   made  as  appropriate,  so  don't  lock
    yourself out if it isn't necessary.

      #: 11219 S2/GEM Support 08-Sep-86 22:13:27

     Fm: SYSOP*Tom Hudson 76703,4224       To: Jim Needhan, DRI 76703,1064
      Right  you  are,  Jim.  The VDI mouse routines are great because they
    are not  affected  by  the  DCLICK  speed  setting, but the system goes
    "HUH?" if you  try   to  intermix  the  VDI  and  AES  mouse calls.  My
    solution: if  you  are  doing  a  mouse   operation   that   won't   be
    declicked,  before the mouse  is  used  set  the  dclick  speed  to its
    fastest speed and restore it afterwards.  Thanks for the help.

      Oh,  do  you  guys  have   any   information   on writing custom GDOS
    device drivers  (like printers and  custom  screen devices)? If so, I'd
    like to get the info if I may.  I'd appreciate it.

      #: 11248 S2/GEM Support 09-Sep-86 01:10:50

     Fm: Corey Cole 76224,66       To: Jim Needhan, DRI 76703,1064
      Jim,  I guess  I  didn't  make  myself  totally  clear.   When  I was
    complaining about  "speed  hits"  when using the AES to read the mouse,
    I didn't  just  mean  response   delays   (although   those   are   bad
    enough).  We're talking actually  failing  to  recognize  events -- for
    example, if the user presses the left mouse button  in  an  application
    using  graf_mkstate,  the application will not be notified  unless  the
    button  remains  depressed  for  a  sizable  fraction  of a second.   I
    believe  the  same is true with  evnt_multi.  This behavior can be seen
    in  many  GEM  applications (Megamax  editor,  DEGAS, etc.) -- user has
    to hold  down  the  button for about  a  second to get a new cursor (or
    whatever). Highlighting (in FLASH,  megamax  editor,  my word processor
    until I went over to  vq_mouse,   etc.)   also  "feels"  jerky  to  the
    user because the program isn't immediately notified.

      At  the  GEM  seminar last year, I  was told that evnt_multi does not
    wait the  double-click  time  if  the   mouse   moves more than a pixel
    or two.  This simply  doesn't  seem   to   be  the case (it should be),
    in my observation.  In general,  mouse  events  have a "clunky" feel to
    the user, which tends to hurt the  "feel"  of  the  entire application.
    Sorry to drag this  into  the  ground,  just  not  sure how clearly I'm
    stating this! -- Corey

      #: 11252 S2/GEM Support 09-Sep-86 03:23:11

     Fm: Alan Page 72227,3507       To: Corey Cole 76224,66
      I  agree  with  you about  the  slowness  of evnt_multi in picking up
    button clicks.   Flash   1.1  uses  a  complicated  kludge  involving a
    mixture of  vq_mouse  and   ev_mmobutton   which  gives  it _immediate_
    response for cursor positioning. - Alan

      #: 11203 S2/GEM Support 08-Sep-86 13:18:40

     Fm: Mark Skapinker (BI) 76703,207  To: SYSOP*Dave Groves 76703,4223
      Here are a few 'goodies' we know about:

      First some bugs:

      -If  you  use  a regular "form_do" in  a desk accessory, you may find
    that your keys 'fall through'  to  the  application,  so be prepared to
    write your own. Falling  through   means   that   if   you  have a desk
    accessory on top of a word  processor  for example, keys pressed during
    a form in the desk accessory would  be  picked  up and used by the word
    processor.

      -Evnt_timer   is   a   very  dangerous  call  to  make  from  a  desk
    accessory; it sometimes   causes   the  entire  program  to  freeze up.
    Regarding timers see the following message from Chris.

      - The system exception  handler  has  some  bugs.  (See the following
    message from Chris)

      -Appl_play and record do not work without a ROM patch from Atari.

      -Alcyon  Compiler  problems.    Appl_init   returns  the  wrong value
    (always returns 1).

      -The  documentation  for  Vex_motv  is  wrong - it requires a jump to
    the saved address to update the driver.

     Some things to remember:
      -Before  doing an fsel_input call, and  before any I/O, make sure you
    have set  path  names  (A:  is  not good enough, it must be A:\), or be
    ready for a freeze.

      -Form_alert strings can only be about 30 characters per line.

      -You   should  modify   the   source   of   form_do  (form_keybd)  to
    change underscores to dashes; underscores blows your application out of
    the water.

      #: 11204 S2/GEM Support 08-Sep-86 13:20:55

     Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223
      There are 2 serious  bugs  related  to  desk  accessories.  Both were
    reported to Atari months ago.

     1.  EVNT_TIMER is flaky.  The timer  event will not always return when
    called. This  seems  to  happen   most  often  when there is heavy disk
    activity, but not always.   If   you  do  an evnt_multi() with messages
    and timers, the timers will eventually   hang  up, but if the accessory
    receives a message, the timers  start  working  again  (for  a  while).
    We  call  this  burping  the   timer.    As  a programmer,  this  means
    that  you  must  find  an alternate way of releasing control  (it isn't
    easy).  That's why some desk accessories degrade the system performance
    so  much.   This  bug  has been ported from the IBM PC version of GEM.

     2.   The  system  exception  handler   has  one  or  more bugs.  If an
    application generates   a   system   alert   (drive   not   responding,
    insert your new A: disk, etc.),   any  desk  accessory  that is running
    is not stopped.   That  is,  if  you  have  an  accessory buzzing along
    waiting for evnt_timers  (which  you  shouldn't),  or   mouse  movement
    events (actually any evnt_ function has this problem), the multitasking
    of  the  desk   accessories   is  not  turned  off  while  the alert is
    presented.   I   checked  this  out  with  an  accessory  that  woke up
    constantly and wrote  a   counter   to   the   screen.   As soon as the
    alert is cleared, the desk accessory,   then  the  application bomb.  I
    suspect it's because the accessory  gets  running  in  supervisor  mode
    and messes up the  super  stack  or  something  like  that.   The  same
    thing can happen in a one drive system in another way (this is probably
    a separate bug).  If the desk  accessory  reads from drive B:, and  the
    system  alert  is  generated  to   swap  diskettes,  after the alert is
    cleared  first  the  desk  accessory  then  the  application will bomb.
    We've even seen it  bomb  the  GEM  Desktop.--  Chris Bailey (Batteries
    Included)

      #: 11232 S2/GEM Support 08-Sep-86 23:33:36

     Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223
      You  want  bugs,  use  the  file   selector.   It  is one of the most
    flawed things  in  the  system.  You can crash it two ways, put the '_'
    in the path. Or,  you can just leave  a disk out and wait two times for
    it to give the abort  continue   error,   after that booomb! Also, when
    you have a single drive system and you  try to treat drive b as disk b,
    it really gets strange.

      #: 11267 S2/GEM Support 09-Sep-86 11:39:02

     Fm: Ken Settle 76556,753       To: SYSOP*Dave Groves 76703,4223
      I  have  noticed  the  following   bugs  in  GEM: Bug series #1: (AES
    object library section)

      In   the   TEDINFO   structure,   te_pvalid   field,   the  following
    validation characters  DO  NOT work properly: 9, A, a, N, n, P, p, (all
    except F and X). The  bug  occurs  when  a  form_dial is called with an
    object containing any of the above  characters in the PVALID field.  If
    the user types an underscore  "_"  on any  character  position  (except
    the last), the system  promptly  "bombs"  out.  The   bug  with the "F"
    character in that situation was fixed in  ROM TOS and the "X" character
    never had this problem (to my knowledge).

      Also  in  the  TEDINFO structure,  the te_txtlen and te_tmplen fields
    both  contain    the    length+1    of    their   respective   strings,
    contrary  to  the documentation.

      Bug series #2: (GEMDOS section)

      Hard disk file WRITE  time  increases  by  roughly  1 second for each
    megabyte stored  on  that   drive   (partition,   whatever).   This  is
    probably  due  to unspeakably slow FAT  search code (it takes about 450
    times as long as it would using two simple 68000 instructions to search
    a FAT sector).

      Dfree() command takes "next to forever" on the hard drive.

      It  is  somehow  possible  to   get   a   folder   (on the hard disk)
    that is impossible to delete,  even  though  it's  empty.  - Ken Settle
    [76556,753]

      #: 11268 S2/GEM Support 09-Sep-86 11:42:38

     Fm: Ken Settle 76556,753       To: Ken Settle 76556,753
      Bug series #3: (GEM Desktop section)

      SOMETIMES  when  you close  a  directory  window  and re-open it from
    another drive,  the  window decides to  exactly cover up the top window
    on the screen. This  has  been   a   major   annoyance causing me to be
    paranoid about closing a directory window.   It seems to be very random
    (as all truly good bugs are).

      Changing  resolution  and/or  colors can  really screw up the desktop
    when you  return  to   it.   It  should  be Desktop's responsibility to
    make sure these conform   to   the   current  defaults.  Desktop should
    also automatically set ALL  DESKTOP.INF   defaults   on   power up, and
    allow ANY application or  accessory  to  have  access  to/modify  these
    defaults  (palette,  key  rate, RS232/Printer setup).

      Desktop  should  be hardy  enough  to  survive  a "close workstation"
    call  by  an   application,   without   losing  it's  "pull-down  menu"
    capability.  This might allow  VDI  to   be   used in any resolution as
    dictated by the application, not desktop.

      It  should  be  possible  to  abort  a  multiple-file  COPY or DELETE
    operation at any time using the mouse and/or keyboard.

      Bug series #4: ("TOS" section)

      An error box stating "TOS  ERROR  #35"  means nothing to most people,
    what's the real message?

      Bug series #5: (AES/VDI section)

      The  dot-pattern  in  the  move  bar  of  a window can get screwed up
    by a redraw  attempt   such  as  after  a  dialog  has disappeared.  It
    appears to happen because  of   the   "blit"   feature  being  used  to
    move  a  window to any  odd  line/pixel   where  VDI  can't  accurately
    match up the pattern.  - Ken Settle [76556,753]

      #: 11307 S2/GEM Support 10-Sep-86 00:26:44

     Fm: Dan Rhea 71777,2337       To: SYSOP*Dave Groves 76703,4223
      Here  is  another interesting  one  I've  stumbled  on.   It is not a
    "GEM" bug but  a  bug  in the  C Runtime (GEMLIB), or the AS68.PRG step
    of the latest and greatest  compiler.    This  has been driving me nuts
    till I finally isolated it to the  following test case.  The test works
    fine with the old compiler/runtime but   gives  bad results for the new
    one (i.e.  every other long has a value of 0).

    main()

      {

      long int a, b, c, d; int i; a = b = c = d = 0L;

      for (i=0; i<25; i++)

      { a++; b++; c++; d++;

      printf ("a=%D b=%D c=%D d=%D\n",a,b,c,d);

      }

      Cconin (); /* Wait for any character */

      }


     Good Results: a=1 b=1 c=1 d=1
      a=2 b=2 c=2 d=3

      ...

      a=25 b=25 c=25 d=25

      Bad Results a=1 b=0 c=1 d=0

      a=2 b=0 c=2 d=0

      ...

      a=25 b=0 c=25 d=0


     Note:  I  included OSBIND.H in the  above program too.  Has anyone hit
    this one yet  or  devised  a  workaround  (other than floating point or
    the obvious two longs for each one used).  Dan Rhea, 71777,2337

      #: 11314 S2/GEM Support 10-Sep-86 09:38:33

     Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223
      Dave,  As the GEM DESKTOP is  simply  a  'program' , I think its bugs
    should be kept separate.

      #: 11310 S2/GEM Support 10-Sep-86 00:43:55

     Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223
      Nope, the only way around them  is  to  write your own file selector.
    Atari will  someday weed the bugs out(hopefully).  It is a shame that a
    solid program can  be  crashed by it.   It looks like the authors fault
    to everyone else, but the blame is the operating systems.  The one that
    gets me the most is when you forget  to   put  a  disk  in or put it in
    crooked and it dies after the second retry.

      #: 11443 S2/GEM Support 12-Sep-86 00:14:24

     Fm: Tom Jeffries 73717,2261       To: Jim Needhan, DRI 76703,1064
      There's  an  old  rule of thumb- if  one  person tells you you have a
    tail, don't  bother  to  look.  If ten people tell you you have a tail,
    you'd better take  a  look  to see  what's going on.  Actually, I think
    most of us look when one  person  tells  us  we have a bug.  There is a
    whole series of  problems  with  reading   the   mouse  which  include:
    slow and inaccurate reading  of  the  mouse  buttons,  especially  from
    the  AES,  evnt_multi()  will  not read both mouse buttons  (as  far as
    I know that's not in the bug list yet, we should add it), mouse  button
    releases  are  not  always recognized,  etc.   etc.  etc.  I must admit
    I'm  getting  a  little  tired  of  DRI and Atari trying to blame these
    problems on their bad code.   Too  many  developers are having the same
    problems for it to  be  bad code.   In  an earlier note, you defend the
    slowness of evnt_multi. If  it really  were accurate, I might go along.
    However, even if that were  the  case,   it   is  hard  to  ignore  the
    fact that the Mac, which also  has  to read double  clicks,  feels much
    less clunky than the ST.   GEM,  like  all  operating systems, has some
    problems.  Actually, if  you  compare  it  with  MS-DOS,  which is much
    simpler but also has lots of  bugs,  you  guys  at DRI and the folks at
    Atari did a terrific job,  especially  considering  the time it took to
    get the machine on  the  market.   No  purpose  is  served, however, by
    trying to blame bad code for problems  that  are real and don't seem to
    be getting solved.  I don't mean  to  cause  offense- but since we have
    the benefit of having some  of  the  people  who wrote  GEM  online,  I
    would like the discussion to be at a realistic level. Thanks,

      #: 11445 S2/GEM Support 12-Sep-86 00:18:23

     Fm: Tom Jeffries 73717,2261       To: Mark Skapinker (BI) 76703,207
      One  more  bug-  despite the documentation,  you cannot read both the
    left and  the  right mouse button with one evnt_multi() call.  You have
    to use two, which  gives  you   time   to  go out for dinner before the
    mouse button event is reported, or use a different call.

      #: 11456 S2/GEM Support 12-Sep-86 16:24:52

     Fm: Michael T.  Smith 73317,3470 To: Mark Skapinker (BI) 76703,207
      OK,  I want in this  mesh  of  messages...   I just yesterday started
    writing a ml routine to be used  in the vex_motv function.  I had heard
    of some bugs in the  vq_mouse and  my  program has been slipping in the
    area of mouse handling..
     So,  the  problem occurred when  it  hits  the  vex_motv it gives me 2
    bombs and I don't know why, I haven't  looked  on Dl2 yet but I will to
    see if my problem can be   answered   there.   (I  think  that's  where
    you  were  going  to put the compiled  list  of bugs) If it's simply in
    MY ml code then I  will  eventually  find   it,   but if there is funny
    business in that routine I would like to know how  to  get  around  it.
    The only other thing  I  think  I'll  be  able  to answer myself:  Desk
    Acc's.  I know that if I get  a  message  20  then I need to redraw. Is
    that  It?  If you have any  Advice  simply  give it.  I appreciate your
    help. Thanks....  Michael T Smith Xetec Inc.  Salina Ks 73317,3470

      #: 11483 S2/GEM Support 13-Sep-86 10:55:39

     Fm: Tom Jeffries 73717,2261       To: Michael T.  Smith 73317,3470
      One  more  bug  (There's always one  more  bug),  I think this one is
    pretty well known and documented but it  can be unpleasant if you don't
    know about it: fsel_input()  resets   the  clipping  rectangle and does
    not reset it on exit. It's  easy to  work around- you just set your own
    clipping area when you regain control.

      #: 11539 S2/GEM Support 13-Sep-86 22:58:44

     Fm: Alan Page 72227,3507       To: [F7] SYSOP*Dave Groves 76703,4223
      Here's another bug for the list.   When  I use the function appl_find
    (from a  desk  accessory)  it   should   return  -1  if the application
    is not found.  However,  if  I  call  appl_find  with  the  name  of an
    application just after I exit it,  I   get  a 'valid' ID.  As soon as I
    run another application then  I  get  the  proper  -1  value  returned.
    It acts like the name of  the  application  is not erased until you run
    another application.  - Alan

      #: 11540 S2/GEM Support 14-Sep-86 01:37:43

     Fm: SYSOP*Tom Hudson 76703,4224       To: [F7] Alan Page 72227,3507
      By  golly,  Alan  --  you have the same bug as I found yesterday!!! I
    was working  on  a  desk  accessory that looked for DEGAS Elite, and it
    works fine until Elite is run.  That is, it knows it's not there before
    Elite is run, but thinks  it's  there  after Elite's done! Fortunately,
    The accessory is written so that that does  not matter, but it is a bug
    that should be reported.

      #: 11641 S2/GEM Support 16-Sep-86 08:47:54

     Fm: Michael T.  Smith 73317,3470 To: SYSOP*Russ Wetmore 76703,2010
      Russ,  Thanks  for the info..  I am using the 'asm{...}' from megamax
    for my  interrupt interrupt but also  'C'...  mint() { asm{...} }.  The
    problem now exists  that  as  soon  as  I call the vex_motv(num1,,); it
    crashes (2 bombs:Bus error)   then   returns   to  the desktop where it
    sits until I move the mouse and  then  I get 4 bombs..  (Illegal inst.)
    Currently, my int.  is only a  nop  which  leads  me  to  believe  that
    it is not  caused  by  my  int,  but  by  the  way  I  am  calling  the
    vex_motv();.  I saw something about having  to  call  , or jump to, the
    location  that the function returns to  you.   Also I noticed once that
    it executed the next 'C'  instruction  after  the vex_motv.  Go FIgure?
    Well, if any of  this  sounds  familiar  than  let  me know.  Michael T
    Smith...  Xetec Inc.

      #: 11667 S2/GEM Support 16-Sep-86 22:23:41

     Fm: SYSOP*Russ Wetmore 76703,2010 To: Michael T.  Smith 73317,3470
      There's  an example  of  calling  vex_timv  in  DL0  someplace that I
    uploaded. The  procedure  should be similar  for vex_motv if you'd like
    to look at it.  [ Russ ]
