November 2002 - Wine-devel - list.winehq.org

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > No, it's wrong. You should be using the Windows API (CreateProcess > etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns were about using CreateProcess initially when I looked at MSDN: CreateProcess executes a Windows executable with parameters, whereas _popen executes as shell, ie. you can do stuff like _popen("dir/w") which will return an open file in which you can read the directory contents from. In essence under Windows, this gets executed at "cmd.exe /C dir/w". Now using CreatePorcess we can potentially do the same, provided that the executable (command interpreter) resides in your path. From MSDN: "The string can specify the full path and file name of the module to execute or it can specify a partial name. In the case of a partial name, the function uses the current drive and current directory to complete the specification." Now wera are faced with a problem in that wcmd is not a pure Windows application and it doesn't reside in your Windows filesystem, rather it is in your *nix path. In the case of _popen, a file-handle is returned which allows you to either read or write to the application unsing the normal fwrite/fprintf/etc. commands. CreateProcess has an information structure containing the following information: typedef struct _PROCESS_INFORMATION { HANDLE hProcess; HANDLE hThread; DWORD dwProcessId; DWORD dwThreadId; } PROCESS_INFORMATION; I don't see any clear way of doing, 1. Converting the above structure into something usable, eg. MSVCRT_FILE 2. Actually allowing us to read or write to the application Potentially the magic lies in the current Wine CreateProcess implementation, I'll have a look at it. Is doing this really feasable using the CreateProcess family? In essence a HANDLE will map back to an fd with the wine implementation (rather we can get an fd for a HANDLE), but can this be used to read/write to the process? The first obstacle however, will be in having a clean way to get wcmd going if it doesn't reside in C:\. Maybe it should be there and should be installed like notepad.exe for example? Some questions, and yes I'm slow tonight... :) I think that just by typing this some concerns have been aleviated so excuse my rumblings but just check the logic. Greetings, Jaco

4 4

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On Fri, 1 Nov 2002 20:50:07 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Giving a fully qualified patch is probably bad advice here. Try "wcmd.exe" > only and have cmd.exe.so in wine's program directory. Wine sets on startup > WINEDLLPATH to "$topdir/dlls:$topdir/programs" and wineapploader there > should manage to start the application. Umm, that might help a bit. When I get to the point of testing again, I'll give it a bash. What seems to be the concensus as to the "right-way-to-do-things(tm)" in this case? Greetings, Jaco

1 0

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On Fri, 1 Nov 2002 11:21:26 -0800 (PST), Francois Gouget <fgouget(a)free.fr> wrote : > Try c:\Windows\System\wcmd.exe and I think you will find that it works. *lol* Like I've said, expect me to be slow tonight :)

1 0

Wine securityflaw.
by Peter Andersson 01 Nov '02

01 Nov '02

Hello again, (FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic) I had some more thoughts on the issue... I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected. The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously. Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large. I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead. Best Regards, Peter Andersson

18 35

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > Jaco Greeff <jaco(a)puxedo.org> writes: > > > 1. Calling the popen function returns a FILE* which needs to be > > converted to a MSVCRT_FILE*. The apprach taken here is potentially not > > the best route but the only one I could think of. Is it suffiecient? > > No, it's wrong. You should be using the Windows API (CreateProcess > etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. I was actually taking a re-look at that this afternoon. I agree, the initial reason for th implementation was obviously that _popen is supposed to mimic popen, but the file conversion leaves me feeling really uncomfortable. I'll fix it up and submit it shortly. Greetings, Jaco

1 0

Re: Treeview notifications before Guy's patch problem
by Dustin Navea 01 Nov '02

01 Nov '02

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On November 1, 2002 02:00 am, you wrote: > > after banging my head on my keyboard for a few minutes > > because i couldnt find treeview_notifyformat i went and looked at cvsweb > > and found out...there is no treeview_notifyformat before guy's patch so > > there is no way for me to get that kind of a debug output... > > Good find. Please add this to Bugzilla. But it presents a big problem: > if we behave correctly, we break the app. What do we do? > I'm wondering if maybe its my app thats broken already and thats why its sending the unicode message.. ---appended--- Maybe Alexandre should look at this too? Appended notes to bug 1073. Does anyone reading this have any ideas on any kind of hack that wont completely break every other app while still fixing this one? __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

1 0

What does "Printer: Wine Poscript Driver, Error: 709" mean
by David.Goodenough＠DGA.co.uk 01 Nov '02

01 Nov '02

I installed a program called Mind Manager, and tried to run it. It installed OK, but when I came to run it the initial dialog came up and it was totally unresponsive to either keyboard or mouse. So I looked around the system for any errors and found that the title of the window in the KDE window list was as shown above. Anyone got any ideas what error 709 means? Thanks in advance David

1 0

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Alexandre Julliard 01 Nov '02

01 Nov '02

Jaco Greeff <jaco(a)puxedo.org> writes: > 1. Calling the popen function returns a FILE* which needs to be > converted to a MSVCRT_FILE*. The apprach taken here is potentially not > the best route but the only one I could think of. Is it suffiecient? No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dlls/msvcrt: msvcrt-popen-1.1
by Joerg Mayer 01 Nov '02

01 Nov '02

On Fri, Nov 01, 2002 at 03:16:58PM +0200, Jaco Greeff wrote: > +/* FIXME: Don't know what this value should be, 10 seems enough as > + * the maximum number of simultaneous _popen'ed processes > + */ > #define POPEN_MAX_FILES 10 ... > +INT POPEN_getOpenFileSlotPos(VOID) > +{ > + INT i = 0; > + for (i = 0; i < POPEN_MAX_FILES; i++) > + { > + if (!POPEN_Files[i].fProcess) > + { > + POPEN_Files[i].fProcess = (MSVCRT_FILE *)POPEN_FILE_IN_USE; > + return i; > + } > + } Please output an ERR here to ask people to report that POPEN_MAX_FILES needs to be increased. > + return -1;

2 1

RE: Wine 0.8 TODO v0.1
by Patrik Stridvall 01 Nov '02

01 Nov '02

> Oh, one other thing that would be nice, while I think of > it... is there > any reason (now we are GPL'ed) that we cannot incorperate cabextract > (http://www.kyz.uklinux.net/cabextract.php3) into Wine? Because we are not GPL:ed. We are LGPL:ed. Application that go under programs/ might as an exception go under GPL. However in the case of cabextract we need substantial parts of it to implement functions like SetupIterateCabinet in SETUPAPI.DLL so only the LGPL or less restrictive is acceptable. However the author(s) of cabextract might agree to release the parts we need under the LGPL. Perhaps it better if he release it all under the GPL since we might want to implement the CAB SDK tools like cabarc.exe that is supposed to do almost exactly what cabextract does (and possibly more) AFAICS. What don't you ask him? > Currently we shell out to it as an external program, Do we? Hmm. OK, it seems we do in dlls/urlmon/umon.c. Ugly. That code should probably call SetupIterateCabinet instead. Of course that function is not implemented yet. See above. > in order to run > Microsoft's setup APIs ecetra. This is really annoying for > new users, as > unless they look closely at pages of logs... theres no real indication > that's why installation of a Microsoft program failed. True.

1 0