21–29 of 29 posts
Driver support seems to me like it could be an advantage over Linux. Does anyone here know the current state of installing a browser on ReactOS?
I think it has WINEs browser which is webkit based
Earlier quoted context omitted.
- the NT kernel is not built around "everything is a file" ... instead the central concept is the handle File descriptor, handle. Potayto, potahto.
> File descriptor, handle. Potayto, potahto. Under Windows, a lot more concepts are handles than just files, directories, symbolic links, pipes, mail slots, ..., e.g. - processes, threads - synchronization objects (mutex, semaphore) - events (CreateEventEx) - I/O Completion Ports - Sections (ZwCreateSection) and Partitions ( https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap... ) for memory - waitable timer…
On a side note, _in the context of workstations_, I wonder if a hypothetical OS that reimplements the Windows APIs (like ReactOS, but with perfect modern hardware support) would be better for end users than a Linux distro with a modern DE. In the past, this hypothetical OS would be a revolution. But I feel that, in recent years, this gap is not as big anymore and Linux supports way more apps than in the past. Such an…
IMHO with a couple of fixes which allow Linux+Wine to better simulate some specific lowlevel Windows behaviours (like this one recently in the news: https://www.xda-developers.com/wine-11-rewrites-linux-runs-w... )... a Linux distro with a 'Windows personality' (e.g. running Windows Explorer as desktop) should be pretty much indistinguishable from native Windows. In the end it's all about driver diversity and quality…
PRO: less telemetry
CON: less battery life
Earlier quoted context omitted.
- the NT kernel is not built around "everything is a file" ... instead the central concept is the handle File descriptor, handle. Potayto, potahto.
> File descriptor, handle. Potayto, potahto. Under Windows, a lot more concepts are handles than just files, directories, symbolic links, pipes, mail slots, ..., e.g. - processes, threads - synchronization objects (mutex, semaphore) - events (CreateEventEx) - I/O Completion Ports - Sections (ZwCreateSection) and Partitions ( https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap... ) for memory - waitable timer…
On a side note, _in the context of workstations_, I wonder if a hypothetical OS that reimplements the Windows APIs (like ReactOS, but with perfect modern hardware support) would be better for end users than a Linux distro with a modern DE. In the past, this hypothetical OS would be a revolution. But I feel that, in recent years, this gap is not as big anymore and Linux supports way more apps than in the past. Such an…
You may be interested in https://loss32.org/
Earlier quoted context omitted.
- the NT kernel is not built around "everything is a file" ... instead the central concept is the handle File descriptor, handle. Potayto, potahto.
> File descriptor, handle. Potayto, potahto. Under Windows, a lot more concepts are handles than just files, directories, symbolic links, pipes, mail slots, ..., e.g. - processes, threads - synchronization objects (mutex, semaphore) - events (CreateEventEx) - I/O Completion Ports - Sections (ZwCreateSection) and Partitions ( https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap... ) for memory - waitable timer…
Earlier quoted context omitted.
> File descriptor, handle. Potayto, potahto. Under Windows, a lot more concepts are handles than just files, directories, symbolic links, pipes, mail slots, ..., e.g. - processes, threads - synchronization objects (mutex, semaphore) - events (CreateEventEx) - I/O Completion Ports - Sections (ZwCreateSection) and Partitions ( https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap... ) for memory - waitable timer…
And you can also argue that that's overengineered (the original NT design docs were posted on here a while ago), that the UNIX model (while much more primitive and simplified) has proven more successful in the real world, and that the original "clean, overengineered" NT design has been buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
The original UNIX model has (considering the current state of GNU/Linux) similarly buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
A central difference is: the NT kernel stayed rather clean (the crapload rather happened in the Windows subsystem).
Earlier quoted context omitted.
And you can also argue that that's overengineered (the original NT design docs were posted on here a while ago), that the UNIX model (while much more primitive and simplified) has proven more successful in the real world, and that the original "clean, overengineered" NT design has been buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was.
> the original "clean, overengineered" NT design has been buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was. The original UNIX model has (considering the current state of GNU/Linux) similarly buried under a progressively bigger truckload of crap year upon year and is no longer as clean as it once was. A central difference is: the NT kernel stayed rather clea…