March 2003 - Wine-Devel - list.winehq.org

Re: CxxFrameHandler problem
by John K. Hohm April 11, 2003

April 11, 2003

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

[announce] QEMU x86 emulator version 0.1
by Fabrice Bellard April 7, 2003

April 7, 2003

Hi, The first release of the QEMU x86 emulator is available at http://bellard.org/qemu/. QEMU achieves a fast user space Linux x86 emulation on x86 and PowerPC Linux hosts by using dynamic translation. Its main goal is to be able to run the Wine project on non-x86 architectures. Fabrice.

3 5

re: Transient registry entries?
by Dan Kegel April 6, 2003

April 6, 2003

> My app reads the registry to figure out network information, in > particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows > NT\CurrentVersion\NetworkCards\] key to discover network cards, then > [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the > IP address of each one (this program can bind to multiple adaptors). > ... > a) In initial setup, ie when you install Wine > b) At Wine startup > c) On demand, ie by writing special cases into the registry access code. Clearly c) because that will work properly even when doing hotplugging of pcmcia cards and doing interactive dialup to an isp. Might want to cache it for 10 seconds or something, and you might need to worry about what happens when programs are reading the reg entries *while* an interface is changing. (heh.) BTW there is a system call getifaddrs on many flavors of Unix that does this kind of query, and there's a library implementation of it for linux. See http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.c http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h The registry code should probably just call this function. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

5 7

Any DCOM experts?
by Bill Medland April 2, 2003

April 2, 2003

Hi guys For the next part of the work I am doing I am trying to figure out if there is any way that the DCOM part of one of our products is going to work under Wine at the server end. I am not having much success so far and I was wondering if anyone knows whether this is because I don't have things set up properly or if it is because of some inherent known lack of functionality. To start the ball rolling I was working with MSDN's DCOMTST test program pair. I managed to get that working using the local server (after adding the definition of IStream to the registry) but am having no luck getting the client under Wine to talk to the server under Win98. In fact the client side doesn't even seem to send out a single TCP/IP packet. (Aside - Nice demonstration of lazy Microsoft code; in their error reporting they call FormatMessage, ignore the return code and somehow print the returned error message, even when one hasn't been allocated; I guess it only works under Windows because the print routine traps the access violation) I am currently running native ole32 and native rpcrt4. The builtin rpcrt4 fails on a call to unimplemented RpcServerInqDefaultPrincName but I don't understand why it is even calling that; why does it think I have Netware only and why does it think this is a server process. Anyone an expert in any of this stuff? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

3 5

Wine's goals
by Francois Gouget April 2, 2003

April 2, 2003

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

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: 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

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

Re: wine/ scheduler/timer.c scheduler/synchro.c in ...
by Bill Medland March 31, 2003

March 31, 2003

On March 30, 2003 05:37 pm, Alexandre Julliard wrote: > ChangeSet ID: 7728 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/03/30 19:37:05 > > Modified files: > scheduler : timer.c synchro.c > include : winternl.h > dlls/ntdll : time.c sync.c om.c ntdll_misc.h ntdll.spec > > Log message: > Moved WaitForMultipleObjects to ntdll (based on a patch by Eric > Pouech). > Added NTDLL_get_server_timeout function to compute ntdll-style > timeouts and adapted the timer code to use it. > > Patch: http://cvs.winehq.com/patch.py?id=7728 > This breaks the build (on my machine at least) sync.c contains a LARGE_INTEGER time and takes time.s.* include/wtypes.h LARGE_INTEGER only contains a QuadPart as far as I can see. > Old revision New revision Changes Path > 1.17 1.18 +9 -22 wine/scheduler/timer.c > 1.45 1.46 +16 -189 wine/scheduler/synchro.c > 1.21 1.22 +1 -0 wine/include/winternl.h > 1.28 1.29 +42 -6 wine/dlls/ntdll/time.c > 1.23 1.24 +192 -5 wine/dlls/ntdll/sync.c > 1.25 1.26 +0 -13 wine/dlls/ntdll/om.c > 1.11 1.12 +2 -0 wine/dlls/ntdll/ntdll_misc.h > 1.101 1.102 +2 -2 wine/dlls/ntdll/ntdll.spec -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

1 0

Re: lostwages/. winehq.css
by Dimitrie O. Paun March 31, 2003

March 31, 2003

On Mon, 31 Mar 2003, Jeremy Newman wrote: > ChangeSet ID: 7729 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/03/31 11:03:14 > > Added files: > . : winehq.css Should we move all CSS stuff in there (like the stuff I use in my Fun/Winelib/etc. pages)? -- Dimi.

2 3

Multicast options in WinSock with java
by Mike Hearn March 31, 2003

March 31, 2003

Hi all, I have a bit of a problem. Essentially, the problem is that Java 1.4 is buggy, it includes winsock.h, but then proceeds to use winsock2. That wouldn't be an issue, except that my app uses multicast sockets, and for reasons known only to Redmond they decided to change the values of some of the multicast socket option constants. Java, therefore, passes in the winsock1 values to winsock2. Windows apparently can deal with this just fine (well, the appw works), despite there being no obvious way to remap them, both IP_MULTICAST_IF and IP_HDRINCL which both == 2 in different winsock versions would be valid at once on XP/2003 for instance. Marcus, I know you took a stab at implementing multicast support once, so if you have any tips that'd be appreciated. If anybody knows a way you might be able to detect that a program is using the wrong headers for the winsock2 dll, please let me know. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

Error in CVS?
by Vilppa Salt March 31, 2003

March 31, 2003

<snip> gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o signal_sparc.o signal_sparc.c gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D__WINESRC__ -D_NTSYSTEM_ -DBINDIR="\"/usr/local/bin\"" -DETCDIR="\"/usr/local/etc\"" -D_REENTRANT -o sync.o sync.c sync.c: In function `call_apcs': sync.c:390: union has no member named `s' sync.c:390: union has no member named `s' make[2]: *** [sync.o] Error 1 make[2]: Leaving directory `/home/vilppa/wineCVS/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/home/vilppa/wineCVS/wine/dlls' make: *** [dlls] Error 2 This is what I get when building latest Wine CVS. --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

2 1

cross compiling Wine under MSVC
by Rolf Kalbermatter March 31, 2003

March 31, 2003

Hello, I have just got the whole Wine sources on a Linux computer and shared the sources directory over samba to try to compile parts of it in MSVC. Here I get several problems which seem to me configuration related, but I wonder how I'm supposed to proceed to get everything working. I have run ./tools/winapi/msvcmaker to create the MSVC project files and hopefully anything else which is required for this. I can of course add some (the correct?) definitions by hand to config.h or port.h but I would rather like to do it the way it is supposed to be or if there is a problem get it resolved now. First problem: wine\tools\winebuild\spec32.c(213) and other lines in that file use macros __ASM_SHORT and __ASM_STRING which should be defined in config.h. How do I get a config.h which is compatible with MSVC? Is there a special tool for this? I obviously can't really run ./configure from my Windows machine ;-) Second problem: Some Wine files include headers which sooner or later include "windows.h" and that causes error messages that this should not be done for Wine sources. There is a macro COM_NO_WINDOWS_H in the Wine sources to avoid this inclusion. ./tools/winapi/msvcmaker does forget to add this macro as standard definition in all project files for the Wine sources, but obviously should not do this for the test project files, I think. I'm no Perl guy so I hesitate to even touch the msvcmaker tool. Up until now I fixed such problems by manualy editing port.h which made it work for my local operation, but it seems to me that we should try to get this resolved, so that not everone does privately reinvent the wheel here. Rolf Kalbermatter

1 0

Re: lostwages/templates/en fun_projects.template
by Dimitrie O. Paun March 31, 2003

March 31, 2003

On March 30, 2003 11:23 am, Andreas Mohr wrote: > ChangeSet ID: 7720 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: amohr(a)wine.codeweavers.com 2003/03/30 10:23:41 > > Modified files: > templates/en : fun_projects.template > > Log message: > Update by Francois > > Patch: http://cvs.winehq.com/patch.py?id=7720 > > Old revision New revision Changes Path > 1.2 1.3 +1 -1 > lostwages/templates/en/fun_projects.template It's better if you send these to me directly, as I maintain these pages (Fun Project, Winelib, etc.) separately, and so we don't run the risk of losing them on next update. I'll apply this one to my page as well. -- Dimi.

1 0

Re: lostwages/templates/en contributing.template
by Dimitrie O. Paun March 31, 2003

March 31, 2003

On March 30, 2003 10:59 am, Andreas Mohr wrote: > ChangeSet ID: 7718 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: amohr(a)wine.codeweavers.com 2003/03/30 09:59:45 > > Modified files: > templates/en : contributing.template > > Log message: > Update by Francois > > Patch: http://cvs.winehq.com/patch.py?id=7718 > > Old revision New revision Changes Path > 1.4 1.5 +67 -62 > lostwages/templates/en/contributing.template I take my critiques back for now -- changes look good. Hopefully we'll fix the smaller things from my TODO, and move the larger ones as individual bugs so we can track them better. I'll do that soon. -- Dimi.

1 0

Re: Contributing page needs fixing
by Dimitrie O. Paun March 30, 2003

March 30, 2003

On March 30, 2003 03:30 pm, Francois Gouget wrote: > Yes, definitely. Now is not the time to say the 'web site is finished we > don't need anyone'. That's simply not true. That will not cut it, sorry. I've posted a list of "still TODO", and asked for comments. Nobody bothered to reply to it. The web site is not the open ended project Wine is. We can reach a state where we are happy with it, and I think that state is not far away. What we need is a list of things that we think we need. I've started such a list. If you want to add something, please say so. Simply saying "we need more stuff" isn't good enough. -- Dimi.

1 0

Re: bin2rc
by Alexandre Julliard March 30, 2003

March 30, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I've just stupidly lost an hour or so trying to figure out > how to convert a .bmp to a .rc script. Such a simple problem... That's what tools/bin2res is for... -- Alexandre Julliard julliard(a)winehq.com

3 3

Re: Contributing page needs fixing
by Dimitrie O. Paun March 30, 2003

March 30, 2003

On March 29, 2003 09:48 pm, Francois Gouget wrote: > Wine-Develipmont</a>. > + <p>WineHQ has been redisigned recently. But there is still work to do. > + So you would feel like writing about Wine or coding in Php your > + contribution will be appreciated. You can find the current task list I think we should remove this section altogether. The page is already way too big, and this is as bad as a not enough info. The site has been redesigned, and there are only a few things that are missing -- and those can't be done by just anyone. Really, now the last thing we need is people comming over and messing with the site. Let's have a *focused* page on where we need help, not a laundry list of just about everything. -- Dimi.

2 2

SHFileOperation regression test
by Rolf Kalbermatter March 30, 2003

March 30, 2003

While working on SHFileOperation in shell32.dll I came across the error in line 286 and 287 which happens on Win98/ME/2K/XP but not on 95/NT. Investigation showed that the copy operation of multiple files with one source file not existing in the list, has different behaviour on these two groups of OS Versions. Win 95/NT abort the copy operation at the first file not existing, and return WITHOUT any error indication whatsoever, leaving the already copied files in the target directory. Win 98/ME/2K/XP have obviously fixed this bug in a rather strict manner, in that such a copy operation is aborted with error return value 1026 (undocumented, resp. meaningless in this cicumstance other than that it is non-zero), and no file is copied at all. (There still exists a small bug, at least in 2K, in that the fAnyOperationsAborted flag in the SHFILEOPSTRUCT structure is not set at all in this case on return.) Obviously our shlfileop.c test needs fixing but I'm not sure how to proceed as I'm fairly new to the Wine regression testing. From what I gathered it is not really acceptable to create Windows version dependant tests in the regression framework, which leaves only two other options, IMO: 1) Remove this particular test altogether or 2) Test only the behaviour which is consistent on all platforms which in this case would be only the non-existence of the test2.txt file. Both options leave out possibly important regression test cases for the future. Any comments on this issue from the more seasoned guys into regression test writing? Appended is the patch which is correct for Win 98/ME/2K/XP but will cause test failure on 95/NT. Rolf Kalbermatter Index: dlls/shell32/tests/shlfileop.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/tests/shlfileop.c,v retrieving revision 1.6 diff -u -r1.6 shlfileop.c --- dlls/shell32/tests/shlfileop.c 14 Jan 2003 23:43:42 -0000 1.6 +++ dlls/shell32/tests/shlfileop.c 30 Mar 2003 08:52:58 -0000 @@ -278,13 +278,15 @@ ok(file_exists(".\\testdir2\\test2.txt"), "The file is copied"); clean_after_shfo_tests(); + /* Copying multiple files with one not existing as source, fails the + entire operation in Win98/ME/2K/XP with return value 1026, but only + the files after the one not existing and without any error indication + in 95/NT, ! */ init_shfo_tests(); tmp_flags = shfo.fFlags; set_curr_dir_path(from, "test1.txt\0test10.txt\0test2.txt\0"); ok(!file_exists(".\\testdir2\\test1.txt"), "The file is not copied yet"); ok(!file_exists(".\\testdir2\\test2.txt"), "The file is not copied yet"); - ok(!SHFileOperationA(&shfo), "Files are copied to other directory "); - ok(file_exists(".\\testdir2\\test1.txt"), "The file is copied"); + ok(SHFileOperationA(&shfo), "Files are copied to other directory "); + ok(!file_exists(".\\testdir2\\test1.txt"), "The file is copied"); ok(!file_exists(".\\testdir2\\test2.txt"), "The file is copied"); shfo.fFlags = tmp_flags; }

1 0

Re: Compiling WINE - Hopeless situation? :)
by Dan Kegel March 30, 2003

March 30, 2003

Sylvain wrote: > --- Michael Stefaniuc <mstefani(a)redhat.de> a écrit : > On Sun, Mar 30, > 2003 at 12:44:31AM +0100, Sylvain Petreolle wrote: >> > The code that has problem for now is C code, not C++, am I right >> here ? >> > Then it has nothing to do with C++ thing. >> Yeah, but the page you pointed to is for C++ incompatibilities, not >> C. >> And a newer 2.96 is stable for C. > If there is one, it isnt shipped with RH 8, or not by default. Red Hat 8 uses gcc3.2. If you have Red Hat 8, you don't need gcc2.96. > "Current snapshots of GCC, and any version labeled 2.96, produce object > files that are not compatible with those produced by either GCC 2.95.2 > or the forthcoming GCC 3.0." This is true only for C++. For C code, Red Hat's gcc2.96's have been just fine. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Compiling WINE - Hopeless situation? :)
by Sylvain Petreolle March 30, 2003

March 30, 2003

Please update gcc to version 3.x.x, gcc2.96 was a broken unofficial version of RedHat and all dependancies must be updated too. (like binutils) Time to put an entry in README or something else ? Is gcc version checked by configure ? --- Matt Bailey <mattb(a)rtccom.net> a écrit : > Hi, > > Any ideas on that last error message I sent? One detail I did not > mention > is that I still have libstdc++2.10 installed, it says it's version > 2.96-0.76mdk. I knew there was some 2.96 package still installed but > I had > forgotten what it was called. I can't uninstall this package because > it is > needed by a BUNCH of other apps........looks like it would just about > trash > my Mandrake install to remove this package. Do I need to upgrade this > > package, and if so, how would I go about it without completely > uninstalling > it? I also have installed libstdc++5, version 3.2-1mdk. > Is it hopeless? I don't blame you if you gave up on this problem. :) > Anyway, > your advice has been greatly helpful already, much appreciated. > > -Matt Bailey ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 8

Re: Possible regression: wine/dlls/kernel/tests/process crashes
by Sylvain Petreolle March 29, 2003

March 29, 2003

> Here is what I did: > > cd ../wine/dlls/kernel/tests > > rm process.o > > > make test > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > kernel32_test.exe.so process.c && touch process.ok you can run it with wine/winedbg without runtest : wine kernel32_test.exe.so process > and after some time this automatically pops up: > process.c:382: Test failed: Child process termination > wine: process.c:400: test_Startup: Assertion `DeleteFileA(resfile) != > 0' > failed. now you know approximatively where the test fail. > The debugger starts again and again. if winedbg fails to debug it, use winedbg --gdb instead. winedbg -- --gdb kernel32_test.exe.so process > > How do I run those test on Win? Can you point me to a document > describing > the procedure? see Francois 's pages or it : http://fgouget.free.fr/wine/tests-en.shtml ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Possible regression: wine/dlls/kernel/tests/process crashes
by Uwe Bonnes March 29, 2003

March 29, 2003

Hallo, wine/dlls/kernel/tests/process crashed. I was not able to decipher what is going on. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

More QEMU fixes
by Ulrich Weigand March 29, 2003

March 29, 2003

Hello Fabrice, I've played a bit with your qemu-0.1.2 release, and got putty running under Wine under qemu on s390-ibm-linux (using a wineserver also running under qemu on s390). To make this work I've had to add a bunch of missing byteorder conversions and other fixes, which I've appended here. Mostly, the changes concern the socket area; wine and wineserver extensively use sockets (sendmsg/recvmsg with ancillary data), and also the X connection needed fixes (setsockopt). There were also some other fixes required (poll, select, execve). I haven't found any problem with the actual CPU emulation, however! Here's the detailed list of changes: glibc-2.3.2 compile fix: Recent glibc supports nanosecond resolution file timestamps in their struct stat, using this construct struct timespec st_atim; /* Time of last access. */ struct timespec st_mtim; /* Time of last modification. */ struct timespec st_ctim; /* Time of last status change. */ # define st_atime st_atim.tv_sec /* Backward compatibility. */ # define st_mtime st_mtim.tv_sec # define st_ctime st_ctim.tv_sec This breaks the use of st_atime etc. as struct members; I've renamed them to target_st_atime etc. Missing data conversion: - socketcall on-stack arguments need to be byteswapped - struct sockaddr (sa_family) needs to be byteswapped - sendmsg/recvmsg ancillary data needs to be converted - execve arg and env vectors need to be byteswapped - select fdset conversion wasn't done due to typo in #if - added marginal support for setsockopt Incorrect data conversion: - poll pollfd array was clobbered (even on native) If you like, I could also send you the patch to make qemu actually work on s390; I'm not sure if you are interested in that at this point ... Bye, Ulrich diff -ur qemu-0.1.2/syscall-i386.h qemu-0.1.2-s390/syscall-i386.h --- qemu-0.1.2/syscall-i386.h 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall-i386.h 2003-03-29 02:33:28.000000000 +0100 @@ -255,11 +255,11 @@ target_ulong st_size; target_ulong st_blksize; target_ulong st_blocks; - target_ulong st_atime; + target_ulong target_st_atime; target_ulong __unused1; - target_ulong st_mtime; + target_ulong target_st_mtime; target_ulong __unused2; - target_ulong st_ctime; + target_ulong target_st_ctime; target_ulong __unused3; target_ulong __unused4; target_ulong __unused5; @@ -290,13 +290,13 @@ target_ulong st_blocks; /* Number 512-byte blocks allocated. */ target_ulong __pad4; /* future possible st_blocks high bits */ - target_ulong st_atime; + target_ulong target_st_atime; target_ulong __pad5; - target_ulong st_mtime; + target_ulong target_st_mtime; target_ulong __pad6; - target_ulong st_ctime; + target_ulong target_st_ctime; target_ulong __pad7; /* will be high 32 bits of ctime someday */ unsigned long long st_ino; diff -ur qemu-0.1.2/syscall.c qemu-0.1.2-s390/syscall.c --- qemu-0.1.2/syscall.c 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall.c 2003-03-29 04:45:12.000000000 +0100 @@ -26,6 +26,7 @@ #include <errno.h> #include <unistd.h> #include <fcntl.h> +#include <time.h> #include <sys/types.h> #include <sys/wait.h> #include <sys/time.h> @@ -40,6 +41,7 @@ #include <sys/uio.h> #include <sys/poll.h> //#include <sys/user.h> +#include <netinet/tcp.h> #define termios host_termios #define winsize host_winsize @@ -166,7 +168,7 @@ static inline fd_set *target_to_host_fds(fd_set *fds, target_long *target_fds, int n) { -#if !defined(BSWP_NEEDED) && !defined(WORD_BIGENDIAN) +#if !defined(BSWP_NEEDED) && !defined(WORDS_BIGENDIAN) return (fd_set *)target_fds; #else int i, b; @@ -188,7 +190,7 @@ static inline void host_to_target_fds(target_long *target_fds, fd_set *fds, int n) { -#if !defined(BSWP_NEEDED) && !defined(WORD_BIGENDIAN) +#if !defined(BSWP_NEEDED) && !defined(WORDS_BIGENDIAN) /* nothing to do */ #else int i, nw, j, k; @@ -256,55 +258,267 @@ return ret; } -static long do_socketcall(int num, long *vptr) +static inline void target_to_host_sockaddr(struct sockaddr *addr, + struct target_sockaddr *target_addr, + socklen_t len) +{ + memcpy(addr, target_addr, len); + addr->sa_family = tswap16(target_addr->sa_family); +} + +static inline void host_to_target_sockaddr(struct target_sockaddr *target_addr, + struct sockaddr *addr, + socklen_t len) +{ + memcpy(target_addr, addr, len); + target_addr->sa_family = tswap16(addr->sa_family); +} + +static inline void target_to_host_cmsg(struct msghdr *msgh, + struct target_msghdr *target_msgh) +{ + struct cmsghdr *cmsg = CMSG_FIRSTHDR(msgh); + struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh); + socklen_t space = 0; + + while (cmsg && target_cmsg) { + void *data = CMSG_DATA(cmsg); + void *target_data = TARGET_CMSG_DATA(target_cmsg); + + int len = tswapl(target_cmsg->cmsg_len) + - TARGET_CMSG_ALIGN(sizeof (struct target_cmsghdr)); + + space += CMSG_SPACE(len); + if (space > msgh->msg_controllen) { + space -= CMSG_SPACE(len); + gemu_log("Host cmsg overflow"); + break; + } + + cmsg->cmsg_level = tswap32(target_cmsg->cmsg_level); + cmsg->cmsg_type = tswap32(target_cmsg->cmsg_type); + cmsg->cmsg_len = CMSG_LEN(len); + + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); + memcpy(data, target_data, len); + } else { + int *fd = (int *)data; + int *target_fd = (int *)target_data; + int i, numfds = len / sizeof(int); + + for (i = 0; i < numfds; i++) + fd[i] = tswap32(target_fd[i]); + } + + cmsg = CMSG_NXTHDR(msgh, cmsg); + target_cmsg = TARGET_CMSG_NXTHDR(target_msgh, target_cmsg); + } + + msgh->msg_controllen = space; +} + +static inline void host_to_target_cmsg(struct target_msghdr *target_msgh, + struct msghdr *msgh) +{ + struct cmsghdr *cmsg = CMSG_FIRSTHDR(msgh); + struct target_cmsghdr *target_cmsg = TARGET_CMSG_FIRSTHDR(target_msgh); + socklen_t space = 0; + + while (cmsg && target_cmsg) { + void *data = CMSG_DATA(cmsg); + void *target_data = TARGET_CMSG_DATA(target_cmsg); + + int len = cmsg->cmsg_len - CMSG_ALIGN(sizeof (struct cmsghdr)); + + space += TARGET_CMSG_SPACE(len); + if (space > tswapl(target_msgh->msg_controllen)) { + space -= TARGET_CMSG_SPACE(len); + gemu_log("Target cmsg overflow"); + break; + } + + target_cmsg->cmsg_level = tswap32(cmsg->cmsg_level); + target_cmsg->cmsg_type = tswap32(cmsg->cmsg_type); + target_cmsg->cmsg_len = tswapl(TARGET_CMSG_LEN(len)); + + if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS) { + gemu_log("Unsupported ancillary data: %d/%d\n", cmsg->cmsg_level, cmsg->cmsg_type); + memcpy(target_data, data, len); + } else { + int *fd = (int *)data; + int *target_fd = (int *)target_data; + int i, numfds = len / sizeof(int); + + for (i = 0; i < numfds; i++) + target_fd[i] = tswap32(fd[i]); + } + + cmsg = CMSG_NXTHDR(msgh, cmsg); + target_cmsg = TARGET_CMSG_NXTHDR(target_msgh, target_cmsg); + } + + msgh->msg_controllen = tswapl(space); +} + +static long do_setsockopt(int sockfd, int level, int optname, + void *optval, socklen_t optlen) +{ + if (level == SOL_TCP) { + /* TCP options all take an 'int' value. */ + int val; + + if (optlen < sizeof(uint32_t)) + return -EINVAL; + + val = tswap32(*(uint32_t *)optval); + return get_errno(setsockopt(sockfd, level, optname, &val, sizeof(val))); + } + + else if (level != SOL_SOCKET) { + gemu_log("Unsupported setsockopt level: %d\n", level); + return -ENOSYS; + } + + switch (optname) { + /* Options with 'int' argument. */ + case SO_DEBUG: + case SO_REUSEADDR: + case SO_TYPE: + case SO_ERROR: + case SO_DONTROUTE: + case SO_BROADCAST: + case SO_SNDBUF: + case SO_RCVBUF: + case SO_KEEPALIVE: + case SO_OOBINLINE: + case SO_NO_CHECK: + case SO_PRIORITY: + case SO_BSDCOMPAT: + case SO_PASSCRED: + case SO_TIMESTAMP: + case SO_RCVLOWAT: + case SO_RCVTIMEO: + case SO_SNDTIMEO: + { + int val; + if (optlen < sizeof(uint32_t)) + return -EINVAL; + val = tswap32(*(uint32_t *)optval); + return get_errno(setsockopt(sockfd, level, optname, &val, sizeof(val))); + } + + default: + gemu_log("Unsupported setsockopt SOL_SOCKET option: %d\n", optname); + return -ENOSYS; + } +} + +static long do_getsockopt(int sockfd, int level, int optname, + void *optval, socklen_t *optlen) +{ + gemu_log("getsockopt not yet supported\n"); + return -ENOSYS; +} + +static long do_socketcall(int num, int32_t *vptr) { long ret; switch(num) { case SOCKOP_socket: - ret = get_errno(socket(vptr[0], vptr[1], vptr[2])); + { + int domain = tswap32(vptr[0]); + int type = tswap32(vptr[1]); + int protocol = tswap32(vptr[2]); + + ret = get_errno(socket(domain, type, protocol)); + } break; case SOCKOP_bind: - ret = get_errno(bind(vptr[0], (struct sockaddr *)vptr[1], vptr[2])); + { + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + socklen_t addrlen = tswap32(vptr[2]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(bind(sockfd, addr, addrlen)); + } break; case SOCKOP_connect: - ret = get_errno(connect(vptr[0], (struct sockaddr *)vptr[1], vptr[2])); + { + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + socklen_t addrlen = tswap32(vptr[2]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(connect(sockfd, addr, addrlen)); + } break; case SOCKOP_listen: - ret = get_errno(listen(vptr[0], vptr[1])); + { + int sockfd = tswap32(vptr[0]); + int backlog = tswap32(vptr[1]); + + ret = get_errno(listen(sockfd, backlog)); + } break; case SOCKOP_accept: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(accept(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(accept(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_getsockname: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(getsockname(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(getsockname(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_getpeername: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[2]); - ret = get_errno(getpeername(vptr[0], (struct sockaddr *)vptr[1], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[2] = size; + int sockfd = tswap32(vptr[0]); + void *target_addr = (void *)tswap32(vptr[1]); + uint32_t *target_addrlen = (void *)tswap32(vptr[2]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(getpeername(sockfd, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_socketpair: { + int domain = tswap32(vptr[0]); + int type = tswap32(vptr[1]); + int protocol = tswap32(vptr[2]); + int32_t *target_tab = (void *)tswap32(vptr[3]); int tab[2]; - int32_t *target_tab = (int32_t *)vptr[3]; - ret = get_errno(socketpair(vptr[0], vptr[1], vptr[2], tab)); + + ret = get_errno(socketpair(domain, type, protocol, tab)); if (!is_error(ret)) { target_tab[0] = tswap32(tab[0]); target_tab[1] = tswap32(tab[1]); @@ -312,27 +526,64 @@ } break; case SOCKOP_send: - ret = get_errno(send(vptr[0], (void *)vptr[1], vptr[2], vptr[3])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + + ret = get_errno(send(sockfd, msg, len, flags)); + } break; case SOCKOP_recv: - ret = get_errno(recv(vptr[0], (void *)vptr[1], vptr[2], vptr[3])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + + ret = get_errno(recv(sockfd, msg, len, flags)); + } break; case SOCKOP_sendto: - ret = get_errno(sendto(vptr[0], (void *)vptr[1], vptr[2], vptr[3], - (struct sockaddr *)vptr[4], vptr[5])); + { + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + void *target_addr = (void *)tswap32(vptr[4]); + socklen_t addrlen = tswap32(vptr[5]); + void *addr = alloca(addrlen); + + target_to_host_sockaddr(addr, target_addr, addrlen); + ret = get_errno(sendto(sockfd, msg, len, flags, addr, addrlen)); + } break; case SOCKOP_recvfrom: { - socklen_t size; - size = tswap32(*(int32_t *)vptr[5]); - ret = get_errno(recvfrom(vptr[0], (void *)vptr[1], vptr[2], - vptr[3], (struct sockaddr *)vptr[4], &size)); - if (!is_error(ret)) - *(int32_t *)vptr[5] = size; + int sockfd = tswap32(vptr[0]); + void *msg = (void *)tswap32(vptr[1]); + size_t len = tswap32(vptr[2]); + int flags = tswap32(vptr[3]); + void *target_addr = (void *)tswap32(vptr[4]); + uint32_t *target_addrlen = (void *)tswap32(vptr[5]); + socklen_t addrlen = tswap32(*target_addrlen); + void *addr = alloca(addrlen); + + ret = get_errno(recvfrom(sockfd, msg, len, flags, addr, &addrlen)); + if (!is_error(ret)) { + host_to_target_sockaddr(target_addr, addr, addrlen); + *target_addrlen = tswap32(addrlen); + } } break; case SOCKOP_shutdown: - ret = get_errno(shutdown(vptr[0], vptr[1])); + { + int sockfd = tswap32(vptr[0]); + int how = tswap32(vptr[1]); + + ret = get_errno(shutdown(sockfd, how)); + } break; case SOCKOP_sendmsg: case SOCKOP_recvmsg: @@ -344,11 +595,11 @@ struct iovec *vec; struct target_iovec *target_vec; - msgp = (void *)vptr[1]; + msgp = (void *)tswap32(vptr[1]); msg.msg_name = (void *)tswapl(msgp->msg_name); msg.msg_namelen = tswapl(msgp->msg_namelen); - msg.msg_control = (void *)tswapl(msgp->msg_control); - msg.msg_controllen = tswapl(msgp->msg_controllen); + msg.msg_controllen = 2 * tswapl(msgp->msg_controllen); + msg.msg_control = alloca(msg.msg_controllen); msg.msg_flags = tswap32(msgp->msg_flags); count = tswapl(msgp->msg_iovlen); @@ -361,17 +612,43 @@ msg.msg_iovlen = count; msg.msg_iov = vec; - fd = vptr[0]; - flags = vptr[2]; - if (num == SOCKOP_sendmsg) - ret = sendmsg(fd, &msg, flags); - else - ret = recvmsg(fd, &msg, flags); - ret = get_errno(ret); + fd = tswap32(vptr[0]); + flags = tswap32(vptr[2]); + if (num == SOCKOP_sendmsg) { + target_to_host_cmsg(&msg, msgp); + ret = get_errno(sendmsg(fd, &msg, flags)); + } else { + ret = get_errno(recvmsg(fd, &msg, flags)); + if (!is_error(ret)) + host_to_target_cmsg(msgp, &msg); + } } break; case SOCKOP_setsockopt: + { + int sockfd = tswap32(vptr[0]); + int level = tswap32(vptr[1]); + int optname = tswap32(vptr[2]); + void *optval = (void *)tswap32(vptr[3]); + socklen_t optlen = tswap32(vptr[4]); + + ret = do_setsockopt(sockfd, level, optname, optval, optlen); + } + break; case SOCKOP_getsockopt: + { + int sockfd = tswap32(vptr[0]); + int level = tswap32(vptr[1]); + int optname = tswap32(vptr[2]); + void *optval = (void *)tswap32(vptr[3]); + uint32_t *target_len = (void *)tswap32(vptr[4]); + socklen_t optlen = tswap32(*target_len); + + ret = do_getsockopt(sockfd, level, optname, optval, &optlen); + if (!is_error(ret)) + *target_len = tswap32(optlen); + } + break; default: gemu_log("Unsupported socketcall: %d\n", num); ret = -ENOSYS; @@ -880,7 +1157,27 @@ ret = get_errno(unlink((const char *)arg1)); break; case TARGET_NR_execve: - ret = get_errno(execve((const char *)arg1, (void *)arg2, (void *)arg3)); + { + char **argp, **envp; + int argc = 0, envc = 0; + uint32_t *p; + char **q; + + for (p = (void *)arg2; *p; p++) + argc++; + for (p = (void *)arg3; *p; p++) + envc++; + + argp = alloca(argc * sizeof(void *)); + envp = alloca(envc * sizeof(void *)); + + for (p = (void *)arg2, q = argp; *p; p++, q++) + *q = (void *)tswap32(*p); + for (p = (void *)arg3, q = envp; *p; p++, q++) + *q = (void *)tswap32(*p); + + ret = get_errno(execve((const char *)arg1, argp, envp)); + } break; case TARGET_NR_chdir: ret = get_errno(chdir((const char *)arg1)); @@ -1404,7 +1701,7 @@ case TARGET_NR_ioperm: goto unimplemented; case TARGET_NR_socketcall: - ret = do_socketcall(arg1, (long *)arg2); + ret = do_socketcall(arg1, (int32_t *)arg2); break; case TARGET_NR_syslog: goto unimplemented; @@ -1468,9 +1765,9 @@ target_st->st_size = tswapl(st.st_size); target_st->st_blksize = tswapl(st.st_blksize); target_st->st_blocks = tswapl(st.st_blocks); - target_st->st_atime = tswapl(st.st_atime); - target_st->st_mtime = tswapl(st.st_mtime); - target_st->st_ctime = tswapl(st.st_ctime); + target_st->target_st_atime = tswapl(st.st_atime); + target_st->target_st_mtime = tswapl(st.st_mtime); + target_st->target_st_ctime = tswapl(st.st_ctime); } } break; @@ -1644,17 +1941,17 @@ unsigned int nfds = arg2; int timeout = arg3; struct pollfd *pfd; - int i; + unsigned int i; pfd = alloca(sizeof(struct pollfd) * nfds); for(i = 0; i < nfds; i++) { - pfd->fd = tswap32(target_pfd->fd); - pfd->events = tswap16(target_pfd->events); + pfd[i].fd = tswap32(target_pfd[i].fd); + pfd[i].events = tswap16(target_pfd[i].events); } ret = get_errno(poll(pfd, nfds, timeout)); if (!is_error(ret)) { for(i = 0; i < nfds; i++) { - target_pfd->revents = tswap16(pfd->revents); + target_pfd[i].revents = tswap16(pfd[i].revents); } } } @@ -1859,9 +2156,9 @@ target_st->st_size = tswapl(st.st_size); target_st->st_blksize = tswapl(st.st_blksize); target_st->st_blocks = tswapl(st.st_blocks); - target_st->st_atime = tswapl(st.st_atime); - target_st->st_mtime = tswapl(st.st_mtime); - target_st->st_ctime = tswapl(st.st_ctime); + target_st->target_st_atime = tswapl(st.st_atime); + target_st->target_st_mtime = tswapl(st.st_mtime); + target_st->target_st_ctime = tswapl(st.st_ctime); } } break; diff -ur qemu-0.1.2/syscall_defs.h qemu-0.1.2-s390/syscall_defs.h --- qemu-0.1.2/syscall_defs.h 2003-03-26 23:34:59.000000000 +0100 +++ qemu-0.1.2-s390/syscall_defs.h 2003-03-29 02:36:30.000000000 +0100 @@ -19,6 +19,11 @@ #define SOCKOP_sendmsg 16 #define SOCKOP_recvmsg 17 +struct target_sockaddr { + uint16_t sa_family; + uint8_t sa_data[14]; +}; + struct target_timeval { target_long tv_sec; target_long tv_usec; @@ -49,6 +54,43 @@ unsigned int msg_flags; }; +struct target_cmsghdr { + target_long cmsg_len; + int cmsg_level; + int cmsg_type; +}; + +#define TARGET_CMSG_DATA(cmsg) ((unsigned char *) ((struct target_cmsghdr *) (cmsg) + 1)) +#define TARGET_CMSG_NXTHDR(mhdr, cmsg) __target_cmsg_nxthdr (mhdr, cmsg) +#define TARGET_CMSG_FIRSTHDR(mhdr) \ + ((size_t) tswapl((mhdr)->msg_controllen) >= sizeof (struct target_cmsghdr) \ + ? (struct target_cmsghdr *) tswapl((mhdr)->msg_control) : (struct target_cmsghdr *) NULL) +#define TARGET_CMSG_ALIGN(len) (((len) + sizeof (target_long) - 1) \ + & (size_t) ~(sizeof (target_long) - 1)) +#define TARGET_CMSG_SPACE(len) (TARGET_CMSG_ALIGN (len) \ + + TARGET_CMSG_ALIGN (sizeof (struct target_cmsghdr))) +#define TARGET_CMSG_LEN(len) (TARGET_CMSG_ALIGN (sizeof (struct target_cmsghdr)) + (len)) + +static __inline__ struct target_cmsghdr * +__target_cmsg_nxthdr (struct target_msghdr *__mhdr, struct target_cmsghdr *__cmsg) +{ + if (tswapl(__cmsg->cmsg_len) < sizeof (struct target_cmsghdr)) + /* The kernel header does this so there may be a reason. */ + return 0; + + __cmsg = (struct target_cmsghdr *) ((unsigned char *) __cmsg + + TARGET_CMSG_ALIGN (tswapl(__cmsg->cmsg_len))); + if ((unsigned char *) (__cmsg + 1) > ((unsigned char *) tswapl(__mhdr->msg_control) + + tswapl(__mhdr->msg_controllen)) + || ((unsigned char *) __cmsg + TARGET_CMSG_ALIGN (tswapl(__cmsg->cmsg_len)) + > ((unsigned char *) tswapl(__mhdr->msg_control) + + tswapl(__mhdr->msg_controllen)))) + /* No more entries. */ + return 0; + return __cmsg; +} + + struct target_rusage { struct target_timeval ru_utime; /* user time used */ struct target_timeval ru_stime; /* system time used */ -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

1 0