XDA forum member RustyGrom has already figured out how to install Windows 10 Technical Preview for phones onto non-approved Lumia devices. As always with Windows – it’s a simple registry switch.
From a high level this works by using FiddlerCore to intercept the traffic going to the Microsoft WPflights server that controls the Insider app and responds with our own custom data. The app accepts registry editing information from the web responses and acts upon that. This allows us to write stuff to select locations in the registry. In the case of the Windows 10 Preview, it appears to only look for your phone’s PhoneManufacturerModelName to decide if it should be offered previews. Windows Update also checks this value. Other devices like Samsungs or HTCs may need different settings.
The hack is still in its early stages, and really, don’t do this if you have no idea what you’re doing, but there are already reports of success.
XDA is a magical, magical place.
Can’t we be rid of that clusterf**k yet?
You think INI files scattered all over the place are any better ?
Scattered .ini files is not the issue. They can easily be placed in predefined paths (/config/vendor/app) which is actually well organized.
The problem in not using “the registry” is each application doing its own thing. Since .ini are app specific plain text format, the applications that use them have to take care of opening, parsing settings on app start and saving any changes on app exit. This may mean code duplication. There is also no auto-notification of setting changes done outside the app at runtime.
It is much better if the operating system provided APIs for reading settings/saving/monitoring settings regardless of the type of storage. That is the strength of the windows registry.
The storage format of the registry itself hardly matters.
Edited 2015-02-16 09:38 UTC
Code duplication is not the matter either, how many software have their own implementation of Codecs (Jpg), parsers (Xml) or UI (Qt) ? The bloat is everywhere, not just around the Ini files.
I’m kind of confused by your post, are you saying that the registry as it is designed as a storage mechanism, and surrounding api is great? Or are you saying that it needs to be improved to have dbus like features?
It sounds like the later.
How many times has a registry corruption totally wrecked an otherwise working Windows System?
compare that to a single .ini file corruption and its effect on the system operation.
IMHO, while the .ini files might be archane I still prefer it to the binary monstrosity that is the Registry.
One of the Software products that I develop for has removed ALL of its dependency on the Windows Registry. If you upgrade from V.old to V.new the migration process takes all the registry bits and pieces and puts them into .ini files. This makes sense as that product runs on Linux/Unix as well as Windows.
To a broader point, I don’t think that is the registries fault, other than the fact that it is a single point of failure.
The real problem with the registry, is really how its used by windows. All those crazy class id registrations for com, com+ and the like. That’s why your system doesn’t boot when its corrupted. Also, “corruption” could mean anything from the class not being registered, ( due to a misbehaving program ) to actual bitrot. The idea was to promote code reuse, and discover-ability of various ocx files. And, honestly, it had a few nice usecases. But more often than not it just brought pain when an app would install and or remove the wrong version of a vb or mfc helper dll , that other applications didn’t like or needed.
It (usually) has nothing to do with a specific application’s configuration being wrong. Its COM thats F’d up. Put that same structure in ini files, and you would still have problems booting when the ini files get screwed up. Its a fragile system they have set up.
So, yeah, If I were still windows programming I would use local configuration files.
Right, restoring a registry hive is another order of magnitude than a local ini file you can keep a backup copy (.bak)
Right, but it wouldn’t be that way if the registry *only* stored program configuration and not register every OCX capability.
It would be slightly worse using a consolidated system like the registry, but not by much.
Its really funny when you think about it. The registry is just a consolidated hierarchy. You could do the same thing with just a directory structure. It seems kinda weird that you would do that any other way. But, maybe it made sense to someone at some point due to FS limitations.
Bill Shooter of Bul,
Indeed.
I’m not against moving this kind of stuff into a database – I love structured databases. Often databases are even easier and more powerful to work with than text files + text processing utilities, and one can always export/import the data in a portable format such as CSV/SQL/etc. But the windows registry just seems to combine the worst of all worlds without matching any of the strengths that text files or real databases offer. It doesn’t even have referential integrity. To me, the registry is a good example of how it should NOT be done.
Well, it looked like a great way to centralize these kind of parameters, just like global variables, you could know what was the color of the default font from anywhere just reading some registry keys.
The idea is good, really. Like you said, some kinda database. But it should have been more atomic.
That’s a very good point. Its a database with a crap ton of interrelated relationships, but no integrity and no sanity checks or recovery operations.
Its kind of a miracle it worked as well as it did.
There’s a lot more reasons for the registry than just code reuse. Raymond Chen covers it in his excellent “The Old New Thing” blog. A summary:
-Permissions can be set per key, which is far-finer grained than at the file level, and works for filesystems that don’t have built-in security.
-Unicode support, as well as binary data, rather than just ASCII strings.
-Multiple threads can access the registry safely.
-INI files are subject to DoS attacks when a file opens and locks an INI, preventing other apps from reading it.
More reasons and details available in is original post:
http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx
I don’t doubt that it was a tempting solution back in the win 3.1/chicago/95 days, but its a terrible solution now.
+ Permissions can be set at the file at a much more granular level in NTFS, than in the registry.
+ Unicode? Binary Data? Yeah its impossible to store those in ini files. /snark
+ Multiple threads can access individual files in a threadsafe manner. Chen addresses that.
+ DoS attacks are the least of my concern on a windows box. There have been plenty of other ways to completely pwn a box since the registry was created. And again, its a lot more difficult to do that if there are more ini files.
Overall, despite his reasoning, time has shown it to be a terrible solution.
“Permissions can be set at the file at a much more granular level in NTFS, than in the registry.”
Even if I would split my ini file into admin.ini and user.ini I would still be only having two levels of access. In the registry you can protect each and every individual key which would be like protecting every individual line of an ini file.
I never really had a problem with the registry. I had more corrupt ini files on my own computer than I had corrupt registry files on my companies network. And corrupt ini files were hard to recover while a corrupt registry file was just a copy from the backup folder (C:\Windows\System32\config\RegBack) . Backups also happen automatically at logical moments like last known good configuration and system restore points during (un)install)
I like .ini files for portable applications though
You wouldn’t need all the magic if mobile hardware wasn’t so sickening locked up. We are mighty lucky it’s not the case with PCs.