[Lazarus] Embedded database for Lazarus/Linux

[Sven Barth]

Hi!

Caution: I'm going very off topic here, so if anyone expects to read 
something about embedded databases for Lazarus/Linux, you might ignore 
this message ;)

Am 19.06.2010 15:53, schrieb Graeme Geldenhuys:
> On 19 June 2010 10:45, Sven Barth wrote:
>>
>> Nevertheless the Registry is not that bad if you think about it: it's an
>> data storage system that is provided by the operating system itself and thus
>> available to all applications running on it.
>
> Our mileage clearly varies a lot. The registry is a mess. Fully of
> crap, often corrupt, easy to corrupt and lots of "uninstalled
> application" information is left there to rot ever though the app is
> not on the system any more.
>

I never said that it's perfect. I only wanted to stress that the system 
"Registry" itself is much more powerful than many people/developers are 
aware of.
The crap that is lurking around is mainly because of crappy 
applications, their deinstallers or because of backwards compatibility 
(from Microsoft's side). But the first two points also apply to file 
based configurations. I don't think, that Lazarus' uninstaller will 
remove my configs that I'm setting with "primary-config-path" (I also 
don't think that it will remove my settings in their default location... 
:S ). So if I'd never install Lazarus again and I'd never delete those 
files, I'd also have crap lurking around taking up disk space and 
wasting time for "search applications" (indexers, anti virus, etc.).
Also the performance of the Registry when being full of crap is 
different from Windows 9x to Windows NT (the secnod one being superior). 
The Registry from NT is not the same as the Registry from 9x, but most 
people think of the Registry as the crap it was back in the 9x days...
(Global) Config files are also easy to corrupt, so nothing is gained here.
The main benefit of the Registry is that it is provided by the OS with a 
documented/consistent API and the OS itself keeps sure that the Registry 
is secured/intact/backed up as good as possible.

>> Another nice thing are permissions: You can - at least on NT+ systems - set
>> the permissions for single keys (not values though) for specific users and
>> groups.
>
> Yeah, this has been around in *nix systems for 30+ years using text
> config files and user/group/world permissions. :-)
>

But what if I want to give Sven full access to a key, Graeme the rights 
to read and write to the key, read only access for all other FPC 
developers and no access rights for every one else? (this example might 
seem constructed, but on multi user systems you might need this) You 
can't really do that with the usual user/group/world permissions... (you 
might be able to do that with POSIX ACLs though)
For example I've blocked access to any webbrowser on the family's 
computer for my brother by only adding his account to the Deny list of 
the application (and of course his account being a "normal user").
Windows NT supports such ACLs on nearly everything the system provides: 
Files, Registry keys, kernel objects (yes, NT is object oriented) like 
Semaphores, Pipes, Sections, Devices... NT itself is much more powerful 
than most people are aware of... if Microsoft hadn't screwed the Win32 
subsystem the way they did (plus the fact of always being Administrator 
from XP on), we'd have a very relieable system there (and with ReactOS 
we also have a very compatible open source variant of it :D ).
Don't get me wrong here though: I'm not a Microsoft-fanboy. I only 
appreciate the way they designed the NT architecture and I realise the 
power that is sleeping in there. Thus I started the NativeNT port of 
FPC, so that I can somewhen release the full power of such an operating 
system. :) (yes, my todo list is also very impressive :P )

>> If your application has the correct priviledges you can also load and unload
>> private Hive-files (the Registry is saved in such files). You can use that
>> for example to make your application portable:
>
> Umm, using a ini file stored in a global location for system wide
> setup, but also allow the application to see if a ini file is in the
> same directory as the executable also makes it instantly  "portable"
> (like running from flash drives). Been doing this for years with
> Windows and Linux software - always using INI files.
>
>

Yes, that is also a way to do it (and I also do it this way ^^).
But the Registry nevertheless allows for things like that and that 
should be kept in mind when designing the data storage backend for an 
application - especially if the application is Windows only (for what 
reason ever).
Also (as said) it might be very useful to write a simple application 
which can make applications portable that rely on the Registry...

Regards,
Sven