if everyone used the API, then yes you're correct. in my opinion, Microsoft should do what you stated, but they don't want to, out of fear of breaking backwards compatibility for people who do the wrong thing. their needs are just as valid as yours or mine.

With how tightly the APIs for accessing the registry are coupled with the model and encodings of the registry, particularly the driver APIs for it, I don't think it would have been so easy to just swap out the back end without breaking something though (which Windows avoids like the plague) but maybe doable by someone more optimistic than me :). The real "rewrite" was the push for Universal Windows apps using the .NET platform which stores everything for the app in XML files and shadow directories instead of the registry. Of course that didn't take over quite like they hoped so they ended up back with using the registry they were trying to leave 10 years later.

And, because almost every vendor thinks like that, median computers of today offer worse UX than their 90's equivalents.

I think they'll eventually learn not to do these things (see also cookie banners). But if they don't, it doesn't matter to me. There's other content available.

>There are some things that users in Administrators group still can't do. Hence the need for TrustedInstaller perms.

By "this exploit" I was referring to the exploit mentioned in the article, not whatever gp did to get trustedinstaller permissions. As far as I know I don't see why you'd need access to the SAM file to give yourself trustedinstaller permissions. You can do that yourself if you're administrator.

Also, from a security point of view there isn't much that administrators can't do. You're right that they can't directly delete certain files, but they can take ownership of any file they want and adjust the ACLs to give them the required permissions. I don't think is some sort of EoP/exploit/hack, but rather protection against accidental deletions (eg. https://news.ycombinator.com/item?id=23054506)

Allowed purposes for said licensing program includes “performing internal security audits of the Microsoft Windows operating system”.

I think this is the exact story being discussed here.

If those types aren't enough for your use case, then you will be forced to roll your own types in some binary/string data anyway, so it seems like it's strictly more work if you just always force everyone to roll their own.

And even then you still end up with the possibility of people using the wrong syntax for your hand-rolled types, like not quoting values that are supposed to be strings or quoting values that are supposed to be numbers.

Besides, wouldn't it be easier to fix this just by adding some more types, or deprecating everything except REG_SZ or something? What's the advantage of moving to a directory based model?

File-based configs on Linux have the same problem anyway. The semantics of any config file you find are defined by the application that's consuming it. Any two config files that superficially seem to be using the same format, may in fact use a completely different one - and you'll never know, up until you edit one and it blows up in your face, because it cannot parse empty lines or #-comments, or escape characters, or negative values, or values larger than 2^16, or...

Whether altering Windows registry or a Linux config file, you cannot make a correct modification without knowing what the owners of the modified settings expect.

Regardless the point wasn't "a filesystem couldn't represent a rewritten registry" it was that the registry is actually a database today (whether viewed as a file-system like db by the reader or hierarchical db it is listed as) and the rest of the technical problems have to do with it being 30 years old and not rewritten not that it wasn't written with a file system representation as primary view in the first place.

http://multicommander.com/

http://multicommander.com/docs/browse-registry

"Back to point 1, the Registry is a half-assed, poor quality implementation of a filesystem. Importantly, it’s not a database. It should be a database!"

Noting "not a database" is bolded.

Default options do not enable any drive encryption Secure boot is as the name says something to make booting secure it has absolutely nothing to do with protecting data on disk from being accessed by someone with physical access to the machine.

https://docs.microsoft.com/en-us/powershell/scripting/sample...

Android is open source and if you don't buy a locked down device from a carrier, the bootloader is unlockable and the system easily rootable.

Your two examples of something more 'not my pc anymore' than Windows aren't exactly good ones.

Now, if you were to mention MacOS and iOS... then you definitely would have had a point.

For what it's worth, all recent Battlefield games run flawlessly through Proton, including multiplayer with anti-cheat, D3D12, and soon (if not already), ray tracing. This includes at least BF:BC2, BF3, BF4, BF1, and BFV. There's no reason to think BF2042 will be any different.

WinPE? Server Core?

Count me in too. Give me minimal install then shut up and take my money.

For me, rider is quickly replacing visual studio as my daily driver for programming.

For example...

Set-Content hklm:\software\xyz\abc -value 1

...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.

I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.

https://twitter.com/Karunamon/status/1413280394439397376

It has become somewhat unfriendly, but I really appreciate that you can still do whatever you want.

To run self-signed apps, run `sudo spctl --master-disable`

To turn off System Integrity Protection, run `csrutil --disable` from recovery mode.

To modify the root filesystem, do all of the above and run `csrutil authenticated-root disable` from recovery mode.

To disable library validation, do all of the above and run `sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true`

To disable AMFI, do all of the above and add the boot argument amfi_get_out_of_my_way=0x1

(Some steps may be a bit different on Apple Silicon Macs, I don't own any so I'm not as familiar.)

---

You now have the same privileges Apple does. You can grant yourself whatever entitlements you like, inject your own code into any process, load your own kernel extensions, or just replace the whole kernel with your custom build of XNU.

I actually think a decent chunk of macOS's perceived "unfriendliness" comes from Mac users being less willing to hack around than users of other OSs. The common refrain in Mac circles seems to be that System Integrity Protection should never be switched off under any circumstances. I agree, if you're a normal user—but if you're not, and the handcuffs are annoying you, just unlock them already. (But do leave everything else in place until such a time as it presents a roadblock.)

Also, method swizzling in Objective-C is fun, try it!

I’m so tired of seeing folks parroting no sideloading on iOS. That’s not been true for a long time. Yes, the conditions of side loading (needs a free developer account, must have app signing refreshed weekly, etc) might not be palatable for your taste (which I’d generally agree), but to say it’s not possible to sideload apps on a stock iOS device is just wrong.

UDS are interfaced with via the same berkeley sockets api, not via the filesystem api. Have you ever written applications that use them?

> We agree on iOS, but the grandparent talked about PCs - iOS really does not fall into that category (that's why I explicitly mentioned smartphones).

that's if you disable through the normal settings interface. the group policy settings stick, although you might have to turn off "tamper protection" first before applying the group policy.

For where the main divergence in what we are each talking about though when I originally said:

> Similar case: posix specifies network sockets be accessed as files/filesystems (as most everything in posix is) but nobody actually used that representation because it's inefficient even though it's the standard and easily mappable to files/filesystems.

I was talking about literally exposing networking through the filesystem by mapping the construct to files and paths as that's what the author's registry tool actually does and what the author was proposing Windows should do in a rewrite - not whether or not sockets can be backed by the preexisting FD handle in an arbitrary namespace using custom socket functions to manage the socket efficiently. As a result I was trying to explain to you why BSD-type sockets don't use a literal filesystem mapping even if they have an FD and you were trying to explain to me how they were still backed by a FD even if it's not in the filesystem (i.e. describing the same API from opposite ends). I agree fully with your take it's a standard FD which has no performance concerns once created and can be treated as such but looking back I think I tried quite hard to point out I was talking about literal files/filesystems mapping not the FD handle so I'm not sure where the split came from... perhaps normally it"everything is a file" vs "everything is a FD" not a big distinction but this case just happened to be about a literal filesystem mapping not whether or not it would end up using a FD.

Also to note when I talk about "inefficient" I don't mean "slow to compute" (after all it ends up a FD once opened, as noted heavily at this point) it's the interface which becomes inefficient (which is what the registry article was dealing with). Even though you call it trivial as in "trivial to expose a mapping", which there is no argument is trivial BSD sockets offered much more straightforward and simple moldability around internet protocol network socket concepts than the filesystem approach by the author/TLI's approach which is a big reason BSD sockets won out. The "rebuilding of the wheel" are that the BSD socket API defines functions fit to purpose instead of molded around traditional file API naming and structure like TLI/XTI did.

In the section "It's not the best for network sockets though so they tend to get a raw handle" 'raw' was meant as another adjective to point out it was just a non-filesystem mapped reference (howso depends on the OS, in *nix still a FD in others not it doesn't really matter though it's just a ref) per the prior sentence not meant to be taken that 'raw handle' was a proper noun describing a different type of handle definition you'll find in the source code.

I appreciate the time, at the very least I'm sure I'll never make the error of conflating TLI with POSIX again and at the most I may have solidified some internals I don't get to think about every day!

On to the question of side loading: technically, Apple does provide a way to load code not from the app store. Some might call that side loading. However, when most people say that they want to be able to side load apps on their phone, they expect that their apps will function as first-class citizens. Apple's version of side loading is more like a very temporary work visa than a grant of citizenship, which makes it structurally different than what is being asked for.

Respectfully, this isn’t about being precise, it’s about being factually correct. I feel your tomato example is off the mark. A more fair (albeit not precise) analogy would be someone saying “there is no sun in the sky” and someone correcting them by saying “yes there is, it’s just behind that cloud” and then the person arguing back that “only suns that aren’t behind clouds count”.