FWIW, I recently implemented a safe Rust crate around the Windows variant of intrusive linked lists [1] and spoke about it at EuroRust [2].
I did it only for compatibility and would still prefer vectors whenever I can use them. Nevertheless, I put some efforts into coming up with a useful and high-performing implementation. To give an example: My `append` function is O(1) and not a poor O(N) version that you rightfully criticized in your tweet.
I have worked on a Windows-compatible kernel. Not at Microsoft, but within the ReactOS Project.
And I can affirm that even after 15 years of low-level development, nowadays mostly within various Rust projects, it doesn't get boring.
Can't imagine going back to high-level while there is still so much work to do on the underlying foundations..
Congrats on your kernel development offer from Microsoft!
I imagine these to be very scarce these days, considering that today's Microsoft seems to be more into services and less about low-level software development.
If you like to chat more about this, just drop me a line. Always interested to hear from low-level devs and aspiring ones. My website/e-mail is in my HN profile.
> Only if you want to be trendchasing rather than letting backwards compatibility take care of itself...
> I'm a native Win32 developer, have been one for a few decades, and know quite a few others still using MSVC6 because it's fast and enough for what they do. Takes <250MB of disk space, and the self-contained binaries it generates will work on any version of Windows starting at Win95.
I share your view about the unmatched backwards compatibility of Win32 binaries, but I wouldn't let a 24-year old compiler like MSVC6 near any new project.
We are talking about a compiler here that doesn't even support the C++98 standard, let alone all the basic features for writing safe software (stack cookies, _s APIs, smart pointers - just to name a few).
When I needed reliable self-contained binaries and backwards compatibility, I switched to VS2019's clang-cl compiler and ported their libc++. Together with winpthreads from the mingw-w64 project, this enabled me to write software using even C++20 features, but still maintain compatibility down to Windows NT 4 from 1996.
If you're interested, it's all documented here: https://colinfinck.de/posts/targeting-25-years-of-windows-wi...
That's really cool, was wondering how hard it would be to make libc++ play nice with XP - currently I still use MSVC 2017 for those builds but that won't get newer language features and I am planning to move to Clang anyway. Do you know of any effort to go even further back and support pre-NT Windows with a modern C++ compiler?
What the author refers to are the three available compression modes on Xerox scanners, which are "normal", "higher", and "highest". It is not clear what that means exactly, but it is possible that all three of those are lossy compression modes.
In my opinion, the only reasonable mode for JBIG2 is lossless, as the lossy mode of JBIG2 is, in general, prone to these character mangling issues. File sizes for lossless JBIG2 compression are already very low, so I would claim that using lossless is almost always worth it, unless character mangling is explicitly not a problem.
I've been using Win32DiskImager since the first Raspberry Pi. Never found a reason to change.
Usbimager looks nice in comparison to the bloated Balena Etcher, but otherwise very similar to the Win32DiskImager I'm already using. Or is there something I am missing?
Pi Imager has some nice Raspbian-specific advanced features hidden behind a keyboard shortcut (Ctrl+Shift+X), which can be useful if you plan on deploying a headless system.
We didn't do it just for the eye candy, but also for threads, offline messages, and user identification.
I wrote down our reasons for moving from IRC to a self-hosted Mattermost here: https://reactos.org/project-news/new-discussion-platform/
We never broke ties with IRC though. You can still join #reactos or #reactos-dev on Freenode, both are bridged to their corresponding Mattermost channels using Matterbridge.
Our Matrix server was set up right in time for FOSDEM 2021. It will soon be extended to bridge to the IRC and Mattermost worlds, as Matrix integrates even better with Freenode's IRC server than Matterbridge.
As an open-source project, never place your bets on a single third-party platform!
I think ReactOS is mainly being used by hobbyists, and I doubt Microsoft would want to sue hobbyists. Little commercial or financial gain, lots of bad press.
The situation is a little bit comparable to Hercules, the IBM mainframe emulator (although not quite the same – Hercules is of course a hardware emulator, ReactOS is an operating system clone). You can use Hercules to run z/OS, but not legally, IBM only licenses z/OS to run on IBM's own hardware, or authorised proprietary emulators that cost $$$$. Thankfully though, IBM doesn't appear interested in suing hobbyists – IBM treats the hobbyist community as if they don't exist. But, try building a business on Hercules, as the company TurboHercules SAS did, and IBM's lawyers will start sending nasty letters to you.
ReactOS dev here. As of today, compatibility is primarily hampered by the fact that many applications don't run under Windows XP anymore.
We don't want to change the entire OS target to something newer than NT 5.2 (XP/Server 2003) at this point. Let's better stabilize on one target than chasing a moving target forever.
This is why a versioning system is being implemented right now to allow applications targeting NT 6.x to use newer DLLs/APIs not available under Windows XP.
Check e.g. this recent PR from a few days ago for details: https://github.com/reactos/reactos/pull/3239
This implementation of doubly linked lists is not even exclusive to Unix-based operating systems, but also known as struct LIST_ENTRY under Windows/ReactOS and heavily used for kernel development there. They also provide a singly linked list version as struct SINGLE_LIST_ENTRY.
If you want to learn more about NTFS internals and my crate, check out the talk I gave at FOSDEM 2022: https://archive.fosdem.org/2022/schedule/event/misc_ntfs_rus...
Also I'm open to any questions here.