|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
ON SECURITY By Susan Bradley It’s a dirty little secret in software — when new code is added to existing code, it doesn’t always result in a more secu
[See the full post at: When newer isn’t more secure, or better]
Susan Bradley Patch Lady/Prudent patcher
I intended to post this last night, but it got stuck in “are you sure you meant to do that?” for some reason…
a 64 bit W10 cannot run older 32 bit programs
There is never any guarantee that software written for an older version of Windows will work on a newer one, though MS has expended much effort to ensure that most of it will. My guess is that the older 32-bit program intended for 95 is not fully 32-bit, and that is why it fails on 64-bit Windows 10.
Windows 95 was sort of a hybrid OS consisting of both 16 and 32 bit code. It could run either or both without any compatibility layer, which allowed it to run any existing Windows 3.x software (which was 16-bit) while still having some of the advantages of a 32-bit OS. This means that software written for 95 would not need to be built as exclusively 32 bit… it could be partly or fully 16-bit, and it would work just fine. As many consumers and business users of Windows had existing software libraries they wanted to keep using, this move by MS helped ensure 95’s success.
Windows NT, on the other hand, was fully 32-bit, and could not natively run 16-bit code. Microsoft developed the WoW (Windows on Windows) compatibility layer (starting with Windows NT 3.1, where it only offered partial compatibility) to allow NT to run 16-bit code. At that time, NT was not intended for consumers, and it would not be until the release of Windows XP that the NT platform would become the base for all Windows versions.
Later, when 64-bit Windows arrived, WoW was used to allow it to run 32-bit code. This has carried forward into all versions of Windows that are based on NT right up through Windows 10.
WoW only ever went one step backwards. The 32-bit versions of Windows could run 16-bit programs via WoW, but the 64-bit versions could not, as that was two steps back.
What is probably happening with your Win 95 program is that some of it is 16-bit, which means those bits will run on 32-bit Windows 10, but not 64-bit Windows 10.
Windows 11 is 64 bit only, and apparently doesn’t include WoW to be able to run 32-bit code.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
Susan,
I believe you missed a significant option to run earlier (32-bit) programs. Use Hyper-V Manager to create a virtual machine running XP or earlier version OS’s. I wrote a 44,000 line business operations program in the mid-’90s which I can still use today! Had to do a little magic for printer support but it does work well.
Also, most security issues are eliminated if you limit pass-through internet.
Thanks for all the education!
RT
Old stuff is more secure than new stuff in a few cases. Plus old stuff works longer than new stuff. In old days, security and longevity were considered in the design. Now a days, security is thrown out the back door since no one cares and longevity is not important since hardware should be replaced in less than 6 months to add more e-waste and make more money to the company.
Security has never really been more than a thing thrown in at the last moment. I believe the original authors of the first UNIX system made such a comment, and it was certainly not any better during the XP era.
The default installation of Windows XP (as it was preinstalled on PCs) was in “administrator” mode, and it was not the kind (as in Vista on up) where it would elevate privileges (using a UAC prompt) only when needed. This was wide open “login as root” type of access, where it is all wide open. This is such a dangerous thing to do that it is disabled on new versions of Windows, as well as many Linux distros, like Ubuntu. The idea of logging in with root privileges at all (even for administrative purposes) is considered too risky to enable, yet this was the main way that Windows XP was used for many millions of users around the world, for many years.
The “XP user as root” paradigm was so normal and expected that much of the software in the XP era expected the user to have root privileges. Lots of programs that had no business expecting or using root access (after the program was finished installing) would fail to function if they were denied these privileges.
It was just how things were done back then, and it was how I managed to be afflicted by the only malware I have ever had in my 35+ years of computer usage.
Back in those days, I was running XP, and I tried to visit a site about guitar strings or some such thing. It had been compromised by miscreants, and simply loading the web page was enough to complete the “drive by” malware infection. While my XP was in admin mode (which allows any malware that gets onto the system to do anything at all), I also had a HIPS program installed, called Outpost Security Suite. The browser was Firefox, with the Java plugin installed (as was typical in that era), which was presumably where the malware found its way into my PC.
Outpost popped up a message when the malware executable tried to run, and by that time I had answered the security message prompts thousands of times, and never once attached to an actual threat. I was aware of the tendency of users just to click through the prompts to be able to keep using the PC, but I was security-aware… I knew what each prompt meant, and whether it represented something innocuous (Outpost was very comprehensive and popped up “allow or not” messages for many, many completely ordinary events that could, at the worst of times, be a sign of malware). When the message appeared, the habit took over, and even as part of my brain was screaming at me to stop, I observed my hand moving the mouse pointer over to the “allow” button.
After years of using Outpost when nothing was wrong, I did the wrong thing when something was wrong.
At least this little alarm in my head, watching in horror as I allowed what I knew was a bad thing, woke me up from my torpor, and I was aware that I had been infected a second after it happened (as opposed to how it would have been without Outpost; it would have infected me quietly and I would not have known it happened). I immediately clicked the Outpost icon and selected the option to shut down all net traffic, then I got up and ran around to the back of the PC and unplugged the ethernet cable. By the time I got back to my chair, another Outpost popup had appeared… now the malware was trying to install itself to the registry key to run automatically on boot, and Outpost had stopped it again. I hit “Deny and terminate process.”
The malware process did terminate (not always a given), and I looked at the Outpost log to find where the malware had hidden itself. I found it, zipped it up with password protection, and emailed it to the “suspicious file” submission address of several antivirus/antimalware vendors, according to their submission procedures.
After I did a full scan with Outpost and a couple of other antimalware programs (Bitdefender free surely being one of them), I took the additional step of restoring from a system image backup to make sure it was gone.
One of the antimalware vendors got back to me after a few days and told me the malware was a new, previously undiscovered one, and that it had been added to their signature database, and that the info was shared with the other vendors (per their agreement to each other to share virus samples).
Had XP not been in admin mode, and if Firefox had not had the Java plugin to run automatically, I never would have been infected at all. Even though I cared enough to buy and install Outpost, not to mention putting up with its constant prompts and the reduction in performance it imposed, I had still not been careful enough to prevent a drive-by malware infection.
In hindsight, it is now widely accepted that XP’s security model was a disaster waiting to happen. It also had the effect of “priming” Windows users to think that the UAC prompts in Vista and later were unnecessarily intrusive and annoying (including myself, at the time I finally upgraded to Windows 7). One of the first things I did was to turn that off… which I now recognize was unwise.
Now that I am accustomed to Linux, I don’t just have to click a button on-screen to say “yeah, I meant to do that” as in Windows UAC when it is time to do something that changes the system configuration… I have to enter my password too, which is a lot more annoying. This is the norm for Linux installations.
I could change that to be more convenient, but I have not done that, as it would make it too easy to get in the habit of just clicking “allow” as I had with the Outpost prompt, which effectively served as my UAC prompt in an OS that did not have UAC yet. Perhaps if I had to type in a password when the Outpost prompt appeared, it would have slowed my roll enough to let that part of my brain screaming at my mouse hand to STOP to do that (to stop).
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
Notifications
