7 ms·

One of the comments mentions this: "Alright, doing some investigating it seems that they are saving the Pqs preferences based off of the instance ID of the pqs

• echelon 3y ago
  Coming from a Linux background, what is the windows registry and why do things need to write to it? All I ever read about it seem to be horror stories. Can't you store stuff alongside the install? Or in some user data location?
  • 4gotunameagain 3y ago
    It's kinda like a system wide dconf
  • mjburgess 3y ago
    It's just /etc
    • hulitu 3y ago
      > It's just /etc Some files in /etc have manpages.
      • ElectricalUnion 3y ago
        Some registry keys also have The Old New Thing posts by Raymond Chen [1] /s [1] https://github.com/mity/old-new-win32api#registry https://github.com/mity/old-new-win32api#registry
  • dataflow 3y ago
    > what is the windows registry and why do things need to write to it? It's a centralized, high-performance small key value store that's the alternative to writing a million config files in random places. It's arguably much better in my experience. E.g. one of the never-ending headaches I always have on Linux is updating config files when a package updates. There's no automatic file merge in general (hence .pacnew and such) so you gotta do it by hand (and not everything is available with the foo.d/ hack). The registry already operates at the value granularity so it bypasses this kind of issue. And as a developer you don't have to worry about some things you might not think about, like the trade-off between corrupting your config files with in-place updates vs. having to create a new file and replace the old one after every config change.
    • throwaway290 3y ago
      It's great and granular until someone starts to push complex serialized structures or large blobs as registry values...
    • manbash 3y ago
      OP asked for an analogue, not a comparison. I think it's silly to compare the two.
    • rapind 3y ago
      What's always annoyed me with many operating systems is this need to organize based on function instead of domain. If I install an application named "Bob" then I want ALL of Bob's configuration to live within Bob. I don't want it split between different registry keys or /usr/local, /etc/, /var, /lib, etc. I'm fine with there being conventions and categorizations, but I'd like to root node to be the application itself. Yes, I even want this for multiple users. I know there are design arguments to / for the various different ways of organizing configurations, but IMO they are just inferior from at least this user's perspective.
      • Someone1234 3y ago
        I think for all future development, the industry agrees with you. Chromeium, iOS, Android, and Windows Store apps all utilize packages and per-package storage. We're just suffering from backwards compatibility for things made over 30-years ago.
  • tlhunter 3y ago
    The windows registry is a hierarchal data storage system. Yes, basically a filesystem.
  • adastra22 3y ago
    It is some combination of /etc and /var. a hierarchical key-value data store shared by the whole system used for configuration management mostly.
  • gruez 3y ago
    https://en.wikipedia.org/wiki/Windows_Registry#Rationale https://en.wikipedia.org/wiki/Windows_Registry#Rationale
  • klodolph 3y ago
    The database-backed configuration mechanism makes a ton of sense, and if you squint, the filesystem is really kind of a database anyway. With the registry, there’s a lot you get for free—you can set defaults system-wide, you don’t have to deal with parsing, you can get new values without re-parsing a file, etc. A lot of the horror stories came from earlier versions of Windows which had problems with reliability. If you spend time as a Windows sysadmin you can start to appreciate it, because it does make certain administration tasks easier. Like “I need to change 10 registry different keys on 50 different machines” is easier on Windows. On Linux, I’d do the same with, like, Ansible scripts which can be a lot more error-prone to write.
    • throeaaysn 3y ago
      [dead]
    • hulitu 3y ago
      > the filesystem is really kind of a database anyway I thought ReFS was a failure. /s
    • imtringued 3y ago
      Most people aren't sysadmins. The registry is inaccessible to them.
  • ilyt 3y ago
    Imagine every setting in ~/.config and /etc is stored in corresponding SQLite database, and you have common interface to access both. Now imagine this database is not a great engineering product like SQLite but really, really REALLY fucking sucks at being database, and slows down quickly with sizing up. Now imagine there is no sensible way to get obsolete data out of it, and as every program uses same file it just gathers, and gathers, and gathers...
    • Someone1234 3y ago
      > REALLY fucking sucks at being database, and slows down quickly with sizing up. This is over 20-years out of date.
      • mcpackieh 3y ago
        Then why does KSP2 spamming the registry with orphaned entries eventually cause KSP2 to hang on launch?
        • c0nsumer 3y ago
          Likely because the app can't deal with the size of the data it's getting back when it tries to get its entries.
        • throeaaysn 3y ago
          [dead]
  • emodendroket 3y ago
    Based on the follow-up questions, it sounds like you already know what it is and just wanted to advertise your allegiance to the Unix way of doing things.
  • deleted 3y ago
    [deleted]
  • hotnfresh 3y ago
    It’s /etc but harder to browse and edit. Or, from the contrary perspective: it’s the 500 places config lives on Linux, but in one place instead. (Except it still has a deep hierarchical structure, so that second one is kiiiinda not entirely true, in that you can run into exactly the same issues as scattered config files on Linux)
    • nullindividual 3y ago
      You can search for keys and values across all loaded hives. This makes finding things in the registry much easier. Editing, sure, you've got essentially a single GUI application and CLI or programmatic access. Your options are certainly more limited than the plethora of text editors available.
      • pests 3y ago
        > you've got essentially a single GUI application and CLI or programmatic access You can export a registry path as a text file, make changes in perferred editor, then import it again. It's annoying but I've done it before when needed.
      • uxp8u61q 3y ago
        Or you can use powershell that allows you to browse the registry as if it were a filesystem. PS> cd HKLM:\Software\Microsoft\Windows\CurrentVersion PS> ls [...bunch of stuff...] PS> gp Themes DesktopBackground DesktopBackground : c:\windows\web\wallpaper\[...default system wallpaper...]
        • imtringued 3y ago
          That kind of defeats the purpose, doesn't it?
          • uxp8u61q 3y ago
            How so? I don't follow. It's still the same optimized, global, secure key-value store. It just has a different interface if you cannot possibly fathom using different tools than the ones you use to deal with the filesystem. Pwsh is pretty neat in that regard. Besides the actual filesystems drives, many systems have "providers" that allow you to treat their objects as files: the registry, environment variables, the functions defined in your session, the variables, the aliases... Unix's "everything is a file" became "everything is an item".
  • WorldMaker 3y ago
    > Coming from a Linux background, what is the windows registry and why do things need to write to it? All I ever read about it seem to be horror stories. The Windows Registry is the NT Kernel's system config/preference store. The closest Linux equivalent is dconf. Like dconf it is built to be a read-mostly/read-optimized database. It's not as strongly focused on a service-bus architecture as dconf. It tries to heavily optimize for an MRU on-disk order (somewhat like redis) and optimize for strong write consistency (unlike redis which is happy to do more in memory between flushes to disk). Any writes at all generally thrash the Registry "hive" database files some. Heavy amounts of writes will murder it. It was optimized for reading not writing. The Registry was side-ported to Windows 95 from the NT Kernel, in part because COM (it became the central spot for registering COM components), and a lot of mistakes were made in the messaging about it. It was intended to be Kernel-focused and mostly never used by user-space applications. That unfortunately wasn't made clear enough, and needing to register COM components in it certainly muddied the message. So Windows apps have a long history of storing a lot of things to the registry, much of which they should probably use user config files for. > Can't you store stuff alongside the install? Or in some user data location? In Windows due to a complicated dance with anti-malware efforts and secure binary memory mapping it is generally frowned upon to store stuff alongside installs (in the %ProgramFiles% or %ProgramFiles(x86)% directories). Many programs (especially well written ones) don't even have write permissions at all to their install folder (similar to how many distros lock down /bin and sometimes /usr/bin and/or /usr/local/bin to superuser accounts only). For backwards compatibility reasons with applications dating all the way back to Windows 95 some app installer are allowed to still re-ACL their install directory to give back write permissions to the application. Also, in modern Windows (since Vista), depending on a number of factors Windows will actually lightly sandbox the app when that occurs and redirect ACL changes and writes to an "overlay" directory, allowing the app to believe that it still is writing to its own install directory but it is actually writing to a machine or user directory outside of %ProgramFiles%. On the other hand there are plenty of user folders available for config storage: Generally the suggestion is %AppData% for most such files. (This is the "Roaming" app data that may be automatically copied to other machines for some users on some networks, mostly enterprise/corporate accounts/users.) Some apps may prefer %LocalAppData% which doesn't roam for larger config files or more machine-specific transient things (like window positions or caches). It's also common enough to see cross-platform apps use Unix-style dotfiles under %Home% and even sometimes XDG-style dotfiles under %Home%/.config/. That's not generally recommend and especially because of roaming behaviors the general preference is to use the appropriate %AppData% or %LocalAppData% and avoid cluttering %Home%. Though many Windows users don't even really use or see %Home% for a variety of interesting reasons, so its not entirely frowned upon as wrong. (Unlike storing config files under %Documents%, an ancient mistake of many Windows apps not as terrible as storing things in the Registry they shouldn't, but more visibly obnoxious to Windows users that want tidy Documents folders and feel that folder should be entirely user-controlled.) Also, there is a machine-wide config location, somewhat akin to /etc, named %ProgramData%.
  • RajT88 3y ago
    The windows registry is both of those things. It has a "hive" which is part of the user profile. User preferences are stored there ("HKEY_CURRENT_USER"). System-wide preferences are stored in a "hive" for system apps ("HKEY_LOCAL_MACHINE"). It allows applications to mix and match system-wide stuff with user-specific stuff, which only differs by which "hive" it wants to query against. It has several data types for different types of records. There's conventions for how to store things (although apps can do whatever they want), so apps usually store their state and config data under HKLM\SOFTWARE\MyCompany\MyApp for system-wide stuff, and user specific stuff will live under HKCR\SOFTWARE\MyCompany\MyApp. All in all, my experience has been that on average its usage is a bit more standardized than config files. Of course on windows, apps (particularly C# apps) ship both with config files and a boatload of registry entries. Lastly - by design, HKCR (the user profile hive) is assumed to sometimes have orphaned data. If a program is installed per-user, and you uninstall it as a different admin user than who installed it, the other user profiles cannot be loaded and modified by the installers thereby orphaning any other user data.
  • doctor_radium 3y ago
    I believe there is a Registry of sorts in Windows 3.1, but is largely empty. It was only in the Windows 95 era that it ballooned into what we have today. Coming (at the time) from an Amiga perspective I was bemused to realize that if 3.1's progman.ini file was damaged, that the program groups in Program Manager (think of each group as a node in Start -> Programs, basically the user-oriented files and executables from a software install) could just disappear! While there's a slight performance hit, one would think it would be more robust to scan the disk for .grp files every boot and build this data dynamically in memory. I have always assumed this was done because 3.1's memory management was complete crap, necessitating that Microsoft "write everything down". Ditto for 95, and being a much more ambitious OS, there was that much more to write down. Then the third party vendors jumped on board. Fast forward to 2023 and this legacy still persists when it doesn't have to. I could be blowing smoke, but this has always been my thinking. An old joke: Registry was derived from the Latin word registratum, which means "put all your eggs in one basket".
  • SSLy 3y ago
    like dconf, but strictly worse (eg, doesn't have schema)
• Waterluvian 3y ago
  “create_or_update pattern considered harmful,” so they say. Actually I kind of do believe this, but separating the two doesn’t always solve the whole problem if you’re creating on every startup rather than only once on, say, profile creation or new game or something.
  • maxbond 3y ago
    I would say, using something that doesn't belong to you as a primary key considered harmful. Create or update is a good pattern for robustness (eg so a troubleshooting user won't brick the app by deleting or renaming the key), if you can guarantee the uniqueness of the primary key. You can't constrain some identifier from a different system.
• jncfhnb 3y ago
  Somewhere a unity exec has just figured out the new metric that determines their royalty pay rate.
  • zeusk 3y ago
    Are you sure it isn't based on number of instructions retired by the CPU? or the number of pixels rendered by the game?
    • hooverd 3y ago
      cubic pixel/seconds
      • chaorace 3y ago
        pixel displacement
        • gabereiser 3y ago
          bitfield component values of a texel color BGRA’s
      • qubex 3y ago
        That’s voxels/second, surely?
    • yazzku 3y ago
      They will bill you by the pixel. Usage metrics are streamed in real-time. You're gonna wish 480x320 came back.
• TomMasz 3y ago
  How could they not notice this?
  • xsmasher 3y ago
    I can understand not noticing the extra writes; but doesn't this mean that they were never loading the proper value, always loading the default, if the new key was always unique?
  • hulitu 3y ago
    It wasn't found in unit tests. /s
    • chatmasta 3y ago
      Even integration tests don't usually test with a sufficiently significant amount of data that this kind of regression would be noticeable.
• hulitu 3y ago
  > So, somebody didn't notice a "changes every game" instance ID was in the path and/or data. They thought they were overwriting a single key. Becsuse messing with Windows registry is a recommended action. /s What's wrong with game config files ?