W98 right-click induced crash.

Has anyone else seen this? Just wondering... I have tried to stop it,
succeeded during one session but can't replicate the fix.

What happens is that in some programs a right-click or other standard
Explorer operation done inside a File Open dialog or other Explorer window
created as part of that program, causes the program to crash, and the
'illegal operation' alert message blames the program itself.

The cleanest way to demonstrate the problem is in a minimal install, then
open some program known to invoke the behaviour, first try a right click in a
File Open dialog. It either works, or crashes. If it works, copy out a file
from that dialog to the desktop, which will also work, then right click again
in the dialog. This time it WILL crash, always, and in every subsequent
attempt after relaunching that or any other program with similar ability to
invoke this. The main shell seems ok, most programs allow the right-click
even after the problem occurs in any session.

TextPad.exe, GhostExp.exe,and Xlutop's Chainer are three examples that
consistently do this. There are many others, I forget their names...

I've found that there are several subtly different versions of the core files
that seem related to this: Shell32.dll, Comdlg32.dll, User.exe, and
Explorer.exe, as used in 98-Lite, i.e. W95 versions of all those except
User.exe. (And there are copies of Comdlg32.dll with identical size and
different version and content).

There are several permutations possible, and my sources aren't reliable
either, so if anyone knows more about this, and knows a clean source of the
right versions to avoid this, please let me know what to get. Even though in
one session I was repeatedly able to do Explorer operations inside a
GhostExp.exe File Open dialog without this crash, I can't replicate the
conditions after days of trying, so it's possible there is no really stable
avoidance of the problem! In which case, it beats me why Google has failed to
show anything conclusive for years. Stuff like this usually gets documented,
somewhere, even if it's just a lot of people calling for help. I can't even
find a clear description of the same problem.

I need to solve this because some tools, like Xlutop Chainer, cause terrible
things to happen in audio drivers that not only jar the nerves, but can
damage equipment. Some programs that invoke it are indispensible, so I have
to solve this.

On 04/17/2011 08:26 AM, Lostgallifreyan wrote:
Has anyone else seen this? Just wondering... I have tried to stop it,
succeeded during one session but can't replicate the fix.

What happens is that in some programs a right-click or other standard
Explorer operation done inside a File Open dialog or other Explorer window
created as part of that program, causes the program to crash, and the
'illegal operation' alert message blames the program itself.
\\\snip

That is totally non-normal behavior

I'd run a RAM test on your machine

philo wrote in :

On 04/17/2011 08:26 AM, Lostgallifreyan wrote:
Has anyone else seen this? Just wondering... I have tried to stop it,
succeeded during one session but can't replicate the fix.

What happens is that in some programs a right-click or other standard
Explorer operation done inside a File Open dialog or other Explorer window
created as part of that program, causes the program to crash, and the
'illegal operation' alert message blames the program itself.
\\\snip

That is totally non-normal behavior


Tell me about it.

I'd run a RAM test on your machine


It happens on several machines, I've had to live with this for years. I'm
currently working out a minimal manual install so it seems like a good time
to try to eradicate this once and for all. Whatever it is, it's software.
Currently I'm looking through ancient CD's to find sysfile sources that
existed before I ever saw any of this, in case they offer answers.

Lostgallifreyan wrote:
philo wrote in :

On 04/17/2011 08:26 AM, Lostgallifreyan wrote:
Has anyone else seen this? Just wondering... I have tried to stop it,
succeeded during one session but can't replicate the fix.

What happens is that in some programs a right-click or other standard
Explorer operation done inside a File Open dialog or other Explorer
window
created as part of that program, causes the program to crash, and the
'illegal operation' alert message blames the program itself.
\\\snip

That is totally non-normal behavior


Tell me about it.

I'd run a RAM test on your machine


It happens on several machines, I've had to live with this for years. I'm
currently working out a minimal manual install so it seems like a good
time
to try to eradicate this once and for all. Whatever it is, it's software.
Currently I'm looking through ancient CD's to find sysfile sources that
existed before I ever saw any of this, in case they offer answers.

The fact that it happens on several of your computers sure sounds like
you're using some "customized" version of windows. Are you using
Win98Lite, and/or have you been subbing out some core files? If so, that's
probably the problem, as I sure don't recall seeing this. In another post
you mentioned using a Win95 shell? What is that? It seems to imply you're
not using Win98 or Win98SE right out of the box and having been doing some
"subs". :-).

The one sub I *did* do to Win98SE was the one that eliminated that explorer
hangup when copying or deleting too many files (fixed this by using older
builds of the two browse DLLs).

"Bill in Co" wrote in
:

The fact that it happens on several of your computers sure sounds like
you're using some "customized" version of windows. Are you using
Win98Lite, and/or have you been subbing out some core files? If so,
that's probably the problem, as I sure don't recall seeing this. In
another post you mentioned using a Win95 shell? What is that? It
seems to imply you're not using Win98 or Win98SE right out of the box
and having been doing some "subs". :-).


Yep. 98-Lite. I've established that the 98-Lite 'Micro' and 'Sleek'
installs do this. They use a W95 shell, (three files, SHELL32.DLL,
EXPLORER.EXE and COMDLG32.DLL), all other files being native to W98.

As I assumed that all 98-Lite users might experience this, I decided to also
assume that if they didn't, it was because the rarer W95osr2c variant used
different shell files, but as far as I can tell from old archives here, those
three files are identical in the more common W95osr2b variant.

The one sub I *did* do to Win98SE was the one that eliminated that
explorer hangup when copying or deleting too many files (fixed this by
using older builds of the two browse DLLs).


Looks like you also supected (rightly too) that older builds might sometimes
be better. This is why I rootled around the earlier W95 install set, but so
far to no result.

What I did find was that swapping out (using 98-Lite itself) the W95 shell to
the original W98 shell fixed the problem. As I am not willing to make that
permanent, I'm currently trying hacks to those W95 shell files to change
internal pointers to Shell32.dll to Shell32.w98 (which is the actual W98
Shell32.dll, renamed and included in W98-Lite installs when something needs
functions special to that DLL.) As this fix often works on many programs, I'm
trying it to see if it fixes the core shell too. So far it either breaks, or
produces no improvement OR impairment, but I'm not done yet...

One thing I'd like to know is whether other people using W98-Lite with a W95
shell also see this behaviour (right-click in File Open dialog's Explorer
view causes a crash of that program, either before or after copying some file
from it to the desktop (test several programs, some do this, but many
don't)). That appears to be the condition likely to produce the problem.
Producing the elusive answer is another matter, but I have seen it work, so
there ought to be a way to make it stick, but that's not in sight yet.

Lostgallifreyan wrote in
:

What I did find was that swapping out (using 98-Lite itself) the W95
shell to the original W98 shell fixed the problem. As I am not willing
to make that permanent, I'm currently trying hacks to those W95 shell
files to change internal pointers to Shell32.dll to Shell32.w98 (which
is the actual W98 Shell32.dll, renamed and included in W98-Lite installs
when something needs functions special to that DLL.) As this fix often
works on many programs, I'm trying it to see if it fixes the core shell
too. So far it either breaks, or produces no improvement OR impairment,
but I'm not done yet...


For those following this unlikely saga, I offer this:

Use only W95 SHELL32.DLL and EXPLORER.EXE, unhacked.
Use W98 COMDLG32.DLL instead of the W95 copy that 98-Lite normally would
intend. HACK that COMDLG32.DLL file so its two references to SHELL32.DLL
point instead to SHELL32.W98, which as I mentioned is the renamed copy of
W98's SHELL32.DLL.

The result is odd, but effective. The file dialogs are clearly W98's own,
they include the little Desktop button. The main Explorer shell is still
W95's. It will take time to see whether this breaks more than it fixes but it
does solve the worst problem I know of. I'll also hold out for a better fix..

Lostgallifreyan wrote:
"Bill in Co" wrote in
:

The fact that it happens on several of your computers sure sounds like
you're using some "customized" version of windows. Are you using
Win98Lite, and/or have you been subbing out some core files? If so,
that's probably the problem, as I sure don't recall seeing this. In
another post you mentioned using a Win95 shell? What is that? It
seems to imply you're not using Win98 or Win98SE right out of the box
and having been doing some "subs". :-).


Yep. 98-Lite. I've established that the 98-Lite 'Micro' and 'Sleek'
installs do this. They use a W95 shell, (three files, SHELL32.DLL,
EXPLORER.EXE and COMDLG32.DLL), all other files being native to W98.

As I assumed that all 98-Lite users might experience this, I decided to
also
assume that if they didn't, it was because the rarer W95osr2c variant used
different shell files, but as far as I can tell from old archives here,
those
three files are identical in the more common W95osr2b variant.

The one sub I *did* do to Win98SE was the one that eliminated that
explorer hangup when copying or deleting too many files (fixed this by
using older builds of the two browse DLLs).


Looks like you also supected (rightly too) that older builds might
sometimes
be better. This is why I rootled around the earlier W95 install set, but
so
far to no result.

What I did find was that swapping out (using 98-Lite itself) the W95 shell
to
the original W98 shell fixed the problem. As I am not willing to make that
permanent, I'm currently trying hacks to those W95 shell files to change
internal pointers to Shell32.dll to Shell32.w98 (which is the actual W98
Shell32.dll, renamed and included in W98-Lite installs when something
needs
functions special to that DLL.) As this fix often works on many programs,
I'm
trying it to see if it fixes the core shell too. So far it either breaks,
or
produces no improvement OR impairment, but I'm not done yet...

One thing I'd like to know is whether other people using W98-Lite with a
W95
shell also see this behaviour (right-click in File Open dialog's Explorer
view causes a crash of that program, either before or after copying some
file
from it to the desktop (test several programs, some do this, but many
don't)). That appears to be the condition likely to produce the problem.
Producing the elusive answer is another matter, but I have seen it work,
so
there ought to be a way to make it stick, but that's not in sight yet.

I don't understand why you don't just stick with the Win98 shell, though.
What is wrong with it? It seems like it's not worth all the bother,
unless you enjoy chasing this down. :-)

"Bill in Co" wrote in
m:

I don't understand why you don't just stick with the Win98 shell, though.
What is wrong with it? It seems like it's not worth all the bother,
unless you enjoy chasing this down. :-)


I do. Also, while not as bad as WXP, the W98 shell has a certain
viscosity.. W95 gave me a taste for raw speed that nothing else satisfied,
except 98-Lite. Minimal and highly responsive and versatile controls are best
for me. Later systems started piling on lots of very specific stuff that
distracts me more than it helps me.

I used win98 for many years and never saw that.

If you think it's software , then start out with a clean install of
Win98...then add one app at a time until you've narrowed it down to the
one causing the problem


Done that more times than I ever want to try to count. That's not the way to
go either, I already know several programs that invoke the problem. The REAL
problem is that no matter how small the W98 base install is, the problem is
there. The only thing I can do, short of useless juggling core sysfiles (as
I've been doing all day, yet again) is to give up on the W95 shell altogether
which i will not do. Especially as I never saw this problem when I was
actually using pure W95osr2c anyway.

What I do not need is to keep blundering around on my own trying to repeat
the apparently unrepeatable. I need to see if others have ever seen this
problem, and in what context. Until I have that, I have about as much chance
of seeing this differently as an astronomer has of taking a paralaz reading
in 5 seconds when it needs 6 months to move Earth far enough to take the
second view. On my own I can't distance myself enough to get any kind of
alternative view, because whatever I do, the problem remains.



It was not clear to me that you were using the Win95 shell

Heck why bother with Win98 at all...as long as you already know you had
no problems in win95osr2c then why not use that?

philo wrote in :

It was not clear to me that you were using the Win95 shell


First post this thread, 4th paragraph.

Heck why bother with Win98 at all...as long as you already know you had
no problems in win95osr2c then why not use that?


Fair point, but I'm after the best W9X I can put together. For one thing,
with latest sysfiles from a set that Sjouke Burry pointed me to (Thread: List
of latest version DLL's?), this can be more compatible with the Maxim Decim
USB driver subsystem, so I have revised my opinions of that thing sharply
upwards, at least as a viable prospect for a good base install of W98. (It
would likely break an existing full W98 install if it wasn't first fixed with
a selected bunch of core files from "sesp21a-en.exe" because there are
several version-specific interdependencies there).

In short, going back to W95 would be throwing babies out with bathwater.