- Wine-Devel - list.winehq.org

Re: I/O Completion Ports (1 of 2)
by Robert Shearman April 1, 2003

April 1, 2003

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 April 1, 2003

April 1, 2003

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 April 1, 2003

April 1, 2003

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 April 1, 2003

April 1, 2003

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 April 1, 2003

April 1, 2003

> 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 April 1, 2003

April 1, 2003

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

Whither specmaker?
by Kevin Cousins April 1, 2003

April 1, 2003

Searching for an answer to my problem, comp.emulators.ms-windows.wine archives at google throw up a post [1] suggesting looking into tools/specmaker. Sources checked out from winehq.com CVS as of last week, updated today, have tools/specmaker as an empty directory. Where might I be able to investigate specmaker? Is specmaker still viable? FWIW, my problem is the oft-asked "How do I call functions in a Windows DLL from an ELF process?" I appreciate WineLib is an option, and have run into a number of snarls along that path: 1. I have created a .dll.so to wrap calls to the offending Windows DLL. Calls are made through static function pointers which have been initialised in the .dll.so by calls to GetProcAddress() from what would be the DllMain() function there. I've not managed to get Wine to call that DllMain() function of my .dll.so, other than through a breakpoint in the debugger, and explicitly calling the function at that time. This way, my code runs even returning from calls to the Windows DLL, but mysteriously, no output file is written! 2. I occasionally see user32.dll.so barf with a SEGV with the call stack mentioning res_146() deep during the first call to wine_dlopen(). I've also had a look at avifile, mplayer, and xine, to investigate how they do things. Linking avifile/plugins/libwin32/loader/libloader.a to my application means I can run as far as attempting to execute DllMain() on my Windows DLL before I see gut-wrenching a SEGV. What are other people doing? -- Kevin. [1]

2 1

Edit box input problem
by Brad Campbell April 1, 2003

April 1, 2003

G'day all, I'm having a strange problem with any application that uses a delphi TMaskEdit component. I have knocked up a simple test application. http://www.seme.com.au/masktest.tgz It's in Borland Delphi 4 and contains both the .exe and the source for the interested or security conscious. Can someone else run this up on their wine build and see if it's doing the same thing? Under windows, it will only accept three numeric characters, under wine I'm unable to edit the field, it accepts over 3 characters and of any type, plus the first one or two character entries create a message storm as watched with a --debugmsg +message. Also, I'm willing to have a crack at fixing this, which .dll source should I start looking at? I also tried this with native comctl32, commdlg and oleaut32 dll's just in case. Problem remains. A normal Edit component works fine, and if I remove the mask it works fine, so it must be something the in the delphi code for the TMaskEdit component that is triggering a wine bug. -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Question about kernel32 resources
by Maxime Bellengé April 1, 2003

April 1, 2003

I am currently working on the EnumSystemLanguageGroups/EnumLanguageGroupLocales functions. I have finished everything but there is one thing I don't know. The different language group names are stored in the kernel32.dll resources in a string table. They are indexed from 1 to 17 in the win2k/winxp kernel32 dll. However, in wine it seems these ID are used. So I am wondering how can I workaround that. I can't change the ID for the groups because they are defined in winnls.h from 1 to 17. At the present time I have a version ready to work but with the group names not stored in the resources (so only one language is possible). Do I have to change the kernel32 resources ( a lot of work) or does anyone have an idea ? Thanks Max -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

2 1

Problem with debugging: XIO: fatal IO error 0 (Success) on X server ":0.0"
by Juraj Hercek April 1, 2003

April 1, 2003

Hi, I have troubles with debugging winelib applications. This is what makes me unhappy: --- $ gdb wine (gdb) r notepad Starting program: /usr/local/bin/wine notepad XIO: fatal IO error 0 (Success) on X server ":0.0" after 187 requests (187 known processed) with 0 events remaining. Program exited with code 01. --- I'm getting similar results with winedbg (running "winedbg notepad") - there is just bunch of debug outputs before the error is printed. However, this happens only when I'm running winedbg from outside wine directory (checked out from cvs). It works when I'm running winedbg from wine directory. I was digging inside wine and problem occurs somewhere in MODULE_DllProcessAttach() function. This lead me to assumption that problem is probably caused by incorrect paths to libraries, which couldn't be found then. I think I should mention that also wineinstall failed because regedit couldn't find "programs/regedit/regedit.exe.so" (this file is definitely there) so I had to run regedit to insert winedefault.reg into registry manualy - I needed to copy winedefault.reg file to /tmp which is accessible from inside wine system as drive E:\. My working environment is mdk-9.1 with XFree86 version 4.3.0, native nvidia driver doesn't work, the same with nvidia driver v. 41.91). If you have any idea what could be wrong with my linux box, please let me know. I prefer gdb for debugging since I can use ddd with gdb. Thanks. --Juraj

2 1