Hi Mike,
please dont add / to the default config. Some reasons no to do that:
- its insecure, since you can write everywhere you want and some filesystem corruption still exist today.
- it will cause recursion/drive change problems => example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:.
Sylvain Petreolle -at work-
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
Only if you run Wine as root. What makes us think we trust Linux software more than Win32 software?
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
Good question. I guess the algorithm must be able to deal with that though, as I've been running with / mapped for months and it hasn't caused any problems that I can see. Simply chopping out subtrees if they are mapped elsewhere would work.
On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:.
Yes, that might be a bit confusing (if you use wcmd), but for newbies having the "Wine cannot find executable" error is even more confusing.
Well, I'm not really bothered either way, but something would need to be done to address those problems I think.
Oooh, here's an idea - how about if when you ran wine from an area of disk that wouldn't normally be mapped, it creates a temporary "ghost" mapping that doesn't appear in the config file but only for itself and child processes? It takes precedance...
That way you wouldn't have to keep either moving files around or mapping new drives. Thoughts?
On Tue, 2003-06-03 at 10:22, mike@theoretic.com wrote:
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
Only if you run Wine as root. What makes us think we trust Linux software more than Win32 software?
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
Good question. I guess the algorithm must be able to deal with that though, as I've been running with / mapped for months and it hasn't caused any problems that I can see. Simply chopping out subtrees if they are mapped elsewhere would work.
On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:.
Yes, that might be a bit confusing (if you use wcmd), but for newbies having the "Wine cannot find executable" error is even more confusing.
Well, I'm not really bothered either way, but something would need to be done to address those problems I think.
On Tue, Jun 03, 2003 at 10:29:52AM +0100, Mike Hearn wrote:
Oooh, here's an idea - how about if when you ran wine from an area of disk that wouldn't normally be mapped, it creates a temporary "ghost" mapping that doesn't appear in the config file but only for itself and child processes? It takes precedance...
Well, what about grafting brains on Wine users instead ?
But well, I would prefer to change the error message to be even more verbose... What about putting a nice URL in it pointing to a page where they could read all about drive configuration in Wine ?
Because mapping '/' by default is plain ugly in my opinion... It's like shipping some server application with a default blank password :-)
Lionel
But well, I would prefer to change the error message to be even more verbose... What about putting a nice URL in it pointing to a page where they could read all about drive configuration in Wine ?
That would work too. But it's just a general pain in the ass even when you know exactly what is going on anyway, it's not like Wine is already too convenient to use or anything.
Because mapping '/' by default is plain ugly in my opinion... It's like shipping some server application with a default blank password :-)
Can't agree, I'm not seeing the security problem here.
Unless you subscribe to the belief that too many Win32 programs have spyware that would be interested in gigs of ELF binaries and config files (as they would be able to see drives/network mappings under windows anyway), I don't see what harm it could do.
That would work too. But it's just a general pain in the ass even when you know exactly what is going on anyway, it's not like Wine is already too convenient to use or anything.
No, but if they users get this error, it means that they did not configure Wine properly... So that we are only hiding the problem anyway.
What makes you sure that they will have set a fake C drive properly or created the sub-directories and all that stuff ?
Can't agree, I'm not seeing the security problem here.
Me neither. Just stupid default values :-)
Lionel
No, but if they users get this error, it means that they did not configure Wine properly... So that we are only hiding the problem anyway.
Hmm? It's pretty common for people to have mount points, extra directories or whatever that aren't detected by wineinstall (or they use a binary package that does not autodetect these things).
What makes you sure that they will have set a fake C drive properly or created the sub-directories and all that stuff ?
Well, if they compile from source and read the README they should have done so, and RPMs will set that up for them. It's when they insert a CD or zip disk for instance, and then wonder why they can't run setup.exe from it that causes problems.
On Tue, Jun 03, 2003 at 12:33:49PM +0200, Lionel Ulmer wrote:
That would work too. But it's just a general pain in the ass even when you know exactly what is going on anyway, it's not like Wine is already too convenient to use or anything.
No, but if they users get this error, it means that they did not configure Wine properly... So that we are only hiding the problem anyway.
What makes you sure that they will have set a fake C drive properly or created the sub-directories and all that stuff ?
My RPMs have a Z drive mapped to /, marked as "network" drive. The network drive mark usually make programs refrain from creating Z:\files.
I don't really see a problem, except a virus might go and scan the whole UNIX system including NFS trees. But the risk is low, and benefits are greater.
Ciao, Marcus
On Tuesday 03 June 2003 11:46 am, Marcus Meissner wrote:
My RPMs have a Z drive mapped to /, marked as "network" drive. The network drive mark usually make programs refrain from creating Z:\files.
I don't really see a problem, except a virus might go and scan the whole UNIX system including NFS trees. But the risk is low, and benefits are greater.
That makes a whole lot of sense to me - I installed wine because there are some windows programs I find useful, I don't want to only be able to use them if I've put the files I want them to work on in the "right" place. I find it annoying enough that windows won't let me CD to a UNC directory.
For people who are using Wine to play games I can see that a totally different approach makes sense - for them a sandbox that the game runs in is a perfect scenario.
Maybe that is why we are having trouble reaching a consensus here
Mike Hearn wrote:
Because mapping '/' by default is plain ugly in my opinion... It's like shipping some server application with a default blank password :-)
Can't agree, I'm not seeing the security problem here.
Unless you subscribe to the belief that too many Win32 programs have spyware that would be interested in gigs of ELF binaries and config files (as they would be able to see drives/network mappings under windows anyway), I don't see what harm it could do.
Just wanted to go on record backing Lionel. I am against mapping the root of the drive to Wine. There have been cases in the past (even published on Slashdot), when people using Wine were infected with document sending viruses. In that case, the root mapping meant things got out.
Mapping the root is a bad security decision, even if we don't see the exact attack vector at the moment.
Shachar
In that case, the root mapping meant things got out.
IIRC the virus was your typical Outlook email worm, which doesn't even need temporary files as far as I know, let alone a large read only drive full of stuff it doesn't understand. Whether root is mapped or not would make little difference to those kind of things.
Mapping the root is a bad security decision, even if we don't see the exact attack vector at the moment.
The most interesting stuff for hackers/virus writers is almost always in the home directory, which is mapped by default. So, I think people overrate the importance of the rest of the system files here.
On June 3, 2003 06:47 am, Shachar Shemesh wrote:
Mapping the root is a bad security decision, even if we don't see the exact attack vector at the moment.
This is of course just FUD. Unix programs don't have such restrictions (they always see /), and there's no security problem there. To use the stupid drive letters to obfuscate the system is just a way of keeping people from using Wine at all. Maybe this is where the security lies...
Even though I know about the problem, I find it incredibly annoying and stupid when Wine complains about that. I think we absolutely need the Z drive for the 0.9 release, we might as well add it now.
Le mar 03/06/2003 à 05:22, mike@theoretic.com a écrit :
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
Only if you run Wine as root. What makes us think we trust Linux software more than Win32 software?
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
Good question. I guess the algorithm must be able to deal with that though, as I've been running with / mapped for months and it hasn't caused any problems that I can see. Simply chopping out subtrees if they are mapped elsewhere would work.
Not sure. There's a DOS utility (I guess it's still there in later versions of Windows) called subst.exe which creates a drive from a directory. So you can say that c:\blabla\mydir is now called f:. Anything beyond c:\blabla\mydir can be accessed through either ways.
On my RH box I have a drive called W: that contains wine sources and P: contains programs/. If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:.
Yes, that might be a bit confusing (if you use wcmd), but for newbies having the "Wine cannot find executable" error is even more confusing.
Is it specifically with wcmd, or in the way Wine gets the DOS name of a file?
Vincent
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
Not sure. There's a DOS utility (I guess it's still there in later versions of Windows) called subst.exe which creates a drive from a directory. So you can say that c:\blabla\mydir is now called f:. Anything beyond c:\blabla\mydir can be accessed through either ways.
This is not what I mean here. I know you can access these files this way and this is normal. But if a software searches for files into z:\home\user\fake_c and is switched to c:\ without reason, this could cause confusion to it (the linux user obviously doesnt care about this)
Is it specifically with wcmd, or in the way Wine gets the DOS name of a file?
Seems to be a drive/directory parsing problem. Wcmd is using normal dos (not linux) file access functions, am I right here ?
Then with the same mapping, the following shouldnt be possible : W: = /home/wine P: = /home/wine/programs
P:> cd .. W:>
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Hi,
please dont add / to the default config. Some reasons no to do that:
I think we just discussed exactly these "reasons"?
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
Then we should make it read-only. Should be no problem.
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
And where's the real problem here? You can create some nice recursions in Windows too. (Read: "subst", symbolic links, NTFS mounts, etc.)
Philipp
Hello,
please dont add / to the default config. Some reasons no to do that:
I think we just discussed exactly these "reasons"?
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
Then we should make it read-only. Should be no problem.
Even with read-only, i don't like the idea of window programs reading in "/dev" and "/proc".
Besides it shouldn't be possible enable "ShowDotFiles" when your home is mapped, because it could read your private ssh keys.
Regards, Carlos.
All this FUD is getting me hungry. <bad pun>
On Tue, 3 Jun 2003, PETREOLLE Sylvain wrote:
: please dont add / to the default config.
: - its insecure, since you can write everywhere you want : and some filesystem corruption still exist today.
Bullshit. Wine can't corrupt your filesystem, unless somehow the host OS is letting users write to arbitrary data blocks of filesystems. This can be done to NT, too, you know -- ever try writing data to "//./PhysicalDrive0" when logged in as Administrator?
(Note that a person who is dumb enough to log in to a Unix box as "root" all the time is *definitely* one who would log in to Windows as "Administrator" all the time. Both of these are security risks for arbitrary files, but restricting file access in Wine under the premise that it protects such arbitrary file access is just as moronic.)
: - it will cause recursion/drive change problems => : example : what will be the current drive/directory : if you access the fake C:\windows : via Z:\home\user\fake_c\windows ?
Red herring. You can do this in Windows too using SUBST, as well as Win2k+ which allows mounting one filesystem in an unlimited number of locations (including inside a filesystem in the Unix fashion). Also think "reparse points".
: On my RH box I have a drive called W: that contains wine sources and P: : contains programs/. : If I am in W: (wcmd) and I do 'cd programs', wcmd now says P:.
Sounds like a wcmd bug to me, or a bug in wine's path parsing, but this is also a red herring as it is *unrelated* to the topic of adding a drive letter mapping to /.
On Tue, 3 Jun 2003, Carlos Lozano wrote:
: Even with read-only, i don't like the idea of window programs : reading in "/dev" and "/proc".
Why not? You can read "//./PhysicalDrive0" in Windows. And winelib programs that choose to access the native libc would have no such restriction anyway.
: Besides it shouldn't be possible enable "ShowDotFiles" when your home : is mapped, because it could read your private ssh keys.
Now you're getting into serious FUD. If I install F-Secure SSH in Windows, don't you think programs will be able to read its private keys too? You do use *passphrases* to lock your private keys, right?
==
Have you folks ever USED the operating systems you're trying to describe? Y'all seem to be under the fallacious impression that letting Wine access arbitrary files is somehow less secure than letting host-OS Unix programs access arbitrary files. It's not like the host Unix OS is permitting Wine to access files or resources that regular Unix commands can't....
Now, if someone would like to offer a *technically competent* argument as to why mapping a drive letter to / is bad, I'd love to hear it.
I am not voting for or against the / config because I have not tested security and viruses but if the / is so controversial why not get the /mnt a default config since most users problems are with removable media.
Just a tought, Hatky.
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Tue, 3 Jun 2003, hatky wrote:
: I am not voting for or against the / config because I : have not tested security and viruses but if the / is : so controversial why not get the /mnt a default config : since most users problems are with removable media.
And this assumes that /mnt is where Arbitrary Unix OS mounts removable media. For one, I know mine doesn't. 8-)
And this assumes that /mnt is where Arbitrary Unix OS mounts removable media. For one, I know mine doesn't. 8-)
I assume someone could get something more generic, I was just rising an idea that more people could agree on
Hatky.
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Now, if someone would like to offer a *technically competent* argument as to why mapping a drive letter to / is bad, I'd love to hear it.
Basically, adding '/' as a drive is to help people which are not able to properly configure / install Wine (and who do not understand the 'Drive' error message).
So it will mask other bugs like games checking that their data file are on a CD-Rom and failing because the data is accessed via the '/' overide and not the CD-Rom path.
So I mostly object for aesthetically reasons (ie as we emulate Windows, be as kludgy as Windows : use drive letters :-) ). For a Winelib application, I would agree with Dimi though.
And finally, as for Wine hurting your FS, there is the famous '!$!$!$!$.cfr' bug when running Eplorer with Wine. I have no idea if it could also break something in your Linux FS though :-)
Lionel
On Tue, 3 Jun 2003, Lionel Ulmer wrote:
So it will mask other bugs like games checking that their data file are on a CD-Rom and failing because the data is accessed via the '/' overide and not the CD-Rom path.
This seems like a different issue. In fact, this will be solved if we also had a proper definition for the CDROM, wouldn't it?
So I mostly object for aesthetically reasons (ie as we emulate Windows, be as kludgy as Windows : use drive letters :-) ). For a Winelib application, I would agree with Dimi though.
Ideally, they would all go through the same configuration. In fact, right now there is little difference between wine app and Winelib apps. In a way the Windows registry (which will contain all of the above configuration) is the equivalent of /etc in Unix, whould be nuts to have different ones for different apps (as common practice :)).
This seems like a different issue. In fact, this will be solved if we also had a proper definition for the CDROM, wouldn't it?
Of course.
But if the user had a correct Wine configuration, he would not have had the problem that made Mike add '/' as a drive path... And all this discussion would not have been started at all :-)
Lionel
On Tue, 3 Jun 2003, Lionel Ulmer wrote:
But if the user had a correct Wine configuration, he would not have had the problem that made Mike add '/' as a drive path... And all this discussion would not have been started at all :-)
Not quite. I, for one, (and I think I'm not in a minority) would like to have such a Z: drive in normal/correct/proper configuration. In which case we have to deal with it being there anyway. And once we do, we might as well have it present by default :)
After further consideration, I have come to believe that we might as well have the root mapping. Enough people seem to want it that, as Dimi say, we need to deal with the possibility anyway. BTW, Todd, I hope when I posted the URL to the article puoti had mentioned, that you did not think the opinions expressed in that article were by any means my own. Perhaps I should have made a disclaimer. :-/
As for using it in the wine config tool, I thought it was going to be a winelib app, as opposed to pure win32. With a winelib app, wouldn't you be able to read the file in with *nix calls? I haven't written any winelib apps myself, so maybe I'll shut up now about that.
Finally, on the security (non) issue, a virus designed with wine in mind (that phrase is fun to say) could get privileges to / if ${HOME} is already mapped. Try this: 'notepad "F:.wine\config"', where F is what ${HOME} is mapped to, and then use your imagination.
-- Jeff Smith
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
On Tue, 3 Jun 2003, Lionel Ulmer wrote:
But if the user had a correct Wine configuration, he would not have had the problem that made Mike add '/' as a drive path... And all this discussion would not have been started at all :-)
Not quite. I, for one, (and I think I'm not in a minority) would like to have such a Z: drive in normal/correct/proper configuration. In which case we have to deal with it being there anyway. And once we do, we might as well have it present by default :)
-- Dimi.
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Tue, 2003-06-03 at 15:24, Jeff Smith wrote:
After further consideration, I have come to believe that we might as well have the root mapping. Enough people seem to want it that, as Dimi say, we need to deal with the possibility anyway. BTW, Todd, I hope when I posted the URL to the article puoti had mentioned, that you did not think the opinions expressed in that article were by any means my own. Perhaps I should have made a disclaimer. :-/
As for using it in the wine config tool, I thought it was going to be a winelib app, as opposed to pure win32. With a winelib app, wouldn't you be able to read the file in with *nix calls? I haven't written any winelib apps myself, so maybe I'll shut up now about that.
My understanding is rather weak here, as well. I've been using a call to fopen("/etc/fstab",...) and it works fine. However, I'm unsure as to why this works: is it because winecfg is a winelib app so fopen is actually coming out of the normal glibc? or does wine pass the name through to the unix filesystem? I currently have a drive mapped to "/", will this continue to work if that is not the case? To summarize the issue: if I call fopen() from winecfg, am I getting the normal GNU/Linux function or some Wine wrapper to it?
[F]ighting [U]ncertainy [D]aily- Patrick
Finally, on the security (non) issue, a virus designed with wine in mind (that phrase is fun to say) could get privileges to / if ${HOME} is already mapped. Try this: 'notepad "F:.wine\config"', where F is what ${HOME} is mapped to, and then use your imagination.
-- Jeff Smith
--- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
On Tue, 3 Jun 2003, Lionel Ulmer wrote:
But if the user had a correct Wine configuration, he would not have had the problem that made Mike add '/' as a drive path... And all this discussion would not have been started at all :-)
Not quite. I, for one, (and I think I'm not in a minority) would like to have such a Z: drive in normal/correct/proper configuration. In which case we have to deal with it being there anyway. And once we do, we might as well have it present by default :)
-- Dimi.
Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
My understanding is rather weak here, as well. I've been using a call to fopen("/etc/fstab",...) and it works fine. However, I'm unsure as to why this works: is it because winecfg is a winelib app so fopen is actually coming out of the normal glibc? or does wine pass the name through to the unix filesystem? I currently have a drive mapped to "/", will this continue to work if that is not the case? To summarize the issue: if I call fopen() from winecfg, am I getting the normal GNU/Linux function or some Wine wrapper to it?
I would suspect this is coming straight from glibc. If it was coming from winelib, specifically msvcrt, I believe you would have to use a windows-ish path, i.e. "Z:\etc\fstab". That is how this whole thread got started, did it not?
The simplest way to be sure is experimentation. Remove the / mapping from the config file, and see if /etc/fstab is still read in as expected. If so, it seems the whole / mapping thing is a non-issue to winecfg.
-- Jeff Smith
__________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
On Tue, 3 Jun 2003, Jeff Smith wrote:
: BTW, Todd, I hope when I posted the URL to the article puoti had : mentioned, that you did not think the opinions expressed in that article : were by any means my own. Perhaps I should have made a disclaimer. :-/
Heh, I didn't imply that at all. When I referred to the article writer as a "poor sap" for allowing random foreign machine code to execute (thus inviting in trojans), it meant nothing towards you. 8-)
: As for using it in the wine config tool, I thought it was going to be a : winelib app, as opposed to pure win32. With a winelib app, wouldn't you be : able to read the file in with *nix calls?
Well, yes, but winelib + native libc is its own ball of hair, because not all the world's a glibc2. In other words, when using native libc plus winelib, you have to deal with host Unix OS dependencies again, *and* ensure that those dependencies don't somehow hose Wine too.
Either 100% native or 100% msvcrt seem better to me, so as not to try to do the funny walk by mixing them. (I'm not in charge of such an app, though, so it's not my call to make.)
: Finally, on the security (non) issue, a virus designed with wine in mind (that : phrase is fun to say) could get privileges to / if ${HOME} is already mapped. : Try this: 'notepad "F:.wine\config"', where F is what ${HOME} is mapped to, : and then use your imagination.
Not just that. A virus could easily do direct traps to invoke i386 syscalls, for which at least open(2), read(2), and write(2) have very similar semantics (and syscall numbers!) between the available x86 Unix implementations. Even execve(2) is the same between a couple different types of Unix-like host OS's.
All this doesn't even address the fact that Winelib apps (say, a virus), can access native system shared libraries. A quick call to dlopen(3) followed by dlsym(3) and....
On Tue, 3 Jun 2003, Lionel Ulmer wrote:
: > Now, if someone would like to offer a *technically competent* argument as to : > why mapping a drive letter to / is bad, I'd love to hear it. : : Basically, adding '/' as a drive is to help people which are not able to : properly configure / install Wine (and who do not understand the 'Drive' : error message).
I see mapping a drive to `/' as `proper' configuration. (i.e. If Wine is meant to integrate apps to the Unix environment, it shold be able to see the full Unix environment.)
I see mapping a drive to `/' as `proper' configuration. (i.e. If Wine is meant to integrate apps to the Unix environment, it shold be able to see the full Unix environment.)
Ah, there is where my opinion diverges the most from most of the people here (and why I advocate a lot for the Desktop option).
I do *NOT* want to have my Windows and my Linux stuff to mix together. So I always use Dekstop mode and I have clearly delimited Windows drives for Wine.
Lionel (who wonders if he's the only one in this case :-) )
You're not the only one. I didnt write it explicitely on my mails, but this is what make me react on this subject.
Ah, there is where my opinion diverges the most from most of the people here (and why I advocate a lot for the Desktop option).
I do *NOT* want to have my Windows and my Linux stuff to mix together. So I always use Dekstop mode and I have clearly delimited Windows drives for Wine.
Lionel (who wonders if he's the only one in this case :-) )-- Lionel Ulmer - http://www.bbrox.org/
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Tue, 3 Jun 2003 22:57:52 +0200, you wrote:
I see mapping a drive to `/' as `proper' configuration. (i.e. If Wine is meant to integrate apps to the Unix environment, it shold be able to see the full Unix environment.)
Ah, there is where my opinion diverges the most from most of the people here (and why I advocate a lot for the Desktop option).
I do *NOT* want to have my Windows and my Linux stuff to mix together. So I always use Dekstop mode and I have clearly delimited Windows drives for Wine.
Lionel (who wonders if he's the only one in this case :-) )
You are not the only one, not for the desktop (I like the integration) but definitely for the delimited drives.
Doing this for the convenience of day-one wine users, that happen to be first-day linux users as well, that don't read any messages seems to me absurt.
(However, the latest generation of users seem to start their wine experience by point-an-click on an .exe in some filemanager. They won't see the messages sent to stderr. Perhaps we should instead of error message "blabla.exe not accessible from a configured", make this a plain MessageBox() call? )
Rein.
Wooo, nested subject lines. This is what I call a Thread!
However, the latest generation of users seem to start their wine experience by point-an-click on an .exe in some filemanager. They won't see the messages sent to stderr. Perhaps we should instead of error message "blabla.exe not accessible from a configured", make this a plain MessageBox() call?
I've thought about this a couple of times now. It's not just for that error, we really need some generic way to report problems and wine output in a totally GUI oriented fashion. OK, so it might not be common *quite* yet, but people will start running Wine from places other than the terminal very soon now.
We have a couple of problems in this area.
Firstly, the output can be misleading/confusing to newbs. Common conversation on IRC:
Them: "My app doesn't work because wine can't open my mixer" Us : "What makes you think it's related to the mixer" Them: "It says err:ossdrv:WAVEOUT could not open mixer" Us : "That's probably not related to your problem."
Secondly, you only get the output if you run from the terminal.
Thirdly, if there is a line that reveals the cause of the users problems, it could be buried amongst huge reams of spew about non-implemented flat scrollbars for instance. This is because we don't distinguish between messages that might help the user, like:
* You need stdole32.tlb for this app to work * Your configuration file is busted * The program crashed because it hit a stub.
from messages that don't help them, like:
* Flat scrollbar/CoSetState/other non-critical fixmes * Warnings/errors about broken apps writing to SEH resource data, mangling surface locks or whatever broken behaviour is in vogue this year.
Basically I think the Wine output should be hidden by default as it's essentially meaningless to anybody but developers (and often, anybody but wine developers).
I would also propose a new class of logging message, or logging macro, USERMSG, which is *only* to be used for things that directly help or inform the user, as opposed to developers. Stuff put in such messages would be low on jargon and high on helpful advice. Developers still have all the other 3 debug channels, winedbg output and so on to help debug a problem if said user/newbie asks for it - for when a friendly wine hacker isn't available, the USERMSG messages might be all they have.
CrossOver already hides the output I'd note, unless you specifically log it. I don't know how they deal with b0rkage.
So, that leaves the question of how to display these USERMSG logs. I'd propose a simple dialog box which contains a graphical list of output. If you've ever seen the Mozilla JavaScript console, something like that. It'd be displayed when the first USERMSG is shown, or on demand via a command line switch or something, as it could be used to filter the log messages at runtime for instance.
Anyway. It's just random brain activity from me. Thoughts? thanks -mike
Mike Hearn writes:
Basically I think the Wine output should be hidden by default as it's essentially meaningless to anybody but developers (and often, anybody but wine developers).
PMFJI, I'm basically a Wine newbie as of 11/01/02 and a Linux newbie as of a year before that, but it was precisely this terminal output that started me down the right path to get my applications working. Had it just "not worked" with no output, I wouldn't have known where to turn and it would have been more frustrating than actually using Windows. So... please don't hide the output by default.
So, that leaves the question of how to display these USERMSG logs. I'd propose a simple dialog box which contains a graphical list of output. If you've ever seen the Mozilla JavaScript console, something like that. It'd be displayed when the first USERMSG is shown, or on demand via a command line switch or something, as it could be used to filter the log messages at runtime for instance.
Anyway. It's just random brain activity from me. Thoughts?
I like that idea of a graphical output box. However, what if the user's problem has something to do with their x11 setup or something? I don't think you should change the current terminal output at all, at least not until after Wine 1.0.
Maybe augment it with an *additional* graphical output dialog box of some sort - have it go behind the main application window without taking focus away from it, and have it be a completely separate process so that it is still there on the screen when the user's application crashes and disappears. But don't work on that until Wine is past the .9 stage, there are too many other more important things to work on! <g>
There are adequate resources all over the web, findable by a simple Google search, to help the newbie users get Wine working with XYZ application. Too many of these users suffer from what I label an "attitude of entitlement" as in "Your application wasted my time and now you have to help me make it work". Wine works, but it is pre-alpha, and users don't need to be hand-holded at this point - they need to get a clue first.
Sorry for being so verbose. I just think that Wine needs to get to the 1.0 release stage before making the output 'pretty'. The trail of what is wrong with XYZ app starts with that terminal output. Certain users can and should be scared away for the time being. <g>
My completely unsolicited .02 cents - hopefully not a complete waste of bandwidth.
On June 4, 2003 05:16 am, Mike Hearn wrote:
I would also propose a new class of logging message, or logging macro, USERMSG, which is *only* to be used for things that directly help or inform the user, as opposed to developers.
We have that, this is what MESSAGE is meant to do.
On Wednesday 04 June 2003 09:59 pm, Dimitrie O. Paun wrote:
On June 4, 2003 05:16 am, Mike Hearn wrote:
I would also propose a new class of logging message, or logging macro, USERMSG, which is *only* to be used for things that directly help or inform the user, as opposed to developers.
We have that, this is what MESSAGE is meant to do.
Really... I didn't know that. Then, should we slap a gui into this as discussed previously?
On June 5, 2003 01:40 am, Gregory M. Turner wrote:
Really... I didn't know that. Then, should we slap a gui into this as discussed previously?
Sure... We just need a volunteer to do it! :)
We have that, this is what MESSAGE is meant to do.
OK, cool, I guess routing that into a GUI should be on somebodies mental if not marked up todo list.
On Thursday 05 June 2003 04:04 am, Mike Hearn wrote:
We have that, this is what MESSAGE is meant to do.
OK, cool, I guess routing that into a GUI should be on somebodies mental if not marked up todo list.
just another note (hmm, by speaking on this, I fear I am getting dangerously close to volunteering): it's probably /not/ cool to use windows API's to implement such a GUI -- because the messages could be coming out before core GUI dlls are loaded. I think another poster mentioned the same issue. So I guess it needs to be a pure-x thing...? Maybe MessageBox is safe, but MessageBox seems like a potentially annoying implementation. Otherwise, perhaps its possible to queue premature messages until the neccesary essential dll's load up -- of course, this may never occur, resulting in eerie silence... maybe a job for interprocess RPC, since it supports string arguments so well ;)
I'd muck around with this, but right now I have cabinet.dll at the top of my queue.... maybe soon....
Le jeu 05/06/2003 à 14:21, Gregory M. Turner a écrit :
On Thursday 05 June 2003 04:04 am, Mike Hearn wrote:
We have that, this is what MESSAGE is meant to do.
OK, cool, I guess routing that into a GUI should be on somebodies mental if not marked up todo list.
just another note (hmm, by speaking on this, I fear I am getting dangerously close to volunteering): it's probably /not/ cool to use windows API's to implement such a GUI -- because the messages could be coming out before core GUI dlls are loaded. I think another poster mentioned the same issue. So I guess it needs to be a pure-x thing...? Maybe MessageBox is safe, but MessageBox seems like a potentially annoying implementation. Otherwise, perhaps its possible to queue premature messages until the neccesary essential dll's load up -- of course, this may never occur, resulting in eerie silence... maybe a job for interprocess RPC, since it supports string arguments so well ;)
Some kind of "console" (nothing at all in common with wineconsole), like some ID games have? Not the one accessible in-game, the yellow-on-blue one you see a few seconds at launch. This app can be a X11/ncurse/Gtk/whatever app, no need for it to use any Win32 API.
And something similar to syslog to transmit the messages to it... (a pipe would be enough for a proof-of-concept), so you can wage through them in real-time. Of course, a full +trace would bring the machine down a bit, but for messages in "normal" usage, it could be useful.
Just nobody make a big button "Send the message log to wine-devel" :)
Vincent
Just have it open an arbitrary app and pipe the messages on stdin. That way you can plug in a GTK front end, curses etc etc
On Thu, 2003-06-05 at 19:21, Gregory M. Turner wrote:
On Thursday 05 June 2003 04:04 am, Mike Hearn wrote:
We have that, this is what MESSAGE is meant to do.
OK, cool, I guess routing that into a GUI should be on somebodies mental if not marked up todo list.
just another note (hmm, by speaking on this, I fear I am getting dangerously close to volunteering): it's probably /not/ cool to use windows API's to implement such a GUI -- because the messages could be coming out before core GUI dlls are loaded. I think another poster mentioned the same issue. So I guess it needs to be a pure-x thing...? Maybe MessageBox is safe, but MessageBox seems like a potentially annoying implementation. Otherwise, perhaps its possible to queue premature messages until the neccesary essential dll's load up -- of course, this may never occur, resulting in eerie silence... maybe a job for interprocess RPC, since it supports string arguments so well ;)
I'd muck around with this, but right now I have cabinet.dll at the top of my queue.... maybe soon....
On Wed, 2003-06-04 at 11:05, Rein Klazes wrote:
On Tue, 3 Jun 2003 22:57:52 +0200, you wrote:
I see mapping a drive to `/' as `proper' configuration. (i.e. If Wine is meant to integrate apps to the Unix environment, it shold be able to see the full Unix environment.)
Ah, there is where my opinion diverges the most from most of the people here (and why I advocate a lot for the Desktop option).
I do *NOT* want to have my Windows and my Linux stuff to mix together. So I always use Dekstop mode and I have clearly delimited Windows drives for Wine.
Lionel (who wonders if he's the only one in this case :-) )You are not the only one, not for the desktop (I like the integration) but definitely for the delimited drives.
Doing this for the convenience of day-one wine users, that happen to be first-day linux users as well, that don't read any messages seems to me absurt.
(However, the latest generation of users seem to start their wine experience by point-an-click on an .exe in some filemanager. They won't see the messages sent to stderr. Perhaps we should instead of error message "blabla.exe not accessible from a configured", make this a plain MessageBox() call? )
Rein.
I think I would hate to have some Message Box to click for each error message during some debugging phase. If it is done I think it should be made a configurable option.
Max
On 04 Jun 2003 19:57:57 +0200, you wrote:
(However, the latest generation of users seem to start their wine experience by point-an-click on an .exe in some filemanager. They won't see the messages sent to stderr. Perhaps we should instead of error message "blabla.exe not accessible from a configured", make this a plain MessageBox() call? )
Rein.
I think I would hate to have some Message Box to click for each error message during some debugging phase.
Just this message. I have seen the complaint "wine doesn't do anything" more then once.
Rein.
El mar, 03 de jun de 2003, a las 13:22, Todd Vierling escribio:
On Tue, 3 Jun 2003, Carlos Lozano wrote:
: Besides it shouldn't be possible enable "ShowDotFiles" when your home : is mapped, because it could read your private ssh keys.
Now you're getting into serious FUD. If I install F-Secure SSH in Windows, don't you think programs will be able to read its private keys too? You do use *passphrases* to lock your private keys, right?
You are right. It is my error, i am too lazy to set a passphrases ;)
Regards, Carlos.
El mar, 03 de jun de 2003, a las 13:22, Todd Vierling escribio:
On Tue, 3 Jun 2003, Carlos Lozano wrote:
: Even with read-only, i don't like the idea of window programs : reading in "/dev" and "/proc".
Why not? You can read "//./PhysicalDrive0" in Windows. And winelib programs that choose to access the native libc would have no such restriction anyway.
Files in "/dev/" are not normal files. For example you can do a "cat /tmp/tmp > /tmp/tmp.2", but try a "cat /dev/urandom > /tmp/urandom".
For example a compress or checksum calculation window application should have surely problems to handle this type of files.
Regards, Carlos.
On Tue, 3 Jun 2003, PETREOLLE Sylvain wrote:
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
This simply not true. Guys, please stop spreading this sort of bullshit, it does no one good.
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
This is also a red herring. We need to handle that anyway, most users will have such setups, we can't simply die on them.
--- "Dimitrie O. Paun" dimi@intelliware.ca a écrit : > On Tue, 3 Jun 2003, PETREOLLE Sylvain wrote:
- its insecure, since you can write everywhere you want
and some filesystem corruption still exist today.
This simply not true. Guys, please stop spreading this sort of bullshit, it does no one good.
Addons : - many users have wine running as root. they didnt see the root warning messages since they use packages.
- spotted by Carlos: you will have read access on special files/devices (Z:\dev\hda*, Z:\dev\fd0, ...)
- it will cause recursion/drive change problems =>
example : what will be the current drive/directory if you access the fake C:\windows via Z:\home\user\fake_c\windows ?
This is also a red herring. We need to handle that anyway, most users will have such setups, we can't simply die on them.
See my answer to Vincent.
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Tue, 3 Jun 2003, Sylvain Petreolle wrote:
: - many users have wine running as root. : they didnt see the root warning messages since they use packages.
And the problem is? Running Wine as root is just as dangerous as running, say, Mozilla, or even "cat" as root. FUD.
: - spotted by Carlos: you will have read access on special files/devices : (Z:\dev\hda*, Z:\dev\fd0, ...)
And the problem with that is? (I suspect FUD, again.)
On Tue, 3 Jun 2003, Sylvain Petreolle wrote:
This simply not true. Guys, please stop spreading this sort of bullshit, it does no one good.
Addons :
- many users have wine running as root.
they didnt see the root warning messages since they use packages.
In which case they are more FOOBARed than words can describe, and this drive letter crap will just give them a false sense of security. In other words, the security will be wonderful, but completely absent. Give me a break...
- spotted by Carlos: you will have read access on special files/devices
(Z:\dev\hda*, Z:\dev\fd0, ...)
So what? Maybe we should restrict windows apps from manipulating bits at all... in which case, simply don't run Wine. A Windows app is no different from a Unix app. The OS will protect against things that apps shouldn't do, be them Unix or Windows.
No reason to a drive-letter-bullshit scheme to cripple Wine. Guys, wake up and think for a second before emailing on this subject!
-
Carlos Lozano -
Dimitrie O. Paun -
Dimitrie O. Paun -
Gregory M. Turner -
hatky -
Jeff Smith -
Lionel Ulmer -
Marcus Meissner -
Maxime Bellengé -
Mike Hearn -
mike＠theoretic.com -
Patrick Griffin -
Paul McNett -
PETREOLLE Sylvain -
Philipp Wollermann -
Rein Klazes -
Shachar Shemesh -
Sylvain Petreolle -
Todd Vierling -
Vincent Béron -
wine＠baker-net.org.uk