this post was submitted on 24 Aug 2023
507 points (96.3% liked)
Technology
59168 readers
2133 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
32 bit
But yes, rebooting for everything, including changing monitor resolution was a pain
This might come as a shock to you, but Windows 95 isn't even an operating system. It's a GUI shell that runs on DOS, which is a 16 bit operating system. There is no Windows 95 kernel.
It’s a bit more complex than that. Intel CPUs (to this day) boot in real mode, which is what DOS is using. In this mode, the system only has access to 640k of RAM. Windows 95 and later switch the processor to protected mode, where the system gets access to all of the RAM and also to memory protection features, so processes can’t real and write each other’s memory. However, in this mode it’s impossible to run real mode code, such as the one provided by DOS.
DOS games had a trick where they briefly switched back to real mode to execute DOS functions (mostly reading and writing to disk) and then back to protected mode, but I don’t think that Windows 95 did that.
Preferred DOS 6.22. Win95 was glorified Win3.11FWG
I used DesQview in DOS and then switched to OS/2 Warp when it came out. DesQview was really cool.
DOS 7 was 32-bit.
32 bit hacked and kludged onto a 16 bit system that was still MS-DOS at the core. It was a mess. A highly unstable "wonder how it's even working" mess. The "lol Windows always bluescreens" memes came from this era because of this. The switch to NT and pure 32 bit from boot to desktop for consumer OSes with Windows XP made the stability issues mostly a thing of history unless you had bad drivers or hardware.
And then starting with Vista, Windows went to 64 bit. It was a complete rewrite of Windows and is way more stable because it requires every driver to be signed by Microsoft. You can disable the signed driver requirement, but then you're risking stability.
It wasn't a complete rewrite of Windows.
Maybe if it was your first NT-based Windows, like you previously had 98 or ME or something, then it might appear that way.
But Vista was a fairly incremental update. Lots of things changed but nowhere close to a complete rewrite.
It was a whole new kernel. They didn't rewrite every single utility, but the kernel was a rewrite along with things like diskpart and the boot loader. The core of the OS. They also dumped all of the old 16 bit legacy apps.
I would like to see a source for that. I know they rewrote critical subsystems (like the audio and video stack), but the whole kernel? I don't think so.
Also, the part no one ever brings up: No per-program volume control. Ugh. That was so actively irritating until they finally added it (was it in XP? or not until 7?)
No per-program volume control was entirely the fault of whatever program you were using, not Windows. The Windows audio API supported global and application-level volume from the beginning with Windows 95 (even Windows 3.1 had it). Even if Windows 95 had not had application-level volume control, a developer could have implemented it for their application since they were composing the audio data sent to the API for playback (in other words, they could have just attenuated all the sample values to a lower volume).
Do you change your IP address, like, ever? DHCP and forget over here in my homelab. I do have like four reservations but they never change.