wine users - May 2005 - Navigating to the upper floor of the /Home directory using Wine.

I want to be able to use Wine to reach the /home base partition or
directory. By wanting such a thing, do I install Wine on the /usr
directory or do I do that on home itself?

Robert Yu schreef:
> I want to be able to use Wine to reach the /home base partition or
> directory. By wanting such a thing, do I install Wine on the /usr
> directory or do I do that on home itself?
Where you install Wine is not relevant to this question (so just install
it to the default location).

Make a symbolic link in /home/username/.wine/dosdevices to your /home
directory and call it d:

When Windows programs then install to or try to read from the D:\ drive
as accessed by an Open or Save dialog dialog, the dialog will be showing
you the files and folders in your /home directory, like so:

 $ la ~/.wine/dosdevices
totaal 0
drwxr-xr-x  2 motub users 120 mei 19 22:35 .
drwxr-xr-x  4 motub users 192 mei 15 17:55 ..
lrwxrwxrwx  1 motub users  10 mei  3 13:00 c: -> ../drive_c
lrwxrwxrwx  1 motub users  11 mei 19 22:35 d: -> /home/motub
lrwxrwxrwx  1 motub users   1 mei  3 13:00 z: -> /


As you can see, c: is a link to ~/.wine/drive_c (the ../ indicates that
you move up one level from the level you're currently at); d: is a link
to the user 'motub''s home directory, and z: is a link to the /
partition.

Hope this helps,
Holly

Robert Yu schreef:
> So to translate this to M$ terms, it shall be the following:
> 
> C:\---------
>             |
>             Macromedia Flash MX
>             Pics
>             Power Rangers Video game
> 
> D:\--------
>            |
>            Home------------
>                                |
>                                 Motobut
> 
> Is there a way to move up the C a and  D directories? And what is a
> symbolic link?
> 
Robert, you've forgotten to use Reply to All again-- the idea of having
a mailing list is that both questions and replies should go to the list
so that others with the same problem can also find the answer.

Now, as to your question: Not exactly.

First of all, let's not "translate into M$ terms". They don't
exist; the
 "drives" you are creating are a fiction to fool Windows-based
programs.
You don't have a C:\ or a D:\ drive under Linux. You have partitions,
mounted to directories under the / filesystem.

Even if you have a FAT32 partition which is recognized as C:\ under
Windows, that is meaningless when you're booted into Linux; that same
partition is no longer considered C:\ (because Linux does not recognize
that naming convention), but /dev/hd*, mounted as
/home/username/windrive (or whatever) via /etc/fstab.

And it seems to me that thinking of that partition as C:\ is just
confusing you, so let's not do that anymore.

Let's talk about symbolic links instead. I think I explained this once
before. A symbolic link (usually known as a symlink) is a way to call a
path by a different name, and often make it shorter.

Let's say I have an important and often-used document-- my CV/resume--
in a folder somewhere on my drive. My resume/CV is called CV.txt, and
it's in the folder /home/holly/storage/docs/work. Thus, the full path to
the document is ~/storage/docs/work/CV.txt.

Now, if I open up a file manager in order to open up that file, I have
to go through 3 folders (since the file manager starts in my home folder
by default) in order to get to it. First (double-)click the "storage"
folder, then (double-)click the "docs" folder, then (double-)click the
"work" folder, then (double-)click the CV.txt file to open it. That
gets
very tedious, very fast, if I use the file a lot.

However, what I can do is make a symlink in my home folder, directly to
the file. The symlink is not itself a file; it's just a pointer that
says where the file is. So if I symlink ~/storage/docs/work/CV.txt to
~/CV.txt, an icon (with a "shortcut" overlay) called CV.txt will
appear
in my home folder. If I (double-)click it, ~/storage/docs/work/CV.txt
will open. The *link* in my home directory is a *symbol* representing
the real file much deeper in my directory tree. I can delete symlinks,
change their names, move them to another directory, all without
affecting the file they refer to, because they're only symbols, and
symbols only mean what we say they mean.

For Wine, the use of symlinks is slightly expanded. The symlinks in
~/.wine/dosdevices are still symbolic links to Linux drives or
partitions mounted under the / filesystem-- but for Wine, names are
important, because Windows only understands certain names, Windows
requires that certain specific names exist, and programs that run under
Windows expect these names to exist and for certain specificly-named
files to be in certain specifically-named places.

So if a program is looking for a particular standard system file, that
file *must be* in C:\Windows(or WINNT)\System(32), dependent on Windows
version, because Windows applications know that that's the only place
Windows places such files.

However, this Linux system does not have a C:\ drive, nor a Windows
folder. What it has is /usr, /home, etc. So Wine uses symlinks to
mediate between the filesystem that Windows applications expect, and the
Linux filesystem that actually exists. This is the purpose of the
/dosdevices directory. It contains the symlinks that tell Wine what
parts of the real Linux filesystem you want to use, and what you want
Wine to tell Windows they are called.

If you look in your ~/.wine/dosdevices directory, you will find at least
two symlinks. One called c: and one called z: . The c: symlink points to
~/.wine/drive_c (if you click it, that is the folder that will open in
your file manager). This folder and its contents are created by Wine on
firstrun, because, in order for Windows to run, a folder must be
designated as "C:\Windows", and that folder must be populated with
certain contents. Otherwise no Windows application will be fooled into
believing that it is being run under Windows. So Wine creates this
folder, populates it with the necessary contents, and creates the c:
symlink. That symlink must be named c: because the drive containing the
Windows system folders is always C:\ (this is in the Microsoft Knowledge
Base). The other symlink, z: , points to the / -- the Linux filesystem
root. This is so that you can get to the rest of your filesystem in a
Windows Open or Save dialog-- and it is named z: so that there is no
possibility of it conflicting with any other symlinks you may create.
The assumption is, then, clearly that you will create additional
symlinks to suit your particular needs.

So yes, you are free to create links using whatever drive letters are
not used by default. For example, a: would by default be your floppy
drive and b: would be a second floppy if you had one-- these are Windows
defaults, so it is best not to link anything to those letters. But d:
through y: are perfectly free for you to link to whatever you like. M:\
is the drive letter Windows usually gives removable devices like CD-ROMs
or DVDs, so I like to link m: to /mnt/cdrom (or /media/dvdrecorder, or
wherever my distribution mounts my DVD-RW). Linking /home/username to d:
makes it faster to browse through Open and Save dialogs if you save a
lot of stuff to your {HOME} since such dialogs usually open in C:\ by
default. I don't save that much in ~/, but I like to keep my Wine
applications all together, so they have their own partition, which I
link to d: and {HOME} to e: .

To make a symlink, open a terminal and type

ln -s <source_directory_or_file>
<location_and_name_of_the_final_link>

So to make a symlink in dosdevices, to /home, called d:, you would type

ln -s /home/username /home/username/.wine/dosdevices/d:

(replace "username" with the name of the user in question) and hit
Enter.

Now browse to ~/.wine/dosdevices in a file manager, and click on the new
d: link; you'll find yourself looking at your home directory. Then open
a Windows program --notepad.exe is a good one for this experiment; wine
notepad.exe in a terminal should bring it up.

In the blank document, type anything, then save it to the D:\ drive as
whatever.txt. Close notepad, open your file manager, and look for
whatever.txt-- there it is, in your /home folder.

That's how it works-- Windows programs now consider your /home folder to
be the D:\ drive, because that's what your symlink told Wine to tell the
Windows programs (that d: is a symbol representing ~/ to Linux and D:\
to Windows).

Hope this helps.
Holly

Hi,

I Cc this posting to the list, because it might be interesting for
others to. It is something about the ideas behind WineTools that could
be interesting for the developers also:

Am Fr, Mai 20, 2005 at 03:03:00 +0200 schrieb Holly
Bostick:
> I also appreciate the info on WineTools, which, from all that I hear, is
> a lovely program. I'm looking forward to trying it at some point, but
> atm I'm "in the middle of" (quoted because I've just
started) a massive
> project testing a huge number of apps (mostly games) under both Cedega
> and several versions of Wine. Since you, among others, consider 20041019
> the last stable Wine, and we both know that it's a wild guess as to
what
> Wine version any user who appears on the wine-user's list may in fact
> have installed, it seems prudent to install the apps I'm testing under
> all Wine versions from 20041019 through current. What I'm trying to
> create is some kind of master list--mostly for myself, but I'm happy to
> post it as a web page for the public that may want to run some of these
> as well, as well as (of course) providing any results to the appdb-- as
> to which of the applications/games I normally want to install run under
> what version of what variant of Wine, and what, if any, configuration
> needs to be done to enable said application or game. I am just *soooo*
> tired of switching distros or reinstalling and being back at Square One
> in terms of getting my personal "bog-standard" apps running.
> 
> This project is so immense that it's already management hell without
> adding a new variable (WineTools) to it, but if I can ever actually
> accomplish it, I'd be happy to see how the use of WineTools makes
things
> easier or more difficult for me.
Let me say it this way: I already had that "management hell" with
WineTools and the 100 programs I actually added. So I made some
assumptions out of my experiences:

- there is a Wine version that works good
- you may have to "extend" this version from the beginning with native
  dlls to enable as many programs as possible to run, but by that
  breaking the possibility to use Wine without a valid Windows license
  - I personally can stay with that as I have four of them comming with
    every PC and Laptop I bought and did not sell later on
- the next versions may or may not work as good, but out of the next
  6-12 versions (6-12 months) there will be a version as good
- there is a config possible with basic settings that match most
  software that is currently able to run with Wine
- if you can, you can get most software running on individual settings
  by either
  - changing the windows version simulated
  - changing some very few DllOverrides like Common Controls, Twain,
    DirectX
- with the next good version you might need to change the basic config
  and the individual settings, so you will have much work with that!!!

As a result of of these assumptions I decided to follow these rules:
- stay with the good version
- use DCOM98 and IE6 by default until these part are definitely
  completed in Wine
- test month by month the next versions with the software you rely most
  on or you identify to be very important for your project
  - with WineTools this is
    - IE6
    - MediaPlayer
    - MDAC/JET (ODBC)
    - Office 2000 and Office Viewers
    - Photoshop
    - Illustrator
    - VirtulaDub (video)
    - X-Lite (audio)
    - Lauge
    - ikMap (last two using parts of IE6)
- if the test fails on one of the products and you can not get a
  solution via changing settings or finding hints in the web you will
  stay with your version
- if you find a good new version you have to make more comprehensive
  tests and have much work to do!!!

Note that after using wine-20031212 for almost nine months I found out
that wine-20040914 was the next version stable enough to use with the
software I need.
> For example, WineTools installs DCOM98 by default, right? This is great,
> because I have at least one game (Pretty Good Solitaire) which I know
> from experience needs DCOM installed and oleaut32 set to native before
> it will run (after which it runs almost perfectly)-- but then that
> spoils my other results, because DCOM is already installed, so I won't
> know which apps/games *don't* need it.
So just stay with it (what I do), because I did not find a software
until now that was harmed by that. *And* you can disable or enable it
in the config on a individual basis. But to inhibit multiple testing I
enabled it by default! So this is easy.
> I'm very happy to take this opportunity to speak to you, though, as I
am
> interested in WineTools. I wonder if you have plans to attach WineTools
> to the Wine package (which sounds like it would be a great thing to have
Wine and WineTools will ever be separated as they are very different
products. But most distributions begin to integrate WineTools in their
packaging.
> happen), and how or if the existence and increasing popularity of
> WineTools affects the Wine documentation... which, no matter what the
As this is not related I think there will be no boost. More than that it
could be that documentation is fading more because of WineTools as it
makes many things for you so you do not have to rely on the
documentation. I hope we will not have this sideeffect. But for sure
that is a problem for me: I need the documentation to make WineTools
work as it does ;-)
> devs say, needs *something*-- witness this whole thread. Even if Robert
> knew of or read the documentation-- which I don't think he has-- how
> would the current docs help him (especially since he probably doesn't
> even know where to find them)?
This is a different question: There are many, many, many users trying to
switch to Linux without changing their programs and without having any
deeper knowledge about Linux at all. This is nothing we have to laugh
about or look down on them, this is something we have to cope with as a
problem to solve! I get many mails from users trying to use WineTools
without having any idea about a command line ("is this that DOS
thing?"). So I wrote WineTools mainly for these users to be able to use
their programs without having to read a documentation. The docu is nice
if you are able to understand it. But there are so many assumptions
about your knowledge in it ("what the hell is a device file?") that I
am in deep doubt whether it is good or bad for linux if someone without
background tries to dig his way through it(**). Yes, it's definitely good
to learn something more about a complex system. But there are so many
users out there that just want to use their system. And yes, I like to
have them switch to linux;-) For them is WineTools.

(**) There was a very tendentious article in the online part of the
leading german political week magazine "Der Spiegel" about linux and
someone trying to run it on a machine with a onboard soft modem.
Everyone with knowledge about linux would say: "Just keep your fingers
off the modem if you don't know enough about linux", but this article
described the myriads of configuration attempts and weeks that the user
spent to solve his problem, failing in the end! This is what
many new comers frustrate on linux. And this is how linux is percepted
often: To be complicated and for experts only.

As of WineTools I have the problem to make it usable as easy as possible
failing at the point where users have to install xdialog and gettext.
That leads to the point where I include parts of these packages in
WineTools which is something like a big "no-no" for an administrator.
Until now the most questions come because of gettext!
> Winecfg is coming... someday (June?)... but what are we supposed to do
Yes, but with Winecfg you have to know what you are configuring. If we
are talking about a nice meal, then Winecfg is the cooking equipment.
WineTools is the restaurant: You can not get everything there, but it is
ready waiting for you, even if you do not know how to make fire!
> until then (and this of course assumes that winecfg works perfectly out
> of the starting gate)? WineTools seems like a great answer to that
> question, but if the docs don't reflect its existence, or how the use
Well if you click "download" on winehq you can find it as the second
entry right beyond the Wine binary packages. If you do not read until
there I think your video recorder is still blinking with 00:00 ;-)

And I think most users find it: After releasing the new 212 version I
had 8000 downloads in four days.
> and configuration of Wine changes due to WineTools, users are left out
> in the cold again unless you personally spend all your time on the list
> helping them out. Which just doesn't seem right ;-) .
This is a good question: Is the docu of WineTools complete or even
comprehensive enough? No, but I thing I will add a FAQ (including this
mail here) to answer some of the questions. And if you are able to
understand the config, than you can just read and interpret it
yourself...
> I'm sorry to ramble on like this. I just feel that the project needs
Don't excuse, your questions are good and needed and I can understand
them very well! That's why I Cc them to the list.
> some kind of help but I don't quite see what (other than a dedicated
> user documentation team and a lot of publicity). I hope that expressing
> my formless concept to someone who is helping in a
'semi-affiliated'
> way, as you are, might offer a new perspective.
Regards
	Joachim von Thadden
-- 
"Never touch a running system! Never run a touching system?
          Never run a touchy system!!!"