On 1/29/2018 9:45 AM, Roy Lambert wrote:
>
> Thank you again. Between you and a lot of googling I now have a VM with Lazarus icon on the desktop and can access my shared folders. Doing this really does make me appreciate Windows
>

This is the most low level method for this - building your own from sources.

Using one of those pre-built bin packages and package manager makes all
of this lot simpler - basically very close to windows experience.


Raul

Raul

>I you ever read Old New thing blog
>(https://blogs.msdn.microsoft.com/oldnewthing/) - it has great stories
>about weird stuff apps did (and even how Windows tried to work around it).

No but I'll give it a look


>> <<Remote Desktop Services, known as Terminal Services in Windows Server 2008 and earlier, is one of the components of Microsoft Windows that allows a user to take control of a remote computer or virtual machine over a network connection>>
>
>Is that Wikipedia?

I don't remember, but since it was the first hit - probably

This is what Microsoft MSDN says "Windows Server 2012
>R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008
>with Remote Desktop Services (formerly known as Terminal Services) allow
>a server to host multiple, simultaneous client sessions"
>
>> Doesn't sound multiuser but since I've never used it I can't really say.
>
>I assure you it's very much multi-user and quite heavily used even today
>for "fat" apps still - there are lot more related tech these days from
>simple app publishing to full virtual desktop (VDI).

OK as I said I've never used it so I'll believe you

>Even for delphi apps there are companies trying to mash these
>technologies to "webify" your delphi app easily - they basically use
>their hooks to do the web UI of the delphi app running on server in
>multiple sessions (see https://www.cybelesoft.com/thinfinity/virtualui/
>for example - it's quite cool actually).

I've seen the odd post or two on the emb forums about it

>Using registry or INI at least is something most management and
>deployment tools know about and can handle.

You are, very unfortunately, right.

Roy

Matthew

>> OK there are 5 main structural elements (HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS,HKEY_CURRENT_CONFIG) which I have never tried to do anything with and I don't think you can. Under those its a bit of a free for all though
>
>The structure is that you can put what you want under a hierarchy. So I can have HKCU\Software\Company\AppName\RecentlyUsed to have a list of recent files, and HKCU\Software\Company\AppName\DataStores for a set of keys with more keys with more keys in a nested hierarchy as I see fit. Can't do that with INI files, and INI files were getting very creaky.

Yes, but there's nothing to stop you putting the data under HKCU\ThisJunk\Company\AppName\RecentlyUsed  and HKCU\Software\Company\AppName\DataStores

I haven't tried writing under HKLM recently but I used to be able to so I could have had one bit of info under HKLM and the other under HKCU.

>
>> > You can set rights to different parts, which means that I can read the settings from Microsoft Office or any other application without knowing anything about how they store their options this version.
>>
>> You've lost me here. Firstly I'm unsure what being able to set rights has to do with being able to read settings without knowing how they're stored and secondly, even if you know they're in the registry if the key has changed you still need to know that.
>
>You can set access rights on any registry key just the same as on any file or folder.

Sorry, still lost. Understand setting access rights but what does that have to do with "which means that I can read the settings from Microsoft Office or any other application without knowing anything about how they store their options this version"

Its probably me being thick.

>> > I can also add to another applications registry (like registering modues with Delphi) without having to use some custom DLL to access their options. It also separates the options from the application, which is important for shared use,
>>
>> Is this really a good thing?
>
>It is better than assuming that WORD.INI is the right place to put things, given that affected all users, and that it meant they couldn't change it easily.

I have mixed views on that, part of me says you're right and part says the opposite. If I can work out why I'll let you know.
>
>> > and it also then allows the user to roam to other computers and keep all of their settings and not have a few left behind because the application stored them in a custom file somewhere.
>>
>> Only if they take their registry with them or can load a remote registry. Both operations beyond c99% of conmputer users.
>
>It is indeed, but if you are on a roaming system then someone else is sorting it for you. The IT depts at most universities, for example, have everything set to roam. So when you go to make a presentation in a lecture theater, you log in as you and all your data and settings are "just there". User's don't need to do anything. And it works because the registry is a common and managed thing.

I accept that the registry can work and does work. However, I do not think it is the best solution and I do think there are better ones that should have been explored. It may be that the registry is the best solution for today's environment. It will be difficult to explore alternatives since that would wreck Windows backwards compatibility and for all its faults and problems Windows have established a well known environment.

Roy

Raul


>This is the most low level method for this - building your own from sources.

I know but IT WORKED - thanks again

>Using one of those pre-built bin packages and package manager makes all
>of this lot simpler - basically very close to windows experience.

That's what I tried first but couldn't find one to work


Roy

Roy Lambert wrote:

> Yes, but there's nothing to stop you putting the data under HKCU\ThisJunk\Company\AppName\RecentlyUsed  and HKCU\Software\Company\AppName\DataStores
>
> I haven't tried writing under HKLM recently but I used to be able to so I could have had one bit of info under HKLM and the other under HKCU.

There is indeed nothing stopping you, but then there is little stopping the user writing duff files all over their computer either.

The key though is that HKCU is designed to be written to for the current user, and not accessible by any other user - no clash of data that an INI file might have. And HKLM is full of read-only options so the current user cannot break things without going elevated and getting admin rights. This means that as a user I can register an add-in to Microsoft Word that works only for me if I want. Or for everyone if I have admin rights.


> Sorry, still lost. Understand setting access rights but what does that have to do with "which means that I can read the settings from Microsoft Office or any other application without knowing anything about how they store their options this version"

The important part is that this is a standard way to handle things. Word, for example, might start off storing all its options in an INI file. Then they realise they'd like to be a bit more complex, perhaps also registering the add-in name. So they change from the INI file to the XML file instead. Only your application pops its details into the INI file instead. Oops. Now if Word wants to keep compatiblity, it has to read both. What if your app updates and writes to the new XML too. Now it has you registered twice.

The Registry allows expansion in a standard way. You create the key to register, and when they want to expand, they add a sub-key. Both fully compatible, no big change needed.


--

Matthew Jones

Matthew

>There is indeed nothing stopping you, but then there is little stopping the user writing duff files all over their computer either.

I know sone of those, but my favourite is the "clicked save and lost it" brigade. People, at the end of the day, can put any old rubbish into any old field, and generally do. I've always tried in my programs to eliminate this and always failed to a greater or lesser degree

>The key though is that HKCU is designed to be written to for the current user, and not accessible by any other user - no clash of data that an INI file might have. And HKLM is full of read-only options so the current user cannot break things without going elevated and getting admin rights. This means that as a user I can register an add-in to Microsoft Word that works only for me if I want. Or for everyone if I have admin rights.

Whilst I'm not, and never was, advocating ini files  it is possible to achieve pretty much what you describe using them. As I understand it HKCU is a separate file for each user - not difficult to duplicate with ini files

>> Sorry, still lost. Understand setting access rights but what does that have to do with "which means that I can read the settings from Microsoft Office or any other application without knowing anything about how they store their options this version"
>
>The important part is that this is a standard way to handle things. Word, for example, might start off storing all its options in an INI file. Then they realise they'd like to be a bit more complex, perhaps also registering the add-in name. So they change from the INI file to the XML file instead. Only your application pops its details into the INI file instead. Oops. Now if Word wants to keep compatiblity, it has to read both. What if your app updates and writes to the new XML too. Now it has you registered twice.

OK. I didn't, and still don't get the linkage between the security aspect and the standardisation aspect.

>The Registry allows expansion in a standard way. You create the key to register, and when they want to expand, they add a sub-key. Both fully compatible, no big change needed.

This is more convention than software / database enforced rules and the same could be applied to ini files - add a section to register, add a key/value pair under that section to expand

OK access may not be as fast as with whatever database the registry is based on (I have a vague memory of Jet) but it would work.

Roy

On 1/31/2018 4:44 AM, Roy Lambert wrote:
> Whilst I'm not, and never was, advocating ini files  it is possible to achieve pretty much what you describe using them. As I understand it HKCU is a separate file for each user - not difficult to duplicate with ini files

Business case again but one of the things windows handles quite well is
making user part of registry fully portable and process transparent to
user - any system (including the terminal services session) they log
into gets their registry.

Nice thing is that it's completely transparent to the apps.

HKCU is technically a file but handling and moving it around is done
automagically by windows so things like unc paths other things are
pulled straight from user AD profile etc.

NMot saying this does not have issues but when it works it's a fantastic
thing.

Raul

On 1/30/2018 10:20 AM, Roy Lambert wrote:
> I know but IT WORKED - thanks again

No worries - once you've gone thru the process once it's actually pretty
simple and makes lot of sense.

Now you've learned how to drive a linux install

Raul

Raul wrote:

> done automagically by windows

Another thing is it allows everyone to read/write all at the same time, taking care of synchronisation. If you have an INI file, it needs to be cached and controlled by the system, otherwise if you go using your TStringList to read and write, then you may write over the change I just made using TIniFile. And if the system is going to do it, then it can't be a simple INI file because there is not enough structure. You want binary, I want a string list, I want child items, etc.

--

Matthew Jones

Raul


Whilst what you've written is true its a bit of a circular argument. It goes - Microsoft used it because its good and its good because Microsoft used it.

Roy Lambert