ChangeSet ID: 1130937534219311569425376
CVSROOT: /cvsroot/wine
Module name: docs
Changes by: dimi(a)sc8-pr-cvs1.sourceforge.net 2005/11/02 05:18:54
Modified files:
en : wine-faq.sgml
Log message:
Jonathan Ernst <Jonathan(a)ErnstFamily.ch>
- user user -> user
Old revision New revision Changes Path
1.13 1.14 +1 -1 docs/en/wine-faq.sgml
Index: docs/en/wine-faq.sgml
diff -u -p docs/en/wine-faq.sgml:1.13 docs/en/wine-faq.sgml:1.14
--- docs/en/wine-faq.sgml 2 Nov 2005 13:18:54 -0000
+++ /dev/null 2 Nov 2005 13:18:54 -0000
@@ -1575,7 +1575,7 @@ export PATH=$PATH:/path/to/wine/binary
or equipment donations, to aid the Wine developers in reaching their goals.
</para>
<para>
- One area where every Wine user user can contribute to this project is by sending high quality
+ One area where every Wine user can contribute to this project is by sending high quality
bug reports to our Bugzilla and helping the developers with any follow up questions that they
may have about a bug that you have come across. It is not only impossible but also impractical
for a developers to have a copy of every program on the market. This is why we need your
ChangeSet ID: 21043
CVSROOT: /opt/cvs-commit
Module name: wine
Changes by: julliard(a)winehq.org 2005/11/02 05:43:20
Modified files:
dlls/shell32 : shfldr_unixfs.c
Log message:
Michael Jung <mjung(a)iss.tu-darmstadt.de>
Added some comments to document unixfs.
Patch: http://cvs.winehq.org/patch.py?id=21043
Old revision New revision Changes Path
1.56 1.57 +104 -0 wine/dlls/shell32/shfldr_unixfs.c
Index: wine/dlls/shell32/shfldr_unixfs.c
diff -u -p wine/dlls/shell32/shfldr_unixfs.c:1.56 wine/dlls/shell32/shfldr_unixfs.c:1.57
--- wine/dlls/shell32/shfldr_unixfs.c:1.56 2 Nov 2005 11:43:20 -0000
+++ wine/dlls/shell32/shfldr_unixfs.c 2 Nov 2005 11:43:20 -0000
@@ -18,6 +18,110 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+/*
+ * As you know, windows and unix do have a different philosophy with regard to
+ * the question of how a filesystem should be laid out. While we unix geeks
+ * learned to love the 'one-tree-rooted-at-/' approach, windows has in fact
+ * a whole forest of filesystem trees, each of which is typically identified by
+ * a drive letter.
+ *
+ * We would like wine to integrate as smoothly as possible (that is without
+ * sacrificing win32 compatibility) into the unix environment. For the
+ * filesystem question, this means we really would like those windows
+ * applications to work with unix path- and file-names. Unfortunately, this
+ * seems to be impossible in general. Therefore we have those symbolic links
+ * in wine's 'dosdevices' directory, which are used to simulate drives
+ * to keep windows applications happy. And as a consequence, we have those
+ * drive letters show up now and then in GUI applications running under wine,
+ * which gets the unix hardcore fans all angry, shouting at us @#!&$%* wine
+ * hackers that we are seducing the big companies not to port their applications
+ * to unix.
+ *
+ * DOS paths do appear at various places in GUI applications. Sometimes, they
+ * show up in the title bar of an application's window. They tend to accumulate
+ * in the most-recently-used section of the file-menu. And I've even seen some
+ * in a configuration dialog's edit control. In those examples, wine can't do a
+ * lot about this, since path-names can't be told appart from ordinary strings
+ * here. That's different in the file dialogs, though.
+ *
+ * With the introduction of the 'shell' in win32, Microsoft established an
+ * abstraction layer on top of the filesystem, called the shell namespace (I was
+ * told that Gnome's virtual filesystem is conceptually similar). In the shell
+ * namespace, one doesn't use ascii- or unicode-strings to uniquely identify
+ * objects. Instead Microsoft introduced item-identifier-lists (The c type is
+ * called ITEMIDLIST) as an abstraction of path-names. As you probably would
+ * have guessed, an item-identifier-list is a list of item-identifiers (whose
+ * c type's funny name is SHITEMID), which are opaque binary objects. This means
+ * that no application (apart from Microsoft Office) should make any assumptions
+ * on the internal structure of these SHITEMIDs.
+ *
+ * Since the user prefers to be presented the good-old DOS file-names instead of
+ * binary ITEMIDLISTs, a translation method between string-based file-names and
+ * ITEMIDLISTs was established. At the core of this are the COM-Interface
+ * IShellFolder and especially it's methods ParseDisplayName and
+ * GetDisplayNameOf. Basically, you give a DOS-path (let's say C:\windows) to
+ * ParseDisplayName and get a SHITEMID similar to <Desktop|My Computer|C:|windows|>.
+ * Since it's opaque, you can't see the 'C', the 'windows' and the other stuff.
+ * You can only figure out that the ITEMIDLIST is composed of four SHITEMIDS.
+ * The file dialog applies IShellFolder's BindToObject method to bind to each of
+ * those four objects (Desktop, My Computer, C: and windows. All of them have to
+ * implement the IShellFolder interface.) and asks them how they would like to be
+ * displayed (basically their icon and the string displayed). If the file dialog
+ * asks <Desktop|My Computer|C:|windows> which sub-objects it contains (via
+ * EnumObjects) it gets a list of opaque SHITEMIDs, which can be concatenated to
+ * <Desktop|...|windows> to build a new ITEMIDLIST and browse, for instance,
+ * into <system32>. This means the file dialog browses the shell namespace by
+ * identifying objects via ITEMIDLISTs. Once the user has selected a location to
+ * save his valuable file, the file dialog calls IShellFolder's GetDisplayNameOf
+ * method to translate the ITEMIDLIST back to a DOS filename.
+ *
+ * It seems that one intention of the shell namespace concept was to make it
+ * possible to have objects in the namespace, which don't have any counterpart
+ * in the filesystem. The 'My Computer' shell folder object is one instance
+ * which comes to mind (Go try to save a file into 'My Computer' on windows.)
+ * So, to make matters a little more complex, before the file dialog asks a
+ * shell namespace object for it's DOS path, it asks if it actually has one.
+ * This is done via the IShellFolder::GetAttributesOf method, which sets the
+ * SFGAO_FILESYSTEM if - and only if - it has.
+ *
+ * The two things, described in the previous two paragraphs, are what unixfs is
+ * based on. So basically, if UnixDosFolder's ParseDisplayName method is called
+ * with a 'c:\windows' path-name, it doesn't return an
+ * <Desktop|My Computer|C:|windows|> ITEMIDLIST. Instead, it uses
+ * shell32's wine_get_unix_path_name and the _posix_ (which means not the win32)
+ * fileio api's to figure out that c: is mapped to - let's say -
+ * /home/mjung/.wine/drive_c and then constructs a
+ * <Desktop|/|home|mjung|.wine|drive_c> ITEMIDLIST. Which is what the file
+ * dialog uses to display the folder and file objects, which is why you see a
+ * unix path. When the user has found a nice place for his file and hits the
+ * save button, the ITEMIDLIST of the selected folder object is passed to
+ * GetDisplayNameOf, which returns a _DOS_ path name
+ * (like H:\home_of_my_new_file out of <|Desktop|/|home|mjung|home_of_my_new_file|>).
+ * Unixfs basically mounts your dos devices together in order to construct
+ * a copy of your unix filesystem structure.
+ *
+ * But what if none of the symbolic links in 'dosdevices' points to '/', you
+ * might ask ("And I don't want wine have access to my complete hard drive, you
+ * *%&1#!"). No problem, as I stated above, unixfs uses the _posix_ apis to
+ * construct the ITEMIDLISTs. Folders, which aren't accessible via a drive letter,
+ * don't have the SFGAO_FILESYSTEM flag set. So the file dialogs should'nt allow
+ * the user to select such a folder for file storage (And if it does anyhow, it
+ * will not be able to return a valid path, since there is none). Think of those
+ * folders as a hierarchy of 'My Computer'-like folders, which happen to be a
+ * shadow of your unix filesystem tree. And since all of this stuff doesn't
+ * change anything at all in wine's fileio api's, windows applications will have
+ * no more access rights as they had before.
+ *
+ * To sum it all up, you can still savely run wine with you root account (Just
+ * kidding, don't do it.)
+ *
+ * If you are now standing in front of your computer, shouting hotly
+ * "I am not convinced, Mr. Rumsfeld^H^H^H^H^H^H^H^H^H^H^H^H", fire up regedit
+ * and delete HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\
+ * Explorer\Desktop\Namespace\{9D20AAE8-0625-44B0-9CA7-71889C2254D9} and you
+ * will be back in the pre-unixfs days.
+ */
+
#include "config.h"
#include "wine/port.h"
