http://bugs.winehq.org/show_bug.cgi?id=12380
Summary: Microsoft Word Viewer 2003: Cannot associate with *.doc files Product: Wine Version: 0.9.58. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: bammzilla@gabriana.com
To reproduce:
1) Start with a clean .wine profile just to make sure (delete .wine and run wineprefixcreate)
2) Install Microsoft Office Word Viewer 2003. Installation should succeed without problems.
3) Create a shortcut in KMenu (in KDE) or Applications menu (in Gnome). The command should look similar to this:
env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE"
depending, of course, on the installation path you selected, and label it Microsoft Office Word Viewer 2003 (or whatever you please).
Note that this step may be unneccessary because Wine may have already created this shortcut for you.
4) Associate *.doc files (application/msword) with the Microsoft Office Word Viewer 2003.
5) Double click on a *.doc file. Word Viewer opens but the document does not open.
==
Analysis:
It seems the wrong path to the document is sent to Word Viewer. To test this, replace wordview.exe with a script that displays the full path name.
You can see this problem without actually associating *.doc files with the viewer. In my desktop you can right-click on a *.doc file, select Open With, choose Other, then browse to the shortcut you created in Step 3. The result is the same; Word Viewer opens but the document is not loaded.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #1 from Lei Zhang thestig@google.com 2008-04-07 11:39:56 --- (In reply to comment #0)
Analysis:
It seems the wrong path to the document is sent to Word Viewer. To test this, replace wordview.exe with a script that displays the full path name.
What is the wrong path being sent? Is KDE/Gnome sending the Unix path to Wine instead of the Windows path?
http://bugs.winehq.org/show_bug.cgi?id=12380
Tefnet developers developers@tefnet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |developers@tefnet.pl
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #2 from Bamm Gabriana bammzilla@gabriana.com 2008-04-12 19:26:07 ---
What is the wrong path being sent? Is KDE/Gnome sending the Unix path to Wine instead of the Windows path?
Sorry for the late reply, lost access to the Internet for a few days. Yes KDE is sending the Unix path to Wine; can't test for Gnome at the moment.
Here's what I did: I whipped up a quick Visual Basic program whose only line is "MsgBox Command". This will display whatever is given as the command line parameters. I compiled it as "param.exe". I then created a Wine shortcut to param.exe, and associated *.doc files with it. After clicking on a document on the desktop, a message box popped up with the following message:
/home/bamm/Desktop/test.doc
Wine should automatically translate a Unix path to the corresponding Windows path. I was hoping to see the following result:
z:\home\bamm\Desktop\test.doc OR simply, d:\Desktop\test.doc (since I have D: mapped to my home folder in winecfg).
Curiously, this bug only affects certain apps. Examples are Word Viewer, Excel Viewer, and IrfanView.
Powerpoint Viewer is not affected, for some reason. One can associate pptview with ppt files and the files are opened with no problem. However I do not understand how PPT Viewer got it right, since my test above shows that a random windows program like param.exe gets sent the Unix path.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #3 from Bamm Gabriana bammzilla@gabriana.com 2008-04-12 19:39:53 --- Created an attachment (id=12109) --> (http://bugs.winehq.org/attachment.cgi?id=12109) Windows executable "param.exe" that displays the command line
The attached executable param.exe was written in VB6 with only one command MsgBox Command.
Replacing wordview.exe with this file, we can see that wordview (and other programs) receives the Unix path instead of the Windows path.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #4 from Tefnet developers developers@tefnet.pl 2008-04-13 03:41:32 --- Maybe you can try this solution: http://article.gmane.org/gmane.comp.emulators.wine.patches/49959
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #5 from Bamm Gabriana bammzilla@gabriana.com 2008-04-13 08:15:54 ---
Maybe you can try this solution: http://article.gmane.org/gmane.comp.emulators.wine.patches/49959
Thanks for the link. The page you gave says:
"File managers naturally use the unix path to start files, and the wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else)."
I think that Wine itself should report the correct path that the applications expect. I already have a shell script that I insert in the command line to correct the path; hence it is not a problem for me. Nevertheless I reported this because it is a bug in Wine, and imho needs fixing. People should be able to associate file types directly without resorting to workarounds.
http://bugs.winehq.org/show_bug.cgi?id=12380
Bamm Gabriana bammzilla@gabriana.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.58. |0.9.61.
--- Comment #6 from Bamm Gabriana bammzilla@gabriana.com 2008-05-07 09:56:50 --- It still doesn't work.
Wine 0.9.60 gave me the impression that this has been fixed. The release notes said:
- Better support for launching apps from Unix file managers.
Vincent Povirk (2): start.exe: Add /Unix switch for native file managers. tools: Modify wine.desktop to use start.exe /unix.
So, with the latest 0.9.61 under Kubuntu, I tried:
1) Clean Wine prefix (by deleting .wine and running wineprefixcreate) 2) Install Word Viewer (installer creates a shortcut in KMenu. Good.) 3) Associate *.doc with the .desktop file associated with Word Viewer. 4) Click on a *doc file.
Result: Word Viewer opens but still no file loaded.
Next, I tried adding start.exe /Unix to the .desktop file's command line. That is, modifying the command line from
env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE"
to
env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" %U
Result: Word Viewer opens but still no file loaded.
So it looks like the solution posted didn't work.
http://bugs.winehq.org/show_bug.cgi?id=12380
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|0.9.61. |0.9.58.
--- Comment #7 from James Hawkins truiken@gmail.com 2008-05-07 10:16:03 --- Don't change the original reported version.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #8 from Bamm Gabriana bammzilla@gabriana.com 2008-05-07 10:44:56 ---
Don't change the original reported version.
Sorry, I didn't know. :)
http://bugs.winehq.org/show_bug.cgi?id=12380
dennis djtm@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |djtm@gmx.net
--- Comment #9 from dennis djtm@gmx.net 2008-05-26 02:52:03 --- I can confirm this bug with Microsoft Word 2003 under wine 0.9.59 and kubuntu.
My fix was to simply add a Z: in front of the path and it worked, as Z: is my root / linux directory.
I also think it should be fixed, as some part of wine should handle converting the file paths to ones that can be understood by the windows programs.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #10 from Bamm Gabriana bammzilla@gabriana.com 2008-05-28 23:56:58 --- Shouldn't this be fixed by 1.0? I mean, people who install Word viewer would want the ability to associate *.doc files with it as easily as they can associate native Linux apps.
My fix was to run word viewer from a script that detects if an arg is a path (by checking if it contains a slash), and if so, replaces each / with a \ and adds a z: at the beginning, and then passes the string to wordview.exe.
Come to think of it, all apps running in Wine (not just wordview) should be run from such a script; this way user files passed on to them would be converted to a DOS-path.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #11 from Bamm Gabriana bammzilla@gabriana.com 2008-05-29 00:08:23 ---
Come to think of it, all apps running in Wine (not just wordview) should be run from such a script; this way user files passed on to them would be converted to a DOS-path.
I applied a similar technique to IrfanView and now all my images can be opened in IrfanView by just double-clicking on them.
#!/bin/sh if [ "$@" ]; then arg=z:`echo $@ | sed -e 's///\\/g'`; fi wine "C:\Program Files\IrfanView\i_view32.exe" "$arg";
The solution being so simple (but inelegant), why can't something similar be implemented by default on all apps installed in Wine?
A more elegant solution would be to get rid of this script altogether and use Wine's built-in function for converting Unix to DOS path. (Is there such a function? I may be misinformed.)
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #12 from Lei Zhang thestig@google.com 2008-05-29 10:48:41 --- yes, it's called winepath.
http://bugs.winehq.org/show_bug.cgi?id=12380
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #13 from Detlef Riekenberg wine.dev@web.de 2008-05-30 17:38:36 --- (In reply to comment #6)
- Clean Wine prefix (by deleting .wine and running wineprefixcreate)
Result: Word Viewer opens but still no file loaded.
Next, I tried adding start.exe /Unix to the .desktop file's command line.
This is the Problem: You used a clean Wine, but the .desktop file is old (without /unix)
to env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" %U
Result: Word Viewer opens but still no file loaded.
Wine is correct here.
So it looks like the solution posted didn't work.
Remember, what parameter is a unix path, and how you modified your .desktop file
Remove the reference of WORDVIEW.EXE:
env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix %U
Problem fixed.
http://bugs.winehq.org/show_bug.cgi?id=12380
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #14 from Vincent Povirk madewokherd@gmail.com 2008-05-30 18:05:48 --- Just to clarify, my intention (and as far as I know it now works this way) was that any file could be opened with "Wine Windows Emulator" in a shell, and it would open with whatever program is associated with that file type in Wine. It should not be necessary to create another .desktop file for Word Viewer.
http://bugs.winehq.org/show_bug.cgi?id=12380
Bamm Gabriana bammzilla@gabriana.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED |
--- Comment #15 from Bamm Gabriana bammzilla@gabriana.com 2008-05-30 19:07:06 ---
env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix %U
I'm using Kubuntu and Mandriva.
Ah, so now I see what you're at. You're solution was to associate it with START not with Word Viewer. So *.doc is still not associated with Word Viewer in Konqueror. Rather, you used the fact that *.doc is associated with Word Viewer in Explorer.
What I want, is for a user to associate extensions to programs in the /same way/ they do for normal Linux programs - that is, you can select a program from the set of existing shortcuts on the applications menu to open it in.
Also, your solution relies on the fact that the installer adds the associations to the Wine registry.
Let's take a look at my other example, IrfanView. By default IrfanView does NOT make any associations in the registry. So associating *.png with "wine start" will not help. Besides, the intuitive approach for any user is to select IrfanView from the menu, and associate it with its Desktop file.
So, I digress. I'm reopening this until Wine itself can correct the paths it sends to the application it runs.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #16 from Vincent Povirk madewokherd@gmail.com 2008-05-30 19:25:38 --- So you're using KDE then..
KDE did not automatically give you the option to open .doc files with Word Viewer when you installed it, did it? If it did, that would be bad (because the application shortcut cannot be used to open files).
Judging by what you tried, it seems opening things with "Wine Windows Emulator" to use a separate and invisible "Wine associations" is not the most intuitive way to solve a problem of the form "I want to open .x files in program Y that I have installed in Wine." The ideal behavior would be to create a separate .desktop file for anything that would show up on the "Open With" list on Windows, for Linux's "Open With" list.
I did a search on this topic, and apparently the "Open With" information is kept in the registry, completely separate from the start menu shortcuts. Somehow Windows gets a list of application names, extensions for each of them to attempt to run (which we can convert to mime types), and icons. We should be able to do that too.
Having Wine "correct the paths it sends to applications" is impossible. There's no way for Wine to determine whether what it is being given is meant to be a unix path (and therefore in need of conversion), windows path, or something completely different (say, a command line switch), and there's no way to determine what the application expects. The only thing the wine command will ever do with its argument list is pass it along unchanged to the .exe it runs.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #17 from Bamm Gabriana bammzilla@gabriana.com 2008-05-30 20:18:51 ---
KDE did not automatically give you the option to open .doc files with Word Viewer when you installed it, did it? If it did, that would be bad (because the application shortcut cannot be used to open files).
I did not understand what you mean. However, a shortcut to Word Viewer was automatically created in the menu. Double-click a DOC file, and the Open With dialog shows up. I select Word Viewer. Now I double click on DOC and the viewer opens but no file.
I can also do, from Konqueror, Settings > Configure Konqueror > File Associations and then add *.doc, and add an application to open it. A list of programs shows up. First I add OpenOffice, then I add Word Viewer.
Judging by what you tried, it seems opening things with "Wine Windows Emulator" to use a separate and invisible "Wine associations" is not the most intuitive way to solve a problem of the form "I want to open .x files in program Y that I have installed in Wine."
From what I read here, I can see that I need to make a shortcut for start.exe,
then select that instead. This will create more problems! Right-clicking on a doc file, selecting the Open With menu, will show "Open with start" rather than "Open with Word Viewer".
The intuitive approach is to select Microsoft Word Viewer from a list of applications. Remember that the .desktop file for Word Viewer is already automatically created by the installer. How is a user supposed to know that he should NOT select it, and that he should create a new desktop for start.exe and use that instead? This is confusing. I am not a newbie but I was confused by it. If Microsoft Word Viewer appears on the list of choices, then I would naturally select it.
The ideal behavior would be to create a separate .desktop file for anything that would show up on the "Open With" list on Windows, for Linux's "Open With" list.
In KDE the Open With list is the same as the applications menu list. A user gets to choose from existing installed applications.
I did a search on this topic, and apparently the "Open With" information is kept in the registry, completely separate from the start menu shortcuts. Somehow Windows gets a list of application names, extensions for each of them to attempt to run (which we can convert to mime types), and icons. We should be able to do that too.
I do not understand what you mean. I hope you can explain it more fully.
Having Wine "correct the paths it sends to applications" is impossible. There's no way for Wine to determine whether what it is being given is meant to be a unix path (and therefore in need of conversion), windows path, or something completely different (say, a command line switch), and there's no way to determine what the application expects.
Let's say Wine receives the following command:
wine C:\WINDOWS\notepad.exe /p /home/bamm/sample.txt
and further assume that we are using native notepad instead of wine notepad. There are two arguments, a /p switch and /home/bamm/sample.txt.
The question is, which is a file and which is a switch, since both begin with a slash?
1) Idea #1
Checking if the file exists may be good for most cases. If file /p exists then convert if not then pass it to notepad. Next step, if file /home/bamm/sample.txt exists then convert to Z:\home\bamm\sample.txt otherwise pass it on as /home/bamm/sample.txt
The only flaw would be if a file /p actually exists in the root directory. However I think it is very unlikely that a switch required by a Win32 program would have a file of the same name exist in the root directory. Only root can create files in the root directory so this would make it unlikely unless the administrator purposely created such a file.
The idea would be that if a user passed on a non-existent file as one of the arguments, it would be passed on to the program unchanged. But if an existing file is passed, as is always the case when a file is double-clicked, then do the conversion.
2) Idea #2
Since the shortcuts have a %U% in them, then we can be sure that these represent files. For example, in my case I have
env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" %U%
the above was auto-created when wordview was installed. Maybe this string can be modified in such a way that Wine will recognize which of the parameters is a file. I have an idea but I need to work on it more.
There will be no confusion for other switches like /p because they have their own desktop files if needed, e.g., Print with Word Viewer would be
env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" /p %U%
I'd like to know how the .desktop shortcuts are created whenever a program is installed in Wine. This will help me develop my idea more.
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #18 from Vincent Povirk madewokherd@gmail.com 2008-05-30 20:59:46 --- In GNOME, the "Open With" dialog simply shows a list of applications. This list contains only .desktop files that claim to be able to open programs (which are not necessarily in the menu at all). Wine installs a shortcut named "Wine Windows Emulator" in wine.desktop, mainly for handling .exe files (my changes were primarily to solve some problems with the .exe file support, not to add support for other filetypes).
"Wine Windows Emulator" should automatically show up in your Open With dialog even though it is not in your menu. You should not have to create a shortcut for it.
I don't think KDE should be offering to open files using random menu shortcuts that do not claim to be able to open files.
The best information I was able to find so far on how the "Open With" dialog works on windows is at http://windowsxp.mvps.org/OpenWith.htm. Apparently programs install certain registry keys to let Windows know that they can open specific types of files.
For how this is handled on Linux, see http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-lates.... Note the MimeType field. If present in a .desktop file (and only then IMO), the desktop environment should offer to open files of that type with that program, whether the .desktop file shows up in a menu or not.
Checking if the file exists may be good for most cases. If file /p exists then convert if not then pass it to notepad. Next step, if file /home/bamm/sample.txt exists then convert to Z:\home\bamm\sample.txt otherwise pass it on as /home/bamm/sample.txt
This won't fly. It will break something. The easiest example for me to come up with right now is cygwin. Cygwin has its own virtual unix paths that we don't want to convert, even though it's likely in many cases that a file exists with the same name.
Since the shortcuts have a %U% in them, then we can be sure that these represent files. For example, in my case I have
env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" %U%
the above was auto-created when wordview was installed. Maybe this string can be modified in such a way that Wine will recognize which of the parameters is a file. I have an idea but I need to work on it more.
Wine does not write shortcuts with %U% in them (and if it were to do something like that, %F would be slightly more correct). KDE probably added that to your shortcut.
That could work though. The .desktop file can be written in such a way that what it calls (which doesn't have to be wine exactly) knows that the first N arguments should be taken literally and anything after that must be a unix filename that should be converted to a windows filename. Of course, the contents of the .desktop file would probably be slightly less readable, and we'd need a command in wine that understands that.
Desktop files for start menu shortcuts are created by winemenubuilder.exe, which calls the wineshelllink script. Roughly, winemenubuilder is responsible for reading information from the .lnk and converting the icon, and wineshelllink uses the information to create the .desktop file and menu structure.
http://bugs.winehq.org/show_bug.cgi?id=12380
Robert Cabane rcoo@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoo@free.fr
--- Comment #19 from Robert Cabane rcoo@free.fr 2008-07-17 02:48:37 --- I had the very same problem, which I found also while trying to associate *.mws files with Maple V R 4 app. And the solution IS quite simple. Clearly, launching from a shellscript wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE $1 ($1 being the document to open) wouldn't work. The viewer starts but doesn't show anything. You have to start, instead : wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE "Z:"$@ THE trick is to insert "Z:" before the command-line arguments.
Now for KDE : just asssign vnd.ms-word mimetype to wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE "Z:"%U
http://bugs.winehq.org/show_bug.cgi?id=12380
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=12380
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com Status|UNCONFIRMED |ASSIGNED Difficulty|--- |Days Ever Confirmed|0 |1 Keywords| |integration Summary|Microsoft Word Viewer 2003: |Support fd.o file type |Cannot associate with *.doc |associations |files |
--- Comment #20 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-22 00:16:33 --- Hello
I am working on this bug. Over the past couple of days I've sent in some related patches.
Accepting, changing summary, adding integration keyword. Expect it to work by next week.
As HKEY_CLASSES_ROOT needs to merge HKEY_CURRENT_USER\Software\Classes but doesn't, this still won't work for some applications like uTorrent (#17019).
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #21 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-22 00:18:07 --- *** Bug 13597 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12380
--- Comment #22 from Damjan Jovanovic damjan.jov@gmail.com 2009-01-24 05:10:27 --- I've sent some patches to wine-patches:
http://www.winehq.org/pipermail/wine-patches/2009-January/068286.html http://www.winehq.org/pipermail/wine-patches/2009-January/068287.html http://www.winehq.org/pipermail/wine-patches/2009-January/068288.html
With them, it works nicely for me :-).
http://bugs.winehq.org/show_bug.cgi?id=12380
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #23 from Damjan Jovanovic damjan.jov@gmail.com 2009-06-12 10:46:09 --- Latest Git has all the needed patches for Wine's file type associations to integrate and work from freedesktop -> closing RESOLVED FIXED.
http://bugs.winehq.org/show_bug.cgi?id=12380
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2009-06-19 10:58:45 --- Closing bugs fixed in 1.1.24.
http://bugs.winehq.org/show_bug.cgi?id=12380
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |f612ed1fcbdf67830f5598dbb08 | |c627a92a46ea7 CC| |focht@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=12380
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |shell32
-
wine-bugs＠winehq.org