Location of Office 2010 option file(s)?


G

Gordon Shumway

What is the path for the file(s) that contain the settings for "Word
Options," "Excel Options" and "PowerPoint Options" within Office 2010.
I would like to have a backup of it(them) just in case.

Any help would be greatly appreciated.
 
V

VanguardLH

Gordon said:
What is the path for the file(s) that contain the settings for "Word
Options," "Excel Options" and "PowerPoint Options" within Office 2010.
I would like to have a backup of it(them) just in case.

Any help would be greatly appreciated.
It is ... wait for it ... the registry.
 
Ad

Advertisements

G

Gordon Shumway

It is ... wait for it ... the registry.
Maybe I should rephrase... what registry location(s) would contain the
information that is changeable through the above programs options?
 
S

Stan Brown

What is the path for the file(s) that contain the settings for "Word
Options," "Excel Options" and "PowerPoint Options" within Office 2010.
I would like to have a backup of it(them) just in case.

Any help would be greatly appreciated.
You're assuming they are files, but as far as I am aware they are
System Registry entries. Specifically:

HKEY_CURRENT_USER\Software\Microsoft\Office

Most are under
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0
but Excel's COM add-ins are under
HKEY_CURRENT_USER\Software\Microsoft\Office\Excel
 
V

VanguardLH

Gordon said:
Maybe I should rephrase...
You asked for "file(s)".
what registry location(s) would contain the information that is
changeable through the above programs options?
Stan gave the user hive (HKCU) for Office settings for your account.
There is also the system hive (HKLM) with the same key for global
settings.

If you still want the files then you want the registry files. Those are
under C:\Windows\system32\config along with the user hive of ntuser.dat
under your own %userprofile% path.
 
V

VanguardLH

VanguardLH said:
You asked for "file(s)".


Stan gave the user hive (HKCU) for Office settings for your account.
There is also the system hive (HKLM) with the same key for global
settings.

If you still want the files then you want the registry files. Those are
under C:\Windows\system32\config along with the user hive of ntuser.dat
under your own %userprofile% path.
By the way, if you're planning to backup (to possible later restore) the
registry then use ERUNT or an image backup program.
 
J

J. P. Gilliver (John)

What is the path for the file(s) that contain the settings for "Word
Options," "Excel Options" and "PowerPoint Options" within Office 2010.
I would like to have a backup of it(them) just in case.

Any help would be greatly appreciated.
It is ... wait for it ... the registry.[/QUOTE]

Yet another case where - IMO - the registry is inappropriate.
 
V

VanguardLH

J. P. Gilliver (John) said:
It is ... wait for it ... the registry.
Yet another case where - IMO - the registry is inappropriate.[/QUOTE]

INI files are slow. File I/O to read an INI file is much slower than
getting settings from memory. Who knows how many times an app might
need to access its settings. File I/O of an INI file is sequential;
that is, you have to start from the beginning and read the whole thing
to find just one setting. The registry gets loaded into memory so each
key and data values under it are randomly accessible. You can access a
registry key and its data values directly, not by having to sequentially
read through a file.

Even if the INI file were loaded into memory, those bytes would occupy
more space than a binary database of all INI files.

There is also almost no access control outside of file permissions on
INI files versus permissions on not just the parent key but the same or
different permissions possible on the child keys. The registry can be
made secure. An INI file never is.

A program may actually want to store or modify "internal-use only"
settings that the users cannot get at. They're all exposed in the
registry. regedit.exe and reg.exe only expose part of the registry so
it's possible to store values that users cannot get at (or malware)
because they're only accessible via the registry API. Registry editors
don't show you everything in the registry. Also, the registry is
binary. Registry editors interpret it so you see the alphanum bytes you
know how to read. There is no parsing (or much less) required to
specify a registry key along with a data item and its value. The
structure of the registry provides much if not all of the parsing so
retrieving settings is very fast (besides the registry being read from
memory instead of from a file).

Just because it may not be easy for you or to your liking doesn't mean
it is harder for program to access the registry. Using the registry is
faster and easier for program and that's what it was designed to work
with, not for users putzing around inside there. That limited access is
granted using regedit.exe doesn't really mean most users should be in
there.

There are 2 real hives: HKLM and HKU. The others are pseudo-hives
comprised of values take from HKLM and HKU. This allows complete
separation of per-user and global settings that is not possible in an
INI file. All settings, per-user and global, are exposed in an INI
file. This also permits coordination with user profiles as separate
keys under HKU instead of relying on file permissions of INI files under
different %userprofile% paths.

The registry is managed by the kernel. If an application crashes before
you can exit, registry changes are still committed.

Access to the registry is thread and multiple instance safe. Multiple
threads and multiple process can SIMULTANEOUSLY acess the same registry
keys and their data items and values without lockout. While you may not
employ multiple concurrent user logins (i.e., multi-user logins),
Windows is still capable of that using either FUS (fast user switching)
or terminal services. Also, this lets multiple components even within
the same application to access the same common settings across all those
components. For example, a suite of components (e.g., MS Office) can
have settings that are common across all components and all of them can
concurrently access the same settings. Changes to the data values is
atomic and immediately affected to the other components. No lockouts.
You can also exchange the same settings between multiple instances of
the same process without conflict. With INI files, one may have to wait
until the other unlocked the INI file (released its handle).

The registry wasn't designed for the convenience of users. It was
designed for better config management by *applications*. The only
reason we users end up delving into the registry is that quite often the
program developers do not expose all the settings in a configuration UI
that is callable from within the program. We have to keep accessing
settings the developers omitted or deliberately chose not to expose. So
if there are settings that you need to get at and seem like they should
be accessible to common or everday users then send feedback to the
program author to enhance the config UI. Yep, lots of Windows settings
are that way, too; however, Microsoft doesn't design registry work for
everyday users and intends experts and admins with education and
experience and eptitude to be delving into the registry.

The registry is daunting for humans, not for programs. There is one
scenario where INI files have an advantage over the registry: portable
operation. So whether or not an application was intended to be portable
is up to the program's author. Ask THEM to provide a settings export
function to save an INI file so their app is portable.
 
W

Wolf K

J. P. Gilliver (John) said:
Yet another case where - IMO - the registry is inappropriate.
INI files are slow. File I/O to read an INI file is much slower than
getting settings from memory.[...]
True, and you've provided a lot of relevant information on the Situation
As She Is Now. But it doesn't have to be that way. What with RAM being
so cheap, there's no reason that the settings data can't be loaded into
memory when the program starts. Besides, program-specific settings are
applied only once, when the program opens, so there's no need for them
to be in the registry. The registry should contain only OS related
settings. The API should take care of any talk between program and OS.

And so on.
 
S

Stan Brown

It is ... wait for it ... the registry.
Yet another case where - IMO - the registry is inappropriate.[/QUOTE]

Why? It seems quite appropriate to me.

In the bad old days, every program had an .ini file. I was delighted
to see us get away from that into storing preferences in the System
Registry. But Microsoft, in its infinite wisdom and mercy, created
AppData, and ProgramData, and god knows what-all-else, so now we have
to spend time searching for program preferences because they're all
in different places, often multiple places.
 
S

Stan Brown

regedit.exe and reg.exe only expose part of the registry
Really? Which parts can one not get at that way, assuming
appropriate privilege?
 
S

Stan Brown

The registry wasn't designed for the convenience of users. It was
designed for better config management by *applications*.
In my previous, I questioned one small part of what you wrote. I
didn't mean to detract from the great value of the rest, all of which
I agree with.

And possibly even of the part I questioned; I may learn something new
from your answer.
 
V

VanguardLH

Stan said:
Really? Which parts can one not get at that way, assuming
appropriate privilege?
The registry is a binary database. You don't read binary. So the
"editor" shows you text. That editor (regedit) cannot access all of the
registry's database. For example, there are system entries that are
considered for use only by the OS and that no user regardless of admin
or otherwise should ever see or touch. No user, including admins, are
allowed to see those system entries. I'm not talking about permissions.
I'm talking about parts of the registry that you will never see and can
never access using regedit.exe or reg.exe. Any program that interprets
the binary registry database by using the registry API can decide what
it will present to you, so some hives may be invisible to you, like:

HKEY_PERFORMANCE_DATA
This key provides runtime information into performance data provided
by either the NT kernel itself, or running system drivers, programs
and services that provide performance data. This key is not stored in
any hive and not displayed in the Registry Editor, but it is visible
through the registry functions in the Windows API, or in a simplified
view via the Performance tab of the Task Manager (only for a few
performance data on the local system) or via more advanced control
panels (such as the Performances Monitor or the Performances Analyzer
which allows collecting and logging these data, including from remote
systems).

Ever see anything listed under HKLM\Security? Just what, if anything,
do you see under HKLM\SAM? Yet your account info is stored in the SAM
database file. You're not allowed to directly dig into there. You have
to use the proper tools to modify account data to ensure it is
structured and validated for storage in SAM (Security Account Manager).
They don't want anyone putzing around directly in there.

Some hives have no value by themself and are built during the boot
process. You can, for example, load the registry database files into
regedit.exe from another instance of Windows: pick a hive, right-click,
and import and the static registry gets loaded as another hive in the
editor's view. Yet the following hive is meaningless when viewed on
your host since the values in that registry are rebuilt during the boot
process. Starts out empty, built on boot, and any changes are worthless
since that hive gets rebuilt on boot the next time.

HKEY_CURRENT_CONFIG (HKCC)
Abbreviated HKCC, HKEY_CURRENT_CONFIG contains information gathered at
runtime; information stored in this key is not permanently stored on
disk, but rather regenerated at boot time. It is a handle to the key
"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware
Profiles\Current", which is initially empty but populated at boot time
by loading one of the other subkeys stored in
"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles".

HKEY_DYN_DATA This key is used only on Windows 95, Windows 98 and
Windows Me. It contains information about hardware devices, including
Plug and Play and network performance statistics. The information in
this hive is also not stored on the hard drive. The Plug and Play
information is gathered and configured at startup and is stored in
memory.

Then there are tricks to hide registry entries. Since I don't practice
these hacks and don't care to screw around with my registry more than
absolutely required and then only to fix a problem, I can only cite
references to those tricks, like:

http://www.reviewingit.com/index.php/content/view/28/2/

Any program using the registry API can expose those hidden data items as
this utilizes a flaw in regedit.exe in how it present the binary data it
reads from the registry files. Also, another trick that doesn't make
them hidden but makes it impossible to delete a key is to use a
non-ASCII7 character that is not otherwise displayed, like character 127
for non-printing space. You won't see and and you cannot enter it and
regedit uses the presented value instead of the read value so it cannot
delete what it read because what it tries to delete is the presented
value and not the hex equivalent of the read value.

If a registry key has permissions that don't permit you to read that key
then the editor won't be showing it to you. In regedit, pick a key and
you'll notice that you have read permission to it. If you didn't then
you cannot read it which means you cannot see it. Read permission
grants you visibility to a key but does not permit you to modify it.
That's why sometimes you have to change permissions on a registry so you
can delete it. But if you can't see the registry key in the first place
then how are you going to select or view it? Yep, by using a 3rd party
program using the registry API to show you all the keys regardless of
their permissions.
 
K

Ken Blake

In the bad old days, every program had an .ini file. I was delighted
to see us get away from that into storing preferences in the System
Registry.

Why? I think it's preferable for each program to have its own file,
rather than sharing them. If the registry gets clobbered, nothing
works.
 
G

Gene E. Bloch

Ever see anything listed under HKLM\Security? Just what, if anything,
do you see under HKLM\SAM?
OK, I looked :)

In my registry editor, those two entries are shown in red, and they look
empty.

I also looked with regedit; there they are shown in black, but they
still look empty.

Now I feel deprived...
 
G

Gene E. Bloch

In the bad old days, every program had an .ini file. I was delighted
to see us get away from that into storing preferences in the System
Registry. But Microsoft, in its infinite wisdom and mercy, created
AppData, and ProgramData, and god knows what-all-else, so now we have
to spend time searching for program preferences because they're all
in different places, often multiple places.
Around the time I was in the service (in the US), the services were
unified. As a result, the three services became four.

Clearly Microsoft has learned from the military.
 
S

Stan Brown

Why? I think it's preferable for each program to have its own file,
rather than sharing them. If the registry gets clobbered, nothing
works.
If every single application has its own options file, and doesn't use
the Registry, what will happen if the Registry gets clobbered?

Right -- none of thee applications will eve get a chance to load,
because Windows won't work.
 
K

Ken Blake

If every single application has its own options file, and doesn't use
the Registry, what will happen if the Registry gets clobbered?

Right -- none of thee applications will eve get a chance to load,
because Windows won't work.

No, you missed my point. Or maybe I didn't make it clearly enough. My
preference is not to have a registry at all.
 
Ad

Advertisements

V

VanguardLH

Gene said:
OK, I looked :)

In my registry editor, those two entries are shown in red, and they look
empty.

I also looked with regedit; there they are shown in black, but they
still look empty.

Now I feel deprived...
As a test, in a virtual machine, you could see what happens to a visible
registry key when you change its permissions to NOT allow read access
(i.e., remove read privilege from that registry key). Then unload and
reload regedit.exe to see if that registry key is now invisible.

I had not thought of this trick to hide registry keys until I read it
while researching my response to Stan. Before that I only knew that
regedit didn't show everything of the registry's database. I has been
way too long since I last touched on that subject. I'm too old now so
new data pushes out old data -- FIFO, and only so many engrams remaining
nowadays while fuzzy logic is becoming more dominant. Time to reserve
some books on the registry at the library to do a refresh but then I'll
probably overwrite the engrams of my last highschool girlfriend's face
(the rest I'll remember for longer).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top