wine-devel

wine-devel@winehq.org

5 participants
84473 discussions

Name, life-cycle, directory structure, autoconf, temporary kludges for wine rpcss subtitute?
by Greg Turner 01 Nov '02

01 Nov '02

Sorry, in advance, for this barrage of questions... but I'm getting anxious to proceed with this thing. Naming: This guy needs a name if I'm ever going to start coding it. How about: Wine Remote Procedure Call System Server aka wrpcss.exe.so? A little misleading with the "ss" thing, but this name will look familiar to windows users, and is more accurate than my previous idea of wine-epmap, since it will eventually need to do more than just endpoint mapping. I pretend this is the right name below, but if there's a better one, just substitute that in everywhere you see "wrpcss" in the following discussion. Life Cycle: Some scenarios will require wrpcss to run all the time as a daemon-type-thingy; most wont -- the majority of scenarios require dynamic on-demand invocation and auto-termination upon unmapping of all registered endpoints, as Ove suggested. Are command line arguments an appropriate way to differentiate between these modes? This ends up going back to the open question of how to implement services in wine; but, of course, I don't want to wait for this to be resolved before proceeding. Whatever solution wine implements for services, adapting wrpcss to it won't be insurmountable (assuming it's a good solution). Also: if run as a service, how do I get "detached" without using "fork()"? Is there some existing example of this I ought to emulate? Directory Structure: dlls/rpcrt4/wrpcss/ ? programs/wrpcss/ ? Autoconf: I can try to implment the necessary infrastructure myself, but if history is any guide, I will screw it up. If anyone is feeling generous with their time, they could give me a skeleton to fill in. Temporary Kludges: DCE does, indeed, provide the necessary idl to implement the endpoint mapper. Unfortunately, although the IDL is reasonably simple, there are just too many types in there to "do it right" from the beginning. Meanwhile, I am getting sick of dragging along the unmerged server parts (it isn't that hard, but I'm lazy). So, as discussed earlier, I propose the named-pipes hack until a full implementation is possible. I would, of course, take some care to keep the kludge-based parts separate from meaningful, potentially permanent parts of the code... howsabout I just listen at \\.\pipe\wrpcss for the time being? thanks for your input, -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

3 5

RFC: prototype skeleton for wrpcss
by Greg Turner 01 Nov '02

01 Nov '02

Is this even close? As before, I didn't include diffs to configure because of an autoconf version mismatch between myself and wine. diff -ur -x CVS -x 'bigdif*' ../wine.test/configure.ac ./configure.ac --- ../wine.test/configure.ac 2002-10-31 03:10:18.000000000 -0600 +++ ./configure.ac 2002-11-01 08:54:33.000000000 -0600 @@ -1512,6 +1512,7 @@ programs/winetest/Makefile programs/winhelp/Makefile programs/winver/Makefile +programs/wrpcss/Makefile server/Makefile tools/Makefile tools/widl/Makefile diff -ur -x CVS -x 'bigdif*' ../wine.test/programs/Makefile.in ./programs/Makefile.in --- ../wine.test/programs/Makefile.in 2002-09-18 18:10:21.000000000 -0500 +++ ./programs/Makefile.in 2002-11-01 09:17:41.000000000 -0600 @@ -27,7 +27,8 @@ winepath \ winetest \ winhelp \ - winver + winver \ + wrpcss # Sub-directories to run make install into INSTALLSUBDIRS = \ @@ -47,7 +48,8 @@ winemine \ winepath \ winhelp \ - winver + winver \ + wrpcss # Programs to install in bin directory # We don't install everything to avoid polluting /usr/bin too much @@ -63,12 +65,14 @@ winefile \ winemine \ winepath \ - winhelp + winhelp \ + wrpcss # Symlinks to apps that we want to run from inside the source tree SYMLINKS = \ wineconsole.exe \ - winedbg.exe + winedbg.exe \ + wrpcss.exe @MAKE_RULES@ @@ -121,7 +125,11 @@ winedbg.exe$(DLLEXT): winedbg/winedbg.exe$(DLLEXT) $(RM) $@ && $(LN_S) winedbg/winedbg.exe$(DLLEXT) $@ +wrpcss.exe$(DLLEXT): wrpcss/wrpcss.exe$(DLLEXT) + $(RM) $@ && $(LN_S) wrpcss/wrpcss.exe$(DLLEXT) $@ + wineconsole/wineconsole.exe$(DLLEXT): wineconsole winedbg/winedbg.exe$(DLLEXT): winedbg +wrpcss/wrpcss.exe$(DLLEXT): wrpcss ### Dependencies: --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/wrpcss/.cvsignore 2002-11-01 08:39:51.000000000 -0600 @@ -0,0 +1,3 @@ +Makefile +wrpcss.exe.dbg.c +wrpcss.exe.spec.c --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/wrpcss/Makefile.in 2002-11-01 08:44:10.000000000 -0600 @@ -0,0 +1,14 @@ +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = wrpcss.exe +APPMODE = cui +IMPORTS = user32 kernel32 + +C_SRCS = \ + main.c + +@MAKE_PROG_RULES@ + +### Dependencies: --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/wrpcss/README 2002-11-01 08:42:27.000000000 -0600 @@ -0,0 +1,14 @@ +wrpcss README + +wrpcss, copyright 2002, Greg Turner +wrpcss is to be distributed under the LGPL/X11-MIT licenses +See the Wine License for further information. + +Wine needs a server whose role is somewhat like that +of rpcss.exe in windows. wrpcss stands for Wine Remote +Procedure Call System Server. + +Enjoy. + +KNOWN BUGS: + Doesn't do anything yet. --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/wrpcss/main.c 2002-11-01 08:51:26.000000000 -0600 @@ -0,0 +1,28 @@ +/* + * wrpcss (main.c) + * + * Copyright 2002 Greg Turner <gmturner007(a)ameritech.net> + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include "main.h" +#include "msvcrt/stdio.h" + +int main( int argc, char **argv ) +{ + printf("Yes, I run.\n"); + return 0; +} --- /dev/null 1969-12-31 18:00:00.000000000 -0600 +++ ./programs/wrpcss/main.h 2002-11-01 08:45:47.000000000 -0600 @@ -0,0 +1,26 @@ +/* + * Copyright 2002 Greg Turner <gmturner007(a)ameritech.net> + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a cop Alexandre Julliard <julliard(a)winehq.com>y of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef _WRPCSS_MAIN_H +#define _WRPCSS_MAIN_H + +#include <windows.h> + +#endif /* _WRPCSS_MAIN_H */ + +/* end of header */ -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

3 4

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by John K. Hohm 01 Nov '02

01 Nov '02

> > 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: I think you need to look more closely at the LPSTARTUPINFO lpStartupInfo argument to CreateProcess. It points to a STARTUPINFO structure having HANDLE hStdInput, HANDLE hStdOutput, and HANDLE hStdError members, which are used if the dwFlags member has the STARTF_USESTDHANDLES bit set.

1 1

MDAC
by Gustavo Junior Alves 01 Nov '02

01 Nov '02

Hi guys, I don't know if this is the right place, but I actually trying to run some commercial applications on Wine. We have sucess in all aplications, but VB. These applications need to use MDAC, and this Microsoft package need to be licensed for commercial use. Anybody know any MDAC project? If not, what about to implement it on Wine? I know that it a huge API, but we need to start someday. Any comments??? Gustavo

1 0

Re: Wine FAQ - call for a volunteer
by Jeremy White 01 Nov '02

01 Nov '02

> > I expect to be living close to it for the next few months and may > well get some questions that don't appear on the mailing list. I also > don't see myself being able to find the time to do much coding, however > much I'd like to. > > On the other hand I'm not sure I can do things in a timely manner with > other commitments. Might be better to have a primary and reserve > maintainer. I'd certainly be prepared to take on the latter. > > I can at least offer to do things from a static IP to make access > control more certain (sorry, I'm a bit of a security freak). Okay, we have a backup FAQ volunteer. Who will be our primary? A certain path to fame, fortune, and a lot of thankless work <grin>. Jer

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel