Location of winword.exe

Lobo's way is a good answer, but an alternative would also be:

Go into Windows Explorer
Highlight the root drive icon (C:)
Go to TOOLS > FIND > FILES & FOLDERS
Search for winword.exe and excel.exe

When they pop up in the result window it will show you the full path.

No please do not mistake me, I want to find it programmatically, Is there any way you can search for the same in the registry?

In the registry, you can find it at the location below:

HKEY_CURRENT_USER\Software\Microsoft\
Office\9.0\Word\Options\PROGRAMDIR

This may not be the same in all machines

The best answer by far is to run the find files & folders application from the start menu, select "lookin" and select "my computer" once this is selected in the "named" bar type in "winword.exe" click on find, diplayed in the botton of the window will be winword.exe, next to the icon will be the location of the folder. My guess would be C:\program files\msoffice\office\winword.exe. Follow the same process for "excel".

I hope this helps

Ben

yeh, it may not be the same in all machines, but you can search for it using PROGRAMDIR as the search phrase.

That's right but I can't do this programmatically, I'll have to do something with the registry only. I can use some API's to read from the registry if I know the path.

Location in registry:

Key: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WinWord.exe"
Value name:
"Path"
Value type:
"String"

Similarly for Microsoft Excel, replace "winword.exe" by "excel.exe"

It will work even in the following scenarios:
1. any version of word/excel,
2. any win32 environment( 95/98/3.11), even win 3.1,
3. any user login
etc.

Best regards
Tikshya

That's right but I can't do this programmatically, I'll have to do something with the registry only. I can use some API's to read from the registry if I know the path.

Hi VCGuru,

If you can make sure you have an existing word (or excel) file you could use API function FindExecutable().

Otherwise read the default value of key in ' HKEY_CLASSES_ROOT \ .doc ', should be something like 'Word.Document.8'. With this you can open a key like ' HKEY_CLASSES_ROOT \ Word.Document.8 \ shell \ open ' where you can find the whole executable path for winword. Proceed the same way for excel.

hope that helps,

ZOPPO

I know how to check "whether" MS office products are installed (from VB)...but I wouldn't know how to check "where" they're installed...if you want to check whether they are installed, let me know...I'll post the code...maybe knowing they are installed is one step closer to knowing where they're installed, huh??

Tikshya answer:

Location in registry:
Key: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WinWord.exe"
Value name: "Path"
Value type:  "String"

Similarly for Microsoft Excel, replace "winword.exe" by "excel.exe"

VCGuru responce:
That's right but I can't do this programmatically, I'll have to do something with the registry only. I can use some API's to read from the registry if I know the path.


Perhaps I'm missing something in your question but tikshya's answer is totally within the registry and can be  retrieved programmically.

Hi st_steve,
I'd like to have the code in VB. I'll increase the points appropriately if it suits my purpose,

Hi Zoppo,
thanks, I'll get back to you very soon,

Hi Tikshya
It works fine but with a hitch, Some of the machines here have word 6.0 The Registry strangely does not have winword.exe in the path you have mentioned.

Hi st_steve,
I'd like to have the code in VB. I'll increase the points appropriately if it suits my purpose,

Hi Zoppo,
thanks, I'll get back to you very soon,

Hi Tikshya
It works fine but with a hitch, Some of the machines here have word 6.0 The Registry strangely does not have winword.exe in the path you have mentioned.

will dig out the code....give me a few hours....it's on a CD-R that I've written to somewhere.....

cool

cool

VCGuru...I got some bad news...I found the CD-R that I've written the source code onto...but it seems I scratched the CD-R unknowingly...and I can't read the thing properly anymore.....

It's been a long time..and I even don't remember how I did that...I think I called some APIs but I can't seem to remember what....anyway...I think it's better for you to wait for an answer from some other experts....sorry I got your hopes up.....:(

word 6.0 is a win3.1 program so it might not be in the registry, perhaps you need to make it a special case.

go on the explorer on you drive c:\programs\micosoft office\office there you find your winword.exe and exel.exe. thats all

it's not always c:\programs files\Microsoft office\office, example I have no programs on my c: at all, it's my boot parition. I have it installed on d:\ and I'm pretty sure the installer allows you do choose the path to install it.

PLZ restate this a little.
You begin this as if q: is your personal PC, then it looks like you support someone anonymous.
In my case as a user, I may have many many versions of these products online, available, depending on when upgraded last, for I get multiple versions thru eMail as people upgrade, and quite often one cannot count on the new Office being able to read the old.  And then, don't forget the disparate varieties of Word readers.  Still, One machine near me now has three versions of Adobe's Reader, can read pdf's once launched, but O/S won't launch any from a browser at the moment (more work to do some day).

However...
If you cannot live with Lobo's check...
If you can MANAGE the environment, and have only simple issue involved, you might prefer to look at what the user 'wants' as the DEFAULT program to use for '.doc' files (word). Continuing, look in Registry for what user 'wants' as the 'default' program for eXplorer's '.xls' entries. Perhaps that is the version(s) of Office products you are interested in.

I don't think NT5 in a default hide-ext mode will defeat that either, but it isn't feb 17 yet.

Hey tommy_b,

before answering a question you should even read the comments, not only the question...

ZOPPO

At least read rejections?

VCGuru,
         Done?
If not, how about this: what are you trying to do?  If this is not complex but simple q:, how about:
A) Select       Start/Run
       enter    WinWord
B) Select       Start/Run
       enter    eXcel

My question is, do you really need the path for something EXECUTABLE to splice in, or, do you fear it not being there by default when you need it, or what?

(above I ref: potential for multiple versions, needing more on the goal here)

C) Start/Program/Command Prompt
       Enter           WinWord
D) Start/Program/Command Prompt
       Enter           _______  (someone else can post this guess)

Could your question involve something on how to get __________ to launch some M$Office exe's, or do you need to stuff something into one of the eight file locations I have listed in Word under tools/options, or are you just trying to explore the registry (like for an inventory-type process), or what? Could you expand further on your feb 2 comeent:
"..do this programmatically, I'll have to do something with the registry only. I can use some API's to read from the registry if I know the path."
Is this what you 'think' you must do?
ie, what is it that you must do.

Zoppo - I did not mean to add redundancy to your February 02 2000 post

As this stands, I guess there may remain something for VCGuru on API function FindExecutable(). Sounds good, but I haven't the experience.

but for FYI, on my NT WinWord (and eXcel similar),

' HKEY_CLASSES_ROOT \ Word.Document.8 \ shell \ open '

needs appended an
' \ command '
which then shows
"C:\microsoft office 97 professional\Office\Winword.exe" /n

which looks to be the answer if one can manage / admin a LAN to where one can count on that version, for in the same registry chain of 'Word.Document.8' I also have others, like 'Word.Document.6'.   So,

VCGuru,

Now, under HKLM's
SOFTWARE/Classes/.doc & SOFTWARE/Classes/.dot
I have a default of: "Word.Document.8"

Which would appear to be the way to flip the coin on which of the selections in HKEY_CLASSES_ROOT to check for path for office_ware; if one insists on doing so through such reg entries.

If it was me, I'd check out the "API function FindExecutable()" [Zoppo] first, for it sounds easier to manage (but I don't have time today).

a sidebar,
a) use file search listed above, find WinWord
b) right click name
c) left click properties
d) path lies under "location"

At this stage it seems to me that reproducing this is code like VB is second part of question.

While 1st part of question is which of potentially many WinWord's to choose from.  

As I suggest using the default for launching .doc's, I am leaving an open issue for this being mapped to alternatives like WordPad, NotePad, or even nothing at all.  This must be handled in the code.

VCGuru,
For Registry: "where exactly in my machine is winword.exe located(The path)?":

Try RegEdit to HKLM:
SOFTWARE/Microsoft/Windows/CurrentVersion/App Paths/<filename(s)>

Value Name Path should give you the goods on Office that you are looking for. This value won't likely need editing.  For more apps, you are better off with the Name (Default) which has both path and executable.  Of course you'll have to truncate the filename part, but on my systems, the Path is not always defined. (ex: WordPad).

This gives you main apps you are interested in, not ALL programs by any means.  It should be able to handle any wierd cases where the file extensions (classes in HKLM) have been redirected to other programs, or perhaps do not exist at all, and handle them without further intervention on your part.

The main problems with this are:

VCGuru want to determine the location of winword exe programmatically and independent from word's version. Older versions of Word do not set any registry key at all.

ZOPPO

Well, shame on M$.
I suspected that 'some' handling of registry settings have changed over time (ex: "the Path is not always defined"), but also thought that M$ had touched registry somewhere for every app added to it.

I have one '95 with version seven indicated in that entry. Maybe they began this section for only MS-Office apps, and Word6 is not one of those animals. Credit where due, I just noticed that my 'app paths' note (16 Feb) was Tikshya's Feb 2 answer: "..It will work even in the following scenarios: 1. any version of word/excel...". I'll leave it for Tikshya to defend an entry for Word6. My Win31 was confiscated by the local beautification committee.

VCGuru
- has some handle if not control of users and how this program(s) will run.  If it is known by VCGuru that the user is running MsWord, if it is known that the version is either v6 or v8, then a binary test for 'is it v8' can allow for rejections to default to v6. Since I just noted that v7 appears to be equally testable/findable this way to v8, then we can refine the boundary for 'older versions'.

Strangely, if I click on a .doc in explorer it rings up Word7, while if I peek the reg at HKLM\SOFTWARE\Classes\.doc
I get a
(default) = "Word.Document.6"
So I confess that some of the logic of this escapes me.

Unfortunatey I remain unsure of what the goal or purpose is, where the program needs to know path in order to _________.   There might be other ways to skinnie this.

VCGuru - is this for a case where the user is actually running the WinWord.exe?  Or is it more like an inventory process, where you make no assumptions on what user may be running?