#UAE & Shell
8 messages in this thread
Hi Keith,
(and Ted Young, Nelson Ford, Costas Kitsos, Keith Pleas, Steve Camp and
Jim McCullan…the infamous "shell gang", I hope I got everyone who has been
in this thread.)
I have found through the Windows gurus, that your problem has become an
official and documented problem with with the Task Manager as of September
25. This is what I have recieved from them:
———————————————————————–
1)The problem occurs when:
a) an FPU is present in the machine (eg 80×87)
b) a WinApp is using the FPU
c) a DOS app is using the FPU
d) multiple task switches occur between b/c
(note that this is possible, but may not always occur, hence this is
difficult to track down)
2) The problem is caused by a minor (to the Developer Gods anyway) bug in the
Windows Task Manager. The task stack gets confused, panics, then shoots
itself in the foot.
————————————————————————
This has been added to the problem report for Windows and hopefully will be
addressed in the next release of Windows. Another one for the Knowledge Base
at least from my end…
I want to thank you all for pushing this as an issue. With the support from
you all, problems can be found to make this a better product. Thanks
Don Funk
There are 5 Replies.
Don,
Great! And thank you for keeping an eye on the "Shell" gang and keeping us
informed.
Costas
Don,
Hallelujah! It's an official bug! So, when's the party? <grin> Seriously,
thanks for putting up with us and taking the time to track down this
strange problem, it's always nice to know when it's a real problem and not
something wrong with the hardware or our code or our imaginations. Any
idea if there's a workaround for this? It's been suggested to me that
saving the math-coprocessor (FPU) stack before shelling and restoring it
after returning fixes the problem. Can you check on this? Thanks!
– Ted
Don:
Well, in my case I'm using ThreadZ's Task Manager. I never did see the UAE
though. I assume Nelson and KeithF are using the Windows Task Manager?
There is 1 Reply.
Hi Don,
Upon second, third, fourth and fifth readings, I'm wondering about the
'official' MS bug and the one we have been chasing.
1. If this is a bug in the Win3 Task Manager program, how come we
discovered it in VB programs that use the VB Shell command or API WinExec
function? Do these functions call the Win3 Task Manager?
2. MS states that the problem occurs if a WinApp and DosApp both use the
math chip and multiple task switches occur. Well, in the entire time that
we have been persuing this 'shell' problem, we have *never* used a DOS test
program that uses the math chip, unless the DOS DIR program does.
3. If MS has acknowledged this to be a Win3 bug then they must be able to
reproduce the bug on their machines, *but* they can't reproduce the bug we
have been chasing.
4. How come very few people on this forum can reproduce the bug we have
been chasing when in fact it was registered as an 'official' Win3 bug FIVE
days before this bug hunt really got under way?
Some food for thought.
KeithF
There is 1 Reply.
Hi Keith,
2nd, 3rd, 4th…I hope that you were just rereading you file you
downloaded. I don't think it got sent more than twice<g>.
1. You have some task swtiching whenever you go from VB to DOS. A common
"function" would be called from the "Task Manager EXE" and any time you go
from one app to another app. When I talk about the Task Manager, I am
refering to this as an "interface" that performs some functions calls that
would be common to the two ways of changing windows.
2. I don't know if the dir statement uses the 80387, I am sure there is some
math going on…however little. Heck even some screen output would use
numbers crunching to position the text on the screen.
3. Who said MS could not reproduce it? I just said I can't, or any one else
here in BASLANG. It was documented through the Windows group(separate from
BASLANG here at PSS). Looking at the Service Request, I am told that it was
a *very* hard bug to reproduce. I don't have all the specifics as to
whether it was the specific machine or just software that reproduced it.
4. Ahh Sherlock<g>! Five days before you all started the thread!<gg>
Actually, the problem was "discovered" through another group here at MS
through another individual having the problem. It didn't even start with
someone with a VB app, but someone with C code specifying use of the
80387sx. MS is *very* large and several groups may work on the same problem
without knowing it.
Don Funk
Well, I first reported this in June, I believe, so I guess I should be
grateful that it is recognized as an official bug, but I have the same
uneasy feeling that KeithF has that MS Techs do not yet have a firm handle
on this.
As Keith pointed out, at least one of their criteria was not met in the
problems we had – no FPU-stuff was run in DOS. Also, there remains the
question of why, in VB, instead of getting a UAE, I get a spurious "Illegal
function call" message.
I hate being in the position of having to tell my users: "Sorry, it's a bug
in Windows; nothing we can do about it." OTOH, as often as Corel Draw,
Ventura, et al, crap out on me, maybe I'm being too sensitive. <g>