Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KSP2 is spamming the Windows Registry until the game stops working

forum.kerbalspaceprogram.com

Post reply on HN
Print view View original

191–200 of 306 posts

Re: KSP2 is spamming the Windows Registry until the game stops working

#191

Post by c0nsumer »

heavenlyblue wrote: post #166
pathartl wrote: post #85

Earlier quoted context omitted.

Most games that _do_ use the registry use it as a data store that may or may not be accessed by external applications. It provides a very reliable pathing (at least at the time of the game's release) to access typed data. For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\ \ergc. This would let one install the game to any drive and still have access to the CD key…

How is that different from accessing $HOME/.config? It does exist on Windows too, but I don't want to Google it. I believe in Windows there's even $SHARED/.config

Using the registry is a pretty simple API call to say place X here, read X if it exists, etc.

If you need to start manipulating configuration files, then you need to deal with all the complexities of that.

The registry is great for exactly this sort of config info. And on Windows, HKLM (HKEY_LOCAL_MACHINE) is for system-wide stuff. If it were per-user config it'd go in HKCU (HKEY_CURRENT_USER).

Re: KSP2 is spamming the Windows Registry until the game stops working

#192

Post by RajT88 »

KennyBlanken wrote: post #159
msla wrote: post #134

Earlier quoted context omitted.

The performance part is questionable, as is the discoverability: Programs write binary blobs to impossible-to-find keys and, as we see here, there's nothing preventing a severe loss of performance if the program writes too much to the registry. It can only be examined with specialized tools, and, due to the binary values written to it, it might not be meaningfully editable at all.

There's also no mechanism for the OS to offer the user the ability to purge registry entries when a program is uninstalled, so the registry just bloats further and further.

Installers are supposed to do that.

But they have to be well-written installers (many aren't). And anyways, lots of installers are written by companies which want to leave their footprint behind even if you do uninstall.

Finding orphaned registry entries is hard - it's not always clear what application put them there, and how to determine that the application is still installed.

Re: KSP2 is spamming the Windows Registry until the game stops working

#193

Post by kortex »

Joker_vD wrote: post #68
kortex wrote: post #8

It feels like the Windows Registry is one of those well-intentioned ideas that ended up being a tremendous mess in actual implementation. "Let's use a central database to store things that the OS, drivers, and UI need to access" somehow became "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck". See also: https://news.ycombinator.com/item?id=322…

> "half assed KV dumping ground for every process and their dog to litter with whatever while acting as a singular bottleneck" Doesn't that describe disk filesystems too? And Unix file namespace in particular (a single hierarchy unifying several block devices, just like registry is composed of several on-disk files)? What about all that junk in one's $HOME?

No, because the filesystem is one layer of abstraction lower than the registry. There's nothing with less bottleneck to the filesystem besides raw device access. The registry runs on top of the filesystem. If you wish to use the registry for filesystem-like purposes (eg storing startup config specific to the app or user state), just use filesystem. If you wish to use it like a database for system-wide information, that's a better use-case, but the registry isn't quite a proper database.

Windows programs proliferate $HOME junk, too. And that's an issue in its own right, which should be addressed by platform-specific application dirs (e.g. the platformdirs library for python).

Re: KSP2 is spamming the Windows Registry until the game stops working

#194

Post by sokoloff »

rapind wrote: post #104
dataflow wrote: post #81

Earlier quoted context omitted.

> 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…

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…

I like being able to use revision control to track config changes mostly in one place (/etc), using etckeeper.

Re: KSP2 is spamming the Windows Registry until the game stops working

#195

Post by tambourine_man »

PretzelPirate wrote: post #100
tambourine_man wrote: post #92

“Be warned though, deleting the wrong thing can stop applications from working, or even break the entire operating system .“ You gotta love Windows.

This is the same case in any OS when you're deleting things with root privileges.

I macOS you can’t delete system files, even with root privileges, unless you disable system integrity, which requires a restart.

Not the same at all.

Re: KSP2 is spamming the Windows Registry until the game stops working

#196

Post by RajT88 »

echelon wrote: post #76
tyingq wrote: post #4

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 object, which, according to unity's own documentation, changes between runs of the game, hence why its saving 10 trillion different copies of the same data" So, somebody didn't notice a "changes every game" instance ID was in the path and/or data. They thought…

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?

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.

Re: KSP2 is spamming the Windows Registry until the game stops working

#197

Post by Narishma »

heavenlyblue wrote: post #166
pathartl wrote: post #85

Earlier quoted context omitted.

Most games that _do_ use the registry use it as a data store that may or may not be accessed by external applications. It provides a very reliable pathing (at least at the time of the game's release) to access typed data. For instance, most EA games from the early 2000's standardized the store of the CD key in ~HKLM:\SOFTWARE\ \ergc. This would let one install the game to any drive and still have access to the CD key…

How is that different from accessing $HOME/.config? It does exist on Windows too, but I don't want to Google it. I believe in Windows there's even $SHARED/.config

I think it's %LOCALAPPDATA% and %APPDATA% respectively.

Re: KSP2 is spamming the Windows Registry until the game stops working

#198

Post by tambourine_man »

Xeamek wrote: post #117
tambourine_man wrote: post #92

“Be warned though, deleting the wrong thing can stop applications from working, or even break the entire operating system .“ You gotta love Windows.

Yes, because if I go to /etc or /var and delete some random thing, linux is just magical and nothing will possible break. Cut the crap

Read my answer below

Re: KSP2 is spamming the Windows Registry until the game stops working

#199

Post by TomMasz »

tyingq wrote: post #4

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 object, which, according to unity's own documentation, changes between runs of the game, hence why its saving 10 trillion different copies of the same data" So, somebody didn't notice a "changes every game" instance ID was in the path and/or data. They thought…

How could they not notice this?

Re: KSP2 is spamming the Windows Registry until the game stops working

#200

Post by squeaky-clean »

ianhawes wrote: post #60
sBqQu3U0wH wrote: post #53

Earlier quoted context omitted.

I heard from someone who actually works in the industry (as engine developer) that companies usually don't use Unity out-of-the-box and write their own tools and extensions (e.g. memory management) and change parts of the engine as the needs vary greatly depending on the game they are making. Not sure how common that really is though.

You may be referring to Unreal in this instance. Unreal is open source* but you pay to license the engine, so you can make core changes I.e. memory management or tweak underlying net code. Unity is closed source and so you can only really extend very core parts of the engine. FWIW my experience in gaming has been that Unity is exceptionally powerful and allows game developers to create games that would otherwise requ…

Plenty of companies have source access to Unity and write their own custom portions of it. It's just not accessible at the hobbyist or indie budget level. It's one of those "call us for pricing" situations.
Post reply on HN