W98 right-click induced crash.

"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 spent a few hours trying to see if the W98 shell can be put into a minimal
core, and so far it looks like it can't. When 98-Lite swaps it back into a
'sleek' or 'micro' install it puts a LOT of stuff back in. While there seem
to be only 4 vital files (SHEll32.DLL, EXPLORER.EXE, COMDLG32.DLL and
SHLWAPI.DLL) plus the core files which they depend on and which must always
be there no matter what, Explorer crashes at boot if some registry data isn't
there. It's possible that might be isolated, and small, but finding it would
be harder than doing what I already did.

Even so I might do it, not for the W98 shell itself, but because a neat
reversal of my right-click crash fix seems possible: Use a minimal W98 shell
as descrbed above, then add the W95 shell files with new extensions of .W95,
and with their internal references changed instead of those in the W98 shell,
and point to it instead of the W98 shell by setting SYSTEM.INI as follows:

[boot]
shell=Explorer.w95

(Or whatever name and extension might be better).

First, this fixes the need to edit ****loads of EXE's and DLL's internal
references, limiting such edits to 3 files at most. Second, if it evades the
need to hunt down whatever registry data is needed to run the W98 shell, this
idea is about as neat as I can imagine for a minimal base install of W9X.

The game is most definitely afoot.

Lostgallifreyan wrote in
:

I spent a few hours trying to see if the W98 shell can be put into a
minimal core, and so far it looks like it can't. When 98-Lite swaps it
back into a 'sleek' or 'micro' install it puts a LOT of stuff back in.
While there seem to be only 4 vital files (SHELL32.DLL, EXPLORER.EXE,
COMDLG32.DLL and SHLWAPI.DLL) plus the core files which they depend on
and which must always be there no matter what, Explorer crashes at boot
if some registry data isn't there. It's possible that might be isolated,
and small, but finding it would be harder than doing what I already did.

Even so I might do it, not for the W98 shell itself, but because a neat
reversal of my right-click crash fix seems possible: Use a minimal W98
shell as descrbed above, then add the W95 shell files with new
extensions of .W95, and with their internal references changed instead
of those in the W98 shell, and point to it instead of the W98 shell by
setting SYSTEM.INI as follows:

[boot]
shell=Explorer.w95

(Or whatever name and extension might be better).

First, this fixes the need to edit ****loads of EXE's and DLL's internal
references, limiting such edits to 3 files at most. Second, if it evades
the need to hunt down whatever registry data is needed to run the W98
shell, this idea is about as neat as I can imagine for a minimal base
install of W9X.

The game is most definitely afoot.


That totally works!

So if anyone wants to try this, here's what happens:
W98 shell is SHELL32.DLL, EXPLORER.EXE, COMDLG32.DLL and SHLWAPI.DLL plus
dependencies. Nothing else.
W95 shell is SHELL32.DLL and EXPLORER.EXE, nothing else, but change their
extensions to W95, and edit the three internal references in EXPLORER.W95
from SHELL32.DLL to SHELL32.W95. Finally, point the SYSTEM.INI shell
invocation to EXPLORER.W95.

This fixes the right-click crash because all standard callsto the W98 shell
work as they expect to, so no proghram files have to be edited either. If
anyone knows Shane Brooks, point him this way, he might like this one.

Lostgallifreyan wrote:
"Bill in Co" wrote in
m:

Lostgallifreyan wrote:
"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 do recall Win95 being more nimble, but after swapping out those two
browse DLLs with the older IE55 builds, I found explorer to still be
pretty fast.


You might not need them at all. On my main system they appear to do
nothing,
they're not in use, one seems to depend only on itself, the other is a
high
level DLL, dependent on a lot more than the core. My test machine has a
core
compiled from as few files as appear to be strictly called for, and that
works too, and has never had those two in it. I'll leave them out of my
main system and watch for signs of panic, but none so far, and I tested
about
ten programs just now.

I think they were also tied into Internet Explorer, which I definitely
wanted to keep - I have Firefox, but I still prefer to use IE.

Incidentally, the two browse files I was refering to were "browseui.dll" and
"browselc.dll", and I think they were needed (at least if you were also
using IE).

I don't know if you were around when the issue of Windows Explorer "hanging"
when copying or deleting large numbers of files came up (with IE6), but
there was a pretty active discussion on this in this newsgroup. Some folks
recommended patching the shell32.dll instead, but as I recall, that did NOT
solve the problem for me, but swapping the IE6 versions of the two browse
DLLs with the IE55 versions most certainly did solve it.


But if one were running a slow 200 MHz CPU, and/or less than 256 MB of
RAM, Win95 might be quite a bit spiffier. But with a 800 MHz CPU, and
at least 256 MB of RAM, Win98SE was still pretty fast and lightweight.



I'll look at that too, but I like the W95 shell specifically for what it
is,
this wasn't just an avoidance move.

What's so unique about the Win95 shell in comparison to the Win98 shell?
(unless you're talking about how it might be a bit more nimble or faster.
I can't recall at this point in time as it's been a long time since I used
Win95.

My short test yesterday morning with the
swapped-back W98 shell wasn't exactly distressing though. I'll
experiment
with that again in the minimal core tests. The standard W98 shell also
appears not to need those 'Browse' DLL's. I haven't yet worked out what
would..

This surprises me. But you might be surprised to know that a copy of one of
those browse DLLs is also normally stored in the Program Files Internet
Explorer subdirectory too (not just in the Windows System folder), so maybe
it's using that one.

"Bill in Co" wrote in
m:

I think they were also tied into Internet Explorer, which I definitely
wanted to keep - I have Firefox, but I still prefer to use IE.

Incidentally, the two browse files I was refering to were "browseui.dll"
and "browselc.dll", and I think they were needed (at least if you were
also using IE).


Yes, those two... I always wondered what they were for. In my system, it
seems to be nothing. Could still be wrong, I'll keep a watch. Something
borked my FireFox install today, so it might well be me hiding them.

I don't know if you were around when the issue of Windows Explorer
"hanging" when copying or deleting large numbers of files came up (with
IE6), but there was a pretty active discussion on this in this
newsgroup. Some folks recommended patching the shell32.dll instead,
but as I recall, that did NOT solve the problem for me, but swapping the
IE6 versions of the two browse DLLs with the IE55 versions most
certainly did solve it.


I wasn't, but I have seen the problem a lot. I think whoever said that
Shell32 patching is the way to go is lilely right, even if it didn't patch
right. I have no idea how, but given where all the interdependencies are in
the W98 core, it would be VERY strange if the 'fix' involved a lot of high
level parts with many extra dependencies to fix trouble at the core. While it
apparently does, as you saw it do so, it suggets that some signal is sent to
the core that makes it work. But if that signal could be generated locally,
so much the better. I'd hoped a similar local method might fix that right-
click thing, and in a way it has, given that it correctly answers W98 shell
calls now, but the price has been a half-MB of extra sysfile. That's cheap
though, a lot of the higher level DLL's are way bigger than that, each alone.

What's so unique about the Win95 shell in comparison to the Win98 shell?
(unless you're talking about how it might be a bit more nimble or
faster. I can't recall at this point in time as it's been a long time
since I used Win95.


Several things, likely more than I know. First is cosmetic, it takes less
space showing bars and buttons, so it's really cool to have a quickly
assembled terrace of Explorer windows onscreen at one time for major complex
manual file management, organiusing backups, etc. The space saving is
extremely significant the moment I deal in multiple views, as is the response
time in handling them all.

More crucially, I learned today, is that the W95 shell, once active, has a
lot of dependencies. If you just want it to handle shell calls for program
dialogs, as I do, then four core files on top of the main base are enough,
plus 2 W95 shell files to show the GUI shell. If I want to use W98 to do that
GUI work, four is NOT nearly enough. When I saw 98-ite swapping a W98 shell
back in for active display, I felt slightly queasy at the rushing list of
files it was rooting out of CAB's. The difference in scale (and neatness)
might easily be an order of decimal magnitude, it's not just aa few percent
difference in space and resources.

Whatever the machine, less demands from the shell means more for programs and
actual work done. I never liked growing an OS to fill the available space.
What really makes me admire engineering is when I see a tiny locomotive
pulling a huge train. I thing an OS should be like that. W98 can
definitely be like that too, maybe more than any other OS, but I don't know
enough to judge that. W98 lets me have a go, so I do it because it's
manageable.


My short test yesterday morning with the
swapped-back W98 shell wasn't exactly distressing though. I'll
experiment
with that again in the minimal core tests. The standard W98 shell also
appears not to need those 'Browse' DLL's. I haven't yet worked out what
would..

This surprises me. But you might be surprised to know that a copy of
one of those browse DLLs is also normally stored in the Program Files
Internet Explorer subdirectory too (not just in the Windows System
folder), so maybe it's using that one.


I read something about them once, many years ago, and totally forgot what it
was. I'm thinking that hiding them from the system might be the fastest
reminder.

Lostgallifreyan wrote in
:

More crucially, I learned today, is that the W95 shell, once active, has a
lot of dependencies.

W98 shell! Probably clear from context, but that was an important typo not to
make.

In message , Lostgallifreyan
writes:
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.

I have experimented with soporific's "Windows 98 tenth anniversary
edition" (or name something very close to that). I found retrofitting it
to an existing system caused some problems (that system still borks when
trying to load - or reload - drivers, and I foolishly didn't back up
enough of it before playing: for once ERU/ERD didn't suffice), but one
system I built from scratch using it seemed very good. Unfortunately I
didn't have much opportunity to play with that as it was for someone
else. I think it uses the decim USB driver - it certainly was happy with
whatever USB drives I plugged into it - and it did include 98lite.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Freedom of the press is limited to those who have one.

In message , philo
writes:

"Lostgallifreyan" wrote in message
...
philo wrote in :

Rather than force an issue why not simply go with what you know works?


Did you also skim over the point about USB? If W95 was the right thing to
do,
do you think Shane Brooks would ever have bothered with 98-Lite? You're
not
thinking this through at all, or reading what is posted, so you're not in
a
good position to second-guess my needs and intentions.

Nope

I saw that but win95 osr2 does have USB support.

I've used it and it works. The only real issue I've had was that the mobo
had to be USB capable...
I've never gotten it to work with an add on PCI card.

I have a machine in my workshop with Win95 osr2 and have confirmed the USB
works...
it's not speculation or second hand info


95OSRrR2 just about manages USB support - I remember getting it going,
and doing so at all felt like a considerable achievement. However, 98
does it better (though still not well).
--
J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

Freedom of the press is limited to those who have one.

"J. P. Gilliver (John)" wrote in
:

I have experimented with soporific's "Windows 98 tenth anniversary
edition" (or name something very close to that). I found retrofitting it
to an existing system caused some problems (that system still borks when
trying to load - or reload - drivers, and I foolishly didn't back up
enough of it before playing: for once ERU/ERD didn't suffice), but one
system I built from scratch using it seemed very good. Unfortunately I
didn't have much opportunity to play with that as it was for someone
else. I think it uses the decim USB driver - it certainly was happy with
whatever USB drives I plugged into it - and it did include 98lite.


Thankyou, that suggests I might make it go. I'll follow leads from what I
have as base install, haven't got hardware stuff in there at all yet, but I'm
definitely making sure that the nase will be ready for easy standard install
of Maxim Decim. It looks like its files match with the "sesp21a-en.exe" set,
which I extract from to build the core. I want the base to be easily
extenable, but as minimal as possible. Until I get some success in hardware
driver experiments, it will be hard to know where the safe margins are. W98
seems fairly modular though, more than MS seem to have wanted us to believe.

Lostgallifreyan wrote in
:

This fixes the right-click crash because all standard callsto the W98
shell work as they expect to, so no proghram files have to be edited
either. If anyone knows Shane Brooks, point him this way, he might like
this one.


Belay that last suggestion, I now KNOW he would like it. I just discovered a
small file called 'Sleekv2' that was part of later versions of 98-Lite. He
does the same thing that I discovered, and for the same reasons (newer
functions in W98's Shell32.dll. I guess some wheels are worth reinventing.
Looking in the files directly, it really is exactly the same move. All three
internal SHELL32 references in EXPLORER.EXE, and the same file versions too,
latest known.

If anyone reads this, and is using W98 with the Sleekv2 or has done what I
described, and notices any oddities with refreshing of content of directories
inside file dialogs, especially the Desktop view (i.e. NOT the
Windows/Desktop subdir but the actual Desktop itself as seen in the dialog
pane), please post because while this isn't bad like the right-click crash,
it is weird, and I imagine that any 98-lite install with the 'Sleekv2' W95
shell swap will do this too.