bammi@cwruecmp.UUCP (Jwahar R. Bammi) (09/30/86)
#!/bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #!/bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# gembugs.txt
# This archive created: Tue Sep 30 02:49:50 1986
# By: Jwahar R. Bammi ()
export PATH; PATH=/bin:$PATH
echo shar: extracting "'gembugs.txt'" '(37636 characters)'
if test -f 'gembugs.txt'
then
echo shar: over-writing existing file "'gembugs.txt'"
fi
sed 's/^X//' << \SHAR_EOF > 'gembugs.txt'
X #11000-#GEM Bug List Page -1-
X
X
X
X #: 11020 S2/GEM Support 04-Sep-86 01:13:17
X
X Fm: Tom Jeffries 73717,2261 To: SYSOP*Dave Groves 76703,4223
X Here's a bug for which I still need a solution. GEM does not always seem
X to report the release of a mouse button. I've tried evnt_multi(), vq_mouse(),
X a routine that steals the mouse interrupt and checks the buttons before
X handing things back to GEM, and a few other things and in all instances the
X status returned is not always correct. It is correct if you move the mouse,
X which leads me to think that the mouse packet doesn't always get sent (which,
X of course, would not be a GEM bug). John Feagans at Atari said they were not
X aware of this problem; however, several other developers on the Atari BBS
X reported the same thing. It happens on the Desktop sometimes: you click on an
X option but nothing happens until you move the mouse. I hope someone has
X solved this one.
X
X
X #: 11023 S2/GEM Support 04-Sep-86 01:21:46
X
X Fm: Tom Jeffries 73717,2261 To: SYSOP*Dave Groves 76703,4223
X Evnt_timer() doesn't always happen. I've never tried to find out any
X details, but sometimes you just don't get a noticeable time delay when you
X call the function.
X
X
X #: 11041 S2/GEM Support 04-Sep-86 03:39:23
X
X Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261
X We've run into several symptoms that appear to be manifestations of this
X (mouse state change not being reported back properly). In particular, we
X discovered that vq_mouse often reports an out-of-date error status, while
X evnt_multi and evnt_mkstate "go into the tank" for a noticeable time (approx.
X 1-2 seconds, perhaps a bit less) before returning correct status. This
X applies even when the "number of clicks" parameter is set to one (not looking
X for multiple clicks), and even if the mouse is instantly moved outside of the
X mouse click dither range. We reported the latter to DRI at their GEM seminar
X in April of 1985, but the problem still exists in version 1.2 of IBM PC GEM,
X as well as on the ST. -- Corey
X
X
X #: 11048 S2/GEM Support 04-Sep-86 10:37:13
X
X Fm: Quack Computer Co., NM 75426,3451 To: SYSOP*Dave Groves 76703,4223
X A GEM bug : If a virtual floppy disk is installed after system start-up,
X the system bombs when required to do virtual disk swapping. Disk swapping
X works fine if the floppies are installed on start-up, though.
X
X
X #: 11053 S2/GEM Support 04-Sep-86 12:59:39
X
X Fm: Dan Moore 74035,243 To: Tom Jeffries 73717,2261
X I can confirm the mouse packet DOES get sent since I have played with the
X packet handler. I think the "missed" release is in GEM or the GEM packet
X handler.
X
X
X
X
X #11000-#GEM Bug List Page -1-
X
X
X
X
X #11000-#GEM Bug List Page -2-
X
X
X
X #: 11075 S2/GEM Support 04-Sep-86 23:06:47
X
X Fm: Tom Jeffries 73717,2261 To: Dan Moore 74035,243
X Very interesting. That means it would be worth writing my own interrupt
X routine and avoiding GEM. I've been holding off because I thought it might be
X in the hardware. Thanks! Tom Jeffries
X
X
X #: 11041 S2/GEM Support 04-Sep-86 03:39:23
X
X Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261
X We've run into several symptoms that appear to be manifestations of this
X (mouse state change not being reported back properly). In particular, we
X discovered that vq_mouse often reports an out-of-date error status, while
X evnt_multi and evnt_mkstate "go into the tank" for a noticeable time (approx.
X 1-2 seconds, perhaps a bit less) before returning correct status. This
X applies even when the "number of clicks" parameter is set to one (not looking
X for multiple clicks), and even if the mouse is instantly moved outside of the
X mouse click dither range. We reported the latter to DRI at their GEM seminar
X in April of 1985, but the problem still exists in version 1.2 of IBM PC GEM,
X as well as on the ST. -- Corey
X
X
X #: 11073 S2/GEM Support 04-Sep-86 23:04:18
X
X Fm: Tom Jeffries 73717,2261 To: Corey Cole 76224,66
X Thanks, Corey. If you ever find a solution please let me know. I have a
X situation where I'd like some text to keep scrolling as long as the mouse
X button is held down in a certain location, but because of this bug it will
X sometimes keep scrolling after the button is released. Not good. Tom
X
X
X #: 11068 S2/GEM Support 04-Sep-86 22:36:34
X
X Fm: Christopher F. Chabris 73277,305 To: SYSOP*Dave Groves 76703,4223
X Just to put in my two cents worth: I suggested to Tim Oren a few days ago
X that the compendium that we are now compiling include all types of ST bugs,
X not just GEM ones. Accordingly, I suggest that the GEMDOS bugs that have been
X responsibly documented by Atari in the GEMDOS spec. in DL7 be included here
X for the benefit of non-registered developers who do not have access to the
X manual. Each function given there has a list of zero or more known bugs which
X should be put in the list.-- Chris Chabris
X
X
X #: 11061 S2/GEM Support 04-Sep-86 20:34:09
X
X Fm: Mark McCulley 72337,3500 To: Tim Oren
X I seem to remember some discussion here a while back about nested
X event_multi() problems and problems that can occur if the message buffer is
X not cleared. I don't remember if the two problems were related. Anybody
X remember the essence of that discussion?
X
X What happens if you just ignore messages (assuming the event_multi is NOT
X waiting on a message)?
X
X
X
X #11000-#GEM Bug List Page -2-
X
X
X
X
X #11000-#GEM Bug List Page -3-
X
X
X
X #: 11063 S2/GEM Support 04-Sep-86 21:29:34
X
X Fm: Tim Oren 76703,202 To: CHUCK WALBOURN 73537,527
X Chuck, first of all I don't have anything to do with RCS any more, having
X left DRI over a year ago. As to Pascal, version 2.0 which will EVENTUALLY be
X released by DRI/Atari does have hooks for Pascal, Fortran, and BASIC. I put
X them in before I left. Unknown trees are mainly used when a resource is
X opened and there isn't any definition file - then you retype them to whatever
X you want. Or, you can make a tree an UNKNOWN if you want to leave a reminder
X that it is odd in some way, and shouldn't normally be altered. - Tim
X
X
X #: 11105 S2/GEM Support 05-Sep-86 20:21:54
X
X Fm: Anker Berg-Sonne 72337,3211 To: SYSOP*Dave Groves 76703,4223
X I have been battling a really weird problem in EAS and VDI for quite a
X while. First the scenario. I'm writing an editor that used GEM windows to
X look into several disk files and use v_text() to write the text. Everything
X works just fine until I resize the window manually with the mouse. If I make
X the window smaller on both axes text doesn't appear in the box until I do
X another resize that makes one of the axes larger! Clearly there's a solution
X to the problem, since 1stword can handle that case. I have tried all kinds of
X tricks, but to no avail. The problem is easy enough to reproduce with
X apskel.c by inserting a call to v_text in the routine that does the painting.
X I'm at my wit's end HHHHEEEEELLLLLLPPPPP!
X
X Anker
X
X
X #: 11106 S2/GEM Support 05-Sep-86 20:24:35
X
X Fm: Anker Berg-Sonne 72337,3211 To: Anker Berg-Sonne 72337,3211
X Of course I meant v_gtext() where I wrote v_text().
X
X Anker
X
X
X #: 11113 S2/GEM Support 05-Sep-86 23:34:54
X
X Fm: Alan Page 72227,3507 To: Anker Berg-Sonne 72337,3211
X GEM doesn't seem to send redraw messages if you shrink a window, just if
X you enlarge it. My solution was to check the size change when I get the
X WM_SIZED message, and if neither axis is being increased then send myself a
X redraw message as in Tim Oren's self_redraw code in the GEM tutorials. -
X Alan
X
X
X #: 11111 S2/GEM Support 05-Sep-86 22:47:28
X
X Fm: NEIL R LINCOLN 73267,2265 To: Tim Oren 76703,202
X An obvious but maybe gentle reminder. Before submitting bugs to the
X compendium it would be helpful for contributors to check that the 'bugs' still
X exist in the current environments. "Bugs" that i have cataloged in my system
X have disappeared over time as various upgrades in software etc have occurred
X
X
X
X #11000-#GEM Bug List Page -3-
X
X
X
X
X #11000-#GEM Bug List Page -4-
X
X
X here. Unfortunately my aged memory plays tricks on me and I find myself
X avoiding nonexistent or antiquated pitfalls.
X
X
X #: 11116 S2/GEM Support 06-Sep-86 00:16:28
X
X Fm: Corey Cole 76224,66 To: Tom Jeffries 73717,2261
X We have a kludgey solution -- depending on one of our state variables, we
X either use vq_mouse or graf_mkstate (the AES equivalent). I have no idea why
X vq_mouse works at some times and not at others, which makes me very nervous!
X Fortunately, at least so far, the situations in which vq_mouse can't be used
X are also those in which response time is not critical. You should stick with
X graf_mkstate if you can handle the slow "feel". - Corey
X
X
X #: 11108 S0/General 05-Sep-86 20:25:17
X
X Fm: OZZIE BOESHANS 73157,2672 To: [F0] SYSOP 76703,2010
X If I have a dialog box with a button in it and the button is defined as
X an EXIT button but not selectable, should pointing at it and clicking cause
X form_do to want to be able to have a big button that I can click on and exit
X from form_do but I don't want it turned to reverse video when it is selected.
X I have found that unless the button is defined as EXIT and SELECTABLE form_do
X does not exit when the button it clicked. Any ideas? Thanks in advance for
X any help!
X
X Ozzie Boeshans 73157,2672
X
X
X #: 11120 S2/GEM Support 06-Sep-86 03:27:52
X
X Fm: Don Curtis 76703,4321 To: SYSOP*Dave Groves 76703,4223
X Dave,
X
X evnt_button(etc....) locks you in never-never land IF while waiting for
X the button event, you move the mouse into the menu bar. There is a
X work-around, you do an evnt_multi(etc...) looking for both the button event
X AND the timer event with a time value of 1ms. The C code for the workaround
X goes like this:
X
X while(evnt_multi(MU_BUTTON | MU_TIMER, .etc...) == MU_TIMER);
X
X As you can see, you will only exit this routine when the button has been
X pressed. Moving into the menu bar will not lock you with this work-around.
X
X
X Don
X
X #: 11121 S2/GEM Support 06-Sep-86 05:07:00
X
X Fm: Dan Rhea 71777,2337 To: SYSOP*Dave Groves 76703,4223
X Well here's one that has bothered me for a long time though it may be a
X feature rather than a bug. When using a file selector box, and you have
X selected a file at the bottom of the list (the slider has been moved down from
X the top). You select the file and all is well. Now you call up the selector
X
X
X
X #11000-#GEM Bug List Page -4-
X
X
X
X
X #11000-#GEM Bug List Page -5-
X
X
X again but this time you are sent back to the top of the selector and need to
X go searching for where you left off. Is it possible for a selector box (even
X optionally), to be able to remember its previous state. Dan Rhea, 71777,2337
X
X
X #: 11128 S2/GEM Support 06-Sep-86 12:30:24
X
X Fm: Stephen Mehalek 73277,2557 To: SYSOP*Dave Groves 76703,4223
X The modulus operator that comes with VDIBIND library is incorrect. The
X lrem.o object module contains 144 bytes and produces results of zero when it is
X used to give the remainder of long integers. The fix is to take the lrem.o
X module from the GEMLIB object modules and move it to the VDIBIND libraries.
X Use the AR^ AR68 utility routine to do this. This bug is not a GEM bug, but
X most people owning the developers package should know about this.
X
X
X #: 11137 S2/GEM Support 06-Sep-86 18:30:21
X
X Fm: OZZIE BOESHANS 73157,2672 To: 76703,4224
X Is there any way to keep a button in a DIALOG box from going reverse video
X when it is selected?
X
X Also, is there a way to set the state of the mouse buttons. I have an
X application that for some reason thinks the button is still down after a press
X and release sometimes. Pressing and releasing the button clears the condition.
X What happens is that I select an option that causes a dialog box to appear and
X once in a while when I move the mouse to a button the button becomes reverse
X video before I even click. If I move to a different button the new button
X doesn't turn reverse video but if I go back to the original it goes reverse
X video. If I click anywhere else on the screen and then reenter the first
X button it no longer goes reverse video. This really has me frustrated.
X Thanks for any help that is given.
X
X Ozzie Boeshans 73157,2672
X
X
X #: 11166 S2/GEM Support 07-Sep-86 21:01:48
X
X Fm: David Beckemeyer 74236,625 To: Corey Cole 76224,66
X I've noticed that the lines between when you should (can) use VDI calls
X and when to use AES are somewhat fuzzy. Is this documented anywhere that you
X know of?
X
X
X #: 11173 S2/GEM Support 07-Sep-86 22:32:42
X
X Fm: Corey Cole 76224,66 To: David Beckemeyer 74236,625
X I don't know of any documentation on [when to use VDI vs. AES calls].
X In general, any display operation can use either/both, while input should be
X restricted to one or the other (if the AES is used at all, your program should
X only do input with AES calls). The catch is that AES is frequently less
X efficient than VDI, sometimes (as with graf_mkstate) by major amounts.
X
X
X #: 11167 S0/General 07-Sep-86 21:13:31
X
X
X
X #11000-#GEM Bug List Page -5-
X
X
X
X
X #11000-#GEM Bug List Page -6-
X
X
X Fm: David Beckemeyer 74236,625 To: Ric Clayton 73317,1350
X Ric, assuming there isn't a simpler, plain old bug, in your program, it
X looks like you may be running up against the classic GEMDOS getting confused
X bug.
X
X I have seen this sort of problem, (GEMDOS unable to open, or create a
X file for no apparent reason), and I have traced it some internal data structure
X handling bugs in GEMDOS. It seems than GEMDOS keeps a copy of the directory
X tree structure of each disk, and as you access directories continually adds to
X this data structure. The idea is to make file accesses faster by avoiding
X reading each directory in the tree of a file spec whenever a file is accessed.
X
X So far so good, but under some circumstances, which seem to relate to the
X number of directories accessed (across all drives), and I think also related
X to floppy disk media changes, this internal GEMDOS data structure gets messed
X up, and GEMDOS doesn't know where to put the next link in its structure, and
X goes out to lunch forever.
X
X I don't know the whole solution to this problem, b but I have been able to
X reduce its frequency by making an undocumented BIOS call at certain times,
X which seems to force GEMDOS to free some internal memory. I found it by
X catching the desktop making BIOS calls. I don't have the code in front of me,
X but maybe John Feagans @ Atari could help? If not, I'll look it up and leave
X you a message. - david
X
X
X #: 11026 S0/General 04-Sep-86 01:31:42
X
X Fm: Ric Clayton 73317,1350 To: All
X Hi there, I have written a program to backup files from my hard disk to a
X floppy disk and have run into a problem I can't seem to get around. The
X program is rather simple; it just copies files from a source directory to the
X same directory on a designated floppy drive, creating directories as needed,
X using GEMDOS calls. Nothing fancy, just regular DOS type file copies. So the
X program goes chugging alone, happily copying files and all of a sudden gets an
X "file not found" error (-33) when it tries to open the Source file for
X reading, the name of which it just got from a directory scan! After this
X occurs, GEMDOS seems to be completely dorked and strange things start to
X happen, requiring a re-boot to restore it to normalcy. It doesn't always
X happen, and when it does it's not always in the same place. Sometimes I can
X get through a whole 5MB partition with no mishap. Sometimes I can't even get
X through the files in the root directory. I have gone over and over the code
X and can't find any error that would cause this. However, I'm new to both the
X ST and 'C' programming environments and may have made some false assumptions,
X so I'm asking for any help I can get. I would be glad to upload the source
X code if anyone would like to give it the go over. The program doesn't use
X GEM, just gemDOS (or is it TOS?). (I've compiled it with Megamax-C and Mark
X Williams C and get the same error. Though I haven't tried Alcyon-C yet.)
X
X Thanks in advance for your help.
X
X Ric Clayton [73317,1350]
X
X
X #: 11196 S2/GEM Support 08-Sep-86 12:30:21
X
X
X
X #11000-#GEM Bug List Page -6-
X
X
X
X
X #11000-#GEM Bug List Page -7-
X
X
X Fm: Jim Needhan, DRI 76703,1064 To: Corey Cole 76224,66
X I assume the confusion is with "mouse" calls and the such... The AES
X should always be used rather than the VDI when making mouse or other hardware
X calls. I have heard the complaints about speed but I do not fully agree with
X those programmer's with the concerns. I do realize that there is a speed
X "hit" but what is gained is a program that is more reliable and more portable.
X The AES cannot keep track of what the VDI is doing so by going through the AES
X the "system" is aware of what is going on.
X
X Of course, you may write directly to the VDI and in graphics display
X calls etc. it is the correct path, but, for windowing, mouse control, etc.
X it is better from the DRI point of view to go through the AES.
X
X Portability? There will be GEM available for other environments, and
X announcements will be made as appropriate, so don't lock yourself out if it
X isn't necessary.
X
X << jim >>
X
X
X #: 11219 S2/GEM Support 08-Sep-86 22:13:27
X
X Fm: SYSOP*Tom Hudson 76703,4224 To: Jim Needhan, DRI 76703,1064
X Right you are, Jim. The VDI mouse routines are great because they are
X not affected by the DCLICK speed setting, but the system goes "HUH?" if you
X try to intermix the VDI and AES mouse calls. My solution: if you are doing a
X mouse operation that won't be declicked, before the mouse is used set the
X dclick speed to its fastest speed and restore it afterwards. Thanks for the
X help.
X
X Oh, do you guys have any information on writing custom GDOS device
X drivers (like printers and custom screen devices)? If so, I'd like to get the
X info if I may. I'd appreciate it.
X
X -Tom
X
X
X #: 11248 S2/GEM Support 09-Sep-86 01:10:50
X
X Fm: Corey Cole 76224,66 To: Jim Needhan, DRI 76703,1064
X Jim, I guess I didn't make myself totally clear. When I was complaining
X about "speed hits" when using the AES to read the mouse, I didn't just mean
X response delays (although those are bad enough). We're talking actually
X failing to recognize events -- for example, if the user presses the left mouse
X button in an application using graf_mkstate, the application will not be
X notified unless the button remains depressed for a sizable fraction of a
X second. I believe the same is true with evnt_multi. This behavior can be
X seen in many GEM applications (Megamax editor, DEGAS, etc.) -- user has to
X hold down the button for about a second to get a new cursor (or whatever).
X Highlighting (in FLASH, megamax editor, my word processor until I went over to
X vq_mouse, etc.) also "feels" jerky to the user because the program isn't
X immediately notified.
X
X At the GEM seminar last year, I was told that evnt_multi does not wait
X the double-click time if the mouse moves more than a pixel or two. This
X
X
X
X #11000-#GEM Bug List Page -7-
X
X
X
X
X #11000-#GEM Bug List Page -8-
X
X
X simply doesn't seem to be the case (it should be), in my observation. In
X general, mouse events have a "clunky" feel to the user, which tends to hurt
X the "feel" of the entire application. Sorry to drag this into the ground,
X just not sure how clearly I'm stating this! -- Corey
X
X
X #: 11252 S2/GEM Support 09-Sep-86 03:23:11
X
X Fm: Alan Page 72227,3507 To: Corey Cole 76224,66
X I agree with you about the slowness of evnt_multi in picking up button
X clicks. Flash 1.1 uses a complicated kludge involving a mixture of vq_mouse
X and ev_mmobutton which gives it _immediate_ response for cursor positioning.
X - Alan
X
X
X #: 11203 S2/GEM Support 08-Sep-86 13:18:40
X
X Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223
X Here are a few 'goodies' we know about:
X
X First some bugs:
X
X -If you use a regular "form_do" in a desk accessory, you may find that
X your keys 'fall through' to the application, so be prepared to write your own.
X Falling through means that if you have a desk accessory on top of a word
X processor for example, keys pressed during a form in the desk accessory would
X be picked up and used by the word processor.
X
X -Evnt_timer is a very dangerous call to make from a desk accessory; it
X sometimes causes the entire program to freeze up . Regarding timers see the
X following message from Chris.
X
X - The system exception handler has some bugs. (See the following message
X from Chris)
X
X -Appl_play and record do not work without an ROM patch from Atari.
X
X -Alcyon Compiler problems. Appl_init returns the wrong value (always
X returns 1).
X
X -The documentation for Vex_motv is wrong - it requires a jump to the
X saved address to update the driver.
X
X
X Some things to remember:
X -Before doing an fsel_input call, and before any I/O, make sure you have
X set path names (A: is not good enough, it must be A:\), or be ready for a
X freeze.
X
X -Form_alert strings can only be about 30 characters per line.
X
X -You should modify the source of form_do (form_keybd) to change
X underscores to dashes; underscores blows your application out of the water.
X
X Mark
X
X
X
X #11000-#GEM Bug List Page -8-
X
X
X
X
X #11000-#GEM Bug List Page -9-
X
X
X
X #: 11204 S2/GEM Support 08-Sep-86 13:20:55
X
X Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223
X There are 2 serious bugs related to desk accessories. Both were reported
X to Atari months ago.
X
X
X 1. EVNT_TIMER is flaky. The timer event will not always return when called.
X This seems to happen most often when there is heavy disk activity, but not
X always. If you do an evnt_multi() with messages and timers, the timers will
X eventually hang up, but if the accessory receives a message, the timers start
X working again (for a while). We call this burping the timer. As a
X programmer, this means that you must find an alternate way of releasing
X control (it isn't easy). That's why some desk accessories degrade the system
X performance so much. This bug has been ported from the IBM PC version of
X GEM.
X
X 2. The system exception handler has one or more bugs. If an application
X generates a system alert (drive not responding, insert your new A: disk,
X etc.), any desk accessory that is running is not stopped. That is, if you
X have an accessory buzzing along waiting for evnt_timers (which you shouldn't),
X or mouse movement events (actually any evnt_ function has this problem), the
X multitasking of the desk accessories is not turned off while the alert is
X presented. I checked this out with an accessory that woke up constantly and
X wrote a counter to the screen. As soon as the alert is cleared, the desk
X accessory, then the application bomb. I suspect it's because the accessory
X gets running in supervisor mode and messes up the super stack or something
X like that. The same thing can happen in a one drive system in another way
X (this is probably a separate bug). If the desk accessory reads from drive B:,
X and the system alert is generated to swap diskettes, after the alert is
X cleared first the desk accessory then the application will bomb. We've even
X seen it bomb the GEM Desktop.-- Chris Bailey (Batteries Included)
X
X #: 11232 S2/GEM Support 08-Sep-86 23:33:36
X
X Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223
X You want bugs, use the file selector. It is one of the most flawed
X things in the system. You can crash it two ways, put the '_' in the path.
X Or, you can just leave a disk out and wait two times for it to give the abort
X continue error, after that booomb! Also, when you have a single drive system
X and you try to treat drive b as disk b, he really gets strange.
X
X - Rich
X
X
X #: 11267 S2/GEM Support 09-Sep-86 11:39:02
X
X Fm: Ken Settle 76556,753 To: SYSOP*Dave Groves 76703,4223
X I have noticed the following bugs in GEM: Bug series #1: (AES object
X library section)
X
X In the TEDINFO structure, te_pvalid field, the following validation
X characters DO NOT work properly: 9, A, a, N, n, P, p, (all except F and X).
X The bug occurs when a form_dial is called with an object containing any of the
X
X
X
X #11000-#GEM Bug List Page -9-
X
X
X
X
X #11000-#GEM Bug List Page -10-
X
X
X above characters in the PVALID field. If the user types an underscore "_" on
X any character position (except the last), the system promptly "bombs" out.
X The bug with the "F" character in that situation was fixed in ROM TOS and the
X "X" character never had this problem (to my knowledge).
X
X Also in the TEDINFO structure, the te_txtlen and te_tmplen fields both
X contain the length+1 of their respective strings, contrary to the
X documentation.
X
X Bug series #2: (GEMDOS section)
X
X Hard disk file WRITE time increases by roughly 1 second for each megabyte
X stored on that drive (partition, whatever). This is probably due to
X unspeakably slow FAT search code (it takes about 450 times as long as it would
X using two simple 68000 instructions to search a FAT sector).
X
X Dfree() command takes "next to forever" on the hard drive.
X
X It is somehow possible to get a folder (on the hard disk) that is
X impossible to delete, even though it's empty. - Ken Settle [76556,753]
X
X
X #: 11268 S2/GEM Support 09-Sep-86 11:42:38
X
X Fm: Ken Settle 76556,753 To: Ken Settle 76556,753
X Bug series #3: (GEM Desktop section)
X
X SOMETIMES when you close a directory window and re-open it from another
X drive, the window decides to exactly cover up the top window on the screen.
X This has been a major annoyance causing me to be paranoid about closing a
X directory window. It seems to be very random (as all truly good bugs are).
X
X Changing resolution and/or colors can really screw up the desktop when
X you return to it. It should be Desktop's responsibility to make sure these
X conform to the current defaults. Desktop should also automatically set ALL
X DESKTOP.INF defaults on power up, and allow ANY application or accessory to
X have access to/modify these defaults (palette, key rate, RS232/Printer
X setup).
X
X Desktop should be hardy enough to survive a "close workstation" call by
X an application, without losing it's "pull-down menu" capability. This might
X allow VDI to be used in any resolution as dictated by the application, not
X desktop.
X
X It should be possible to abort a multiple-file COPY or DELETE operation
X at any time using the mouse and/or keyboard.
X
X Bug series #4: ("TOS" section)
X
X An error box stating "TOS ERROR #35" means nothing to most people, what's
X the real message?
X
X Bug series #5: (AES/VDI section)
X
X The dot-pattern in the move bar of a window can get screwed up by a
X
X
X
X #11000-#GEM Bug List Page -10-
X
X
X
X
X #11000-#GEM Bug List Page -11-
X
X
X redraw attempt such as after a dialog has disappeared. It appears to happen
X because of the "blit" feature being used to move a window to any odd
X line/pixel where VDI can't accurately match up the pattern. - Ken Settle
X [76556,753]
X
X
X #: 11307 S2/GEM Support 10-Sep-86 00:26:44
X
X Fm: Dan Rhea 71777,2337 To: SYSOP*Dave Groves 76703,4223
X Here is another interesting one I've stumbled on. It is not a "GEM" bug
X but a bug in the C Runtime (GEMLIB), or the AS68.PRG step of the latest and
X greatest compiler. This has been driving me nuts till I finally isolated it
X to the following test case. The test works fine with the old compiler/runtime
X but gives bad results for the new one (i.e. every other long has a value of
X 0). main()
X
X {
X
X long int a, b, c, d; int i; a = b = c = d = 0L;
X
X for (i=0; i<25; i++)
X
X { a++; b++; c++; d++;
X
X printf ("a=%D b=%D c=%D d=%D\n",a,b,c,d);
X
X }
X
X Cconin (); /* Wait for any character */
X
X }
X
X
X Good Results: a=1 b=1 c=1 d=1
X a=2 b=2 c=2 d=3
X
X ...
X
X a=25 b=25 c=25 d=25
X
X Bad Results a=1 b=0 c=1 d=0
X
X a=2 b=0 c=2 d=0
X
X ...
X
X a=25 b=0 c=25 d=0
X
X
X Note: I included OSBIND.H in the above program too. Has anyone hit this one
X yet or devised a workaround (other than floating point or the obvious two
X longs for each one used). Dan Rhea, 71777,2337
X
X #: 11314 S2/GEM Support 10-Sep-86 09:38:33
X
X
X
X
X #11000-#GEM Bug List Page -11-
X
X
X
X
X #11000-#GEM Bug List Page -12-
X
X
X Fm: Mark Skapinker (BI) 76703,207 To: SYSOP*Dave Groves 76703,4223
X Dave, As the GEM DESKTOP is simply a 'program' , I think its bugs should
X be kept separate.
X
X Mark
X
X
X #: 11310 S2/GEM Support 10-Sep-86 00:43:55
X
X Fm: Rich Plom (Intersect) 73307,1676 To: SYSOP*Dave Groves 76703,4223
X Nope, the only way around them is to write your own file selector. Atari
X will someday weed the bugs out(hopefully). It is a shame that a solid program
X can be crashed by it. It looks like the authors fault to everyone else, but
X the blame is the operating systems. The one that gets me the most is when you
X forget to put a disk in or put it in crooked and it dies after the second
X retry.
X
X
X #: 11443 S2/GEM Support 12-Sep-86 00:14:24
X
X Fm: Tom Jeffries 73717,2261 To: Jim Needhan, DRI 76703,1064
X There's an old rule of thumb- if one person tells you you have a tail,
X don't bother to look. If ten people tell you you have a tail, you'd better
X take a look to see what's going on. Actually, I think most of us look when
X one person tells us we have a bug. There is a whole series of problems with
X reading the mouse which include: slow and inaccurate reading of the mouse
X buttons, especially from the AES, evnt_multi() will not read both mouse
X buttons (as far as I know that's not in the bug list yet, we should add it),
X mouse button releases are not always recognized, etc. etc. etc. I must
X admit I'm getting a little tired of DRI and Atari trying to blame these
X problems on bad code. Too many developers are having the same problems for it
X to be bad code. In an earlier note, you defend the slowness of evnt_multi.
X If it really were accurate, I might go along. However, even if that were the
X case, it is hard to ignore the fact that the Mac, which also has to read
X double clicks, feels much less clunky than the ST. GEM, like all operating
X systems, has some problems. Actually, if you compare it with MS-DOS, which is
X much simpler but also has lots of bugs, you guys at DRI and the folks at Atari
X did a terrific job, especially considering the time it took to get the machine
X on the market. No purpose is served, however, by trying to blame bad code for
X problems that are real and don't seem to be getting solved. I don't mean to
X cause offense- but since we have the benefit of having some of the people who
X wrote GEM online, I would like the discussion to be at a realistic level.
X Thanks,
X
X Tom Jeffries
X
X
X #: 11445 S2/GEM Support 12-Sep-86 00:18:23
X
X Fm: Tom Jeffries 73717,2261 To: Mark Skapinker (BI) 76703,207
X One more bug- despite the documentation, you cannot read both the left
X and the right mouse button with one evnt_multi() call. You have to use two,
X which gives you time to go out for dinner before the mouse button event is
X reported, or use a different call.
X
X
X
X
X #11000-#GEM Bug List Page -12-
X
X
X
X
X #11000-#GEM Bug List Page -13-
X
X
X
X #: 11456 S2/GEM Support 12-Sep-86 16:24:52
X
X Fm: Michael T. Smith 73317,3470 To: Mark Skapinker (BI) 76703,207
X OK, I want in this mesh of messages... I just yesterday started writing
X a ml routine to be used in the vex_motv function. I had heard of some bugs in
X the vq_mouse and my program has been slipping in the area of mouse handling..
X So, the problem occurred when it hits the vex_motv it gives me 2 bombs and i
X don't know why, I haven't looked on Dl2 yet but I will to see if my problem can
X be answered there. ( I think thats where you were going to put the
X compiled list of bugs) If its simply in MY ml code then I will eventually
X find it, but if there is funny business in that routine I would like to know
X how to get around it. The only other thing I think I'll be able to answer
X myself: Desk Acc's. I know that if I get a message 20 then I need to redraw.
X Is that It? If you have any Advice simply give it. I appreciate you help.
X Thanks.... Michael T Smith Xetec Inc. Salina Ks 73317,3470
X
X
X #: 11483 S2/GEM Support 13-Sep-86 10:55:39
X
X Fm: Tom Jeffries 73717,2261 To: Michael T. Smith 73317,3470
X One more bug (There's always one more bug), I think this one is pretty
X well known and documented but it can be unpleasant if you don't know about it:
X fsel_input() resets the clipping rectangle and does not reset it on exit.
X It's easy to work around- you just set your own clipping area when you regain
X control.
X
X
X #: 11539 S2/GEM Support 13-Sep-86 22:58:44
X
X Fm: Alan Page 72227,3507 To: [F7] SYSOP*Dave Groves 76703,4223
X Here's another bug for the list. When I use the function appl_find (from
X a desk accessory) it should return -1 if the application is not found.
X However, if I call appl_find with the name of an application just after I exit
X it, I get a 'valid' ID. As soon as I run another application then I get the
X proper -1 value returned. It acts like the name of the application is not
X erased until you run another application. - Alan
X
X
X #: 11540 S2/GEM Support 14-Sep-86 01:37:43
X
X Fm: SYSOP*Tom Hudson 76703,4224 To: [F7] Alan Page 72227,3507
X By golly, Alan -- you have the same bug as I found yesterday!!! I was
X working on a desk accessory that looked for DEGAS Elite, and it works fine
X until Elite is run. That is, it knows it's not there before Elite is run, but
X thinks it's there after Elite's done! Fortunately, The accessory is written so
X that that does not matter, but it is a bug that should be reported.
X
X -Tom
X
X
X #: 11641 S2/GEM Support 16-Sep-86 08:47:54
X
X Fm: Michael T. Smith 73317,3470 To: SYSOP*Russ Wetmore 76703,2010
X Russ, Thanks for the info.. I am using the 'asm{...}' from megamax for
X
X
X
X #11000-#GEM Bug List Page -13-
X
X
X
X
X #11000-#GEM Bug List Page -14-
X
X
X my interrupt interrupt but also 'C'... mint() { asm{...} }. The problem now
X exists that as soon as I call the vex_motv(num1,,); it crashes (2 bombs:Bus
X error) then returns to the desktop where it sits until I move the mouse and
X then I get 4 bombs.. (Illegal inst.) Currently, my int. is only a nop which
X leads me to believe that it is not caused by my int. but by the way I am
X calling the vex_motv();. I saw something about having to call , or jump to,
X the location that thee function returns to you. Also I noticed once that it
X executed the next 'C' instruction after the vex_motv. Go FIgure? Well, if any
X of this sounds familiar than let me know. Michael T Smith... Xetec Inc.
X
X
X #: 11667 S2/GEM Support 16-Sep-86 22:23:41
X
X Fm: SYSOP*Russ Wetmore 76703,2010 To: Michael T. Smith 73317,3470
X There's an example of calling vex_timv in DL0 someplace that I uploaded.
X The procedure should be similar for vex_motv if you'd like to look at it. [
X Russ ]
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X #11000-#GEM Bug List Page -14-
SHAR_EOF
if test 37636 -ne "`wc -c 'gembugs.txt'`"
then
echo shar: error transmitting "'gembugs.txt'" '(should have been 37636 characters)'
fi
# End of shell archive
exit 0
--
usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi
csnet: bammi@case
arpa: bammi%case@csnet-relay
compuServe: 71515,155