Re: export variables in dlls
Am Die, 2003-08-19 um 00.36 schrieb Dimitrie O. Paun:
> Try doing winegcc in standard sh, I doubt you'll get any shorter/cleaner
> code. Not to mention a bit slower :)
You challenged me :-) really, shell coding is one of my favorites.
Have a look at the attached code, if you like. Actually, I found it
easier to mimic winegcc than wineld. For C++ code, a link
winec++ -> winecc needs to be created.
I have added a few enhancements, such as dealing with non-standard Wine
installation directories, running from a Wine source tree, and more
sophisticated debug output. Therefore, the code indeed isn't shorter
than the C code. IMO it is more readable and to the point, though - but
that's of course a matter of taste.
I found that paths in the original winegcc/winewrap are broken for my
wine/linux installation, so the paths that I put in these scripts may be
broken for MingW. They can be easily customized with environment
variables, though; see bottom of winetools.sh.
All three files must be somewhere in the PATH.
Everyone is invited to try this stuff out. I ran it with bash, ash, zsh,
and pdksh here, so I guess it must be fairly portable.
Please send bug reports to my email address because I'am not reading
wine-devel on a daily basis.
Martin
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
#!/bin/sh
# winecc - winegcc clone in POSIX shell language.
# Copyright (C) 2003 Martin Wilck <[EMAIL PROTECTED]>
#
# 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
. winetools.sh || { echo "Cannot find winetools.sh; please adjust PATH">&2; exit 129; }
### Set script name (for error messages etc.)
if expr "$0" : '.*++[^/]*$' >/dev/null; then
myself=$WINE_CXX
cpp_opt=-C
compiler="$CXX"
else
myself=$WINE_CC
cpp_opt=
compiler="$CC"
fi
__MY_VERSION__=0.1
usage="\
usage: $__ME__ [options] file...
Options: like $compiler options
--keep do not delete temporary files
--wrap generate wrapper code (e.g. for C++ code using static objects)
-v|--verboseincrease verbosity level
-q|--quiet decrease verbosity level
"
win_gccopts="-fPIC -fshort-wchar"
win_defs="-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -D__WINNT -D__WINNT__ \
'-D__stdcall=__attribute__((__stdcall__))' \
'-D__cdecl=__attribute__((__cdecl__))' \
'-D__fastcall=__attribute__((__fastcall__))' \
'-D_stdcall=__attribute__((__stdcall__))' \
'-D_cdecl=__attribute__((__cdecl__))' \
'-D_fastcall=__attribute__((__fastcall__))' \
'-D__declspec(x)=__attribute__((x))'"
wine_defs="-DWINE_UNICODE_NATIVE \
-D__int8=char -D__int16=short -D__int32=int '-D__int64=long long'"
keep=
link=y
stdinc=y
stdlib=y
exe_mode=cui
msvcrt=
static=
output_name=
### scan_options
scan_options() {
while [ "$#" -gt 0 ]; do
case $1 in
-\?|--help)
quit "$usage";;
-c|-S|-E|-M*)
link=;;
--keep) keep=y;;
-mno-cygwin)
msvcrt=y;;
-mwindows)
exe_mode=gui;;
-nostdinc)
stdinc=;;
-nodefaultlibs|-nostdlibs)
stdlib=;;
-static|--static)
static=y;;
-v|--verbose)
__VERBOSE__=$(($__VERBOSE__+1));;
-q|--quiet)
__VERBOSE__=$(($__VERBOSE__-1));;
-V)
quit "Version: $__MY_VERSION__";;
-Wl)
expr "$1" : '.*-static' && static=y
esac
shift
done
}
get_obj() {
case $1 in
*.o|*.a|*.res)
append link_cmd $1;;
*)
debug 1 "===> compiling $1"
spawn "$myself -c -o $tmp_dir/${1%.*}.o $wineccargs $1"
append link_cmd "$tmp_dir/${1%.*}.o";;
esac
}
do_link() {
link_cmd="$WINE_LD -m$exe_mode $cpp_opt"
tmp_dir=`mktemp -d $TMPDIR/wineccXX` || \
die "failed to create temporary
Re: export variables in dlls
Am Mon, 2003-08-18 um 14.24 schrieb Dimitrie O. Paun: > First, I don't know perl, so that was not an option. As for bash, the > kind of argument manipulations we're doing are not easily achieved in > bash, and it seemed it would have been cleaner to do it in C. I am not sure what manipulations you're talking about; AFAICS the hard stuff is done by winebuild anyway. What I don't like about C in this case is that all the low-level stuff (realloc() and friends) makes the code hard to read and prone to buffer overflows and the like. Anyway, you do the work, you decide. > Moreover, it seems that C is way more prefered > (on average) than scripting languages, and in fact it's a better way > of inviting contributions. See the latest attempt to use Perl for our > conformance tests... Yeah, the wine guys like low-level coding :-) Perhaps I'll contribute a bash version of winewrap soon, just for fun. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: export variables in dlls
Am Fre, 2003-08-08 um 14.32 schrieb Dimitrie O. Paun: > Yes, this is good advice for the forseable future. Without compiler > support, we can't do much about the dllimport/dllexport bit. This means that, with the introduction of .def files in wine, porting software (especially C++) with winelib has become considerably more troublesome than before. Whatever we think about dllexport, it is widely used by Windows programmers. binutils with PE support can be used to extract a .def file with all symbols from an object file right now. Unfortunately, binutils on most standard Linux distributions do not support PE. But it may be acceptable to demand that winelib developers recompile their binutils. Btw Dimi, is their any specific reason why winewrap/winegcc are written in C rather than in some scripting language like bash or perl? I'd think that winewrap/winegcc scripts would be much easier to maintain and customize than the current C code, and would actually be the adequate tool for the job. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: export variables in dlls
Am Fre, 2003-08-08 um 13.23 schrieb flyker: > extern "C" __declspec(dllimport) void xxx(char *str, ...); > extern "C" __declspec(dllimport) char *zzz; Except on CygWin/MingW, gcc has no support for __declspec(dllimport) and __declspec(dllexport). If I understand Dimi right, enabling DLL compilation with winegcc/winewrap is on his to-do list. I have also looked into this recently and found ts hard to do right. Best thing right now is probably to write a "def" file manually. If you have access to a MingW/cygwin system, you can create one their with dlltool or ld. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Stuck with winelib + DLL import
Hi, after a good while I had some time to look at my winelib project again. Last time I worked on it was last December, before the "import library" concept was introduced. I had to realize that winelib had changed so much that I couldn't make my code compile anymore. I tried all day to figure it out for myself, but it seems I'll need some guidance. This is what I have (strongly simplified): a DLL written in C++ and an App (also C++) importing that DLL. I want to compile both under winelib, and link everything together to get a working app. I fail miserably in setting this up with winemaker like I did it in the past. This is what I understood so far: - DLLs now need an associated ".def" file to be imported, - winebuild generates ".def" from ".spec", - winewrap/winegcc are the future way to go, but they don't support building DLLs yet. My problem is that I don't have a "spec" file for my DLL except the winemaker-generated one (which is just a zero-length dummy). I also have no "def" file, and because the DLL is C++, I have no clue how to write a spec or def file manually (name mangling). Actually, I'd rather avoid writing that stuff by hand. It would be fine to use static linking instead of a DLL (ie the equivalent of linking statically with a .lib file), but I have no clue how to do that either except to brutally link all object files together into a single executable. As long as no wrapper code is involved, it seems that I can avoid the problem by simply linking with unix ld.so. But I recall that this is utterly wrong. In short, I am clueless. Any hints appreciated. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
New winsock maintainer needed
Hi everybody, I am sorry to announce that I won't be able to continue as wine's winsock maintainer. I will be lacking the time and power to fulfill a maintainer's duties appropriately. I guess I have already failed to do so in the last 2 months. There have been few bug reports lately, so the code isn't completely broken for my successor, I hope. On the other hand, I would have liked to clean up some other things like the select() call and the transport provider interface. The fact that I didn't have the time to get going on these also shows that I'd better hand this off to someone else. I'll be coming back here, and perhaps I'll have more time for contributions some time in the future. In any case, I'll be available for questions or complaints about the winsock code under this email address and under my private email, [EMAIL PROTECTED] I have certainly not lost interest in Wine, Linux, and Free Software. Working with you guys has definitely been great fun and I have learned more than in years before. See you later, Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
Am Don, 2003-02-06 um 23.50 schrieb Mike McCormack: > OK, what happens if one thread closes an FD in the middle of another > thread's read operation (that might take multiple accesses to an FD)? I > think that's unlikely, but that seems to me to be what the dup/close > business is all about. That'd be impossible if close() calls were prohibited. I entirely agree that the handling of Unix fd's must be up to the Wine core. But *because of that* I despise the close() calls spread all about our code. However, see my answer to Alexandre's mail for a constructive proposal. > Another way to solve the problem would be to enter a critical section > instead of dup'ing a handle, but that also has a cost, and somebody will > forget to leave the critical section somewhere in the code... I don't think that is an option. That would mean no two threads could simultaneously read and write. A usage count on an fd would be possible. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
Am Don, 2003-02-06 um 22.17 schrieb Alexandre Julliard: > The risk is a detail, the real point is that an API that returns an fd > to a client has to return a new fd and let the client close it, since > we can't know when the client is finished with it. Currently because > of the fd cache it happens that we don't really need the close() but > that's an implementation detail that could change; and we need to keep > the flexibility to change it. It is not clean to hide the system call that creates the fd and require the client to make the call that destroys it. It'd be better to have the client call wine_server_get_fd() (as now) to get the fd and wine_server_release_fd() if it's done with it. Then it'd be entirely up to wine core functionality whether or not get_fd()/release_fd() requires a dup() and a close(). That'd be much better than what we have now, and keep the flexibility you're talking about. Instead of doing dup() and close(), we could have a usage count associated with a Unix fd. Can we come to an agreement along these lines? > I don't see why it would be hard to close fds, it's just standard > resource management, like freeing allocated memory, etc. If the async > I/O code makes this hard to do then the code is broken. Asynchronous IO, broken or not, allows for hundreds of simultaneous IO operations on a single HANDLE, and therefore gets us into *resource shortage* as long as we use up an fd for each such operation. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
Just a side issue: On my system (PIII 1GHz), one pair of dup()/close() calls takes about 1us. Not all too much, but it may matter in IO-intensive applications. Of course I am not arguing in favor of sacrificing stability for a tiny bit of performance. Just another small pro for my patch :-) Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
On Mon, 2003-02-03, I wrote:
> Why is that relevant to Wine? 99% of the Wine code uses DOS/Windows
> functions like WriteFile() anyway. All we need to do is make sure that
> these functions handle the Unix fd's properly (and they will if they
> don't call close()).
What's up, people? I think at least I deserve an answer to this
argument. Or is everybody just too busy?
I am not going to give up easily on this one, because I still think it's
the right thing to do. If anybody is worried about regressions or the
risk of future close() calls, I am willing to care for that.
As for the risk of someone inadvertently close()ing an fd and someone
else writing to it, how about something like this:
static inline int wine_close_unix_fd (int fd) { return close (fd); }
#define close(fd) ERROR --- please dont call close() in Wine !!
in the Wine headers, and changing close() to wine_close_unix_fd()
wherever the close() is found to be legitimate?
Martin
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
Am Sam, 2003-02-01 um 10.53 schrieb David Laight: > No, it causes horrid corruptions that are particularly difficult > to find. > > What happens is that someone else does an open() and is given > the number of the (incorrectly) closed fd. The owener of the fd > will then write into the newly opened file. Why is that relevant to Wine? 99% of the Wine code uses DOS/Windows functions like WriteFile() anyway. All we need to do is make sure that these functions handle the Unix fd's properly (and they will if they don't call close()). No user code can ever access the Unix fd's. I admit my patch isn't small but it also shows that the close() calls are only in half a dozen source files. In the code that is using the Unix fd's, however, the close() calls are confusing, ugly, and easy to forget. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: PATCH: Get rid of superfluous dup() and close() calls.
Am Fre, 2003-01-31 um 22.37 schrieb Alexandre Julliard: > I think it's cleaner to return a dup of the fd instead of relying on > the fact that the fd is cached internally. This may not always be the > case, and it's better to risk an fd leak than to risk invalidating the > cached value in case someone closes the fd when they shouldn't. I see your point, but I don't see the risk you're talking about. The new coding rule (after removing the dup) is very simple: ** Never close() a Unix fd that you haven't open()d or dup()d ** yourself. Actually, one could formulate it more clearly: ** Never call close() unless you really know what you're doing. That is easy to understand for everybody, I reckon. I think it is much more likely that a programmer forgets a close() call than that he erroneously writes one, especially because it is pretty hard to even find the hidden dup() that creates all these fd's. When I was new to wine I guess it took me least a week to understand why the close() calls appeared everywhere. The current rule is much more complex. Especially with asynchronous IO it becomes *very* hard to track the open fd's. Please rethink your position on this subject. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
PATCH: Get rid of superfluous dup() and close() calls.
nix_handle);
return FILE_TimeoutRead(hFile, buffer, bytesToRead, bytesRead);
}
switch(type)
@@ -1856,7 +1851,6 @@
&highOffset,
FILE_BEGIN)) &&
(GetLastError() != NO_ERROR) )
{
- close(unix_handle);
return FALSE;
}
}
@@ -1872,7 +1866,6 @@
off_t offset = OVERLAPPED_OFFSET(overlapped);
if(lseek(unix_handle, offset, SEEK_SET) == -1)
{
- close(unix_handle);
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
@@ -1886,7 +1879,6 @@
FILE_SetDosError();
break;
}
-close( unix_handle );
if (result == -1) return FALSE;
if (bytesRead) *bytesRead = result;
return TRUE;
@@ -1998,7 +1990,6 @@
return !register_new_async (&ovp->async);
error:
-close (fd);
return FALSE;
}
@@ -2037,12 +2028,10 @@
if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) )
{
TRACE("Overlapped not specified or invalid event flag\n");
- close(unix_handle);
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
-close(unix_handle);
overlapped->InternalHigh = 0;
if(!FILE_WriteFileEx(hFile, buffer, bytesToWrite, overlapped, NULL,
overlapped->hEvent))
@@ -2075,7 +2064,6 @@
&highOffset,
FILE_BEGIN)) &&
(GetLastError() != NO_ERROR) )
{
- close(unix_handle);
return FALSE;
}
}
@@ -2086,7 +2074,6 @@
return FALSE;
if (overlapped)
{
-close(unix_handle);
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
@@ -2098,7 +2085,6 @@
off_t offset = OVERLAPPED_OFFSET(overlapped);
if(lseek(unix_handle, offset, SEEK_SET) == -1)
{
- close(unix_handle);
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
@@ -2115,7 +2101,6 @@
FILE_SetDosError();
break;
}
-close( unix_handle );
if (result == -1) return FALSE;
if (bytesWritten) *bytesWritten = result;
return TRUE;
Index: files/smb.c
===
RCS file: /home/wine/wine/files/smb.c,v
retrieving revision 1.16
diff -u -r1.16 smb.c
--- files/smb.c 24 Jan 2003 00:54:58 - 1.16
+++ files/smb.c 24 Jan 2003 14:14:02 -
@@ -1532,7 +1532,6 @@
if(total>=bytesToRead)
break;
}
-close(fd);
if(bytesRead)
*bytesRead = total;
Index: include/async.h
===
RCS file: /home/wine/wine/include/async.h,v
retrieving revision 1.5
diff -u -r1.5 async.h
--- include/async.h 4 May 2002 18:37:08 - 1.5
+++ include/async.h 24 Jan 2003 14:14:02 -
@@ -72,7 +72,6 @@
ovp->next = ovp->prev = NULL;
-close( ovp->fd );
if( ovp->event != INVALID_HANDLE_VALUE )
NtSetEvent( ovp->event, NULL );
Index: scheduler/client.c
===
RCS file: /home/wine/wine/scheduler/client.c,v
retrieving revision 1.92
diff -u -r1.92 client.c
--- scheduler/client.c 31 Oct 2002 03:41:56 - 1.92
+++ scheduler/client.c 24 Jan 2003 14:14:05 -
@@ -436,7 +436,6 @@
*/
}
-if ((fd != -1) && ((fd = dup(fd)) == -1)) return STATUS_TOO_MANY_OPENED_FILES;
*unix_fd = fd;
return STATUS_SUCCESS;
}
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Winsocket hanging
Am Fre, 2002-12-13 um 13.02 schrieb Uwe Bonnes: > trace:winsock:__ws_select read 0x406e2bb0, write (nil), excp (nil) timeout 0x406e2cb4 This looks as if the app is doing a blocking select() but nothing ever happens on the socket (no connect). Doesn't look like an error at first sight. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winelib + unicode
Am Mit, 2002-12-11 um 16.49 schrieb Dimitrie O. Paun: > On December 11, 2002 10:52 am, Martin Wilck wrote: > > well the configure script should probably check if -fshort-wchar is > > supported, add the option to CFLAGS if yes, and issue a warning if no. > > But the problem is that winemaker will run on different systems that > configure runs on... It will get it mostly right, but now always. I can't follow you. Winemaker generates a configure.ac file. You need to run autoconf and configure anyway to build your code. We just need to make sure that Winemaker puts a test for -fshort-wchar into configure.ac. What am I missing? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winelib + unicode
Am Mit, 2002-12-11 um 16.17 schrieb Dimitrie O. Paun: > The -fshort-wchar is the only correct fix to the problem, and just > by enumerating the other hacks we just confuse the issue. Agreed - at least I see no need for automating them. > Who is crazy enough to use the other hacks where there is such a > simple (and correct) fix available? This option is probably supported > nowadays by most gcc installations, and for the 1 in 1000 that doesn't > want to use it (for whatever reason), they will bring it up on wine-devel > and they'll get an answer. No point in cluttering the documentation > (Winelib User's Guide), the scripts (winemaker), etc. with them. well the configure script should probably check if -fshort-wchar is supported, add the option to CFLAGS if yes, and issue a warning if no. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
winelib + unicode
wouldn't it be nice to have winemaker-generated sources automatically add "-fshort-wchar" to the C compiler options? To make this robust, one could write a configure test for it. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine/dlls/winsock/socket.c: Force SO_REUSEADDR ...
Hi, judging from the Traces these programs are rare examples of lame network programming. You find series of things that shouldn't be done, such as bind()ing in a client application, not closing down a socket cleanly but expecting the next bind() to the same address to succeed, polling the socket with ioctl (FIONREAD), etc. I am really asking myself if it's right to hack wine to violate the specs just for the sake of so poorly programmed applications. I'd be grateful for advice by experienced Wine hackers here. Perhaps we need to introduce Windows version-dependent behavior. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine/dlls/winsock/socket.c: Force SO_REUSEADDR on beforebind()/Ignore SO_DONTROUTE
Am Mon, 2002-12-09 um 14.57 schrieb Christoph Frick: > > I'd like to know what remote addresses exactly the apps call bind() for, > > and in what order. Perhaps there are subtle differences in the way > > EADDRINUSE and SO_REUSEADDR are handled. > > I can basically describe you what this games do network-wise and/or i can > provide you with traces (with and without patch) - what do you prefer? What i > can not do is testing in windows. Run with -debugmsg trace+winsock. You may also need to set DEBUG_SOCKADDR to 1 (look for it close to the top of socket.c), and recompile and reinstall the winsock DLL. Oh, and given the "NetTrans" thing below, run with "trace+reg", too. > > However the patch implements the first behavior (ignore) whereas > > the Windows TCP/IP transport behaves as the second (later calls to > > getsockopt() refelect the SO_DONTROUTE settings, which seems to have no > > further effect). > > So closer to windows would be store and ignore. In general i wonder, if > windows does this always or if this depends somehow on the "device" the socket > is finally bound to - or in other words: is always the same code on windows in > charge or could it be that this might be implemened e.g. by a NIC driver. It is the "Service provider" which in this case is Microsoft TCP/IP (think of it as one of the "protocols" Windows allows you to install in the Network settings). Other service providers are IPX, NetBEUI, or Appletalk. Since TCP/IP is pretty important nowadays, if Microsoft TCP/IP ignores SO_DONTROUTE (actually, it seems to ignore the MSG_DONTROUTE flag to send(), too!) it is probably ignored almost everywhere in the MS world. Wine's Winsock implementation is not (yet) modular - it doesn't use service providers. > Why i ask: please see my mail to wine-devel from 2002-10-25; the game also > checks the .../NetTrans/... settings. I am not sure what these are for. They seem to be Win95/98 specific - my Win2k box doesn't have them. It appears that for Win9x there should be one System/Services/Class/NetTrans/000x entry for each installed transport service provider. > Maybe here is something missing that > tell the game to set SO_DONTROUTE. Wine does not set them automatically like > other hardware/driver related stuff. I really can not imagine, why a game > should set this option explicit when it connects to an server (the ip/name is > entered manually in this case, so the game should expect the host not in the > same network). Well, browsing through MSDN, the reason may be past trouble with PCs with several network interfaces, where the game wanted to connect through a dial-up connection rather than through a LAN (or vice-versa). In any case it can't be much more than a hack some games were using to work around some obscure Win9x networking limitation. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine/dlls/winsock socket.c
Am Sam, 2002-12-07 um 00.19 schrieb Alexandre Julliard: > Christoph Frick <[EMAIL PROTECTED]> > Force (WS_)SO_REUSEADDR before binding to a socket; Sorry, this is definitely wrong. Windows, just as Unix, returns WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There must be some special circumstances involved in those games the patch is supposed to fix. Perhaps they assume a certain Winsock implementation or Windows version. I'd like to know what remote addresses exactly the apps call bind() for, and in what order. Perhaps there are subtle differences in the way EADDRINUSE and SO_REUSEADDR are handled. > ignore (WS_)SO_DONTROUTE; Network games in Grand Prix Legends and Nascar 2002 > are possible now. Footnote (i) in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/socket_options_and_ioctls_2.asp says that this is - in principle - legal: "A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way." However the patch implements the first behavior (ignore) whereas the Windows TCP/IP transport behaves as the second (later calls to getsockopt() refelect the SO_DONTROUTE settings, which seems to have no further effect). > Patch: http://cvs.winehq.com/patch.py?id=6523 Alexandre, please back this patch out for now, at least the SO_REUSEADDR part which is plain wrong. Please don't get me wrong: These issues need to be fixed, but please, not by applying hackish patches for special applications such as this one. Christoph: sorry I missed out on your previous mails to wine-devel. Next time, say something about sockets in the subject line and chances are I won't miss them again. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Dll separation question
I am sorry to say that I still don't quite understand this issue, but - can anybody point me to a resource saying what exactly I may or may not do when writing code for a wine DLL? In particular, when writing code for DLL X, which functions from other DLLs may I call? Example: When writing netapi32 code, can I call advai32 Registry functions to obtain config options, or do I need to use the (IMO rather awkward) ntdll interface ? Btw: Dll separation is a really complex issues and I think I'm not the only one who feels he doesn't quite understand what it means. IMO winehq needs a very clear description of that somewhere where it's easy to find. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Fix winsock conformance test on Windows NT
Am Mit, 2002-12-04 um 10.21 schrieb Francois Gouget: > > With the following fixes, the winsock test runs fine (0 errors) on Win > > NT (and Wine!). > > I applied the patch but the test still fails and gets stuck on NT4: Strange - on my Win2k box it runs perfectly. Error 10022 is WSAEINVAL - I have no idea how this could happen, unless I did something wrong with the TLS stuff. However it runs on W2k, it runs on Wine, and AFAICT it's programmed to the specs. What now? Martin - Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: The conformance tests need you!
Hi Francois, You may have seen that Alexandre applied my patch, so the winsock test issue appears to be fixed. I inserted an #ifdef _WIN32 clause at the top to adjust includes to run with VC++. I wonder if this should be done for all test programs to avoid the editing hassle. The "Running tests on Windows" section in the Wine docs _definitely needs correction_. It currently doesn't talk about running tests on Windows at all - it covers running tests in Wine!! Besides, it is largely out of date, talking about perl tests and such. With the current docs, my level of wine experience, and a fair amount of googling, it took me about 2 hours to find out how to get the tests running on Windows (1 - do "make test" in wine, 2 - copy .c files and wine/test.h to Windows, 3 - import everything into a VC++ project, 4 - adjust #include directives with trial and error, 5 - go for it). I guess for newbies it will be pretty much impossible to figure this out. Or is there a really simple way that I just missed? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: strcat+strcat+strcat == baaad
Am Mon, 2002-12-02 um 20.15 schrieb David Laight: > Actually I don't have glibc - I'm running netbsd not linux. > Netbsd might benefit from faster strxxx routines. Can't you use an optimized glibc on NetBSD? > OTOH the times are very dependant on the cpu model! > My slotA athlon 700 executes my str_add() faster the > way I coded it - I tried the other order and it sucked. With gcc 3.2? That compiler optimizes the jmp away in an if statement, apparently assuming that the "if" clause is executed much more often. The "else" clause, OTOH, jmp's to the end of the subroutine and jumps back afterwards. Thus if the compiler guesses wrongly, the CPU'll have to do two more jmp's per loop, with possible instruction cache miss. Hard for me to believe that'll be a speed improvement on any CPU. If the compiler guesses right, 1 jmp will be saved per loop. > Of course you can use the same tricks as glibc does to speed > up your own variant of the copy routine. I am not talking what you or I could or couldn't do. I am just saying Wine should rely on glibc for these things, and not try to outwit those who're doing these things all the time. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: The conformance tests need you!
Am Mon, 2002-12-02 um 19.12 schrieb Francois Gouget: > > Am Sam, 2002-11-30 um 04.02 schrieb Francois Gouget: > > > > > > Come on people, we can do better. > > > Send fixes to wine-patches, and send me emails to so that I update this > > > table. > > > > I'll have a look at the winsock stuff. > > Thanks :-) I am currently having trouble with running stuff natively on Windows. Can anybody run the winsock test with verbose output (trace enabled) on Windows NT and send me the result ? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: strcat+strcat+strcat == baaad
Am Mon, 2002-12-02 um 13.57 schrieb David Laight: > It is as if the code from your program is executing far > slower than anything from libc! That is very well possible if he has the right libc. Take a look at the optimizations in the string functions in glibc, and you'll have an idea why. Unless you are a assembler programming Guru for a certain architecture, you'll have a hard time beating them. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: strcat+strcat+strcat == baaad
Am Son, 2002-12-01 um 23.07 schrieb Shachar Shemesh:
> When I'm wrong, I'm wrong.
> sun@sun:~/sources/wine/test$ ./way1
> Operation took 0 seconds 450763 usec
> sun@sun:~/sources/wine/test$ ./way2
> Operation took 0 seconds 598408 usec
> sun@sun:~/sources/wine/test$ ./way3
> Operation took 0 seconds 427037 usec
First off, the program is wrong in that "way3" doesn't do what it's
supposed to (concatenate). Below is a patch for your benchmark with a
"WAY4" going a similar path as WAY3, but using strlen() and memcpy(),
and a WAY5 that is pretty similar to David's, but better with gcc 3.2.
My resume is: Don't try to outwit the C library. Assume that the user
has installed a good one, and use library functions.
(Btw ever looked at the section about "strcat" in the glibc info pages?)
WAY4 below is very fast with a good C library. On i686, it is best for
all optimizations except -O1 where gcc inlines self-generated
i386-optimized code which is more than a factor of 2 slower than the
library routine. It also requires the "-march=i686" option to gcc,
otherwise gcc wrongly assumes that i386 optimizations are the best, and
uses them always.
Of course, if the lengths of the strings are known, you can speed this
up a lot by doing without strlen().
WAY2 depends on the "strcat" implementation in the library. It may be
slower than the snprintf solution if strcat is badly optimized. (And
it's unsafe)!
David's WAY3, being not library dependent, is quite good except for -O0.
With GCC 3.2 and optimization -O2 and above, it is necessary to reverse
the "if" and "else" clauses in str_add(), otherwise performance degrades
because gcc assumes the "if" branch is taken more often. (That reversed
str_add is called "WAY5" below.
These are my results, obtained on a PIII system with RedHat 8.0, using
"gcc -Ox -march=i686" as optimization: (I took gcc3.2 -O0 as "reference
value" 1.0):
GCC 3.2 -O0-O1 -O2 -O3
WAY11.000.980.970.97
WAY20.930.980.920.93
WAY32.280.670.951.05
WAY40.491.000.460.41
WAY52.530.660.660.76
GCC 2.96 -O0-O1 -O2 -O3
WAY11.000.981.021.02
WAY20.930.930.930.93
WAY32.210.670.690.63
WAY40.491.020.480.42
WAY52.420.670.690.63
Martin
--- strorg.cMon Dec 2 13:29:43 2002
+++ strcpy.cMon Dec 2 17:35:00 2002
@@ -12,15 +12,38 @@
int c;
do {
+#if WAY5
+ if ( s < lim ) c = *a++;
+ else {
+ s = lim - 1;
+ c = 0;
+ }
+#else
if (s >= lim) {
s = lim - 1;
c = 0;
} else
c = *a++;
+#endif
*s++ = c;
} while (c);
- return s;
+ return --s;
+}
+
+char*
+str1_add(char*s, int *len, const char *a)
+{
+
+int l = strlen(a);
+if ( l >= *len )
+l = *len - 1;
+
+memcpy ( s, a, l ) ;
+*len -= l;
+s += l;
+*s = 0;
+return s;
}
int main()
@@ -32,7 +55,7 @@
gettimeofday(&before, NULL);
for( i=0; imailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: How to debug wineserver
Am Don, 2002-11-28 um 17.16 schrieb Tony Lambregts: > >is there any way we can debug the wineserver? > I am not sure this is the right answer since I am not a wine guru. > However when you start wineserver you can start it with debug levels > i.e., "wineserver -d1". Setting d0 turns winserver debugging off. Starting wine with "-debugmsg trace+server" works quite well. Furthermore, wineserver is a true Unix program. You can run in through gdb. I often run wine normally, then start gdb and simply attach to the running wineserver process. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [RFC] Winelib enhancements
Am Don, 2002-11-28 um 15.24 schrieb Dimitrie O. Paun: > I've addressed both of these on the web page :) Well, I should have read it more thoroughly, I guess :-/ > If we are to just generate a parallel build system, we'd be wasting out > time. We have to make it simple so we have a chance of the app maintainers > doing the porting themselves. I understand your reasoning now. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [RFC] Winelib enhancements
Am Don, 2002-11-28 um 11.37 schrieb David Fraser: > means people won't have to keep on using VC++. Or does winemaker do this > already? Yes. Actually, it produces "configure" and "Makefile.in". Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [RFC] Winelib enhancements
Am Don, 2002-11-28 um 07.35 schrieb Dimitrie O. Paun: > -CC=gcc > +CC=wcc > > -RC=windres > +RC=wrc > I can't follow you here. You seem to have been porting Applications using Unix-Style Makefiles. I'd guess the vast majority of Applications comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). In any case, IMO this is what's winemaker is all about. Your idea of introducing compatibility tools is nice but somewhat limited in scope. What we really need is a much more intelligent winemaker. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
RE: Whither SwitchToThread()?
Am Mit, 2002-11-27 um 17.36 schrieb Patrik Stridvall: > Hmm. Which reminds me. In theory we could do even better. Since Alexandre > has to approve each patch we get a slightly larger "turnaround" time for > "obvious" fixes like the one this thread is about. > > So why not have a special CVS tree (or perhaps branch of the current tree) > for Winelib users where anybody of the regular Wine developers could check > in "obvious" fixes for immediate use. Ever heard of Rusty Russell's "patch monkey" for the Linux kernel? Martin PS even if Sean is happy now, and his boss too, let's keep realistic - we were able to give quick feedback here because the solution was simple. -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Die, 2002-11-26 um 19.28 schrieb Martin Fuchs: > Yes. Now my program does read the files without problems under wine. > Contradicting to the real windows environment overlapped file i/o is not very > fast, but at least it works. :-) Sure. In Wine overlapped IO is probably slower than synchronous IO in most cases. You are welcome to rework Wine's overlapped IO to use Linux' new aio API - then we should catch up :-) > Thank's for your effort to find a solution for my litte problem. Good to hear it works. I'll submit the patch to Alexandre. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
RE: Overlapped I/O without an hEvent
Am Die, 2002-11-26 um 00.33 schrieb Ryan Reading:
> I finally got it working, but not by ignoring the hEvent member in the
> case that it is NULL. I tried that first (before I understood the
> problem better), but it didn't work. The GetOverlappedResult()
> implementation was not going to work with hEvent == NULL.
Please try this patch, where GetOverlappedResult is modified, too:
Index: files/file.c
===
RCS file: /home/wine/wine/files/file.c,v
retrieving revision 1.170
diff -u -r1.170 file.c
--- files/file.c21 Nov 2002 03:45:03 - 1.170
+++ files/file.c26 Nov 2002 10:34:21 -
@@ -1593,32 +1593,40 @@
ERR("lpOverlapped was null\n");
return FALSE;
}
-if(!lpOverlapped->hEvent)
+if( lpOverlapped->hEvent )
{
-ERR("lpOverlapped->hEvent was null\n");
-return FALSE;
+if ( bWait )
+{
+do {
+TRACE("waiting on %p\n",lpOverlapped);
+r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE);
+TRACE("wait on %p returned %ld\n",lpOverlapped,r);
+} while (r==STATUS_USER_APC);
+}
+else if ( lpOverlapped->Internal == STATUS_PENDING )
+{
+/* Wait in order to give APCs a chance to run. */
+/* This is cheating, so we must set the event again in case of success -
+ it may be a non-manual reset event. */
+do {
+TRACE("waiting on %p\n",lpOverlapped);
+r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE);
+TRACE("wait on %p returned %ld\n",lpOverlapped,r);
+} while (r==STATUS_USER_APC);
+if ( r == WAIT_OBJECT_0 )
+NtSetEvent ( lpOverlapped->hEvent, NULL );
+}
}
-
-if ( bWait )
+else
{
-do {
-TRACE("waiting on %p\n",lpOverlapped);
-r = WaitForSingleObjectEx(lpOverlapped->hEvent, INFINITE, TRUE);
-TRACE("wait on %p returned %ld\n",lpOverlapped,r);
-} while (r==STATUS_USER_APC);
-}
-else if ( lpOverlapped->Internal == STATUS_PENDING )
-{
-/* Wait in order to give APCs a chance to run. */
-/* This is cheating, so we must set the event again in case of success -
- it may be a non-manual reset event. */
-do {
-TRACE("waiting on %p\n",lpOverlapped);
-r = WaitForSingleObjectEx(lpOverlapped->hEvent, 0, TRUE);
-TRACE("wait on %p returned %ld\n",lpOverlapped,r);
-} while (r==STATUS_USER_APC);
-if ( r == WAIT_OBJECT_0 )
-NtSetEvent ( lpOverlapped->hEvent, NULL );
+/* hEvent == NULL: we cannot wait.
+ * FIXME: According to MSDN, NT, Win2k, and XP use the hFile handle for
+notification
+ * in this case. */
+if ( bWait )
+{
+SetLastError ( ERROR_INVALID_HANDLE );
+return FALSE;
+}
}
if(lpTransferred)
@@ -1818,7 +1831,7 @@
if (flags & FD_FLAG_OVERLAPPED)
{
if (unix_handle == -1) return FALSE;
-if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) )
+if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent(
+overlapped->hEvent, NULL ) ) )
{
TRACE("Overlapped not specified or invalid event flag\n");
close(unix_handle);
@@ -2042,7 +2055,7 @@
if (flags & FD_FLAG_OVERLAPPED)
{
if (unix_handle == -1) return FALSE;
-if ( (overlapped==NULL) || NtResetEvent( overlapped->hEvent, NULL ) )
+if ( (overlapped==NULL) || ( overlapped->hEvent && NtResetEvent(
+overlapped->hEvent, NULL ) ) )
{
TRACE("Overlapped not specified or invalid event flag\n");
close(unix_handle);
Index: include/async.h
===
RCS file: /home/wine/wine/include/async.h,v
retrieving revision 1.5
diff -u -r1.5 async.h
--- include/async.h 4 May 2002 18:37:08 - 1.5
+++ include/async.h 26 Nov 2002 10:53:28 -
@@ -73,7 +73,7 @@
ovp->next = ovp->prev = NULL;
close( ovp->fd );
-if( ovp->event != INVALID_HANDLE_VALUE )
+if( ovp->event && ovp->event != INVALID_HANDLE_VALUE )
NtSetEvent( ovp->event, NULL );
if ( ovp->ops->call_completion )
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Die, 2002-11-26 um 10.46 schrieb [EMAIL PROTECTED]:
> Hi Martin,
>
> > Is it correct to say, then, that it is broken behavior by your app to
> > not handle ERROR_HANDLE_EOF correctly, and that it "runs on Windows"
> > only if the files you're accessing are on a local disk?
> >
> > I'm asking because this seems to be one of the rare cases where fixing
> > the app rather than fixing Wine may be the right thing to do.
>
> No, my library handles both cases very well. It does this, because in the
> case of network files the file has been read already completely before the last
> ReadFileEx() call returns the error code. So there's no problem. My get()
> function returns EOF and so the application leaves it read loop.
OK. So you're saying that EOF is only passed to the completion function
when there is nothing more to read.
Would the patch below satisfy your needs? It will call the completion
function with SUCCESS if any data was read (case (b)) and with EOF
otherwise. Thinking about it, this is also consistent with the EOF
conditions I've seen elsewhere (and my previous attempt wasn't:-().
This does still not fix the fact that ReadFileEx() doesn't detect EOF
right away. I hope that is ok - I would really like to postpone the
error handling of ReadFileEx() to the async handler unless it really
breaks stuff. Inserting such code in ReadFileEx (andf ReadFile()?) would
be a lot of hassle and possibly break IO on non-regular files.
Martin
diff -u -r1.170 file.c
--- files/file.c21 Nov 2002 03:45:03 - 1.170
+++ files/file.c26 Nov 2002 10:34:21 -
@@ -152,7 +152,7 @@
async_fileio *ovp = (async_fileio*) data;
TRACE ("data: %p\n", ovp);
-ovp->completion_func( ovp->lpOverlapped->Internal,
+ovp->completion_func( RtlNtStatusToDosError ( ovp->lpOverlapped->Internal ),
ovp->lpOverlapped->InternalHigh,
ovp->lpOverlapped );
@@ -1697,6 +1705,11 @@
r = FILE_GetNtStatus ();
goto async_end;
}
+else if ( result == 0 )
+{
+r = ( lpOverlapped->InternalHigh ? STATUS_SUCCESS : STATUS_END_OF_FILE );
+goto async_end;
+}
lpOverlapped->InternalHigh += result;
TRACE("read %d more bytes %ld/%d so
far\n",result,lpOverlapped->InternalHigh,fileio->count);
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Overlapped I/O without an hEvent
Am Mon, 2002-11-25 um 21.05 schrieb Eric Pouech: > > wth does that mean? does it mean i can just wait on the file handle as > > though it were an HEVENT? > > I think they refer to this, but I may be wrong > > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k111_9dte.asp I don't know. My interpretation was that this is equivalent to waiting on non-event handles such as pipes, comm ports, or files. I thought this "feature" was already supported by wine, although not with the overlapped semantics - I may very well be wrong here. I have another MSDN reference here (last paragraph): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/synchronization_and_overlapped_input_and_output.asp In any case, this feature is strongly deprecated in the Microsoft docs. They're repeating that over and over. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Winelib Applications
Am Mon, 2002-11-25 um 22.56 schrieb Dimitrie O. Paun: > Good point. But the page is not intended to justify the existance > of Winelib, but why we should make more use of it. Maybe I should > add something about "Why have a Winelib app in the first place?"... There are some applications where you simply have no chance of just runnning the native Windows app on Wine. Winelib can be a solution for porting such software to Linux by only rewriting those parts that need to be rewritten, replacing NT with Unix functionality. This is much easier than doing a native port; most of the application's code can be left untouched. IMO this is the "real world" reason for doing Winelib development - you can *combine* Windows and Unix code. OTOH Putty and Mozilla are apps that I'd expect to be able to run natively. The reasons for Winelib work you give on your page are ok but sort of self-referential: They only make sense to people who have already accepted as a fact that Winelib is a good thing. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Die, 2002-11-26 um 09.11 schrieb Martin Fuchs: > And yes, there is: If you read the same files as before, but now using a > network connect (even if the files are located on the same computer), now > Windows behaves a bit different. The completition function IS called in this > case with ERROR_HANDLE_EOF as parameter. > > I think, this is the reason, why MSDN isn't as exact, as it could (or should) > be. The behaviour in respect to calling the completition function depends on > the type of dfriver, which is used to access the files. Is it correct to say, then, that it is broken behavior by your app to not handle ERROR_HANDLE_EOF correctly, and that it "runs on Windows" only if the files you're accessing are on a local disk? I'm asking because this seems to be one of the rare cases where fixing the app rather than fixing Wine may be the right thing to do. By the way, thanks for your very detailed analysis. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Winelib Applications
Am Fre, 2002-11-22 um 23.52 schrieb Dimitrie O. Paun: > http://www.dssd.ca/wine/Winelib-Apps.html > > Comments, suggestions, flames -- all welcome! Just for curiosity: Apart from debugging + improving Winelib, is there a reason why you try to build these as Winelib apps rather than running the native Windows apps in Wine instead? I recommend to put a statement about this on the page because I feel this is a question many people will ask themselves. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Overlapped I/O without an hEvent
Am Sam, 2002-11-23 um 02.11 schrieb Ryan Reading: > The software that I have is using Overlapped (asynchronous) I/O for > communication of an IR port. The software makes WriteFile(), > ReadFile(), and GetOverlappedResult() calls. However, before making any > of the calls, the software does NOT initialize the hEvent member of the > OVERLAPPED structure that is passed to the functions (it just zeroes the > entire structure). Apparently the Win32 implementation of this is OK, > but it is pretty obvious that the Wine implementation will not work with > hEvent == 0. What we could (relatively) easily do is 1 ) Do not return an error condition if hEvent == NULL. 2 ) Handle hEvent == NULL correctly elsewhere ( in particular, in the async handler where the event would normally be set ). 3 ) In GetOverlappedResult(), simply skip the waiting for hEvent == NULL. This may not be enough though. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getoverlappedresult.asp says that for NT/2000,XP, "if the hEvent member of the OVERLAPPED structure is NULL, the system uses the state of the hFile handle to signal when the operation has been completed". I doubt that wine can (easily) support this behavior, but I'm not sure. Please tell me if you think 1-3 would suffice for you. Martin PS: Please use plain-text email next time. -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Mon, 2002-11-25 um 11.22 schrieb Martin Fuchs: > I've tested it under Windows XP. Windows doesn't call the completition > function at all, if the file end has been reached. It simpy returns FALSE > for the ReadFileEx() call, and reports ERROR_HANDLE_EOF (38) via > GetLastError(). We must distinguish 2 cases: a) The file pointer in the overlapped structure is already beyond EOF. This condition is one where ReadFileEx() should arguably react as you are describing. b) The file pointer in the overlapped structure is below eof, but the App wants to read more than available (file pointer + number of bytes to read is beyond EOF). If I understand you right, in this case ReadFileEx() returns TRUE, sets the last error to ERROR_HANDLE_EOF, reads as much as it can and calls the completion function with an Error code of 0. Right? This is against what MSDN says: According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/fileiocompletionroutine.asp the error code for the completion function is set to ERROR_HANDLE_EOF if "the application tried to read past the end of file", which is case b) to my understanding. But of course, Wine needs to behave like Windows behaves, and not like it's supposed to behave. > The problem with my > library under wine is: If an end-of-file error code is signaled via the > completition function, this is taken as an error condition. It doesn't even > pass the partial last file block data to the application. I'd say this broken behavior. However, Windows supports it, so :-/ > And yes: It does run with "real" windows. ;-) > If you want to reproduce the exact behaving of windows with the currrent > wine implementation, you have to change it a lot. You have to check file > length, or try to call pread() directly in ReadFileEx(). Then call > SetLastErorr(ERROR_HANDLE_EOF) and return FALSE without calling the > completition function. We had the direct read call until a few months ago. This is ok for regular files, but not an option for any type of FIFOs like sockets, pipes, or comm ports. The problem we have is that in general we don't know if a file handle passed to ReadFile()/ReadFileEx() is a regular file or not. > If you are interested, I can put a little test program on the web or send it > per private mail. You could use it for testing. It simple reads a file, you > can specify on the command line, and prints it to stdout. It can't hurt, although your reports on real Windows behavior are more valuable. Please tell me the exact behavior you are observing in case a and b above. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Sam, 2002-11-23 um 11.54 schrieb Martin Fuchs:
> After investigating the problem a bit more, I found a better solution:
> The completition function should NOT be called with STATUS_END_OF_FILE.
Passing it STATUS_END_OF_FILE is of course a bug because we have to
report a DOS error code, not an NT status. Please try the patch below.
> Instead ReadFileEx() should report the error, if there's no more to read.
Yeah, MSDN says that. I was hoping (so far) that it suffices to pass
error conditions to the completion function. That should be the same to
a reasonably well-written application because it must check the
condition in the completion function anyway.
> + if (ovp->lpOverlapped->Internal == STATUS_END_OF_FILE) {
> +ovp->completion_func( 0,
> + ovp->lpOverlapped->InternalHigh,
> + ovp->lpOverlapped );
You report success when the condition is EOF - I don't consider that a
good idea. Please try the patch below.
Martin
Index: files/file.c
===
RCS file: /home/wine/wine/files/file.c,v
retrieving revision 1.170
diff -u -r1.170 file.c
--- files/file.c21 Nov 2002 03:45:03 - 1.170
+++ files/file.c25 Nov 2002 08:34:22 -
@@ -152,7 +152,7 @@
async_fileio *ovp = (async_fileio*) data;
TRACE ("data: %p\n", ovp);
-ovp->completion_func( ovp->lpOverlapped->Internal,
+ovp->completion_func( RtlNtStatusToDosError ( ovp->lpOverlapped->Internal ),
ovp->lpOverlapped->InternalHigh,
ovp->lpOverlapped );
@@ -1695,6 +1695,11 @@
if(result<0)
{
r = FILE_GetNtStatus ();
+goto async_end;
+}
+else if ( result == 0 )
+{
+r = STATUS_END_OF_FILE;
goto async_end;
}
Re: wine and asyncronous file i/o
Hi Martin,
> I've attached the interesting section of the resulting trace file.
> Maybe you see, what's going on.
> The programs reads a file with 21517 bytes length.
> After fetching five blocks of 4096 bytes correctly, it reads the remaining
> 1037 bytes. But it does not stop! It reads this last file block continuously.
EOF conditions are nasty. Seems we got it wrong... Please try the
following patch (it should solve your problem). However I guess it needs
regression testing because it changes overlapped ReadFile() semantics
drastically. If this condition turns out to be right, we may actually be
able to get rid of the special treatment of sockets in
FILE_AsyncReadService().
Martin
Index: files/file.c
===
RCS file: /home/wine/wine/files/file.c,v
retrieving revision 1.170
diff -u -r1.170 file.c
--- files/file.c21 Nov 2002 03:45:03 - 1.170
+++ files/file.c22 Nov 2002 11:00:47 -
@@ -1697,6 +1697,11 @@
r = FILE_GetNtStatus ();
goto async_end;
}
+else if ( result == 0 )
+{
+r = STATUS_END_OF_FILE;
+goto async_end;
+}
lpOverlapped->InternalHigh += result;
TRACE("read %d more bytes %ld/%d so
far\n",result,lpOverlapped->InternalHigh,fileio->count);
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winewrapper
Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun: > If Wine was a mature, stable project, I'd agree with you. But it's not. > The ability to make a small change in Wine, go back to the Winelib app, > and test it, is invaluable. I would have simply given up debugging PuTTY > f I had to go through a wine install for every little test and experiment > I was making. For me it was quite ok to do a "make install" only in the dll subdirs where I had modified something. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine and asyncronous file i/o
Am Fre, 2002-11-22 um 04.43 schrieb Martin Fuchs: > I've got an application, which uses an asynchron file stream library. I uses > ReadFileEx() and alertable wait with SleepEx(). > This doesn't work right with wine. It seems to get caught in an endless loop. > Wine and wineserver together use 100 % cpu power. This should work. The IO is currently not truly asynchronous, though - but with SleepEx() all should be fine. > Which debug switches wold be usefull to trace this? trace+file,trace+server Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Patch: winsock.h problem
Am Don, 2002-11-21 um 06.05 schrieb Dimitrie O. Paun: > #include > #include > > fails miserably in Wine (but apparently works in Windows) > In file included from /home/dimi/dev/wine/wine.src/include/windows.h:62, > from /home/dimi/dev/wine/wine.src/include/winsock.h:33, > from winnet.c:46: > /home/dimi/dev/wine/wine.src/include/winsock2.h:401: warning: type defaults to `int' >in declaration of `SOCKET' This is because of the "circular" include sequence winsock.h -> windows.h -> winsock2.h -> winsock.h where the last include doesn't "work" because _WINSOCKAPI_ is already set. The following patch fixes it. Martin Index: include/winsock.h === RCS file: /home/wine/wine/include/winsock.h,v retrieving revision 1.47 diff -u -r1.47 winsock.h --- include/winsock.h 30 Oct 2002 20:26:32 - 1.47 +++ include/winsock.h 21 Nov 2002 09:38:15 - @@ -26,14 +26,14 @@ # endif #endif -#ifndef _WINSOCKAPI_ -#define _WINSOCKAPI_ - #ifndef __WINE__ # include "windows.h" #else # include "windef.h" #endif + +#ifndef _WINSOCKAPI_ +#define _WINSOCKAPI_ /* * Setup phase
Re: msvcrt vs std incl
Am Die, 2002-11-19 um 15.59 schrieb Dimitrie O. Paun: > Nevertheless, they solve only part of the problem: > > [dimi@dimi wine]$ gcc -fshort-wchar -I /home/dimi/dev/wine/wine.src/include/msvcrt >-I /home/dimi/dev/wine/wine.src/include test.c > test.c: In function `main': > test.c:8: `wchar_t' undeclared (first use in this function) > test.c:8: (Each undeclared identifier is reported only once > test.c:8: for each function it appears in.) > > This shouldn't have, should it? s/wchar_t/WCHAR/g The winemaker-generated build line would look somthing like gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I/home/martin/exp/include/wine/msvcrt -I. -I/home/martin/exp/include/wine test.c Using this line and WCHAR instead of wchar_t, I'm fine. It prints "sizeof (WCHAR) = 2". Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
RE: Configure question
Am Die, 2002-11-19 um 15.17 schrieb Patrik Stridvall: > One thing that you shouldn't assume is for example that > if a function exists its reentrant variant exists as well. Sure, got that. > And yes, you really should use the > reentrent variant if present as well as having an > alternative implementation if not. Hmm - really really always? This generates messy code, and a lot of effort for very rare cases. I think we need a compromise, something in the line of either - a) use non-reentrant functions, protecting them with a critical section (IMO ok for rarely called functions) or - b) use only reentrant and treat the case where these aren't available like the case where the respective functions aren't available at all. Of course b) would only be viable if a sufficiently large portion of systems that support the non-reentrant variant support the reentrant one as well. I have no idea whether that's the case for the getpwXYZ functions. > As to the implict existance question: I'm not sure. > First of all, to answer the related question: > Should you have a alternative implementation for > defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)? > > IMHO the answer is no. It is not worth the effort to > support hypotetical platforms unless we can verify the > existance of one. Very true. Perhaps the practical way would be to assume HAVE_GETPWUID == HAVE_GETPWNAM and see whether someone with a really strange platform complains (but see below). > I suggest that we should detect the presence or absence > of ALL function we use that is verified not to exist on > some platform and have for example code like > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > defined(HAVE_GETPWENT) > # if (defined(HAVE_GETPWUID) + defined(HAVE_GETPWNAM) + > defined(HAVE_GETPWENT)) == 3 > # define __HAVE_GETPW > # else > # error All or none of the functions getpwuid, getpwnam and getpwent are > assumed to exist > # endif > #endif > > in order to formalize the assumptions and generate a common define to use in > the code. Well I'd say that for a start we could simply do something like /* CAUTION: If there turns out to be some insane platform that has * getpwuid() but not getpwnam() and getpwent(), this must be * improved. */ #define __HAVE_GETPW HAVE_GETPWUID This would keep bloat out of configure in the first place, while providing a generic __HAVE_GETPW macro for possible later use. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Configure question
> Maybe you should at least check for "grp.h" and getgrent etc in a > separate check, > since they are in a separate header file ... although "pwd.h" might > imply the > existence of "grp.h", it could make errors if it didn't harder to work > out if there > wasn't a separate configure check. Yeah, I figured that, too. Thanks, Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Question: domain name
Using a default domain name in Wine would be beneficial for certain Netapi functions. While it's no big deal to add a config option for that, there is the Windows registry value DefaultDomainName in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon which could be used for exactly that purpose. Is it better to - use a Wine config key, - use the above MS key, - or use both, the Wine key overriding the MS one if set? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Configure question
I am thinking about some netapi32 improvements where I'd need to call the functions of the getpw/getgr family: getpwnam(), getpwent(), getgrent(), etc. Configure checks for the "pwd.h" header and getpwuid(). Must I add more checks for all the functions I use, or is it ok to assume that getpwuid() presence implies getpwnam() presence? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: wine/ programs/rundll32/rundll32.c dlls/kernel ...
Am Fre, 2002-11-15 um 05.17 schrieb Alexandre Julliard:
> ChangeSet ID: 6302
> Modified files:
> programs/rundll32: rundll32.c
> dlls/kernel: computername.c
>
> Log message:
> Warning fixes.
Your compiler seems to issue more warnings than mine :-/
It is good to see these patches are really reviewed. The lenW thingy
is really embarrassing for me.
Two questions/remarks:
@@ -426,12 +426,13 @@
memcpy( name, buf, len );
name[len] = 0;
*size = len;
+ret = TRUE;
This shouldn't be necessary because the whole block is executed only
if ret == TRUE.
}
}
__EXCEPT(page_fault)
{
SetLastError( ERROR_INVALID_PARAMETER );
-ret = FALSE;
+return FALSE;
}
__ENDTRY
What is the point of this one? (applies also to the last hunk)
Martin
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: ComputerName, take 2
Am Mit, 2002-11-13 um 02.27 schrieb Alexandre Julliard: > This bit is going to break the default keys, it will make them stored > into the user registry files. > I'd suggest moving the computer name stuff out of allocate_default_keys() OK - this leaves only a single key that is actually allocated in allocate_default_keys - namely, "Dyndata\Perfstats\Statdata". Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Some dead links on winehq
A small contribution to the winehq fixes: A list of dead or non-functional links on the Development/References page. (http://www.winehq.com/development/index.php?refs) Wine Wine API - mostly useless, IMHO (is this really up-to-date? - at least it shouldn't be on top of the page). Vintage wine sources - ftpsearch.ntnu.no unfortunately out of service. Win32 Win32 API intro - dead WinDoc - only the "Local Mirror" works, the "at microsoft.com" links bring you to the main MSDN site. Unix Unix98 - needs registration LinuxThreads - why is this linked here? AFAIK not used by wine anyway. X The motif zone - dead lamentation - dead Fonts Internet Font archive - gone. X11R6 fonts - dead t1lib -dead Curvesoft - have ceased operations, a few tools still available. x86 Assembly Intel Documentation - dead Writings on software development Homesteading the Noosphere - dead Lisp... - I don't know why it's there, but I love it :-) The Open Source-revolution - dead Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: docbook (was: Re: ComputerName)
Am Mit, 2002-11-06 um 22.11 schrieb Alexandre Julliard: > Well, I personally have no love for SGML, and I think the man pages > are just fine in troff. If you don't like SGML, why is it the docs are SGML ? If we'd convert those few man pages, we'd have more flexibility (ability to combine docs & manpages in a single format) and less danger of the docs & man pages becoming inconsistent, it'd be easy to have a "wine man pages" section in the WWW docs, etc. Not that I really care a lot though. I can edit troff if it's necessary. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
docbook (was: Re: ComputerName)
Am Mit, 2002-11-06 um 18.19 schrieb Dimitrie O. Paun: > I had a similar reaction (never touched troff before), but you're > better off than trying to install the docbook tools :) > I guess that nobody did it (you have to set up the .sgml -> troff > conversion as well). That's a no-brainer, really, since docbook tools need to be present anyway. "docbook2man" is the tool of choice. All recent Linux distributions come with docbook. The converted man pages could be part of CVS (as some other autogenerated files are) so that users wouldn't be required to have docbook in order to generate the manual pages. The benefit would be that the man pages would be ready for PS/PDF/HTML conversion, and could go into e.g. an appendix of the wine docs. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: ComputerName
Am Mit, 2002-11-06 um 16.43 schrieb Dimitrie O. Paun: > Can you also please update the documentation as well (man pages, etc.)? Ok. Btw is there any specific reason why the man pages have not been converted to Docbook yet? I really dislike hand-editing troff. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: ComputerName
Am Mit, 2002-11-06 um 16.54 schrieb Dmitry Timoshkov: > Shouldn't be sizeof(special) above divided by sizeof(WCHAR)? Good catch, thanks. Martin
Re: RFC: rpcss skeleton prototype #2
Am Die, 2002-11-05 um 21.51 schrieb Francois Gouget: >> Are these "simple changes" documented anywhere ? > Nope. > Winebuild is a bit of a mystery for everyone. The trick is to look at > how Wine's Makefiles do things and do the same :-) I was guessing so :-/ Perhaps I'll give it a try. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: GetComputerName() question
Oops - just stumbled into this one: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/computer_names.asp On Win2k and later DNS name and Netbios name are linked "by convention". That is, having them separate is discouraged, but not impossible. I wonder what we should do about that. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: rpcss skeleton prototype #2
Am Die, 2002-11-05 um 13.43 schrieb Ove Kaaven: > Hmm, that may not be necessary. If Samba provides a RPC registration > service then we wouldn't need another DCE RPC daemon like freedce's, we > could just use Samba as our registration service (and if uses the port but > doesn't have that feature yet, someone might be able to convince them to > add it). Good luck! From what I learned in my latest Samba inquiry, they have other things to worry about. In any case you must make sure this is all properly separated, for GPL license issues. > It'd probably be worth looking into when the time comes. I recommend approaching the Samba guys early so that they know this functionality is desired. Whoever wants to implement this must be prepared to dig into Samba hacking. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: rpcss skeleton prototype #2
Am Mon, 2002-11-04 um 23.45 schrieb Francois Gouget: > Any volunteer for making the necessary (simple) changes to winemaker? Are these "simple changes" documented anywhere ? Winebuild is a miracle to me, and I guess to many others too, even people who have contributed substantial amounts of code. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: So lets say we do it
Am Fre, 2002-11-01 um 00.09 schrieb Dimitrie O. Paun: > -- the big "Navigation" box is wasted space, because > 1. It contains items everybody expects as a left-hand menu > 2. Contains no real content > -- while pretty, the layout is a non-standard, and is a wee bit > too far away from the "least surprise" principle > -- the news/announcements need a bit more space I disagree. Although there may be room to improvement, I see no point in making winehq conform to that "standard". There are already way too many web sites looking all the same. Winehq has a top navigation bar, and that's perfectly fine to my taste. >You need only *one* click. In our site, you need 3-4 clicks, >scrolling, etc. Vast majority of people don't have such a long >attention span. Sorry, people who consider 4 mouseclicks too many will not have the patience to setup wine, not even after your 0.8 release. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: GetComputerName() question
> This works for GetComputerName(), but not for apps that look directly > in the registry. This is why we need to put something in there. Yes, but only if there is nothing in there yet. I am not against setting this registry value and I see why it's set. I was just saying that this init stuff makes me nervous when thinking about improving the function - obviously the "normal" registry functions aren't yet available. What I'd propose for init time is - check the availability of the ComputerName entry in the registry, - if not there, set it directly from gethostname() Then I'd implement proper ComputerNameEx(), ComputerName() in Kernel32 with all options, and remove it from the init code. > Do you really need a NetBIOS name different from the hostname? I do not strictly need it. But without doubt the two name concepts are different. Users/administrators may need it. I like the idea that administrators can have consistent settings between Samba and Wine (btw I thought about parsing smb.conf for these entries to make additional registry editing superfluous, but this is a future issue). Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: GetComputerName() question
Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. I can't help myself - I think the current implementation in wine isn't correct, at least not as correct as it could be. http://www.jsifaq.com/SUBH/tip3900/rh3982.htm It wouldn't be hard to fix this, but the fact that this stuff happens during Wine initialization scares me off. That's why I want to know why this is done so early. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: GetComputerName() question
Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. You did not explain why this must happen at wine initializaiton time (why is this code in win32/init.c?). Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: GetComputerName() question
Am Mit, 2002-10-30 um 20.25 schrieb Alexandre Julliard: > Because users are not going to edit the registry if their Unix > hostname changes so it will always be wrong. Now if the problem is the > FQDN then it should be trivial to truncate it to just the hostname. Sorry, how many machines are out there that change their host name on a regular basis, so that the registry name would "always" be wrong ? The way Samba does this is IMO reasonable: "netbios name (G) - This sets the NetBIOS name by which a Samba server is known. By default it is the same as the first component of the host's DNS name." I'd propose: If the registry contains an explicit ComputerName entry, use it as Netbios name; otherwise, use the Unix hostname. This would affect only the users that enter a Netbios name in their registry, and thus not those with changing host names that you're worried about. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
GetComputerName() question
Why is GetComputerName() an init function, or in other words, why is it important that HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\ComputerName\\ComputerName be set at registry initialization time (in _allocate_default_keys())? I am asking because GetComputerName() IMO returns the wrong value (FQDN rather than NETBIOS name). A real implementation of GetComputerName() would look for the above value in the Registry and use gethostname() only as a fallback, but currently it's the other way around - why ? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RPC test code?
Am Mit, 2002-10-30 um 16.43 schrieb Greg Turner: > Actually, I was leaning towards the idea of having the test program > itself be both client and server... but AFAIK there is no > wine-compatible way to fork()..? Why don't you just use CreateThread()? I am doing this for the winsock tests and it works just fine. You can use thread-local storage to keep variables separate. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Versions & mass-appeal
> You need good > understanding of Windows system calls plus Linux coding experience - a > difficult combination to find. IMO one is enough to get started. Solid Linux experience + access to MSDN gives a you good start. I had no Windows programming experience whatsoever before I started working on wine's winsock. > I think that a lot of people will look at > the code, browse the web/bugzilla, be unable to find anything quick to > break into the fold and give up. There are such things, but most of them are of course boring. The "sexy" parts are hard to get started with. But that's no different than with other larger projects. > I personally think this is changing with CodeWeavers delivering > commercial products based on Wine. Yes, Codeweavers got brilliant reviews. Transgaming is also doing quite a good job. This may encourage users, but does it encourage developers? > What both you and James are referring to is making the process more > transparent. People need clear deliverables to be able to focus and > redirect their engergy towards something. With my newbie hat on, I can > say that we don't provide that. Unless you have been around for a > longish period of time, you have no real idea as to the state of affairs. What is most urgently needed IMHO is more up-to-date documentation. Wine is changing very rapidly and the docs, even on WineHQ itself, more often than not don't reflect the changes. And the most important part of the docs would be an easy-to-understand, up-to-date and in-depth tutorial of how to debug wine crashes, failures, etc. using different techniques (trace, winedbg, ..). I know there are docs on that but we must make sure that they are up-to-date. It has happened to myself that I ran into some wine problem, wanted to produce a meaningful bug report, and than gave up because the debugger wouldn't run as expected (or described in the docs I had). Setting up wine such that you can do meaningful debugging currently almost requires "wine guru" capabilities. The wine Wiki is great but there are far too many empty "New Item" entries. > 2. Making sure BugZilla is always updated anbd used in the right > fashion. If something gets done, close the bug and make a comment A problem is that many reporters don't know how to use it. (Report bug, receive request for more information, never answer back - this has happened to me with a bug reporter employed in a wine-related company!). The only way to deal with that is to close the bug if it happens. For such situations I'd appreciate clear guidelines for maintainers. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winsock + DSTRICT
Michael Stefaniuc wrote: > i'm not sure if the compiler will optimize away the assert > from __handle2socket on machines where sizeof(HANDLE) = > sizeof(SOCKET). gcc does optimize this away if the function is declared inline, checked that. The assert is used only when new sockets are allocated (i.e. only in socket() and accept() calls), it is certainly not performance-critical. Alexandre Julliard wrote: > The assert is useless anyway. Even if the types have different sizes > you'll need to allocate a billion handles to trigger it. If _you_ say that - I didn't feel bold enough to argue that way :-) > It's much > better to use a simple cast (without ULONG_PTR) so the compiler will > warn if the pointer and integer are different sizes. If you really want a compiler warning rather than a runtime error, OK. Perhaps someone could check if SOCKET is really a 32bit type on 64bit Windows. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
winsock + DSTRICT
Hi Michael, all,
here is a patch to make winsock compile without warnings without
-DWINE_NO_STRICT. Comments are welcome.
Martin
PS Michael, will you send this stuff to wine-patches?
Index: Makefile.in
===
RCS file: /home/wine/wine/dlls/winsock/Makefile.in,v
retrieving revision 1.18
diff -u -r1.18 Makefile.in
--- Makefile.in 18 Oct 2002 23:46:28 - 1.18
+++ Makefile.in 28 Oct 2002 15:02:23 -
@@ -1,4 +1,4 @@
-EXTRADEFS = -DUSE_WS_PREFIX -DWINE_NO_STRICT
+EXTRADEFS = -DUSE_WS_PREFIX
TOPSRCDIR = @top_srcdir@
TOPOBJDIR = ../..
SRCDIR= @srcdir@
Index: async.c
===
RCS file: /home/wine/wine/dlls/winsock/async.c,v
retrieving revision 1.27
diff -u -r1.27 async.c
--- async.c 17 Oct 2002 16:43:43 - 1.27
+++ async.c 28 Oct 2002 15:02:24 -
@@ -136,6 +136,10 @@
#define AQ_GETSERV 2
#define AQ_GETMASK 3
+/* The handles used are pseudo-handles that can be simply casted. */
+/* 16-bit values are used internally (to be sure handle comparison works right in
+16-bit apps). */
+#define WSA_H32(h16) ((HANDLE)(ULONG_PTR)(h16))
+
/* --- helper functions - */
static int list_size(char** l, int item_size)
@@ -335,7 +339,7 @@
return size;
}
-static HANDLE __ws_async_handle = 0xdead;
+static HANDLE16 __ws_async_handle = 0xdead;
/* Generic async query struct. we use symbolic names for the different queries
* for readability.
@@ -486,7 +490,7 @@
}
break;
}
- PostMessageA(HWND_32(aq->hWnd),aq->uMsg,aq->async_handle,size|(fail<<16));
+ PostMessageA(HWND_32(aq->hWnd),aq->uMsg,(WPARAM)
+aq->async_handle,size|(fail<<16));
HeapFree(GetProcessHeap(),0,arg);
return 0;
}
@@ -547,7 +551,8 @@
aq->ptr1= ptr1;
aq->int2= int2;
aq->ptr2= ptr2;
- aq->async_handle = ++__ws_async_handle;
+ /* avoid async_handle = 0 */
+ aq->async_handle = (++__ws_async_handle ? __ws_async_handle :
+++__ws_async_handle);
aq->flags = flags;
aq->sbuf= (SEGPTR)sbuf;
aq->sbuflen = sbuflen;
@@ -579,10 +584,10 @@
HANDLE WINAPI WSAAsyncGetHostByAddr(HWND hWnd, UINT uMsg, LPCSTR addr,
INT len, INT type, LPSTR sbuf, INT buflen)
{
- TRACE("hwnd %04x, msg %04x, addr %08x[%i]\n",
+ TRACE("hwnd %p, msg %04x, addr %08x[%i]\n",
hWnd, uMsg, (unsigned)addr , len );
- return __WSAsyncDBQuery(hWnd,uMsg,len,addr,type,NULL,sbuf,buflen,
- AQ_NUMBER|AQ_COPYPTR1|AQ_WIN32|AQ_GETHOST);
+ return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,len,addr,type,NULL,sbuf,buflen,
+ AQ_NUMBER|AQ_COPYPTR1|AQ_WIN32|AQ_GETHOST));
}
/***
@@ -604,10 +609,10 @@
HANDLE WINAPI WSAAsyncGetHostByName(HWND hWnd, UINT uMsg, LPCSTR name,
LPSTR sbuf, INT buflen)
{
- TRACE("hwnd %04x, msg %08x, host %s, buffer %i\n",
+ TRACE("hwnd %p, msg %08x, host %s, buffer %i\n",
hWnd, uMsg, (name)?name:"", (int)buflen );
- return __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen,
- AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETHOST);
+ return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen,
+ AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETHOST));
}
/***
@@ -629,10 +634,10 @@
HANDLE WINAPI WSAAsyncGetProtoByName(HWND hWnd, UINT uMsg, LPCSTR name,
LPSTR sbuf, INT buflen)
{
- TRACE("hwnd %04x, msg %08x, protocol %s\n",
+ TRACE("hwnd %p, msg %08x, protocol %s\n",
hWnd, uMsg, (name)?name:"" );
- return __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen,
- AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETPROTO);
+ return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,0,name,0,NULL,sbuf,buflen,
+ AQ_NAME|AQ_DUPLOWPTR1|AQ_WIN32|AQ_GETPROTO));
}
@@ -654,9 +659,9 @@
HANDLE WINAPI WSAAsyncGetProtoByNumber(HWND hWnd, UINT uMsg, INT number,
LPSTR sbuf, INT buflen)
{
- TRACE("hwnd %04x, msg %04x, num %i\n", hWnd, uMsg, number );
- return __WSAsyncDBQuery(hWnd,uMsg,number,NULL,0,NULL,sbuf,buflen,
- AQ_GETPROTO|AQ_NUMBER|AQ_WIN32);
+ TRACE("hwnd %p, msg %04x, num %i\n", hWnd, uMsg, number );
+ return WSA_H32( __WSAsyncDBQuery(hWnd,uMsg,number,NULL,0,NULL,sbuf,buflen,
+ AQ_GETPROTO|AQ_NUMBER|AQ_WIN32));
}
/***
@@ -678,10
Re: Services
Am Don, 2002-10-24 um 19.30 schrieb Alexandre Julliard: > I think that if an application really requires extensive compatibility > with the Windows security mechanism, then it may not be a good idea to > run it under Unix at all, since it probably won't do what you want > anyway. So what are the real world cases that require these kinds of > things? I have a real-world example for an application needing the service API and the logevent API. No user-account switching and "extensive compatibility with the Windows security mechanism" is required. It could very well be run in a special account, and doing that would IMO not raise substantial security issues. All that's needed is a working service implementation in the sense that services can be registered which wine would start automatically when it's launched. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Services
Am Don, 2002-10-24 um 17.08 schrieb Dustin Navea: > I was actually thinking more from a read the file > standpoint, i.e if in the future wine runs as a > service with its own account, would wine be able to > read the file after someone changed the file's owner > from wine to, say user speeddy, or would it just say > access denied and not let you read the file, therefore > making you have to redo the permissions or make it > owned by wine again. In the near future this would depend on whether wine's account has (group or world) rights on speedy's word file. Actually in the near future the user is far more likely to start a separate instance of wine in his own account for editing his word files. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Services
Am Don, 2002-10-24 um 15.43 schrieb Dustin Navea: > Another potential problem popped into my head though, > and that is: > > what if someone edits the initscript to where wine > runs as root (or someone compromises the server and > does it), If the system is already compromised it is too late anyway. Some intruder who can change init scripts already has root rights and probably wouldn't bother with wine. If sysadmin himself changes the init script to run wine as root it is his own fault (he could as well have their apache or bind run as root, also a bad idea for both). > or what if someone just changes the > owner/group on the file (like a word doc), and then > tries to run it with wine, what happens then? Unless wine has some suid capabilities (which it shouldn't) this has no impact - wine runs in the account of the user who opens the file (runs word). Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Services
Dear Shachar, Thanks for this clean and convincing model. > As for printer drivers, and services at large - there is a major > question here of whether we wish Wine services to be able to server > non-wine processes. If the answer is "yes", as is probably the case with > an Adobe PDF printer driver, or with a winmodem's driver, root must > install them. You mean Administrator here, right? I still think Administrator != root. If e.g. CUPS passes PDF data to a wine printer driver acting as a filter, I don't see why this filter would need to run as root. The winmodem is different because it requires hardware access. > If the answer is "no", then there is no breaking of the model. With the > directory structure as defined today, each user can install it, claiming > full admin rights over the loca directory structure. Of course, the new > adobe's printer driver only serves his programs. Yes, both approaches can actually coexist on the same machine. Great! Now someone just needs to start implementing security handling in Wine... Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Services
This thread has immediately jumped to the future-development discussion :-) In the first place, I simply wanted to know what the current rudimentary "service" implementation (which simply calls CreateProcess) is good for, and whether anybody knows about Windows or Winelib programs running on Wine that actually use this API. I think this simple approach could take us quite far without even thinking about changing user accounts, acquiring extra Unix capabilities, etc. > A system administrator already could do this. Anyhow there's really no need > to bring sudo into the picture. If a sysadmin is crazy enough to want to run > a wine "service" as root, Wine shouldn't run as root. I don't see strong arguments against running a wine service in a dedicated non-root Unix user account, though. > they could just invoke their executable from an > init script; that's more "service" like anyhow. That has nothing to do with the Windows service API and won't help you a bit trying to port a Windows app that uses that API. > OTOH, I guess sudo could be used like this: if we are going to go the > route of "being uncompromisingly unixey" then the services API should > just manipulate init scripts. IMO a bad idea, this comes down to real root access for wine. I'd rather install a single init script starting a daemon that - changes uid/gid to a dedicated unix account with non-root privileges, - (perhaps) does a chroot(), - starts wine. The wine process would then start all registered Windows services in his environment. An "autostart" service would mean that the process is started when the first wine process starts. To stop the services, we'd need a "shutdown" application of some sort. Obviously this would require wineserver calls, no idea if a server protocol extension would be necessary. Controlling these services would require a su(1) to the service account and starting a windows service-control executable. > This way, a user could "be administrator" within wine, but not be root > on their unix box. If you think about it, this is exactly the situation that we have now, and it's not so bad after all. No restrictions in the Win environment, but normal user privileges from the Unix perspective. > And if the user creates a symlink, all hell breaks loose because > fake_windows becomes a mix of files owned by root and files owned by the > user. I could concoct tons of similar examples. But I'll spare you the bandwidth. This could be solved by a system-wide wine installation with its own security handling. All installed files would (in the Unix sense) belong to the user the wine process is running as. For very good reasons that user shouldn't be root. > Once we start getting more sophisticated > about W32 security (and it seems to me, based on recent discussion, that this > time is coming sooner than later), it's going to be inappropriate to continue > with this approach, because we don't want to encourage users to do wine > stuff as root. I can't follow you here - **wine must not be run as root**, and we can't do anything but repeat that over and over again, whether or not we implement services and/or security management in wine. In any case, if a future wine did its own security management, the users and groups must still map to Unix users and groups - if not, how would such a future wine determine the access rights of a Unix file that only shows Unix user/group permissions? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
What I need (was Re: Using winbind with Wine)
First of all thanks everybody for the feedback. It seems that Wine/Samba integration will not be a solution for general Wine RPC, at least not in the short term. However I have determined the functionality I need and I think most of it can be implemented on top of existing winbind functionality as I originally intended. These are the functions I need: LogonUser(ADVAPI32) - can be done through pam_winbind to authenticate against PDC NetGroupGetUsers- Can be implemented with nss_winbind's getgrent() NetGroupGetInfo - Also getgrent() (?) NetLocalGroupGetMembers - Hmm - I don't think Windows' local/global group distinction makes sense on Unix - windbind looks for global groups, I suppose? NetGetDCName- Get name of primary domain controller - seems to be the most difficult part. Could be solved by simply looking it up in the Samba config file. This approach means that the respective functions are not really carried out as Windows RPCs - for example the "servername" argument to these functions will be ignored because I cannot tell winbind on which server to execute its RPC. Even if wine had a fully-fledged RPC implementation I doubt that would be reasonable to implement these functions on top of that, because groups and users really need to be mapped to their Unix equivalents. Comments welcome! Martin Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Marshalling code for me to use?
Am Die, 2002-10-22 um 21.43 schrieb Ove Kaaven: > Samba is GPL, is it not? Also, it has been my impression that Samba-TNG > was moving towards using freedce anyway, though I haven't looked at any of > their code (probably since the license would make it useless anyway). Studying their code can't hurt. And the IDL compiler would be usable, regardless whether it's GPL or not. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Services
I have had a look at dlls/advapi/services.c and found that it is pretty incomplete. Can anybody tell what the current implementation is used for (are there any known programs starting services?) In particular I'd like to know what people generally think about the usefulness of Services in Wine. The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless. However it may be desirable to translate services into something useful on Unix, especially for winelib (it would be useful for the app I am trying to port). Has there been a discussion yet how to set this up without compromising system security? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Marshalling code for me to use?
Am Die, 2002-10-22 um 13.46 schrieb Ove Kaaven: > > I found te freedce project at sourceforge. Maybe rpc could borrow (ndr-)code there? > > I borrowed the UuidHash algorithm from freedce. I don't think we can > borrow a lot since the way rpcrt4 does ndr internally is part of the > exported API, but it can be used as a reference implementation (and maybe > a source of .idl files?) What about Samba-TNG (www.dcerpc.org, www.samba-tng.org)and the sidlc compiler that is part of it? (Forgive me if that's a stupid suggestion) Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
LogonUser(), netapi work
Hi, after having been busy with other stuff for a while, I'd like to inquire the status of my LogonUser() patch (http://www.winehq.com/hypermail/wine-devel/2002/09/0448.html) I have had almost no feedback, positive or negative, on this, and it wasn't applied either. I still think it could be useful, although it is clear that wine won't (shouldn't) be able to change personality in the foreseeable future. Andriy, what is the status of your netapi work? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:Martin.Wilck@;Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Error message
Am Mon, 2002-10-14 um 06.58 schrieb Dima: > In debug level 2 it says: > > sock_init: shutdown() causes POLLHUP > > Anyone know what this can be? This is only informational. I am 99% certain it has nothing to do with the error wine is bailing out with. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Load .so error
Am Don, 2002-10-10 um 09.16 schrieb Fabian Cenedese: > > > new PC. The Windows dll was MyDll.dll which I turned now into a .so. > > > ELF_LoadLibraryExA is looking for a libMyDll.so but returns with > > > error=2. Rename your library to libmydll.so (all lower case) and try again. Wine will not load any Winelib library containing any non-lower-case character. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: is winemaker working?
Am Mit, 2002-10-02 um 02.58 schrieb Michael Cardenas: > So, is anyone using winemaker? Has anyone used it to make a simple > winelib app recently? Does it still work? There seem to have been a > lot of changes to the spec file format recently, which have probably > rendered it unusable. Yes, I am using it quite extensively. Winemaker indeed used to be broken. There have been a number of patches by different people during the last month that should have fixed most of these issues. E.g. winemaker used to generate mixed-case project names which wouldn't be found by wine after installation. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Wine and Sambe (was: Re: RFC: Wine and PAM integration)
Am Don, 2002-09-26 um 00.01 schrieb Steve Langasek: > And if we say "strings use the current locale > encoding", then anyone who needs to handle large chunks of Unicode from > within Wine needs to be using a UTF-8 locale. Forgive me, I'm pretty dumb when it comes to character sets. If I understand you right, UTF-8 will pass intact through a non-character-set-aware communication layer (i.e. one that handles strings with standard C library functions such as strlen()). > I happen to think that the suggestion tendered in this thread to give Wine > suid capabilities is a much more serious case of "working around Unix > security mechanisms" than not requiring Windows apps to use Unix > authentication APIs would be. I agree. Wine itself shouln't be able to change uid. Even if Wine implemented a perfect authorization mechanism for the respective wine "system calls", someone could build a winelib DLL with direct setuid() calls that would succeed if the Wine process loading the DLL had the SUID capability. Sounds evil. > If Windows applications really need to be > able to change security contexts, they should gain this privilege the same > way as everything else: either you start the application as root, or you That's not much better than having Wine suid root in the first place :) > set the Windows binary itself suid root and you make sure the Linux kernel > has the necessary hooks to confirm this when the application starts > (binfmt_misc support should already imply this). Most processes will be started from within wine by opening the file and jumping to its entry point - suid bits on the files won't help a lot in that context, unless wine is able to change personality. Imagine some server that requires a user to log in and carries out something on that user's behalf, with his credentials. Honestly, I have no idea how something like that could be achieved without severely compromising system security. Perhaps it would be possible to design a small, easy-to-audit helper tool that would be started by wine in such a case to check the credentials again and start a new wine process; something in the spirit of sudo. In any case, IMO wine should rather not support this at all than compromise the host system. > In contrast, the dcerpc.org developers have been hard > at work for a couple of years now implementing stand-alone daemons for > many of the RPC services Wine would use -- lsarpc, winreg, and spoolss > among them. Thanks, I'll have a look into that. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Using winbind with Wine
Am Mit, 2002-09-25 um 19.38 schrieb Richard Sharpe: > I do not think that libsmbclient is the right way to do this. I think that > the correct way is to make the various Samba client RPC libaries available > as separate DSOs so that clients can make dirrect use of what they need. > Then the wine group can possibly build a thing DLL wrapper around the > underlying RPC libraries. Licensing is an important issue. I future Samba RPC libraries come with GPL, they won't be usable for Wine (as you probably know, Wine is LGPL and ReWind X11). I don't want to start a licensing debate here. I expect the Samba team to release their stuff GPL'd in the future, thus I accept is as a fact that Wine cannot be linked to Samba libraries, present or future. For that reason I find the winbind concept of socket communication attractive. To my understanding this would not raise license issues. We are not currently worried about performance, we just need access to a few RPC calls. To initiate this process we'd "only" need a standardized protocol for the socket communication. Andrew said that doesn't exist and won't with regard to winbind. I'd like to focus the discussion in this direction. - is the winbind team willing to standardize the protocol, or at least ensure backward compatibility in future versions? - is the winbind team willing to add more RPC calls to the interface? If not, Wine might do best by creating a "winebind" that meets these requirements. That might be the best way after all, because incorporating the functionality needed by Windows clients into winbind would make no sense in environments where Wine is not running, just increase winbind's size unnecessarily. "winebind" would be linked against Samba libraries, and therefore be GPL from the start. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [Controversial] Developper only CVS sandbox
Am Mit, 2002-09-25 um 23.35 schrieb Lionel Ulmer: > That would be the best... But well, I never heard much good about CVS's > prowess in handling branching (with all the mess like handling properly > conflicts, precise branch management, ...). I have never understood why people keep saying CVS can't do this. After all, CVS was made for exactly that. It is easy to setup branches and sub-branches, merge, etc., with CVS. Every VC system is in trouble when merging branches that have diverged for a long time and expose a lot of conflicts, until someone comes up with an AI that understands what the different developers actually meant. In this respect, CVS is exactly as smart as diff3. Some systems may be better than CVS at this, admitted. But as long as there are only a few branches and people keep their stuff more or less in sync with main, I think it'd be fine - especially for people working on relatively separate subtrees like D3D8. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [Controversial] Developper only CVS sandbox
Am Mit, 2002-09-25 um 23.28 schrieb Lionel Ulmer: > Well, the problem is that I am spoiled by using ClearCase at work (it's > pretty slow sometimes, but well, it's really powerful to manage parallel > developments, something that would be equivalent to what I propose here). Here you have a good one for a flame (though really OT here, ought to go to alt.version-control.advocacy :-). I am also forced to use CC and I openly confess I hate it more than my alarm clock. IMHO all the really productive features of CC are available with CVS as well, and the rest is excruciatingly slow bloat. OK, everyone should be happy with their favorite VC system. I just couldn't resist to respond to that statement :-) Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: winemaker (WAS Where is the specfile documented nowadays?)
Am Mit, 2002-09-25 um 20.57 schrieb Bill Medland: > > OK. Here is where I have a slight problem. (I am quite prepared to accept > that it may be because I am not thinking, I am missing or I am just an > idiot). You are moving in realms that I've not yet dared enter :) > But winemaker seems to be setting things up so that it will create > /usr/local/lib/libshfile.dll.so. This is because winemaker was designed to create winelib DLL replacements. I guess linking lib/wine/shfile.dll.so to lib/libshfile.so might do the job - right? Perhaps you also need to create an empty shfile.dll in your Windows\System directory, but now I am demonstrating that I'm ignorant. Perhaps winemaker should be fixed such that both lib/wine/xyz.so and lib/libxyz.so are created. That'd be a fairly easy hack. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: ToDo's
Am Die, 2002-09-24 um 22.55 schrieb Steven Edwards: > - Better seperation of win16/32 code. > - remove/rewite win16/9x api dependancy on newer code > - remove/rewrite wineisms from code > - documentation fixes I may be missing something, but there's already enough on that list to keep all of us busy until the release of Windows ZXF 2016. Are there plans to go through a public voting to determine which of these we need to fix until 0.9/1.0 ? Don't get me wrong, no specific recjection against Steven's points, just a general question. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Using winbind with Wine
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett: > Firstly, it's good to see that winbind is starting to get some interest > :-) I have been ignoring it so far, but in the context of the current inquiries I tried it out and was impressed :-) > Secondly, don't fall into the trap squid (with my encouragement I might > add...) fell into - don't use the winbind pipe directly. The winbind > API is an internal Samba API, and can change without warning. Hmm - what other APIs are there? The only libraries that are accessible are nss_winbind and pam_winbind. Those two already carry us a long way, BUT ... I started thinking about other options when I found the "wbinfo -n" call. AFAIK there is no way to obtain equivalent info through PAM/NSS, simply because these APIs have no concept of a SID. Obviously apart from the SID there is a lot more information to gather from a PDC. I have not digged deeply enough into this to be able to enumerate everything, but think of the different GetUserInfo() calls on NT. libsmbclient can't be used by wine because it's GPL. And even if we could use it, it's headers only define calls related to shares and printing, which is not what I'm currently aiming at. > As to unicode, I > have designated one call as being in utf8, to cope with external > interaction, so it's possible things can happen here. What matters to wine is that if a call goes like this: Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC <-> Windows server, we must ensure that the Unicode string wine receives from the app reaches the server ungarbled. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: Where is the specfile documented nowadays?
Am Mit, 2002-09-25 um 01.48 schrieb Bill Medland: > (I guess we ought to do something about winemaker too; it still names things > as lib.so) Can you be more specific? I thought with my latest patches these issues with winemaker were settled. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Using winbind with Wine
Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Wine and Sambe (was: Re: RFC: Wine and PAM integration)
On Mon, 2002-09-23, 11.28, I wrote: > > It seems it is better to ingegrate Wine with each > > protocol individually - implement PAM-like > > architecture inside Wine, but this architecture will > > provide much more information to Wine. > > No, please - let's not reinvent the wheel! I have been thinking about this a bit further - perhaps I was wrong in the first place. There are two aspects I neglected: * NT security and NETAPI have a broader scope than PAM + NSS combined. * Unicode. What we discussed so far were user authentification and user/group/hostname lookups. Of course, this is only a small subset of the NETAPI interface. winbindd itself can do more, for example lookup a user SID on the remote server. Even more functionality would be available by linking directly against the Samba library libsmbclient.so, but we can't do that due to license issues. Perhaps we should think about an extended winbindd that would follow similar lines as the current Samba winbindd (talk to Unix Apps through a Unix domain socket), but offer even more functionality that isn't implemented in winbind because the information passed by such calls makes no sense to Unix applications. AFAICS, winbind does not expect applications to pass Unicode strings for user names, domain names, etc., either. Our winbindd replacement would need to be able to handle that, too; otherwise we wouldn't be able to pass Unicode strings from a Windows application to a Windows server without corruption. The winbindd replacement would need to be GPLd in order to link against Samba libraries. That way wine would be able to use the existing samba functionality. If we had such a daemon, we could to reconsider the PAM and NSS routes because these probably won't be Unicode aware for some time to come (correct me if I'm wrong). Of course, we might as well try to convince the Samba team to offer more functionality through winbindd itself, or submit patches for winbindd to them. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: Winsock todo's
Am Die, 2002-09-24 um 10.55 schrieb Martin Wilck: I forgot one: There are planse to convert the HANDLE type to void* throughout wine. http://bugs.winehq.com/long_list.cgi?buglist=90 If this happens, Winsock needs to be adapted, too. Under Windows, SOCKET is an int type and HANDLE is void*, nevertheless it is legal to pass SOCKETs to functions such as WriteFile() expecting HANDLERs. I am uncertain how to do The Right Thing (tm) for Winsock here. Martin - Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
RFC: Winsock todo's
This is a RFC for comments. I may currently be the "offical" winsock maintainer in wine, but I wrote only a very small part of the code. I invite everybody, especially the authors of the other parts of winsock, to comment on these opinions. On Son, 2002-09-22, 18.48 Thomas Wickline wrote: > Can you give me a update on winsock todo's ? > And any other todo that you are aware of .. I have received very few bug reports lately, so I guess the basic Winsock functionality is working. A few important patches went in after the latest CVS snapshot, though. In general, the Winsock implementation in wine has a few parts that look really hackish and would need substantial cleanup. IMO this applies to the async.c file in total, but maybe I am doing injustice to authors of that file. I just find the code is really hard to read. Things like the User-space callbacks in WSAAccept() are impossible to implement correctly because the Unix accept() system call doesn't support callbacks. I do not like the fact that some Winsock1 calls, in particular select(), use direct system calls instead of using related wine APIs, e.g. WaitforMultipleEvents(). Actually if you have sockets with overlapped IO this may cause havoc. Changing this seems to be an average-difficulty task, suitable for contributors with some insight into wine internals. I'd like to see this fixed before 1.0. There are quite a few stubs left in ws2_32.spec. Some of these can probably be implemented easily and would be good work for beginners or casual wine contributors looking for a simple task, e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl(). More unit tests need to be written, also a nice task for people interested in Winsock. Wine has no concept of the Winsock2 "provider" interface. All calls to these functions are either stubs or dummy functions, such as WSAEnumProtocols(). I had a patch for this, but never got it ready for prime-time. It is unrealistic to support a "real" provider interface, allowing (like Windows) to hook new protocol handlers in the network stack, but at least we should pass some realistic information to clients. Should be done for 1.0. There is no such thing as a QOS or socket group concept in wine either, but these seem to be rarely-used features -> post-1.0, if needed at all. Although I had a relevant part in implementing the asynchronous IO in winsock, I am not quite content with it because it is not really asynchronous. Alexandre is against using threads. On Linux at least, Ben LaHaise's asyncio can be expected to become part of the 2.6 kernel series, and if that happens the wine asynchronous IO functionality should be rewritten to use the asyncio API on systems that support it. (I still havent't figured out whether aio will support sockets, though). A non-winsock todo that comes to my mind is support for NT security concepts such as tokens. But that would be a big one and should probably also be postponed after 1.0 Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: Wine and PAM integration
Am Mon, 2002-09-23 um 17.08 schrieb Andriy Palamarchuk: > As I uderstand from your explanation we can use PAM > for authentication and standard Unix calls for other > user management needs, is this correct? I think so. Had no time for a proof-of-concept implementation yet. But if windbindd is configured, you can use standard Unix commands to get group/user info, like this: $ id 'synergy.dom\wilck' uid=10050(SYNERGY.DOM\wilck) gid=10005(SYNERGY.DOM\cc_user) Gruppen=10005(SYNERGY.DOM\cc_user) Note: this info comes from our PDC. If you do an 'ltrace' on the id(1) command, you see that it calls getpwnam(), getpwuid(), getgrent() and friends only. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: RFC: Wine and PAM integration
Am Fre, 2002-09-20 um 21.25 schrieb Andriy Palamarchuk:
> I played a couple of days with PAM (Pluggable
> Authentication Modules). I do not have big experience
> in this area and want to know your opinion about my
> ideas.
> *** PAM and Wine ***
>
> Integration with PAM allows Wine to provide
> authentication services for Windows applications
> through Windows API. PAM has modules for native Unix
> authentication, Samba, flat files, relational
> databases.
Did you have a look at the LogonUser() implementation I
submitted last week?
> Questions, problems:
>
> Do we have requirement for wineserver to work across
> user boundaries?
I think we'll ultimately have to, although that's certainly a
long-term-future project. wineserver and the ntdll would need to
have a concept of security tokens etc., and we would need to figure out
a way to e.g. change personality with CreateProcessAsUser() without
compromising underlying Unix security.
AFAICT, this would mean substantial additions to the core of wine, and
must be done very carefully. For CreateProcessAsUser(), for example,
wine would need to have the CAP_SETUID capability, although we certainly
don't want to run wine with root privileges.
> If no, then we probably don't need PAM service for
> Wine itself.
> As you see Wine won't know anything about NT domains.
> I was thinking about passing service name through
> domain name parameter.
I strongly disagree.
I think the domain should be the domain, and nothing else.
This is the approach in my LogonUser() implementation
("user", "domain") -> "domain\user", and do Samba authentication
with that user name.
This is also the syntax you use when authorizing yourself
with smbclient or smbmount in large NT networks with several domains.
The beautiful aspect of this is that the pam_winbind module
authenticates against a Windows PDC for you, which is what the Windows
application expects.
> Call LogonUser accepts lpszDomain parameter. Instead
> of the domain name DOMAIN1 user provides to the
> application PAM service name SERVICE1.
> PAM service SERVICE1 is configured to use Samba module
> for authentication in NT domain DOMAIN1.
I think it would be more reasonable to put a "pam servicename"
entry into the registry for each application that uses authentification.
If there is none, we'd use the standard "wine" service, and if that
doesn't exist either, PAM would automatically use "other" which is
usually very restricted.
> PAM provides authorization and nothing else. To get
> more information from the authorization provider you
> should access it directly. E.g. with PAM only it is
> impossible to get list of users, groups from Windows
> NT domain, which user belongs to which group. Even
> more, it is impossible to know that some PAM service
> underneath uses NT domain and name of this domain.
But you can do these things with nss switch.
With windbind properly configured, getpwnam() and friends
will work with the PDC through winbind.
The whole picture looks like this:
For authentification, account and session setup:
wine -> PAM -> pam_winbind -> winbindd -> PDC
For user/group info:
wine -> NSS switch -> nss_winbind -> winbindd -> PDC
> I can't imagine how to implement with PAM scenario
> like this - Windows application gets list of users
> belonging to some group, presents it to the user, then
> does authentication for one of user names.
> On other hand it is possible to do that with Samba.
PAM must use samba, that's the point.
The main reason to use PAM is that wine should not (I am positive about
that) work around the "native" Unix authorization mechanisms that PAM
provides.
> It seems it is better to ingegrate Wine with each
> protocol individually - implement PAM-like
> architecture inside Wine, but this architecture will
> provide much more information to Wine.
No, please - let's not reinvent the wheel!
> The downside - this is much more complex approach than
> PAM.
Exactly.
I think what causes confusion is that PAM only covers part of what
belongs into "security management" in NT. It's main functionality is
to provide a transparent authentication mechanism.
However, it does this job very well, and it can easily be complemented
by other components (see above) to do the rest.
Martin
--
Martin WilckPhone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
An attempt at LogonUser()
support)
+ * lpPasswordW : (IN) Cleartext password
+ * dwLogonType : (IN) logon type, IGNORED
+ * dwLogonProvider : (IN) login provider, IGNORED
+ * phToken : (OUT) handle to user token, IGNORED
+ *
+ * RETURNS
+ * TRUE on success.
+ */
+BOOL WINAPI LogonUserW( LPWSTR lpUserNameW, LPWSTR lpDomainW, LPWSTR lpPasswordW,
+DWORD dwLogonType, DWORD dwLogonProvider, LPHANDLE phToken )
+{
+#if ! HAVE_PAM
+ERR( "stub - wine needs to be compiled against PAM library\n" );
+SetLastError ( ERROR_NOT_SUPPORTED );
+return FALSE;
+#else
+int ulen = 0, dlen = 0, plen = 0, ret;
+LPSTR buf = NULL;
+LPSTR lpUserName, lpPassword, lpDomain;
+
+if ( !lpUserNameW || !lpPasswordW || !phToken )
+{
+SetLastError ( ERROR_INVALID_PARAMETER );
+return FALSE;
+}
+
+ulen = WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, NULL, 0, NULL, NULL );
+plen = WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, NULL, 0, NULL, NULL );
+if ( lpDomainW )
+dlen = WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, NULL, 0, NULL, NULL );
+
+buf = malloc ( ulen + plen + dlen );
+if ( !buf )
+{
+SetLastError ( ERROR_NOT_ENOUGH_MEMORY );
+return FALSE;
+}
+
+lpUserName = buf;
+WideCharToMultiByte( CP_ACP, 0, lpUserNameW, -1, lpUserName, ulen, NULL, NULL );
+
+lpPassword = buf + ulen;
+WideCharToMultiByte( CP_ACP, 0, lpPasswordW, -1, lpPassword, plen, NULL, NULL );
+
+if ( lpDomainW )
+{
+lpDomain = lpPassword + plen;
+WideCharToMultiByte( CP_ACP, 0, lpDomainW, -1, lpDomain, dlen, NULL, NULL );
+}
+else lpDomain = NULL;
+
+ret = LogonUserA( lpUserName, lpDomain, lpPassword,
+ dwLogonType, dwLogonProvider, phToken );
+
+memset ( buf, 0, ulen + plen + dlen );
+free ( buf );
+return ret;
+
+#endif /* HAVE_PAM */
}
Index: dlls/advapi32/advapi32.spec
===
RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v
retrieving revision 1.28
diff -u -r1.28 advapi32.spec
--- dlls/advapi32/advapi32.spec 6 Sep 2002 19:36:37 - 1.28
+++ dlls/advapi32/advapi32.spec 18 Sep 2002 19:00:29 -
@@ -1,3 +1,5 @@
+init advapi32_init
+
@ stdcall AbortSystemShutdownA(ptr) AbortSystemShutdownA
@ stdcall AbortSystemShutdownW(ptr) AbortSystemShutdownW
@ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) AccessCheck
@@ -127,8 +129,8 @@
@ stdcall IsValidSecurityDescriptor(ptr) IsValidSecurityDescriptor
@ stdcall IsValidSid(ptr) IsValidSid
@ stub LockServiceDatabase
-@ stub LogonUserA
-@ stub LogonUserW
+@ stdcall LogonUserA(ptr ptr ptr long long ptr) LogonUserA
+@ stdcall LogonUserW(ptr ptr ptr long long ptr) LogonUserW
@ stdcall LookupAccountNameA(str str ptr ptr ptr ptr ptr) LookupAccountNameA
@ stub LookupAccountNameW
@ stdcall LookupAccountSidA(ptr ptr ptr ptr ptr ptr ptr) LookupAccountSidA
Index: include/config.h.in
===
RCS file: /home/wine/wine/include/config.h.in,v
retrieving revision 1.129
diff -u -r1.129 config.h.in
--- include/config.h.in 29 Aug 2002 01:51:32 - 1.129
+++ include/config.h.in 18 Sep 2002 19:00:33 -
@@ -320,6 +320,9 @@
/* Define if you have NAS including devel headers */
#undef HAVE_NAS
+/* Define if you have PAM including devel headers */
+#undef HAVE_PAM
+
/* Define to 1 if you have the header file. */
#undef HAVE_NCURSES_H
Index: include/winbase.h
===
RCS file: /home/wine/wine/include/winbase.h,v
retrieving revision 1.158
diff -u -r1.158 winbase.h
--- include/winbase.h 17 Sep 2002 18:54:42 - 1.158
+++ include/winbase.h 18 Sep 2002 19:00:33 -
@@ -1123,6 +1123,16 @@
#define SCS_POSIX_BINARY4
#define SCS_OS216_BINARY5
+/* LOGON support APIs */
+#define LOGON32_LOGON_INTERACTIVE 2
+#define LOGON32_LOGON_NETWORK 3
+#define LOGON32_LOGON_BATCH 4
+#define LOGON32_LOGON_SERVICE 5
+#define LOGON32_PROVIDER_DEFAULT 0
+#define LOGON32_PROVIDER_WINNT35 1
+#define LOGON32_PROVIDER_WINNT40 2
+#define LOGON32_PROVIDER_WINNT50 3
+
BOOL WINAPI GetBinaryTypeA( LPCSTR lpApplicationName, LPDWORD lpBinaryType );
BOOL WINAPI GetBinaryTypeW( LPCWSTR lpApplicationName, LPDWORD lpBinaryType );
#define GetBinaryType WINELIB_NAME_AW(GetBinaryType)
@@ -1364,6 +1374,9 @@
BOOLWINAPI ImpersonateLoggedOnUser(HANDLE);
BOOLWINAPI ImpersonateSelf(SECURITY_IMPERSONATION_LEVEL);
BOOLWINAPI IsProcessorFeaturePresent(DWORD);
+BOOLWINAPI LogonUserA(LPSTR,LPSTR,LPSTR,DWORD,DWORD,PHANDLE);
+BOOLWINAPI LogonUserW(LPWSTR,LPWSTR,LPWSTR,DWORD,DWORD,PHANDLE);
+#define LogonUser WINELIB_NAME_AW(LogonUser)
BOOLWINAPI
LookupAccountSidA(LPCSTR,PSID,LPSTR,LPDWORD,LPSTR,LPDWORD,PSID_NAME_USE);
BOOL
