

       #11000-#GEM Bug List                                     Page -1-
 
 
 
      #: 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.
 
 
 
 
       #11000-#GEM Bug List                                     Page -1-
 
 
 
 
       #11000-#GEM Bug List                                     Page -2-
 
 
 
      #: 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)?
 
 
 
       #11000-#GEM Bug List                                     Page -2-
 
 
 
 
       #11000-#GEM Bug List                                     Page -3-
 
 
 
      #: 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!
 
      Anker
 
 
      #: 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().
 
      Anker
 
 
      #: 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.  -
 Alan
 
 
      #: 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 cataloged in my system
 have  disappeared  over time as various upgrades in software etc have occurred
 
 
 
       #11000-#GEM Bug List                                     Page -3-
 
 
 
 
       #11000-#GEM Bug List                                     Page -4-
 
 
 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".  - Corey
 
 
      #: 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!
 
      Ozzie Boeshans 73157,2672
 
 
      #: 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.
 
 
 Don
 
      #: 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
 
 
 
       #11000-#GEM Bug List                                     Page -4-
 
 
 
 
       #11000-#GEM Bug List                                     Page -5-
 
 
 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 reenter the first
 button  it  no  longer  goes  reverse  video.  This really has me frustrated.
 Thanks for any help that is given.
 
      Ozzie Boeshans 73157,2672
 
 
      #: 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
 
 
 
       #11000-#GEM Bug List                                     Page -5-
 
 
 
 
       #11000-#GEM Bug List                                     Page -6-
 
 
 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, b 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 go 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.
 
      Ric Clayton [73317,1350]
 
 
      #: 11196 S2/GEM Support 08-Sep-86 12:30:21
 
 
 
       #11000-#GEM Bug List                                     Page -6-
 
 
 
 
       #11000-#GEM Bug List                                     Page -7-
 
 
 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.
 
      << jim >>
 
 
      #: 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.
 
      -Tom
 
 
      #: 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
 
 
 
       #11000-#GEM Bug List                                     Page -7-
 
 
 
 
       #11000-#GEM Bug List                                     Page -8-
 
 
 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 an 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.
 
      Mark
 
 
 
       #11000-#GEM Bug List                                     Page -8-
 
 
 
 
       #11000-#GEM Bug List                                     Page -9-
 
 
 
      #: 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, he really gets strange.
 
      - Rich
 
 
      #: 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
 
 
 
       #11000-#GEM Bug List                                     Page -9-
 
 
 
 
       #11000-#GEM Bug List                                     Page -10-
 
 
 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
 
 
 
       #11000-#GEM Bug List                                     Page -10-
 
 
 
 
       #11000-#GEM Bug List                                     Page -11-
 
 
 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
 
 
 
 
       #11000-#GEM Bug List                                     Page -11-
 
 
 
 
       #11000-#GEM Bug List                                     Page -12-
 
 
 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.
 
      Mark
 
 
      #: 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 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,
 
      Tom Jeffries
 
 
      #: 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.
 
 
 
 
       #11000-#GEM Bug List                                     Page -12-
 
 
 
 
       #11000-#GEM Bug List                                     Page -13-
 
 
 
      #: 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  thats  where  you  were  going  to put the
 compiled list of bugs) If its 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 you 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.
 
      -Tom
 
 
      #: 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
 
 
 
       #11000-#GEM Bug List                                     Page -13-
 
 
 
 
       #11000-#GEM Bug List                                     Page -14-
 
 
 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 thee 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 ]
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
       #11000-#GEM Bug List                                     Page -14-

