One of the reasons why Defragmentation is slow on Vista


Recommended Posts

That's more or less how it works today. COM stuff goes under Software\Classes (from both HKLM and HKCU, as HKEY_CLASSES_ROOT). Windows stuff goes under Software\Microsoft\Windows. Apps can put stuff under Software\AppDeveloper\AppName.

HKLM requires admin access, so most apps won't be able to touch that.

There have been ideas about things like per-application registries, especially in the LUA world, so anything is possible.

Applications can directly modify the Windows sections of the registry, however.

As for indexing, metadata support is one area where it can be improved upon.

Link to comment
Share on other sites

Applications can directly modify the Windows sections of the registry, however.

As for indexing, metadata support is one area where it can be improved upon.

As I understand it (Brandon can obviously explain it better), the indexer doesn't directly deal with metadata. It's all in the IFilters given to it. In that, it's capabilities are practically limitless. You provide it with an IFilter for a file type (or other data type, like email stuff), and it knows everything that that IFilter gives it.

Link to comment
Share on other sites

Applications can directly modify the Windows sections of the registry, however.

How would you prevent that? And in many cases, the "Windows sections" need to be modified by other applications - for example, when registering a shell extension.

Applications can only alter the per-user registry hive, unless they're elevated.

As for indexing, metadata support is one area where it can be improved upon.

How so? There's already an extensible schema, 900 or so properties registered by default covering basically everything, and multiple ways to populate them (IFilter, property handlers, etc). All the major datatypes are available. So what exactly are you asking for?

Link to comment
Share on other sites

How would you prevent that? And in many cases, the "Windows sections" need to be modified by other applications - for example, when registering a shell extension.

...

In the *nix world, the GUI preferences are not a "system" level thing. Gnome, KDE and such have settings that are made at the user level for the GUI. Anything global is installed at root, so it is already the root user making these changes.

Perhaps Microsoft would benefit from separating (if only logically) the Windows GUI into a "system" section for all users/admin/system level, and have any user-installed apps affect only the user level. User-installed shell extensions, as your example, would extend the shell at a user level for only that user.

Linux and the rest of the Open Source world learn and emulate the good parts of Microsoft and Apple software, why should not Microsoft leverage some of the good ideas generated outside the walls of Redmond? Seems like all users would benefit. :yes:

Link to comment
Share on other sites

How would you prevent that? And in many cases, the "Windows sections" need to be modified by other applications - for example, when registering a shell extension.

Applications could use API calls specific to tasks such as COM registration that require modification of the Windows sections of the registry.

Link to comment
Share on other sites

In the *nix world, the GUI preferences are not a "system" level thing. Gnome, KDE and such have settings that are made at the user level for the GUI. Anything global is installed at root, so it is already the root user making these changes.

Perhaps Microsoft would benefit from separating (if only logically) the Windows GUI into a "system" section for all users/admin/system level, and have any user-installed apps affect only the user level. User-installed shell extensions, as your example, would extend the shell at a user level for only that user.

That's exactly how it works on Windows. Per-user stuff goes in the per-user registry (HKEY_CURRENT_USER), or in the User's AppData folder in their user directory. Per-system stuff goes in HKLM (HKEY_LOCAL_MACHINE) and can only be accessed by an administrator. Same goes for ProgramData (the per-system version of AppData).

Shell extensions, for example, can be registered in either of HKCU or HKLM, depending on the intent.

Linux and the rest of the Open Source world learn and emulate the good parts of Microsoft and Apple software, why should not Microsoft leverage some of the good ideas generated outside the walls of Redmond? Seems like all users would benefit. :yes:

I'd say they/we do that when appropriate.

Link to comment
Share on other sites

Perhaps Microsoft would benefit from separating (if only logically) the Windows GUI into a "system" section for all users/admin/system level, and have any user-installed apps affect only the user level. User-installed shell extensions, as your example, would extend the shell at a user level for only that user.

This is becoming one of my major irritations in Linux. I want (the option) to install a shell-extension for all users. Although is is more of a distro-descided thing I also find it abnoxious that no distro seems to come with an "all users" directory that every user on the local machine has read/write access to. There doesn't seem to be any easy way to share a resource, such as a config file or a directory across multiple users.

For what its worth, a developer friend suggested storing system-wide application settings in the registry rather than in an XML file because that's more obscure for would-be tinkerers that might ruin a setting (and then complain to me that its broken).

Link to comment
Share on other sites

Ive always disabled System Restore since WinXP and ive been disabling Superfetch aswell snice ive been using Vista and ive not had any problems and would recomend people to do the same IMO.

Link to comment
Share on other sites

This is becoming one of my major irritations in Linux. I want (the option) to install a shell-extension for all users. Although is is more of a distro-descided thing I also find it abnoxious that no distro seems to come with an "all users" directory that every user on the local machine has read/write access to. There doesn't seem to be any easy way to share a resource, such as a config file or a directory across multiple users.
Huh? Can you give a specific example of what you mean by this?

I can give a specific example of it doing exactly like you say you want. In my fluxbox install, there are 'system' themes and 'user' themes. System ones are seen by all users, whereas user ones are (of course) for individual users.

And "no distro comes with an 'all users' directory"? Just make one, if you want one. Local or over a network. It's not like what you are talking about is impossible you know. ;)

Link to comment
Share on other sites

Windows (XP and Vista) have an "all users" profile. Place a file in its "desktop" folder and it appears on everyone's desktop. When installing, most applications with prompt the user if they'd like the program to be available to all users, if so thus shell extensions are created for everyone and the proper folders get created in that all users folder. The all users' documents folder also serves as a location all users have read/write albilites to.

I know its easy to share a folder in Linux by changing its permissions. But in either KDE or Gnome I see no equivalent to the profile settings aspect of the Windows all users proifle. I also don't see any distro with a system-wide shared folder present by default.

Link to comment
Share on other sites

So, in effect, you are complaining because account separation is default in Linux. Even though a shared access area is trivial to create.

In fact, your exact statement was "There doesn't seem to be any easy way to share a resource, such as a config file or a directory across multiple users", which is provably false.

Link to comment
Share on other sites

So, in effect, you are complaining because account separation is default in Linux. Even though a shared access area is trivial to create.

In fact, your exact statement was "There doesn't seem to be any easy way to share a resource, such as a config file or a directory across multiple users", which is provably false.

So, is there a way to force a resource to be constant across user accounts? For instance, a setting in the xorg.conf, or force an icon to be on the desktop for all users on *nix?

I don't know enough about Linux to answer, but I'm curious.

Link to comment
Share on other sites

So, is there a way to force a resource to be constant across user accounts? For instance, a setting in the xorg.conf, or force an icon to be on the desktop for all users on *nix?

I don't know enough about Linux to answer, but I'm curious.

I'm off to bed, but a quick answer before I log off.

Yes, xorg is a system setting (video card, mouse, keyboard, display). Those really don't change user to user on the same PC. So, yes, those are constant for all users.

Putting an icon on the desktop for all users would only be challenging, I think, in cases like mine. I prefer fluxbox, which has no desktop icons. No way to force one on my desk. :p

However, an admin would be able to restrict my desktop preferences and (for example) force Gnome upon all users. I am not a Gnome user, but I don't see how it would be difficult to put an icon on every user's desktop. So, if something like this was important for a particular computer with multiple users, I would think that the admin would go the "one supported desktop" route to avoid complications of people like me.

Generally, anything in the user's home directory is the user's. Things that you want global, you put elsewhere (like system configuration/defaults in /etc/).

EDIT: This thread has been off-topic for a long while. :unsure: At least discussion is generally calm and reasoned.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.