April 2003 - Wine-devel - list.winehq.org

Wine's goals
by Francois Gouget 02 Apr '03

02 Apr '03

I propose the following WineHQ patch to present and clarify Wine's goals. I'm submitting this to wine-devel first to get a feel of whether that would be a good addition and whether that sounds reasonable and accurate enough. Index: templates/en/about.template =================================================================== RCS file: /home/wine/lostwages/templates/en/about.template,v retrieving revision 1.7 diff -u -r1.7 about.template --- templates/en/about.template 24 Mar 2003 22:49:03 -0000 1.7 +++ templates/en/about.template 30 Mar 2003 02:35:46 -0000 @@ -29,4 +29,70 @@ <a href="mailto:julliard(a)winehq.com">julliard(a)winehq.com</a>. For a list of current developers, see the <a href="?page=who">Wine Who's Who</a>.</p> + +<h1>Wine's Goals</h1> + +<p>As mentionned in many places, the primary goal of Wine is to make it +possible to run Windows applications on x86-based Unix systems. But there is +often confusion as to what this covers. So let's clarify things a bit: + +<ul> + <li>Wine does not try to be a better Windows than Windows. What this means + is that Wine will not try to extend, improve or 'fix' the Windows API in + an attempt to lure developpers into using it. While we think that it is + important to provide a way to reuse the legacy Windows applications that + are out there, we feel that for new developments there are better APIs + than Win32. + + <li>Wine Is Not a (CPU) Emulator. So no, we will not integrate a CPU + emulator in Wine any time soon. However we will do what we can to make it + possible to integrate Wine into a CPU emulation environment that would + provide the regular Unix services that Wine depends on. In such a scheme + both Wine and the Windows application would be run in that environment. + Two candidates that come to mind are <a + href="http://fabrice.bellard.free.fr/qemu/">QEMU</a> and + <a href="http://www.transitives.com/tech_overview.htm">Dynamite</a> from + <a href="http://www.transitives.com/">Transitives Technologies</a>. + + <li>Wine's goal is to provide replacements for just those DLLs and APIs + that are needed to run Windows applications. This means that we will not + provide replacements for DLLs that are always shipped together with an + application. This also means that implementing an API that no application + ever uses is not a priority. Similarly, until there are applications out + there that use the Win64 API, it will not be a priority. That being said, + we will certainly try to keep our options open and to improve our API + coverage as we can. + + <li>Making it possible to use Windows device drivers or VxDs on Unix is not + part of Wine's goals. Device drivers don't use the same API that Windows + applications do, and run in ring 0 instead or ring 3. To make it possible + to use them on Unix, one would have to hack the kernel, implement a + completely different API. In other words, this would be a completely + separate project. However, if you want to reuse Windows drivers on + non-Microsoft operating systems we recommend that you have a look at + <a href="http://www.reactos.com/">ReactOS</a>. + + <li>Wine is not an operating system or a desktop environment. So writing + device drivers, file or window managers that look like Windows, are not + part of Wine's goals. If you are interested in those, the best would be to + contribute to the <a href="http://www.kernel.org/">Linux</a>, + <a href="http://www.freebsd.org/">FreeBSD</a> or + <a href="http://www.reactos.com/">ReactOS</a> kernels, or to the + <a href="http://www.gnome.org/">Gnome</a> or + <a href="http://www.kde.org/">KDE</a> desktop environments. You will get + the added benefit that your contribution will then be usable by everyone, + not just by Wine users. + + <li>Wine's focus is on Unix operating systems, and to some extent Linux + because that is what most of our developpers are using. However we welcome + ports to other architectures such as + <a href="http://www.reactos.com/">ReactOS</a> or + <a href="http://bewine.beunited.org/">BeWine</a>, and will try to make + it possible for them to reuse as much of Wine as possible. After all, + reimplementing the Windows API is a big enough task that it is best if we + can all work together on it. +</ul> + + <p> </p> + -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

2 2

Wine
by Tuch 02 Apr '03

02 Apr '03

I recently tried to install wine from src and ran into a problem. when it prompted me to enter the root password to do a "make install" I did so, and it proceeded to tell me that I entered an incorrect password. I tried this several times realizing it is possible to enter the password incorrectly, but each time gave the same result. Now I know the password was correct as I am the only user of this box and I installed Slackware 9.0 myself. As a request of your install app, I am e-mailing you this. Thanks Bill

1 0

Re: valgrind for WINE
by Eric Pouech 01 Apr '03

01 Apr '03

Adam Gundy wrote: > a new version of the valgrind patch has been uploaded to sourceforge - > the only change is a small fix to the signal handling which should > prevent "signal handler frame" uninitialized errors. > > http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… > > comments? bug reports? success stories? did test it yet. As a global note, I think it would be appreciated breaking the patch in smaller bits... it makes it easier to track/follow what happens. For example, I don't see any reason for including the msvcrtd patches into this patch I think that Alexandre is currently integrating (bit per bit) your changes into wine. look for the patch about zeroing the request zones (which is another implementation of your structure packing), as well as local availability of the thread PID on a more minor side of things, I would keep the VALGRIND prefix in heap.c last point, using the .vg extension to the wine script may not be optimal. it won't work (as it is written) for winelib programs (which got started also thru the wine script) one solution would be (to follow your idea) to link (for a winelib app called foo) foo.vg to script wine (and change your rule something like *.vg|*/*.vg). another option would be to embed this support as an option to the wine script (like --valgrind) how are your patches doing on the "other side" (I mean valgrind's) ? A+ -- Eric Pouech

2 1

Re: resent: menu capture tracking fix
by Alexandre Julliard 01 Apr '03

01 Apr '03

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > [I don't know why this wasn't applied, without any comment; > resending it] You don't really expect me to apply a patch that adds a #ifdef FUBAR_CODE, do you? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: I/O Completion Ports (1 of 2)
by Robert Shearman 01 Apr '03

01 Apr '03

I will try to fix this sometime in the next week, depending on whether I can get CVS access to take advantage of the work Eric Pouech has done. >>> Alexandre Julliard <julliard(a)winehq.com> 03/28/03 01:56 AM >>> "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > +static int io_completion_send_data( struct thread *thread, void *cookie, struct io_completion_data * data ) > +{ > + struct io_completion_send_data_reply reply; > + int ret; > + > + reply.cookie = cookie; > + reply.signaled = STATUS_SUCCESS; > + reply.bytes_transferred = data->bytes_transferred; > + reply.completion_key = data->completion_key; > + reply.overlapped = data->overlapped; > + if ((ret = write( get_unix_fd( thread->wait_fd ), &reply, sizeof(reply) )) == sizeof(reply)) > + return 0; You cannot send different message sizes into the wait_fd pipe, this won't work since pipes don't preserve message boundaries. I'd suggest simply using the normal wait mechanism and then doing a separate call to retrieve the rest of the info. -- Alexandre Julliard julliard(a)winehq.com

1 0

A few questions on the mingw port.
by Steven Edwards 01 Apr '03

01 Apr '03

Hello Everyone, First I want to thank everyone for the help they have given me in dealing with my bad spelling, lack of grammer and not following the rules when working to get most of wine built for mingw. I'm trying to do a little house keeping with Wine and ReactOS and had a few changes/questions that could make my and the ReactOS teams life a little easyer with the port. 1. Can we set --disable-win16 CFLAGS=-DWINE_NOWINSOCK" to be default when building under Mingw? I tried to write a configure patch for this a while back but never could get the bastard to work. Once this option is removed all we will be left with is ./configure to configure wine for mingw. None of the WINE networking stuff will really work for anyone working with mingw and I dont expect that to change anytime soon. Without this flag anything that include winsock.h or winsock2.h will puke when building on Windows. I know that WINE on linux will need win16 for a while due to older installers that are 16bit but for the mingw port thats kind of not important. 2. Can we set a conditional option to not build winegcc and winewrap? These are not needed on Windows as they are only used to port mingw applications to winelib. Due to the use of Unixisms in these programs (fork, waitpid, etc) they wont build. Now I know we could stub fork and wrap waitpid to wait but its kind of pointless and I can see one day when someone will ask why these dont work on windows even though we build them. IMHO they just shouldnt get built for us. winegcc.c: In function `spawn': winegcc.c:86: warning: implicit declaration of function `fork' winegcc.c:89: warning: implicit declaration of function `waitpid' winegcc.c:92: warning: implicit declaration of function `WIFEXITED' winegcc.c:92: warning: implicit declaration of function `WEXITSTATUS' gcc -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -o winegcc winegcc.o -L../libs/port -lwine_port winegcc.o(.text+0x1a3): In function `spawn': g:/src/wine-dev/wine/tools/winegcc.c:86: undefined reference to `fork' winegcc.o(.text+0x1d2):g:/src/wine-dev/wine/tools/winegcc.c:89: undefined refere nce to `waitpid' winegcc.o(.text+0x202):g:/src/wine-dev/wine/tools/winegcc.c:92: undefined refere nce to `WIFEXITED' winegcc.o(.text+0x211):g:/src/wine-dev/wine/tools/winegcc.c:92: undefined refere nce to `WEXITSTATUS' 3. Exclude WINEserver. This is a fun one. I took a look at this a while back a was able to get about 80% of it to compile native on windows. Before we can even get wineserver to build/link on mingw we still have the same problem a cygwin port has and that is what to do with the get/set thread_context stuff. Also from all I have read a mingw port would require a major redesign because of the signal/pipe usage. I looked at porting some of the stuff to windows sockets a while back and decided I still cant program well enough and I have more interesting things to do like work on ReactOS. =P 4. This may be more a mingw problem rather then something with WINE but I figured I would ask while I was making noise. When I try to build the regression tests under mingw with gcc-3.x I am getting this error. If I dont include wines libmsvcrt.a it goes away. do the exit functions in wine and mingws source not agree? gcc registry.o testlist.o -o advapi32_test.exe -L../../../dlls -ladvapi32 -lke rnel32 -lntdll -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x40):crt1.c: fi rst defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit C:/mingw/bin/../lib/gcc-lib/mingw32/3.2.1/../../../crt2.o(.text+0x60):crt1.c: fi rst defined here make[1]: *** [advapi32_test.exe] Error 1 make[1]: Leaving directory `/g/src/wine-dev/wine/dlls/advapi32/tests' make: *** [tests] Error 2 At some point I will do documentation for Mingw on MSYS/Cygwin <g> Thanks Steven

2 2

Re: FindFirstFileExW
by BiGgUn 01 Apr '03

01 Apr '03

How can you know which version of Windows, WIne is currently emulating ? Thanks in advance. Stephan

2 1

Re: wine/ tools/winewrap.c tools/winegcc.c include ...
by Dimitrie O. Paun 01 Apr '03

01 Apr '03

On March 31, 2003 07:12 pm, Alexandre Julliard wrote: > Log message: > Use _spawnvp to replace fork for non-Unix platforms. What about adding it to the portability lib? I can do the patch if you want... -- Dimi.

3 6

Fw: glibc tracker bug - installshiels
by Davide Giannotti 01 Apr '03

01 Apr '03

> RedHat 9 > > You need to set the environment variable LD_ASSUME_KERNEL=2.2.5 in the shell > prior to running configure and prior to running wine. > after installing i suggest to add the line in your winelauncher script (/usr/local/bin/winelauncher) and to launch associate the .exe extension with winelauncher. It works fine for me. ---- I'm still hanging on installshield. I copied the suggested stdole* files and rcp*4 from my win98 cd (or whatever i don't rembe now) in my system folder, but the microsoft installer 2 doesn't install correctly. It doesn't create it's directory in the common files. I tried to install it in a clean win98 pc and copy the dir, but installshield doesn't work from some apps. I think this should be fixed in some way. Thank you all guys. Davide Giannotti ITS Planet s.n.c. E-mail: davide.giannotti(a)itsplanet.com Sito web: www.itsplanet.com

1 0

Re: PATCH: /dlls/ntdll/cdrom.c -- portability breakage
by Alexandre Julliard 01 Apr '03

01 Apr '03

Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: > How about the following patch? > > It's needed for compilation on FreeBSD; in case it's not correct, > how should we solve the problem? I think the code is wrong, we shouldn't store a Linux-only define in a Windows structure, we should use a Windows define. Any one knows what the right value should be? -- Alexandre Julliard julliard(a)winehq.com

3 2