4 ms·

>"most Windows 95 applications still run fine in Windows 10" Uhm, no. Not really. With hacks by the user (or OS) maybe, but if hacks are allowed then most of t

by Dahoon 8y ago

>"most Windows 95 applications still run fine in Windows 10" Uhm, no. Not really. With hacks by the user (or OS) maybe, but if hacks are allowed then most of that list can be deleted.

hartator 8y ago
Aren’t computers just a hack of physics laws? I think the line between a hack and genuine software is more blurry than what we would assume.
- mixmastamyk 8y ago
  A “rock we tricked into thinking.”
  - Casseres 8y ago
    A bunch of sand powered by spinning rocks.
gsich 8y ago
Yes, really. Most games do not however. I don't have programs though for testing. Edit: http://www.ecsis.net/pub/netuser/ftp.html http://www.ecsis.net/pub/netuser/ftp.html tried Rftp, worked with Windows 10. At least 22 years of compatibility.
- Dahoon 8y ago
  Testing a single .exe as simple as Calculator doesn't show much. How about running StarOffice 4.0?
  - gsich 8y ago
    It shows compatibility, which you doubted in the previous post ("no, not really"). Doesn't matter how simple you deem the program. Where can I download it?
AnIdiotOnTheNet 8y ago
Actually yeah, lots of software that was compiled for Windows 95 really does still run fine on Windows 10. Games are a big exception. What doesn't work is 16-bit Windows applications, at least not without DOSBox.
- Dahoon 8y ago
  Yes lots of programs still work if you just do this little thing and maybe this little hack which is the same as not working unless you use hacks. Which brings us back to what I wrote.
  - gsich 8y ago
    What "little thing" for example?
badsectoracula 8y ago
The main issue you'll face on trying to run old 32bit Windows 95 applications on modern 64bit Windows 10 is that the installers often are 16bit and 64bit Windows do not support 16bit applications (which was actually technically possible, at least for protected mode 16bit applications which is the majority of them, as shown by Wine being able to run almost all 16bit programs under 64bit Linux). Once you go past that hurdle though (and it is often very easy to do that since almost all of them tend to use InstallShield and there are workarounds for it... or in some cases, you can just copy the files manually :-P) the applications themselves tend to run just fine. For example here is Visual Studio 6 running on my Win10 machine (with a demo from DirectX 7 SDK) [0] - all i had to do was to edit an .ini file to disable the Java VM setup. Similarly here is Borland C++ 5 compiling my C engine [1] - BC5 works just fine (and i actually use it very often since it compiles the code instantly and offers an ok debugger). Outside of compilers, here is Wally [2], a texture editor/painter/manager for Quake, Quake 2 and similar games - the program is from around 1998 but works perfectly fine in Windows 10. I use and run a lot of old applications for Windows and generally i almost never have issues getting them to work in Windows 10. One notable exception is games (of which i also have A LOT of older titles) that have a combination of DirectX abuse and memory bugs that in 9x weren't noticed due to looser checking. My go-to solution is to drop dgVoodoo2's dlls in the game folder and run RTSS to limit the framerate at 60fps - this solves 99% of the issues. Interestingly (but expectedly, considering the issues mentioned in the article) the situation is reversed with Linux. I tried recently to play several older game demos (i have around 30 of them) made for Linux around late 90s, early 2000s. Most of them worked fine (after installing a missing .so or two and an OSS-to-ALSA bridge), with the main exception being Shogo which relied on Gtk1 that i just couldn't figure out how to make work in Debian (which doesn't ship Gtk1 at all). This last part is what reverses the situation for Linux: older applications relying on older versions of Gtk, Qt, etc just do not work at all and often you can't just grab the older .so files and drop them in, as they have big webs of dependencies that often go outside just libraries (like scripts, data files, etc). Which is also why i really dislike both Qt and Gtk - the former, being a C++ API, cannot guarantee a stable ABI even if they wanted to, while the latter being written in C could provide a stable ABI but the developers just don't care at all about stability. Ironic that the most stable (API-wise) and backwards compatible desktop tech in Linux is Wine. [0] https://i.imgur.com/Qz4GoJk.png https://i.imgur.com/Qz4GoJk.png [1] https://i.imgur.com/M6TXWFu.png https://i.imgur.com/M6TXWFu.png [2] https://i.imgur.com/ggX9Ybq.png https://i.imgur.com/ggX9Ybq.png

by Dahoon 8y ago

>"most Windows 95 applications still run fine in Windows 10" Uhm, no. Not really. With hacks by the user (or OS) maybe, but if hacks are allowed then most of that list can be deleted.

hartator 8y ago

Aren’t computers just a hack of physics laws? I think the line between a hack and genuine software is more blurry than what we would assume.

mixmastamyk 8y ago
A “rock we tricked into thinking.”
- Casseres 8y ago
  A bunch of sand powered by spinning rocks.

gsich 8y ago

Yes, really. Most games do not however. I don't have programs though for testing. Edit: http://www.ecsis.net/pub/netuser/ftp.html http://www.ecsis.net/pub/netuser/ftp.html tried Rftp, worked with Windows 10. At least 22 years of compatibility.

Dahoon 8y ago
Testing a single .exe as simple as Calculator doesn't show much. How about running StarOffice 4.0?
- gsich 8y ago
  It shows compatibility, which you doubted in the previous post ("no, not really"). Doesn't matter how simple you deem the program. Where can I download it?

AnIdiotOnTheNet 8y ago

Actually yeah, lots of software that was compiled for Windows 95 really does still run fine on Windows 10. Games are a big exception. What doesn't work is 16-bit Windows applications, at least not without DOSBox.

Dahoon 8y ago
Yes lots of programs still work if you just do this little thing and maybe this little hack which is the same as not working unless you use hacks. Which brings us back to what I wrote.
- gsich 8y ago
  What "little thing" for example?

badsectoracula 8y ago

The main issue you'll face on trying to run old 32bit Windows 95 applications on modern 64bit Windows 10 is that the installers often are 16bit and 64bit Windows do not support 16bit applications (which was actually technically possible, at least for protected mode 16bit applications which is the majority of them, as shown by Wine being able to run almost all 16bit programs under 64bit Linux). Once you go past that hurdle though (and it is often very easy to do that since almost all of them tend to use InstallShield and there are workarounds for it... or in some cases, you can just copy the files manually :-P) the applications themselves tend to run just fine. For example here is Visual Studio 6 running on my Win10 machine (with a demo from DirectX 7 SDK) [0] - all i had to do was to edit an .ini file to disable the Java VM setup. Similarly here is Borland C++ 5 compiling my C engine [1] - BC5 works just fine (and i actually use it very often since it compiles the code instantly and offers an ok debugger). Outside of compilers, here is Wally [2], a texture editor/painter/manager for Quake, Quake 2 and similar games - the program is from around 1998 but works perfectly fine in Windows 10. I use and run a lot of old applications for Windows and generally i almost never have issues getting them to work in Windows 10. One notable exception is games (of which i also have A LOT of older titles) that have a combination of DirectX abuse and memory bugs that in 9x weren't noticed due to looser checking. My go-to solution is to drop dgVoodoo2's dlls in the game folder and run RTSS to limit the framerate at 60fps - this solves 99% of the issues. Interestingly (but expectedly, considering the issues mentioned in the article) the situation is reversed with Linux. I tried recently to play several older game demos (i have around 30 of them) made for Linux around late 90s, early 2000s. Most of them worked fine (after installing a missing .so or two and an OSS-to-ALSA bridge), with the main exception being Shogo which relied on Gtk1 that i just couldn't figure out how to make work in Debian (which doesn't ship Gtk1 at all). This last part is what reverses the situation for Linux: older applications relying on older versions of Gtk, Qt, etc just do not work at all and often you can't just grab the older .so files and drop them in, as they have big webs of dependencies that often go outside just libraries (like scripts, data files, etc). Which is also why i really dislike both Qt and Gtk - the former, being a C++ API, cannot guarantee a stable ABI even if they wanted to, while the latter being written in C could provide a stable ABI but the developers just don't care at all about stability. Ironic that the most stable (API-wise) and backwards compatible desktop tech in Linux is Wine. [0] https://i.imgur.com/Qz4GoJk.png https://i.imgur.com/Qz4GoJk.png [1] https://i.imgur.com/M6TXWFu.png https://i.imgur.com/M6TXWFu.png [2] https://i.imgur.com/ggX9Ybq.png https://i.imgur.com/ggX9Ybq.png