Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday August 25 2015, @03:09PM   Printer-friendly
from the just-out-of-the-teens dept.

It was twenty years ago yesterday (August 24, 2015) that Windows 95 was introduced, says El Reg.

Windows 95 was a great success, despite not being the most stable of operating systems. Microsoft's own Windows NT 3.1, released two years earlier, was built on stronger foundations, but high system requirements and lack of compatibility with many DOS applications and games made it unsuitable for consumers. Windows 95 was better in both respects, running in as little as 4MB of RAM – though painfully, with 8MB a more realistic minimum – and retaining DOS complete with 16-bit device driver support.

At the time, most PCs ran Windows 3.1 or 3.11 (Windows for Workgroups), and IBM was pushing OS/2 as a "better Windows than Windows". Windows 95 was a considerable improvement on Windows 3.x, with pre-emptive multitasking, mostly 32-bit code, and plug and play hardware detection. There was also new support for "portable computers", with a battery indicator on the taskbar and the ability to suspend the system without turning it off completely.

Perhaps what I'm going to say will be controversial, but I'm of the opinion that Windows 95 is the greatest software engineering feat ever, given the challenge Microsoft faced at that time. Unlike Apple, which continues to make its own computers, Microsoft did not and, therefore, had to do a vast amount of testing in order to ensure that Windows 95 would work on most existing 32-bit Intel machines.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by darnkitten on Tuesday August 25 2015, @05:13PM

    by darnkitten (1912) on Tuesday August 25 2015, @05:13PM (#227680)

    The last person I was personally aware of that used Windows 95 died a couple of years ago--still have 2 or 3 locally that I know use Win 98, as well.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Tuesday August 25 2015, @10:11PM

    by Anonymous Coward on Tuesday August 25 2015, @10:11PM (#227816)

    I have been under the impression that all of the 9x-era APIs have been covered by the WINE guys for quite some time now.

    I asked the other day if anyone had an example of a app that will run under 9x but won't run via WINE.
    I am still interested to know of any such cases.

    In particular, if a network connection is required to use a 9x-compatible app, then running an OS that has zero security doesn't sound like a great notion.

    -- gewg_

    • (Score: 3, Interesting) by Marand on Wednesday August 26 2015, @05:14AM

      by Marand (1081) on Wednesday August 26 2015, @05:14AM (#227972) Journal

      I have been under the impression that all of the 9x-era APIs have been covered by the WINE guys for quite some time now.

      I asked the other day if anyone had an example of a app that will run under 9x but won't run via WINE.
      I am still interested to know of any such cases

      I can't think of any specific examples, but I remember having problems with anything using DirectX 7 or below in wine. Wine itself doesn't have direct support like it does for DX8 and 9, and trying to install the real thing doesn't always work out. Realistically, it's a problem only for a small subset of old games that adopted DirectX in the time between the end of DOS games and the adoption of DirectX 8, and luckily some of those came with OpenGL or software renderers, too.

      Past that DirectX 8 threshold, though, wine is actually better than Windows at handling old games in my experience. Setting the OS version via winecfg to Windows 98 makes a lot of old games and installers work, and seems to do so even more reliably than the Windows compatibility modes. Old games that require workarounds, DLL patches, and have other issues will often work with less trouble in wine, and the fake desktop option in wine is helpful for running old fullscreen-only games.

      • (Score: 0) by Anonymous Coward on Wednesday August 26 2015, @07:42AM

        by Anonymous Coward on Wednesday August 26 2015, @07:42AM (#228004)

        +1 Interesting.

        wine is actually better than Windows

        I've known more than 1 person to say that.

        more reliably than the Windows compatibility modes

        There was once a "WINE for Windoze" port^W effort that I have assumed was meant to address this.
        I don't think it ever got all that far and I don't think it's gotten much love from developers for several years now.

        -- gewg_ (who is not a gamer at all)

        • (Score: 2) by Marand on Wednesday August 26 2015, @11:07PM

          by Marand (1081) on Wednesday August 26 2015, @11:07PM (#228332) Journal

          wine is actually better than Windows

          I've known more than 1 person to say that.

          It's a rather weird situation, because in a lot of ways it's still not as good as the "real thing", because you often have to do a lot of tinkering to make apps work, and even when they do work it's possible that you'll get odd visual problems or that performance will be lower (sometimes it does things on CPU that are otherwise hardware accelerated in native Windows, for example). It's also at a disadvantage because applications often do non-standard things based on quirks in Windows itself to improve performance or do unusual tasks, so a 100% "pure" implementation won't always work properly, forcing wine devs to implement the same problems and undocumented quirks for compatibility reasons

          However, other things sometimes run better for some of the same reasons. Differences in the underlying OS and missing Windows quirks can also make other applications faster. For example, back in the Linux dark ages, I used to use wine to run winRAR and the "lame" audio encoder because of a lack of native support, and they both did their jobs 20-30% faster that way vs. native Windows on the same machine. I always figured it was mostly due to differences in the filesystems more than wine improvements, but it's an example that stood out at the time.

          What really makes wine awesome, though, is how well it works for its Windows version faking and virtual desktop modes, along with the $WINEPREFIX concept. You can install multiple wine "OSes" in their own directories, which lets you isolate windows applications within their own "Windows" containers. That way, you can isolate badly behaving games that need strange workarounds, or ones that need to run fullscreen and don't work well with modern display resolutions, etc. That tends to improve multi-tasking as well, because it makes the alt-tab behaiour much cleaner than how Windows handles alt-tabbing from fullscreen games.

          You also get the benefit of other tools on the system; I've used it to run old games that were forced to 640x480 resolution by running the game in a prefix that was isolated to a fake "desktop" in a window, and then using kwin's screen magnifier (one of the compositing effects) to zoom in until the game was actually playable. Furthermore, it means you can sandbox untrusted applications by removing a wineprefix's access to the rest of your filesystem, or install multiple versions of an application simultaneously that normally won't allow it (such as Internet Explorer).

          So, it's not a catch-all "this is better" but there are specific circumstances where wine actually wins over trying to run software in Windows.

          There was once a "WINE for Windoze" port^W effort that I have assumed was meant to address this.
          I don't think it ever got all that far and I don't think it's gotten much love from developers for several years now.

          That, if I remember correctly, died fairly long ago, which is a shame. In addition to the compatibility benefits, it could have given people a way to get newer DirectX features (or other software) on older versions of Windows. DirectX is the biggest carrot Microsoft uses to "encourage" people to update to versions of Windows they otherwise don't want, and anything that interferes with that is a win for the end user.

      • (Score: 2) by TheRaven on Wednesday August 26 2015, @09:54AM

        by TheRaven (270) on Wednesday August 26 2015, @09:54AM (#228036) Journal

        Realistically, it's a problem only for a small subset of old games that adopted DirectX in the time between the end of DOS games and the adoption of DirectX 8

        That's a big gap. DirectX 3 was about when DirectX games started to be more common than DOS games for new releases (I remember it well, because I dual-booted DOS and NT4 and the lack of DirectX 3 in NT4 for a long time - until SP3, and even then it didn't include Direct3D - meant that there were a lot of games I couldn't play). From DirectX 3 to DirectX 8 is a 4-year period from 1996 to 2000, when a lot of good games were released.

        --
        sudo mod me up
        • (Score: 2) by Marand on Wednesday August 26 2015, @07:22PM

          by Marand (1081) on Wednesday August 26 2015, @07:22PM (#228223) Journal

          That's a big gap. DirectX 3 was about when DirectX games started to be more common than DOS games for new releases (I remember it well, because I dual-booted DOS and NT4 and the lack of DirectX 3 in NT4 for a long time - until SP3, and even then it didn't include Direct3D - meant that there were a lot of games I couldn't play). From DirectX 3 to DirectX 8 is a 4-year period from 1996 to 2000, when a lot of good games were released.

          Right, but it isn't a problem for all of those games. The non-3d parts of DirectX are usually no problem, from what I remember, and wine has gotten better at installing running old d3d versions over time. I mostly had trouble with d3d6 and 7, but it's been a while since tried so the gap has probably shrunk since then. It's possible that between VMs and wine we'll eventually have full coverage of that era if we don't already. Maybe even cover it entirely by wine one day.

    • (Score: 2) by urza9814 on Wednesday August 26 2015, @05:21PM

      by urza9814 (3954) on Wednesday August 26 2015, @05:21PM (#228169) Journal

      I have been under the impression that all of the 9x-era APIs have been covered by the WINE guys for quite some time now.

      I've got one! Organizer's Database. It's some super basic VB6 database app...but I haven't been able to get the damn VB6 JET drivers to run in Wine -- just gives an error that it can't find the DLLs. I've hit the same error on Windows and resolved it by installing an old copy of the VB6 runtime, but that doesn't do it on Wine. Haven't spent a ton of time looking into it though so there might be some way to get it to run, but it's not an application that enough people still use to be able to just google for instructions. I can't find much of anything at all about VB6 JET drivers in wine.

      Really wish I could get that working though, there's a few groups that I suspect would *really* appreciate a remote instance of that app running on a Linux VPS.

  • (Score: 1, Informative) by Anonymous Coward on Wednesday August 26 2015, @01:06AM

    by Anonymous Coward on Wednesday August 26 2015, @01:06AM (#227897)

    Have an old ThinkPad that runs Win 98SE -- it never goes online, only talks to a nice ledger size (11" x 17") printer/copier/scanner with autofeeder, over an Ethernet direct cable (no network). Files go back and forth by USB stick (I saved some older PNY sticks that have drivers for 98SE).

    The 98SE machine also runs an early version of Acrobat for converting scans into PDFs (as images). If I want OCR, that is faster with a newer machine.

    Have had a few BSODs, but not many.