ReactOS 0.4.14 (opens in new tab)

> biggest vector for malware is not an insecure operating system but user negligency

This is victim blaming. Windows have been teaching users to install from third parties since 90's, added auto-run features to removable media, hid files extensions making it difficult to detect files that could do harm, took a decade to implement processes isolation, never added a good package manager and spent years making fun of FLOSS.

Windows users may have a twisted view about security. I personally heard a few of them saying things like "linux is safe because nobody uses it" or "you MUST use an anti-virus". They may sound naive of negligent but in fact, they were carefully trained for decades to behave that way.

That is, historically, completely false. Windows before WinXP SP2 was a wide-open door for malware. I still remember the whole summer of malware where the IT had to do an emergency shutdown of the whole building network at the switch to stop Blaster from spreading one afternoon.

So hopefully ReactOS, while implementing Win2k, includes the XPSP2 mitigations?

This does not answer the question. If you don't know the answer, it's best not to respond.

> e.g. by opening malicious attachments in e-mails

And how pray tell do those malicious emails take over a system if an insecure OS isn’t at fault too?

This seems no longer true with apples imessage 0 click example [0] for instance. Perhaps you can say using iPhone and iOS which has such a crazy bug is user negligency .

- [0] - https://9to5mac.com/2021/07/19/zero-click-imessage-exploit/

What an incredibly strange Google-translated read in the comments this was:

https://habr.com/ru/post/208614/comments/#comment_7183314

Where did you find/remember this from?

It's pretty interesting how it does this too.

Legally they can't copy source code from windows, so they have to do something called block box reverse engineering.

That just means they can't look at the code, but they can try to copy exactly how the code works. This is for legal/copyright reasons.

It's really impressive so far. Windows is a complicated beast that has been built up since the early 90's without much old functionality being thrown out.

I know some communities use the kernel code as reference a lot

At work we have a glovebox running DOS. The software is written in MS/GW/Q basic and only works with a specific set of ISA IO cards. The manufacturer is long gone but one of their techs bought out the remainder and now gate keeps the software. He has the source but refuses to update, sell, license or release it. Last we spoke to him he wanted $20000 to write a new control program in visual basic using a PCI card and refused to release source code. We flat out said no. The plan is once there are no more spare parts on the shelf the whole thing is getting gutted and a modern PLC system installed in-house.

I have a lot of experience in the industrial SCADA domain. I largely agree with you, but I will say that historically most installations have had all the relevant source code available to them, or owned by them.

In most cases, the limiting factors for lifespan were: 1) Inability to get replacement hardware 2) Inability to find anyone who can understand the source code.

There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"

Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.

The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.

Does management really understand how long the equipment is going to be used when it is purchased? From what I've seen, upper management has done the cost analysis before purchasing but maintenance is going to ultimately going to be be responsible for keeping the equipment running. By this point in time, those that approved the purchase are likely retired.

I would find it more likely that old device drivers get decompiled and reverse engineered.

Heck I think there's a lot of value in an emulator for old device drivers. Who cares what the source was when you just execute the black box in a highly regulated sandbox? (Note doesn't work for some medical software). I think medicine and astro / aero are the few places that would require full decompilation of an original driver.

Well, one of the main goals of ReactOS is in fact to be able to use native Windows drivers.

Flat? Where? I think it's just like Server 2003 or XP Classic theme. Is there a flat UI theme?