Hi there. I didn't mean to hurt anyone's feelings here, my apologies if I did. 😥
I rather explained my point of view, which isn't necessarily correct.
However, I also can't deny what I know/remember from back then.

Windows 3.1 and Win32s were available to developers before Windows NT 3.1 and Windows 95.
So in reality, this was the original Win32 platform 32-Bit programs were being written to.
And Windows 95 isn't even true Win32, it's Win32c.

Then there's PCI. It's not just "another bus". It's a new architecture, essentially.
PCI used different types of interrupts (INTs rather than IRQs) and supported bus mastering and uses IDs, complete with text strings for the PCI cards.

The Pentium processor, as typically found on PCI motherboards, adds support for a new Programmable Interrupt Controller and a new System Timer.
https://en.wikipedia.org/wiki/Advanced_Progra … ller#APIC_timer

All in all, it's essentially a different type of x86 PC platform. Like Japanese PC-98 with its C-Bus, which differs from PC/AT with ISA.

That's why emulators like Qemu/Bochs has a separate machine type for it ("ISA PC").

That's what I meant to say. An 386/486 PC with ISA or VLB (or anotger local bus like Opti bus) is another platform.
Strictly speaking, classic x86 PCs ended with those traditional, non-PCI motherboards.
They're the last with native ISA bus, also. More or less, I mean.

Okay, strictly speaking, ISA runs natively on an 80286 PC without chipset only.
Any chipset with a memory controller insulates the processor's front side bus from the peripheral bus (ISA in that case).
Because doing so, the chipset can hide/set aside/re-map Extended Memory from the 80286 processor to simulate EMS or Shadow Memory.

Likewise, the PCI-ISA bridge found on Pentium motherboard does insulate ISA from the CPU.
All the IRQ/DMA stuff etc. is being done by the help of that bridge.
All other busses, EISA, MCA, VLB, Opti etc. do rather work in tandem with ISA, they're not controlling it.
That's why I said PCI was an alien technology (to Windows 95).
It's not just another slot/bus. It's a new x86 platform.

And Windows 95 was heavily being developed on in 1993/94, using Windows 3.1x/WfW 3.11 as a basis
(see Alpha and Beta builds of Chicago, Beta Archive etc. have documented them).
Both of which were not designed for PCI at the time. Or Plug&Play.
The PCI support and the drivers basing on it were new and not fully tested.
Yes, they worked. Their maturity is another question, though..
"Where do you want to go today?" was more like "Where do your IRQs want to end up today?".

Windows 95/Chicago was no new, ingenious development, it was an intermediate solution.
A hack (a remarkable one, albeit, I admit). Windows NT was supposed to replace it ASAP.

The separation into a "consumer" and "professional" line of Windows was just good marketing, it was not cleverly planned.
DOS-based Windows was meant to die in the 80s, altogether.
Unfortunately, the OS/2 dilemma, the success of Windows 3.0 and the slow development of NT made Windows 95 a necessity.

1993/94 were still pretty much still 486/VLB days.
http://dosdays.co.uk/topics/pc_buses_explained.php#VLB

I'm not saying thus that Windows 95 had to be limited to a 486 CPU
(though 586 introduced more complicated cache/pipeline/in-order or out-of-order execution) .
It's the motherboard that causes trouble/stability issues.

A 586 class CPU on a 486 era motherboard is more or less fine.
A Pentium Overdrive or 5x86 etc could be used here.

Or in other words: A 386/486 motherboard with ISA/VLB needs no chipset drivers!
To software, it's a generic PC motherboard.
With PCI motherboards, all the chipset driver drama slowly started.
(Edit: Except to those OSes not aware of it;
DOS and Windows 3.1x rely on BIOS mainly or use drivers with integrated PCI-support.)

Hm. I'm not sure if my wording is good to read. I hope so. 🤷‍♂️

Edit: Typos/formatting fixed (on PC).

If you summarized what you said as Windows 95 on it's retail release day could not run the chipsets that came after (except maybe slower), I would agree with you. Your one example is plug & play, that was a current evolving technology. The plug & play BIOS was not available for manufacturers until after Windows 95 came out! So Windows 95 was using the plug & play spec based on what was currently available, without BIOS support because it wasn't there. The PCI bus support, while had to be supported in DOS (through BIOS or whatever) before Windows 95, did not have to ship with Windows drivers, after Windows 95, this platform support started evolving in a different legacy BIOS free direction where it made sense, and since Windows 95 was a different platform, drivers would be written for these later revisions of chipsets to access full functionality for Win9x. This is in essence very similar to the vcache issue. It was fine for PCs at release. However I noticed the issue with system resources in the very late 90s where upgrading to having alot more memory in the system. Yes Win95 gets more deficient when as you go later. This doesn't make it a fault of the OS it could not drive later stuff it was not expecting on the retail or point oem releases.

The OP was mostly concerned about the memory usage and leaks in Windows 95.

64-128 megabytes is plenty enough memory, and with proper adjustments to the cache and other memory management related settings the OS runs really well. Cacheman is really just a GUI front-end to adjusting parameters and settings already present within the operating system itself, so if one had to argue, I would make the case that the system default settings were simply poorly chosen, which makes the memory management appear a lot worse than it really is. IMO this has always been the case though, with practically every version of Windows.

Maybe we need another topic for discussing the development and technical merits of the Windows-lineage to keep the thread from being derailed?

To summarize, this is what I hoped the OP would take away:

- Windows 95 (B/C) runs beautifully on Pentium/Pentium II/Pentium III era hardware, it is technically Windows 98 (or Win98 is Win95 with changes)
- Memory management out-of-box needs a couple of tweaks for best performance
- Measurable slow-down in GUI operations and increased memory use result if Internet Explorer installed, as well as a lot of additional bugs/security vulnerabilities

If I had to use a web browser on the platform, I would go with Opera 9/10. It is a much better browser with a much smaller footprint and much better standards compliance than IE. IE/Netscape are the nostalgia choices.

leonardo wrote on 2023-05-29, 12:53:

- Windows 95 (B/C) runs beautifully on Pentium/Pentium II/Pentium III era hardware, it is technically Windows 98 (or Win98 is Win95 with changes)

No, it's not, even though it may look indeed that way.
Windows 98/SE has an overhauled memory management (in the link it's being explained in detail).

Anyway, it doesn't matter anymore. I'm tired of arguing here. 😴
You guys are free to believe what you want.
You have your experience, I have mine.
They don't necessarily have to be the same.

Edit:

leonardo wrote on 2023-05-29, 12:53:

Maybe we need another topic for discussing the development and technical merits of the Windows-lineage to keep the thread from being derailed?

Translated that means "go pack your things and leave"? Just kidding. 🙂
Ok, ok, I understand. I'm quiet now and won't talk about this anymore.
I was talking in defense, anyway, explaining my reasoning.

"Derailed".. Um-yes.. 🙄
That makes it sound as if we had started talking about something completely irrelevant here.
But RAM and bus systems are related to each others, at least.
PCI Shadow Memory is used for providing UMBs, for example. Peope use UMBPCI all the time here.

Anyway, as far as I'm is concerned, I must pass.
I haven't enough time and energy to educate others (it's also not my style).
And personally, I'm also too exhausted to constantly keep being diplomatic all the time if being confronted with un-logic. 😓
I think I'll make a pause for a while.

Jo22 wrote on 2023-05-29, 19:16:

... […]
Show full quote

...

Translated that means "go pack your things and leave"? Just kidding. 🙂
Ok, ok, I understand. I'm quiet now and won't talk about this anymore.
I was talking in defense, anyway, explaining my reasoning.

"Derailed".. Um-yes.. 🙄
That makes it sound as if we had started talking about something completely irrelevant here.
But RAM and bus systems are related to each others, at least.
PCI Shadow Memory is used for providing UMBs, for example. Peope use UMBPCI all the time here.

Anyway, as far as I'm is concerned, I must pass.
I haven't enough time and energy to educate others (it's also not my style).
And personally, I'm also too exhausted to constantly keep being diplomatic all the time if being confronted with un-logic. 😓
I think I'll make a pause for a while.

Don't take my writing in a negative way - I could have worded my reply better. Maybe 'diversion' would have been a better choice? Anyway, maybe the OP found all the stuff fascinating. I do too - but sometimes when I search information on a specific topic only to find pages and pages of replies that have little to do with the original question or title of the topic - well - I just thought what you were writing about would deserve a thread of its own. I mean that in the best possible sense.

I love debating stuff and getting educated in the process. 😀

Well... to get back on topic, last weekend I restored my original WIN95 image from my Ghost server onto a spare hard drive. As usual, I used a Compaq C500 that happened to have 64MB of RAM.

Since the image was originally on a tower (long gone) with an AMD CPU, Trio 9750 video, AWE64 soundcard and no network (didn't have internet in those days), I didn't know how it would handle an Intel Celeron, Intel inbuilt video and sound, and a Intel PCI network card. Thankfully it didn't throw a fit, instead it installed various drivers with a reboot every now and then. When it was done there was no network, no sound, and 16-colour video. But it was otherwise working. I have the other hardware drivers, and no issue getting them in and working. I found that IE5.5 was included, so it finally got onto the internet for the very first time. After that, various other software was installed, plus USB-stick support, so in the end it works quite well for what it is.

After seeing this story of leakages, I started up the system monitor to see what this one did. I could see the swapfile grow, but after waiting about 1-2 minutes it would be released. Same with memory usage. So, if there's supposed to be a leakage issue, I couldn't see it.

I was impressed how well it handles a massive hardware change. And no need to re-activate it either!

Robbbert wrote on 2023-05-30, 05:55:

Well... to get back on topic...
After seeing this story of leakages, I started up the system monitor to see what this one did. I could see the swapfile grow, but after waiting about 1-2 minutes it would be released. Same with memory usage. So, if there's supposed to be a leakage issue, I couldn't see it.

It looks like I misremembered Nathan's note being about memory, rather it was about system resources. He cites a broken Common Controls Library (comctl32.dll, 5.80), which shipped with some versions of IE as a cause for having to constantly reboot his system. Whether this particular issue was fixed with later releases of IE, or the Common Controls Library, I'm not sure as I've stuck to not running IE on Windows 95-installations myself, but he does supply a version of the DLL he claims does not suffer this problem. I went and dug up the exact page where this issue is talked about.

To my understanding 'system resources' does not directly correlate with available memory, but is some kind of abstraction or reference to internal handles within Windows. Maybe someone has a good explanation for what those actually are or what they do? 😀

That could be very interesting, and perhaps it might solve a WIN95 issue that I have. I won't be able to get back to those computers until next Sunday, but I can describe the problem.

I have 2 other hard drives which have WIN95 images, originally from my old workplace. Recently I went through everything to install a common suite of useful programs (as far as could be made to work), and this us what happened:

7z (9.20) - On WIN95, there's no text in the menus or dialogs. For example where you choose what extensions to support, the screen is blank and clicking OK crashes it.
K-Meleon - On WIN95 the menus and many icons are missing. If you type in a URL, pressing Enter or "Go" does nothing.

So I just assumed that 95 simply wasn't able to run these programs. But with the new image that I talked about 2 posts up, these programs work perfectly. Which means there's something wrong with the other ones.

I wonder if this DLL has something to do with it... I'll have to check next week.

Robbbert wrote on 2023-05-30, 10:31:

That could be very interesting, and perhaps it might solve a WIN95 issue that I have. I won't be able to get back to those compu […]
Show full quote

That could be very interesting, and perhaps it might solve a WIN95 issue that I have. I won't be able to get back to those computers until next Sunday, but I can describe the problem.

I have 2 other hard drives which have WIN95 images, originally from my old workplace. Recently I went through everything to install a common suite of useful programs (as far as could be made to work), and this us what happened:

7z (9.20) - On WIN95, there's no text in the menus or dialogs. For example where you choose what extensions to support, the screen is blank and clicking OK crashes it.
K-Meleon - On WIN95 the menus and many icons are missing. If you type in a URL, pressing Enter or "Go" does nothing.

So I just assumed that 95 simply wasn't able to run these programs. But with the new image that I talked about 2 posts up, these programs work perfectly. Which means there's something wrong with the other ones.

I wonder if this DLL has something to do with it... I'll have to check next week.

Which DLL are you referring to? The only DLL kind of referred to in this thread is the IE4+ update. And yes, there were bugs in IE4+. But as its APIs got introduced and standardized, it is not completely avoidable. If you had to add IE back in the day, you installed without IE first, and then went to install the very latest version Microsoft provided, and disabled the desktop enhancements. It was a bit easier when IE5 came out to do this, but I don't believe it squashed all the bugs. But some apps may run then.

@leonardo : your suggestion bore fruit. The 2 non-working WIN95 machines used comctl32 ver 4.70 and 4.72 respectively, while the working machine used 5.81

Both non-working machines had IE 3.0 as their browser. On one machine I upgraded to 5.5 SP2, which fixed the 7zip issue and the usability of K-Meleon issue. It also fixed msconfig not working. The other machine doesn't have enough space so I only upgraded the comctl32 file instead. Winzip then started complaining of a missing entry point, so the old version was copied into the Winzip folder. The only issue left is the missing icons in K-Meleon, but that's not a major problem.

Flushed with success I decided to look into a problem with 2 of my XP machines - the symptoms being (1) no dialogs in the search screen, so impossible to search (2) blank info in the IE8 About screen (3) Windows Media Player versions 9 and 11 crash at start. The search problem turned out to be the search assistant UI dll not being registered. Surprisingly, fixing that fixed the other problems as well. I don't see how it's related, but we all know windows works in mysterious ways.

Robbbert wrote on 2023-06-06, 05:42:

@leonardo : your suggestion bore fruit. The 2 non-working WIN95 machines used comctl32 ver 4.70 and 4.72 respectively, while the working machine used 5.81

Both non-working machines had IE 3.0 as their browser. On one machine I upgraded to 5.5 SP2, which fixed the 7zip issue and the usability of K-Meleon issue. It also fixed msconfig not working. The other machine doesn't have enough space so I only upgraded the comctl32 file instead. Winzip then started complaining of a missing entry point, so the old version was copied into the Winzip folder. The only issue left is the missing icons in K-Meleon, but that's not a major problem.

This is super interesting, because none of my machines with Windows 95 have any version of IE installed, and thus probably remain at the 4.72 version of comctl32 I think. Running 7Zip on them is still not an issue. The IE update you performed must have fixed some other inherent problem in those installs.

For K-Meleon I cannot say as I have not tested it in a long time, but I seem to recall that this was a program that ironically required one to have Internet Explorer installed (install another browser to use our alternative browser?, eww - no thanks) hence why I would have originally gone with Opera instead.

Anyway, I'm glad you at least found some kind of solution to your problem!

Hi, this is the author of this topic 😁
After a lecture of all posts here and some experiments I came to the conclusion that the main issue is Internet Explorer.
The second thing is probably driver or software memory leaks. Like I mentioned earlier, in 2002 (or '03 don't remember) I had 486 66 MHz with 36MB of ram and it fast crazy fast given the slow CPU.
For me the next logical step is going to be IE removal and trying vcache tweaks.

I did the vcache thing on one machine and it made a little improvement, so good luck with that.

When I did the work in my last post it was on the machine with insufficient disk space, so I simply copied the comctl32.dll from the fully-working machine onto this one, and saw that it healed most problems.

Then I did the other machine and I was hoping that installing IE5.5 might fix the remaining issue but it was not to be. As we know, IE less than 8 is almost entirely useless, so you should be able to remove yours, as long as it doesn't mess with your DLLs.

It's a pain that upgrading IE was the best way to get better DLLs, but of course back then there was no automatic updates, and not everyone even had internet access (I didn't) - so getting IE upgrades did the job instead - as awful as that idea sounds.

Of course the end result is that everyone's WIN95 installations were a hodge-podge of mixed-up upgrades and DLL hell. Windows has come a long way since then - at least in that way.

winuser_pl wrote on 2023-06-06, 14:47:

The second thing is probably driver or software memory leaks. Like I mentioned earlier, in 2002 (or '03 don't remember) I had 486 66 MHz with 36MB of ram and it fast crazy fast given the slow CPU.
For me the next logical step is going to be IE removal and trying vcache tweaks.

My original revelation came with a Pentium and 32 megabytes of RAM. Before installing IE and the desktop update, it was really snappy. Afterwards it was slow as molasses, constantly swapping.

You're going to be best off by doing a clean installation of Windows 95 without ever installing IE. I've aped the instructions from Nathan's MAD IE De-integration Lab onto my Windows 95 install guide here on the forum (see section 2.2 Modifying setup files to remove IE).

Robbbert wrote on 2023-06-06, 16:50:

It's a pain that upgrading IE was the best way to get better DLLs, but of course back then there was no automatic updates, and not everyone even had internet access (I didn't) - so getting IE upgrades did the job instead - as awful as that idea sounds.

Of course the end result is that everyone's WIN95 installations were a hodge-podge of mixed-up upgrades and DLL hell. Windows has come a long way since then - at least in that way.

There is a really well put-together rollup of the OSR2 updates by Noel Piring that takes care of this for Windows 95. It is not a Frankenstein-hodge-podge of backports and hacks, but a collection of all the official updates and patches, together with some tools and utilities. You can find the now-archived page here and the download (OSR2SP1L.EXE) itself here.

I cannot emphasise how much trouble you'll save if you install the necessary updates using this, as opposed to picking them individually from random sources and figuring out what comes before or after what else. The only downside is that this is for the English language version of Windows 95, so if you have a localised version there could be issues...

leonardo wrote on 2023-06-06, 17:14:

The only downside is that this is for the English language version of Windows 95, so if you have a localised version there could be issues...

Thanks for the links. My 3 WIN95 are all version B, so I'll try out the pack on one that has enough disk space.

leonardo wrote on 2023-06-06, 17:14:

My original revelation came with a Pentium and 32 megabytes of RAM. Before installing IE and the desktop update, it was really s […]
Show full quote

winuser_pl wrote on 2023-06-06, 14:47:

The second thing is probably driver or software memory leaks. Like I mentioned earlier, in 2002 (or '03 don't remember) I had 486 66 MHz with 36MB of ram and it fast crazy fast given the slow CPU.
For me the next logical step is going to be IE removal and trying vcache tweaks.

My original revelation came with a Pentium and 32 megabytes of RAM. Before installing IE and the desktop update, it was really snappy. Afterwards it was slow as molasses, constantly swapping.

You're going to be best off by doing a clean installation of Windows 95 without ever installing IE. I've aped the instructions from Nathan's MAD IE De-integration Lab onto my Windows 95 install guide here on the forum (see section 2.2 Modifying setup files to remove IE).

Robbbert wrote on 2023-06-06, 16:50:

It's a pain that upgrading IE was the best way to get better DLLs, but of course back then there was no automatic updates, and not everyone even had internet access (I didn't) - so getting IE upgrades did the job instead - as awful as that idea sounds.

Of course the end result is that everyone's WIN95 installations were a hodge-podge of mixed-up upgrades and DLL hell. Windows has come a long way since then - at least in that way.

There is a really well put-together rollup of the OSR2 updates by Noel Piring that takes care of this for Windows 95. It is not a Frankenstein-hodge-podge of backports and hacks, but a collection of all the official updates and patches, together with some tools and utilities. You can find the now-archived page here and the download (OSR2SP1L.EXE) itself here.

I cannot emphasise how much trouble you'll save if you install the necessary updates using this, as opposed to picking them individually from random sources and figuring out what comes before or after what else. The only downside is that this is for the English language version of Windows 95, so if you have a localised version there could be issues...

I think you really start to notice the need of a fast 2D card with the IE5 update. Even chipsets that ppl think aren't much different like GL5430 to GL5434 and TGUI 9440 and TGUI9680 were quite a difference between earlier and later models. Not sure if that was early direct draw support or something.

I do remember having got an OSR 2.5 install up to a state where it would run anything that claimed it needed 98 or better, that was until DX8 or 9 came out though. By then it was almost 98 anyway with working USB and various patches. There didn't seem a point in throwing much more memory than 64MB at it as I recall, it just behaved worse.

Best Win95 system I've ever run was/is a Pentium 60 on an Asus P5MP3 board, that one is smooth like butter. Even when you load it beyond the capability of the P60, it plods smoothly. None of this appear frozen then everything happens at once after staring at it for 90 seconds crap. Just.. the... events... spread... out... but... it... still... keeps... going... kind of thing.

leonardo wrote on 2023-05-30, 09:54:

To my understanding 'system resources' does not directly correlate with available memory, but is some kind of abstraction or reference to internal handles within Windows. Maybe someone has a good explanation for what those actually are or what they do? 😀

If you run Programs -> Accessories -> System Tools -> Resource Meter, you'll see those vague terms "System resources", "User resources" and "GDI resources". Yes, on the surface I guess it's related to handles. From the article below, I think the issue is that when you ask Windows 95 to allocate some types of object, it will allocate them from the global heap (giving you a handle) and that means it's limited only by your RAM + swap, but some other objects are allocated out of smaller pools of memory for some compatibility reasons.

From the Microsoft Windows ‘‘Chicago’’ Reviewer’s Guide (link to tech-insider.org which seems like an interesting site with historical press releases or something):

To help reduce the system resource limitation, a number of the data structures stored in the 16-bit GDI and USER heaps in Window […]
Show full quote

To help reduce the system resource limitation, a number of the data structures stored in
the 16-bit GDI and USER heaps in Windows 3.1 have been moved out of these heaps
and stored in 32-bit heaps, providing more room for the remaining data elements to be
created. Users will see improvements by not encountering a decrease in system
resources as rapidly as they may have seen with Windows 3.1.

All objects were not simply removed from the 16-bit GDI or USER heaps, and placed
in 32-bit heaps for compatibility reasons. For example, there are some Windows–
based applications that manipulate the contents of the GDI heap directly, bypassing the
published API mechanisms for doing so. These application vendors to do this for
perceived performance reasons. However, because they bypass the Windows API
mechanisms, moving the data from the existing heap structures and placing them in 32-
bit heaps would cause the existing applications to fail due to memory access violations.

Both Win16 and Win32–based applications use the same GDI and USER heaps. The
impact of removing selected items from the heaps was closely examined and objects
were selected based on the biggest improvement that could be achieved, while
affecting the fewest number of applications. For example, the GDI heap can quickly
become full due to the creation of memory-intensive region objects that are used by
applications for creating complex images and by the printing subsystem for generating
complex output. Regions have been removed from the 64K 16-bit GDI heap and
placed into a 32-bit heap, benefiting graphic-intensive applications and providing for
the creation of more smaller objects by the system. Chicago improves the system
capacity for the USER heap, by moving menu and window handles to the 32-bit USER
heap, raising the total limit of these data structures from 200 in Windows 3.1, to a total
limit now of 32,767 menu handles and an additional 32,767 window handles per
process rather than system wide.

There's a bit more information there about system resources too.

I found that article on a TechNet CD initially, and while TechNet seems to have similar text to the above, it also has a table comparing the limits for different types of things like items per listbox, installed fonts, etc. between Windows 3.1 and 95.

For anyone interested in such things, if you read that whole article you might get some laughs about the things that Microsoft considered to be great improvements at the time, as we'd probably look back and say that for example Windows 95's "System-wide Robustness Improvements" were incremental and nothing like what we'd expect today. I guess it also has beta version screen shots too, unless they're actually just mock-ups - I see diamond-shaped radio buttons!