реестр Windows
Carmel Kittell
I've incremented the Pure java code originally posted by David to allow acessing the 32-bits section of the registry from a 64-bit JVM, and vice-versa. I don't think any of the other answers address this.
I've done this before using jRegistryKey. It is an LGPL Java/JNI library that can do what you need. Here's an example of how I used it to enabled Registry editing through regedit and also the "Show Folder Options" option for myself in Windows via the registry.
In the end it depends on what you're wanting to do: storing preferences for your app is what the Preferences does just great. If you're wanting to actually change registry keys not having to do with your app, you'll need some JNI app, as described by Mark (shameless steal here):
Thanks to original post. I have reskinned this utility class and come up over the flaws which it had earlier, thought it might help others so posting here. I have also added some extra utility methods. Now it is able to read any file in windows registry(including REG_DWORD, REG_BINARY, REG_EXPAND_SZ etc.). All the methods work like a charm. Just copy and paste it and it should work. Here is the reskinned and modified class:
The best way to write to the register probably is using the reg import native Windows command and giving it the file path to the .reg file which has been generated by exporting something from the registry.
However, a pirate called David Croft has worked out that it's possible to use methods in Sun's implementation of the Preferences API for reading the Windows registry from Java without JNI. There are some dangers to that, but it is worth a look.
The Preferences API approach does not give you access to all the branches of the registry. In fact, it only gives you access to where the Preferences API stores its, well, preferences. It's not a generic registry handling API, like .NET's
The java.util.prefs package provides a way for applications to store and retrieve user and system preferences and data configuration. These preference data will be stored persistently in an implementation-dependent backing stored. For example in Windows operating system in will stored in Windows registry.
This one launches reg.exe under the covers, reading/writing to temporary files. I didn't end up using it, but it looks like a pretty comprehensive implementation. If I did use it, I might dive in and add some better management of the child processes.
will do all the magic. I have tried it, while making jar as windows service using servany.exe which requires changes to made in registry for adding javaw.exe arguments and it works perfectly. You might want to read this:
This uses the same Java internal APIs as in in David's answer, but I've rewritten it completely. It's shorter now and nicer to use. I also added support for HKEY_CLASSES_ROOT and other hives. It still has some of the other limitations though (such as no DWORD support and no Unicode support) which are due to the underlying API and are sadly unavoidable with this approach. Still, if you only need basic string reading/writing and don't want to load a native DLL, it's handy.
Outa curiosity.. Who in their right mind is so fond of KSP2 right now, they will risk running a game that is spamming the registry and then on top of it, run some random person's code to delete blocks of reg data?
Storing anything at all in the windows registry is somewhat bad practice, but using it for large amounts of runtime data, AND not even deleting it afterwards or managing it correctly. Wow. That is some grade A+ premium bad practice spaghetti I would get second hand embarrassment from seeing in a 24 hour gamejam codebase. My only hope is that whichever developer wrote this was either extremely sleep deprived or didn't read the documentation for the PlayerPrefs API and just guessed what it did from function names alone. Even then something called "PlayerPrefs" should be a red flag if you're aiming to store anything other than player preferences.
If this is still planned to ever be a cross-platform title, trying to store anything at all to the Windows registry should probably cause a post-build automated test to fail. Mono has a registry emulation capability (CKAN used to use it), but why go that route if you don't have to?
The code never was meant to be in the final build, best I can tell from more sleuthing, its for an editor tool to allow them to move PqsObjects in playmode, and then load them back after playmode has stopped, which likely does not change the instance ID in the same editing session
Confirmed on my Windows 11 machine. This report prompted me to check with regedit and I have a 1.4MB Intercept Games reg entry fouling my system after just a few hours in game. Even after refunding and uninstalling, this piece of software still lingers.
Let's assume that it's indeed a leftover from an internal tool. That uses the registry to store some session values instead of storing the in a dictionary. And somehow that code made it into production.
Absolutely unacceptable. The game should had never been released, even in early access, until the base game was stable. New features, thermals, parts, etc should not be even a considered priority when the foundation of the game is already held together with sticks and tape....
Buddy. there can be more than one person on the internet with "shadow" in their name, if you're gonna go after someone you may wanna make sure you have the right guy. i know at least two different Lupi's on the internet, if not more, and that's nowhere near as common of a permutation of latin as "shadow" is just a straight up English word.
I have two gaming computers, one which at one point had KSP2 installed and is in the process of being mothballed as the 2nd machine is new and never had the game installed. Last night I went in to the older machine, checked to make sure that KSP2 was uninstalled and deleted the entire "Intercept Games" registry key via regedit. It had enough entries in it that it literally took over five minutes to scroll from the first entry to the last. I would not feel comfortable running IG's registry fix, nor am I comfortable running any code from IG or T2 in the future. Given this stance, I probably won't be missing anything in the future considering the "Writing On The Wall" is a good indicator that this title will never be completed to the expectations that were presented to the consumers.
Better make sure it cleans ALL the entries, and when we uninstall the game, it cleans the registry of everything but the product code/serial number entries. Some of us with health issues don't have the energy to go through editing all this stuff out ourselves (I'm waiting for a lung transplant).
It worked fine on Windows Vista - you could go into Windows' display settings and Windows would recognize the third monitor and let you drag it around accordingly. With Windows 7, the third monitor literally is not there in Windows' display settings. The driver allows you to display to the third monitor, but you can't move where it is. The display settings are misplaced relative to my other two (if you drag windows over to it, they end up on the bottom when it should be aligned).
I called tech support and they said that there isn't a driver with this functionality for Windows 7 yet. But here's my hunch. The monitor placement is still somewhat similar to where I had it on Vista, it's just off about 500 pixels or so. I think there is either a registry key or driver file somewhere that is telling this monitor where to exist. If I could just modify the number and move it up 500 pixels, it would be in the right place and I don't have to wait 6 months for the company to come out with a new driver.
The annoyance here is due to the fact that the registry editor doesn't interpret the 32 bits as anything other than an unsigned decimal integer or a hexadecimal representation of binary data. However, when Windows retrieves that binary data when positioning your displays, it interprets it as a signed integer. In order for Windows to know that a 32-bit signed integer is negative, it sets the last bit to 1 (leftmost) and the rest of the bits are inverted. So -1 will have a binary value of 11111111 11111111 11111111 11111111 (hex: FF FF FF FF). If you translate that into an unsigned decimal integer (like the registry editor does), you get 4,294,967,295. So, for our purposes, 0 equates to 4,294,967,296 which you can simply add your negative number to in order to get the unsigned decimal integer you need that the registry editor saves in binary form and that the system will later interpret as a negatively-signed integer.
Instead of calculating negative values it may be easier to understand if you keep all values positive by making a logical 0,0 at the physical top left of a virtual box you would draw if you tried to surround all the monitors. Think like when you move a monitor up and left, that you are really pushing the others away to the right and down.
For example, I had 1280x1024 and 1920x1200 monitor with the first smaller one defaulting to the top right side of the second, not the bottom left of the first where it is physically positioned (left) and aligns-with (bottom edge is at same height, the top is lower of course because it's not as high).
Logging off Windows then logging back on applied the settings for me. It's also useful to know that this works on Windows Hyper-V Server (I just did this on 2012 R2 which means these settings still work in Windows 8 and 8.1). That's really useful for people locked out of the screen resolution settings but trying to achieve a "bare metal" style host PC (you hardly ever have to update or reboot) and work purely with virtual machines inside via Remote Desktop (copy that from another machine).
d3342ee215