..humbug not really but I had only mentioned the few caveats for full
disclosure sake, but ''to me personally'' I feel those caveats are minor
and well worth the gain. The only caveat with the unknown that goes along
with it though is of course by using the v5 dlls in place of the v6 - what
'if any' security concerns does it leave or open up?-keeping in mind
though since with the rest of updated v6 is in place could it even follow
through... ...I suspect we will never know that 'exact' answer since it
would take the original coders to revisit and reconcile/determine what the
5/6 /\ 6/5 flow of data in this alternate software circuit is actually
doing; ..but for some reason I'm not worried about it since v6 was born out
of v5 base anyway & the rest of updated v6 is intact - heck for all we know
it may even make it uniquely better avoiding crack.  As for the lock
toolbar frillies - I never need to use that and actually never knew those
options even existed in the first place.

I still have hope for the shell32 project but focus expanding to also
include solving the 'real cause' of the problem in the first place, however
I've let it go to the whim of the universe now since the few+ people that
are capable of doing it may never take/have the time to tackle it.

Rick

On Sat, 28 Apr 2007 15:03:48 -0400, "MEB"

I don't remember a Shell32.dll swap as a fix, just the two
Browse*.dll; I think if anything, the Shell32.dll swap would have as
big or bigger vulnerability impact as the other two .dlls... replacing
Shell32.dll has been a commonly-successful fix for shell failures in
Win9x in the past, e.g. where you can only get into Windows by setting
something other than Explorer.exe as the shell= in System.ini

I dropped out of everything for a while, then was active mainly in a
few elists and blogging, then recently switched from blogging back
into these newsgroups, but via MS's news server this time.

What I haven't done for yonks, is update my "real" web site; in fact,
I haven't accessed if from this system at all, so I'd have to hunt
down pwds etc. to get back into it.  

That's why I didn't update this...

http://cquirke.mvps.org/bexp1.htm

...to reference Rick's work on this subject, as I wanted to do.

I certainly would not pick a "version soup" fight with the OS kernel;
I might even prefer the Win98Lite approach over that    ;-)

  I'm on a ten-year lunch break

The copy2gb.exe = kernel32.dll is specifically to resolve the 2-4 GB file
size usage with W98x, and absolutely I use this since it's 100%
valid/sanctioned in every respect.  It really comes in handy to have that
limitation dissolved too.  I may have initially during testing
inadvertently mentioned to you that one affected the other, but in
retrospect realize that was only in the activity bustle of the moment that
I innocently albeit inaccurately linked the explorer hang with the kernel,
afterall the explorer hangs reach is so all encompassingly vague in the
first place it just seems to affect everything while it happens.

The shell32.dll stands on its own but only as a workaround for the explorer
hang, which I've found the hang can still less occasionally happen though,
it's just that you don't have to necessarily reboot to clear it since it
after the 10 or so second hang, it appear to recover (meaning you don't
have to reboot to continue on like before.. I think that's still a pain the
arse though since being so close to the issue for so long right along, I
have no tolerance for the hang in the first place anymore and is why I
would rather the 5.5 dll workaround instead of seeing any hint of an
explorer hang present itself.

imho, ymmv

Rick