- wine-devel - winehq.org

Re: Resend: Implements languagegroups functions
by Dimitrie O. Paun 05 Apr '03

05 Apr '03

On April 5, 2003 09:31 am, Maxime Bellengé wrote: > 245,246c245,246 > < @ stub EnumLanguageGroupLocalesA > < @ stub EnumLanguageGroupLocalesW > --- Please use uniffied diffs for the patches (diff -u). Check out http://www.winehq.org/?page=sending_patches for more info. -- Dimi.

1 0

Re: Implements languagegroups functions
by Mike Hearn 05 Apr '03

05 Apr '03

Hi, Just a few comments, things that have been mentioned to me so I should probably pass along :) Here: - FIXME("stub\n"); - SetLastError( ERROR_INVALID_PARAMETER ); - return FALSE; + TRACE("\n"); + + unsigned int i,j,nStrLen; Normally you'd put a TRACE with the parameters passed after the variable declarations, I think otherwise it might violate strict C. Also putting the parameters into the trace statement makes debugging easier as you don't have to decode a relay trace to see what was given. Again, I'm not a C expert but I think it's invalid strict C to declare variables half way through a block, they all have to be at the top of the function together. + } + + // 1 to 17 is the constants for LGRPID_xxx + for(i=1;i<=17;i++) { + sprintfW(val,valm,i); + length = sizeof(installed); Wine doesn't like C++ style comments (//) because some C compilers don't accept them, I think you have to use /* */ Not sure how rigidly this rule is followed though.

4 3

Re: RtlAtom tests improved
by Dmitry Timoshkov 05 Apr '03

05 Apr '03

"GyЖrgy 'Nog' Jeney" <nog(a)sdf.lonestar.org> wrote: > I figured out that the RtlCreateAtomTable function as expecting to get passed > in a NULL as the initial Table, otherwise it thinks that the argument is a > valid atom table and just returns success. This unfourtuneatly makes the test > results that Dimitrie send useless because RtlCreateAtomTable thought that the > table was valid but all the other functions realised that it wasn't. Could > someone please rerun these tests on an nt system again? Much better this time. Here are the results: atom.c:173: Test failed: PinCount is not 2 but 1 atom.c:185: Test failed: PinCount is not 2 but 1 atom.c:186: Test failed: We found wrong atom atom.c:219: Test failed: Didn't get expected retval with querying an empty atom table, retval: c0000034 atom.c:247: Test failed: Unable to delete atom from table, retval: 40000019 atom.c:250: Test failed: Able to find deleted atom in table atom.c:334: Test failed: Expected pincount 0 but got 1 atom.c:335: Test failed: Expected refcount 2 but got 1 atom: 163903 tests executed, 0 marked as todo, 8 failures. P.S. I had to make the <stdio.h> very first include, otherwise compiler complains that "wine/test.h" uses the non prototyped functions. -- Dmitry.

1 0

Launching files with params
by Vilppa Salt 05 Apr '03

05 Apr '03

Hello! This kind of command fails with wcmd: start /wait somebatfile.bat This was related to the T++ and random garbage characters bug. When executables are launched from other executables Wine freaks out and used to output T++ and random garbage characters. Now wine doesn't do that anymore but outputs: Sharing violation However, if run such a program with --debugmsg +seh this happens: U++ €&#"/#&(&)€(€( So the bug is still remaining in the debug channel (I guess). One program that does this is Valentine Dancer winamp plugin (nice visualizer BTW :) It can be downloaded from: http://classic.winamp.com/plugins/detail.jhtml?componentId=44849 It extracts two files to the windows\temp directory (valentinesdancer_winamp.exe and wtinstallpimp.bat) and runs the bat file which is: @echo off if NOT EXIST %1\valentinesdancer_winamp.exe exit start /wait %1\valentinesdancer_winamp.exe del %1\valentinesdancer_winamp.exe del %1\wtinstallpimp.bat and the crash happens at the start /wait command because Wine doesn't find the file. Attached is the debulog.txt that should have the relevant parts of the --debugmsg +relay output. So actually there are two bugs here. The debugmsg +seh bug and the wcmd bug. I hope here is enough information for someone to fix these. --- 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

Re: RtlAtom tests improved
by György 'Nog' Jeney 05 Apr '03

05 Apr '03

> I figured out that the RtlCreateAtomTable function as expecting to get > passed in a NULL as the initial Table, otherwise it thinks that the > argument is a valid atom table and just returns success. This > unfourtuneatly makes the test > results that Dimitrie send useless because RtlCreateAtomTable thought ^^^^^^^^ I realy did mean Dimitry. > that the > table was valid but all the other functions realised that it wasn't. > Could someone please rerun these tests on an nt system again? > > ChangeLog: > * dlls/ntdll/tests/Makefile.in > * dlls/ntdll/tests/atom.c > Add tests for RtlAtom functions. > > nog.

2 1

Re: add tests for ntdll atom functions
by Dmitry Timoshkov 05 Apr '03

05 Apr '03

"GyЖrgy 'Nog' Jeney" <nog(a)sdf.lonestar.org> wrote: > This adds tests for the RtlAtom functions in ntdll. I'm not sure about the > correctness of this patch, so could some people with an nt system run these > and send me the output? Attached atom.txt is the result of running your test under win2k SP3. Results are not very encouraging... -- Dmitry.

1 0

gdi32 and wine
by KK singh 05 Apr '03

05 Apr '03

Hi, I am new to wine and it seems I would be sticking to it for sometime. I saw the builtin gdi32.dll specs. They seem quite different from What I see in dependency walker for gdi32 on windows xp. Actually, due to this difference, I get Function Not implemented error when i run wine. I am using the 20030318 build of wine from winehq. When i opened the gdi32.spec.c file, the header says it is automatically generated and that it should not be edited. Now, I want to contribute to wine by updating the builtin gdi32.dll parallel to the native one installed on xp. But, how to go ahead with it ?? Or more precisely How gdi32.spec.c is generated using winebuild. How can I add missing functions.. (NamedEscape) and how can i update export table of gdi32.dll.so Any suggestions pointers are welcome TIA kks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

3 5

It's been great
by Tony Lambregts 05 Apr '03

05 Apr '03

I will be starting A new job on Tuesday and therefore I will not be very active in wine (at least for a couple of months). It seems hard to believe that my first post was just over a year ago (Ragging on about the online Documentation). The last year has been great. When I look back I am amazed at the real progress that has been achieved over the last year and I am proud to say that I have be a small part of it. -- Tony Lambregts <lurking>...

1 0

RE: glibc 2.3.2 and Xilinx Webpack 5.1
by Steven Garrison 04 Apr '03

04 Apr '03

I have checked out and built wine from CVS today and my application now runs on Redhat 9. Thanks for the NPTL changes! -Steve -----Original Message----- From: Mike Hearn [mailto:m.hearn@signal.qinetiq.com] Sent: Thursday, April 03, 2003 3:33 AM To: Kevin DeKorte Cc: Steven Garrison; wine-devel(a)winehq.com Subject: Re: glibc 2.3.2 and Xilinx Webpack 5.1 On Wed, 2003-04-02 at 20:53, Kevin DeKorte wrote: > I saw one of those > > > XIO: fatal IO error 2 (Success) on X server ":0.0" > > after 5251 requests (5243 known processed) with 0 events remaining. > > Errors this morning on a RedHat 8.0 (glibc 2.3.2). I killed wine and > wineserver. But that did not fix it. However, logging out and back into KDE > did solve it... Weird. I think it's partly timing related, hence the general wierdness of this bug -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: Use the new swapvp function
by Steven Edwards 04 Apr '03

04 Apr '03

shell32 shelllink.c uses fork on line 748 and waitpid on line 789 Dimitrie O. Paun wrote: >As promissed... > >Any other places that may need it? > >ChangeLog > Make use of the new swapvp function in wine{gcc,wrap}. > > > >

6 7

Re: gdi32 and wine
by Rolf Kalbermatter 04 Apr '03

04 Apr '03

KK singh <kk_singh(a)yahoo.com> wrote: > > > > KK> I am not using any of these in native form... > > You *are* using such a dll. It's called... > > ATMLIB.DLL > > Find out, what dll or application requires this > system > component, which clearly will never work under Wine. KK > **NEVER** is bit challenging !!! I agree it is a strong statement, but probably not very far from the truth. KK > What if the required functions are implemented in KK > gdi32.dll ? Chances are very high that with every new function you implement even as stub you just run into the next missing export! Also a stub implementation may work for some functions, but more sooner than later you end up with really bad functionality in the caller. KK > This one seems to raise the issue of KK > changing other builtin libraries, But some hack KK > should exist. KK > What if a builtin implementation of ATMLIB.dll is KK > written, which doesnt use the missing functions. Mmmh, are you proposing to write it? This library looks to me like a full featured font type manager and then some. Does a full API description exist at all? How big are the chances, that implementing such a library will conflict sooner or later with patents of some sort? And you may be ending up reimplementing substantial parts of things Ghostscript or similar packages already do. Rolf Kalbermatter

2 2

err:keyboard:X11DRV_ToUnicode no char for keysym FE20 (ISO_Left_Tab)
by Paul McNett 04 Apr '03

04 Apr '03

Who understands how to implement ISO_Left_Tab? (I looked at the source but it is way over my head): err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicode (virtKey=9,scanCode=F,keycode=17,state=11) TIA! -- Paul McNett Liberal Earthling

1 0

OSS Bug
by Rod Taylor 04 Apr '03

04 Apr '03

http://bugs.winehq.com/long_list.cgi?buglist=1349 I think bug 1349 is related to the below conversation. http://www.winehq.com/hypermail/wine-devel/2003/03/0379.html Robert Reif suggested I send in a note. -- Rod Taylor <rbt(a)rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc

3 6

Re: valgrind for WINE
by Alexandre Julliard 04 Apr '03

04 Apr '03

Adam Gundy <arg(a)cyberscience.com> writes: > 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? I played a bit with it, it works pretty well, and I have already fixed a few bugs found with it. Great work! I have also applied those of your fixes that seemed correct, the rest will need a bit more work The signal stuff in particular is not going to work properly with NPTL, it would be really better if we could somehow make valgrind use real threads. I have no idea if this is possible though. -- Alexandre Julliard julliard(a)winehq.com

4 9

Wine & RH9
by Dimitrie O. Paun 04 Apr '03

04 Apr '03

Alexandre, I've noticed you've checked in already some NTPL patches. Does this mean that Wine is ready for RH9? Can I go ahead and upgrade my system? -- Dimi.

6 10

winsock.h problem
by Dimitrie O. Paun 04 Apr '03

04 Apr '03

I get this when trying to compile putty: winegcc -mno-cygwin -Wall -O2 -D_WINDOWS -DDEBUG -DWIN32S_COMPAT -DNO_SECURITY -D_NO_OLDNAMES -DNO_MULTIMON -I. -c winnet.c In file included from /usr/local/include/wine/windows/windows.h:62, from /usr/local/include/wine/windows/winsock.h:114, from winnet.c:46: /usr/local/include/wine/windows/winsock2.h:401: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:401: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:401: parse error before "WSAAccept" /usr/local/include/wine/windows/winsock2.h:402: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:403: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:406: parse error before "const" /usr/local/include/wine/windows/winsock2.h:412: parse error before "HANDLE" /usr/local/include/wine/windows/winsock2.h:416: parse error before "HANDLE" /usr/local/include/wine/windows/winsock2.h:417: parse error before "LPWSAOVERLAPPED" /usr/local/include/wine/windows/winsock2.h:423: parse error before "u_long" /usr/local/include/wine/windows/winsock2.h:424: parse error before "u_short" /usr/local/include/wine/windows/winsock2.h:428: parse error before "DWORD" /usr/local/include/wine/windows/winsock2.h:435: parse error before "u_long" /usr/local/include/wine/windows/winsock2.h:436: parse error before "u_short" /usr/local/include/wine/windows/winsock2.h:438: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:439: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:440: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:443: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:444: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:445: parse error before "LPWSABUF" /usr/local/include/wine/windows/winsock2.h:449: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:449: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:449: parse error before "WSASocketA" /usr/local/include/wine/windows/winsock2.h:450: warning: type defaults to `int' in declaration of `SOCKET' /usr/local/include/wine/windows/winsock2.h:450: warning: `__stdcall__' attribute only applies to function types /usr/local/include/wine/windows/winsock2.h:450: parse error before "WSASocketW" /usr/local/include/wine/windows/winsock2.h:451: parse error before "LPSOCKADDR" /usr/local/include/wine/windows/winsock2.h:452: parse error before "LPSOCKADDR" In file included from winnet.c:46: /usr/local/include/wine/windows/winsock.h:267: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:271: parse error before '}' token /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `PROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `PPROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: type defaults to `int' in declaration of `LPPROTOENT' /usr/local/include/wine/windows/winsock.h:271: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:279: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:284: parse error before '}' token /usr/local/include/wine/windows/winsock.h:345: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:350: parse error before '}' token /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `SERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `PSERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: type defaults to `int' in declaration of `LPSERVENT' /usr/local/include/wine/windows/winsock.h:350: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:359: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:366: parse error before '}' token /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `HOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `PHOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: type defaults to `int' in declaration of `LPHOSTENT' /usr/local/include/wine/windows/winsock.h:366: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:373: `SOCKET' redeclared as different kind of symbol /usr/local/include/wine/windows/winsock2.h:450: previous declaration of `SOCKET' /usr/local/include/wine/windows/winsock.h:383: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:386: parse error before '}' token /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `SOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `PSOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: type defaults to `int' in declaration of `LPSOCKADDR' /usr/local/include/wine/windows/winsock.h:386: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:389: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:392: parse error before '}' token /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `LINGER' /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `PLINGER' /usr/local/include/wine/windows/winsock.h:392: warning: type defaults to `int' in declaration of `LPLINGER' /usr/local/include/wine/windows/winsock.h:392: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:412: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:419: parse error before '}' token /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:419: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `FD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `PFD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: type defaults to `int' in declaration of `LPFD_SET' /usr/local/include/wine/windows/winsock.h:419: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:422: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:425: parse error before '}' token /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `TIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `PTIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: type defaults to `int' in declaration of `LPTIMEVAL' /usr/local/include/wine/windows/winsock.h:425: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:483: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:483: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:484: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:484: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:485: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:485: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:486: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:486: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:540: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:544: warning: type defaults to `int' in declaration of `S_un_b' /usr/local/include/wine/windows/winsock.h:544: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:549: parse error before '}' token /usr/local/include/wine/windows/winsock.h:549: warning: type defaults to `int' in declaration of `S_un' /usr/local/include/wine/windows/winsock.h:549: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:565: parse error before '}' token /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `IN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `PIN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: type defaults to `int' in declaration of `LPIN_ADDR' /usr/local/include/wine/windows/winsock.h:565: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:568: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:571: parse error before "sin_addr" /usr/local/include/wine/windows/winsock.h:571: warning: type defaults to `int' in declaration of `sin_addr' /usr/local/include/wine/windows/winsock.h:571: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:573: parse error before '}' token /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `SOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `PSOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: type defaults to `int' in declaration of `LPSOCKADDR_IN' /usr/local/include/wine/windows/winsock.h:573: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:583: syntax error before '{' token /usr/local/include/wine/windows/winsock.h:591: parse error before '}' token /usr/local/include/wine/windows/winsock.h:591: warning: type defaults to `int' in declaration of `WSADATA' /usr/local/include/wine/windows/winsock.h:591: warning: type defaults to `int' in declaration of `LPWSADATA' /usr/local/include/wine/windows/winsock.h:591: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:903: parse error before "LPWSADATA" /usr/local/include/wine/windows/winsock.h:906: parse error before '*' token /usr/local/include/wine/windows/winsock.h:906: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:906: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:907: parse error before '*' token /usr/local/include/wine/windows/winsock.h:907: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:907: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:908: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:908: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:909: parse error before '*' token /usr/local/include/wine/windows/winsock.h:909: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:909: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:910: parse error before '*' token /usr/local/include/wine/windows/winsock.h:910: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:910: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:910: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:910: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:911: parse error before '*' token /usr/local/include/wine/windows/winsock.h:911: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:911: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:911: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:911: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:913: parse error before '*' token /usr/local/include/wine/windows/winsock.h:913: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:913: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:914: parse error before '*' token /usr/local/include/wine/windows/winsock.h:914: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:914: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:914: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:914: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:915: parse error before '*' token /usr/local/include/wine/windows/winsock.h:915: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:915: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:915: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:915: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:917: parse error before "WS" /usr/local/include/wine/windows/winsock.h:919: parse error before '*' token /usr/local/include/wine/windows/winsock.h:919: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:919: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:919: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:919: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:920: parse error before '*' token /usr/local/include/wine/windows/winsock.h:920: warning: type defaults to `int' in declaration of `WS' /usr/local/include/wine/windows/winsock.h:920: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:920: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:920: warning: data definition has no type or storage class /usr/local/include/wine/windows/winsock.h:921: parse error before '*' token /usr/local/include/wine/windows/winsock.h:921: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:921: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:922: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:922: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:923: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:923: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:924: warning: parameter has incomplete type /usr/local/include/wine/windows/winsock.h:924: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:924: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:925: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:925: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:926: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:926: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:927: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:927: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:928: parse error before '*' token /usr/local/include/wine/windows/winsock.h:928: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:928: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:929: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:929: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:930: parse error before '*' token /usr/local/include/wine/windows/winsock.h:930: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:930: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:931: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:931: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:932: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:932: warning: parameter names (without types) in function declaration /usr/local/include/wine/windows/winsock.h:933: `WS' declared as function returning a function /usr/local/include/wine/windows/winsock.h:933: warning: parameter names (without types) in function declaration winnet.c: In function `sk_cleanup': winnet.c:143: warning: implicit declaration of function `closesocket' winnet.c: In function `sk_namelookup': winnet.c:239: warning: implicit declaration of function `inet_addr' winnet.c:275: warning: implicit declaration of function `gethostbyname' winnet.c:275: warning: assignment makes pointer from integer without a cast winnet.c:342: dereferencing pointer to incomplete type winnet.c:344: dereferencing pointer to incomplete type winnet.c:358: warning: implicit declaration of function `ntohl' winnet.c: In function `sk_getaddr': winnet.c:383: storage size of `a' isn't known winnet.c:384: warning: implicit declaration of function `htonl' winnet.c:385: warning: implicit declaration of function `inet_ntoa' winnet.c:385: warning: passing arg 2 of `strncpy' makes pointer from integer without a cast winnet.c:383: warning: unused variable `a' winnet.c: In function `sk_address_is_local': winnet.c:407: storage size of `a' isn't known winnet.c:407: warning: unused variable `a' winnet.c: In function `sk_addrcopy': winnet.c:434: storage size of `a' isn't known winnet.c:434: warning: unused variable `a' winnet.c: In function `sk_new': winnet.c:547: parse error before "a" winnet.c:573: warning: implicit declaration of function `socket' winnet.c:585: warning: implicit declaration of function `setsockopt' winnet.c:614: `a' undeclared (first use in this function) winnet.c:614: (Each undeclared identifier is reported only once winnet.c:614: for each function it appears in.) winnet.c:616: warning: implicit declaration of function `htons' winnet.c:625: warning: implicit declaration of function `bind' winnet.c:680: warning: implicit declaration of function `connect' winnet.c: In function `sk_newlistener': winnet.c:725: parse error before "a" winnet.c:778: `a' undeclared (first use in this function) winnet.c:826: warning: implicit declaration of function `listen' winnet.c: In function `try_send': winnet.c:876: warning: implicit declaration of function `send' winnet.c: In function `select_result': winnet.c:1012: warning: implicit declaration of function `ioctlsocket' winnet.c:1023: warning: implicit declaration of function `recv' winnet.c:1092: storage size of `isa' isn't known winnet.c:1093: sizeof applied to an incomplete type winnet.c:1096: sizeof applied to an incomplete type winnet.c:1098: warning: implicit declaration of function `accept' winnet.c:1092: warning: unused variable `isa' winnet.c: In function `net_service_lookup': winnet.c:1219: warning: implicit declaration of function `getservbyname' winnet.c:1219: warning: assignment makes pointer from integer without a cast winnet.c:1221: warning: implicit declaration of function `ntohs' winnet.c:1221: dereferencing pointer to incomplete type Error: gcc failed. make: *** [winnet.o] Error 2 [dimi@dimi putty]$ -- Dimi.

2 4

PuTTY: server infinite loop
by Dimitrie O. Paun 04 Apr '03

04 Apr '03

On startup, PuTTY remains in an infinite loop. A run with --debugmsg +all reveals the following repeating sequence: [...] 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=0049035c, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=1 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423955.356901 (-0.000050), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.357089 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.854213 (-0.000046), handles={0x3c} ) 000b: select() = TIMEOUT [the above seems to be repeated ad infinitum] 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=0049054f, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=0 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423955.855377 (-0.000051), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423955.855568 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.355795 (-0.000045), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=00490744, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=1 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423956.356958 (-0.000052), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.357150 (-0.000027), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: set_queue_mask( wake_mask=00000040, changed_mask=0000007f, skip_wait=1 ) 000b: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000b: select( flags=4, cookie=0x40801c18, timeout=0, handles={0x38,0x3c} ) 000b: select() = PENDING 000b: *wakeup* signaled=0 cookie=0x40801c18 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.853835 (-0.000046), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = 0 { type=5, win=0x10048, msg=00000118, wparam=0000ffff, lparam=40f806f8, x=0, y=0, time=00490936, info=00000000, total=0, data={} } 000b: start_hook_chain( id=3 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=6 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: start_hook_chain( id=-1 ) 000b: start_hook_chain() = 0 { handle=(nil), proc=(nil), unicode=0, module=L"" } 000b: set_caret_info( flags=00000004, handle=0x10048, x=0, y=0, hide=0, state=-1 ) 000b: set_caret_info() = 0 { full_handle=0x10048, old_rect={1,0;3,14}, old_hide=0, old_state=0 } 000b: select( flags=12, cookie=0x40801c70, timeout=1049423956.855226 (-0.000113), handles={0x3c} ) 000b: select() = TIMEOUT 000b: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 000b: get_message() = PENDING { type=0, win=(nil), msg=00000000, wparam=00000000, lparam=00000000, x=0, y=0, time=00000000, info=00000000, total=0, data={} } 000b: select( flags=12, cookie=0x40801bc8, timeout=1049423956.855488 (-0.000026), handles={0x3c} ) 000b: select() = TIMEOUT [... ad infinitum...] -- Dimi.

1 0

Re: PATCH: provide MSVCRTD.DLL debugging C runtime DLL
by Alexandre Julliard 03 Apr '03

03 Apr '03

Adam Gundy <arg(a)cyberscience.com> writes: > * dlls/Makefile.in: Rebuild the msvcrt directory twice, once for > msvcrt.dll.so and once for the debug msvcrtd.dll.so. You can't do that, the Makefile.in is generated automatically. I'd suggest creating a separate directory for msvcrtd and make it forward everything to msvcrt like crtdll does. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: valgrind for WINE
by Adam Gundy 03 Apr '03

03 Apr '03

At 19:45 01/04/03 -0600, Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >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 the reason msvcrtd is there is that you need to use it for valgrind to do any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c) is required to tell valgrind that freshly allocated blocks are uninitialized, and the freed blocks are now invalid. If you build a debug executable using MSVC you have to use MSVCRTD.DLL, hence the new spec file for msvcrtd.dll.so >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 haven't seen these yet >on a more minor side of things, I would keep the VALGRIND prefix in heap.c not sure what you mean here, but the heap.c stuff appears to have been committed (slightly rewritten by the look of it...). To be of ANY use you need the MSVCRTD stuff as well though! >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) maybe, this was just a hack to make it easier to use "in tree". not sure people would want a "--valgrind" switch in a (presumably) production winelib piece of software - it would show the world all your bugs ;-) >how are your patches doing on the "other side" (I mean valgrind's) ? just starting to make progress into CVS commits - there appear to be several other patches which overlap with mine, so there will probably be some ordering and refactoring required... Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

4 12

glibc 2.3.2 and Xilinx Webpack 5.1
by Steven Garrison 03 Apr '03

03 Apr '03

I am running RedHat 9.0 and wine 20030219. So I have run afoul of the new thread issue. I cannot successfully install the Xilinx Webpack tools with the current setup which includes: setting LD_ASSUME_KERNEL=2.2.5 or setting the kernel parameter nosysinfo. The install dies with the following error with either of the above settings: wine setup.exe fixme:ntdll:RtlImpersonateSelf (00000002), stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40b9ea98): stub fixme:ntdll:RtlAddAccessAllowedAce (0x403b3ff0,0x00000002,0x00000003,0x403b3fb0),stub! fixme:ntdll:NtAccessCheck (0x403b3fd0, 0xcafe, 00000001, 0x40b9eacc, 0x40b9eab0, 0x40b9eadc, 0x40b9eac4, 0x40b9eaa8), stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 (Success) on X server ":0.0" after 5251 requests (5243 known processed) with 0 events remaining. This package does install and run if I follow the instructions posted on the comp.emulators.ms-windows.wine thread with RedHat 8.0, kernel 2.4.20 and XFree86 4.3.0. So there are applications that do not now run under RedHat 9.0 with the new threading disabled. -Steve Garrison

4 3

loading dlls & winemaker & --wrap option
by Juraj Hercek 03 Apr '03

03 Apr '03

Hi, I would like to know whether it's important to load xyz.dll.so using dlopen() *before* I would use LoadLibrary() on xyz.dll and call GetProcAddress() to get address of function I would like to call. "winemaker --wrap" uses this way to get adress of WinMain/main in wrapped executable. However, I've figured out that it is not needed to dlopen shared object before it can be used by LoadLibrary() function. It work's without dlopening - I'm surprised & happy, since it was annoying to dlopen .so file before using. I also know it *was* needed before. Reason why I'm asking is that I want to be sure it's save to get rid of dlopen/dlclose functions and related stuff in <filename_>wrapper.c file created by winemaker. --Juraj

1 0

Re: Re[2]: SEGFAULT on WM_SETFOCUS
by Sylvain Petreolle 03 Apr '03

03 Apr '03

oops... didnt see your name :) --- Vitaliy Margolen <wine-devel(a)kievinfo.com> a écrit : > Thanks for the replay, but I'm already between steps 6.1.11 - debug > it and > 6.1.12 - Fix it. ;-) > > Thursday, April 3, 2003, 12:00:00 AM, you wrote: > > > Please use the wine-users list and read > > http://www.winehq.com/docs/wine-user/bugs.shtml. > > > --- Vitaliy Margolen <wine-devel(a)kievinfo.com> a écrit : > >> I'm getting more and more of %subj%. Most of the time when I > closing > >> window. > >> After that program tries to show some error message box, but > frizzes > >> up (main > >> window). Other windows continue to update. But can't get focus or > >> keyboard > >> input. Debugger doesn't say anything, after initial segfault. > >> > >> This problem appeared some time in January-February. Last week it > got > >> really bad. > >> The e-mail program I'm using (The Bat) frizzing up every time I'm > >> closing message > >> window. > >> > >> Any advise on what should I look for (--debugmsg)? > > > ===== > > 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 > ===== 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

SEGFAULT on WM_SETFOCUS
by Vitaliy Margolen 03 Apr '03

03 Apr '03

I'm getting more and more of %subj%. Most of the time when I closing window. After that program tries to show some error message box, but frizzes up (main window). Other windows continue to update. But can't get focus or keyboard input. Debugger doesn't say anything, after initial segfault. This problem appeared some time in January-February. Last week it got really bad. The e-mail program I'm using (The Bat) frizzing up every time I'm closing message window. Any advise on what should I look for (--debugmsg)? -- Best regards, Vitaliy Margolen

2 1

Re: Fix MaskEdit from Delphi
by Brad Campbell 03 Apr '03

03 Apr '03

Vitaliy Margolen wrote: > This suppose to be SetKeyboardState function, not Reset :-) > > Vitaliy Margolen > > changelog: > remove bogus initialization in SetKeyboardState > Indeed that fixed part of the problem, but there is still an issue with the input box accepting more than three characters, where under windows 95/98 it will stop hard at three. Thanks for the fix and pointer though. I'll have a play and see if I can sus the other half out. -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

SMATCH: Returning with freed result
by Michael Stefaniuc 02 Apr '03

02 Apr '03

Hello, this was found by unfree-wine.pl a slight modification of smatch's unfree.pl. The first occurence was easy to fix (see attachment) but i don't know what should be done in this case: dlls/ole32/filemoniker.c 1084 1086 FileMonikerImpl_CommonPrefixWith(75) Returning with freed result var_decl(commonPath) This is due to this code: HeapFree(GetProcessHeap(),0,commonPath); return CreateFileMoniker(commonPath,ppmkPrefix); I would save the return of CreateFileMoniker to a temp variable and after that free commonPath but i don't know if it's the desired fix. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - fix for return of a previous freed object bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

RE: glibc 2.3.2 and Xilinx Webpack 5.1
by Steven Garrison 02 Apr '03

02 Apr '03

I'll give this a shot. One more thing, I'm running Gnome, the default environment of RedHat 9. I just did and here is the error output: export LD_ASSUME_KERNEL=2.2.5 [steveng@localhost xilinx]$ wine setup fixme:ntdll:RtlImpersonateSelf (00000002), stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000008,0x00000000,0x40b9ea98): stub fixme:ntdll:RtlAddAccessAllowedAce (0x403b3fe0,0x00000002,0x00000003,0x403b3fa0),stub! fixme:ntdll:NtAccessCheck (0x403b3fc0, 0xcafe, 00000001, 0x40b9eacc, 0x40b9eab0, 0x40b9eadc, 0x40b9eac4, 0x40b9eaa8), stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 (Success) on X server ":0.0" after 8777 requests (8776 known processed) with 0 events remaining. I did not notice anything unusual in either /var/log/messages or /var/log/XFree86.0.log Thanks, Steve -----Original Message----- From: Uwe Bonnes [mailto:bon@elektron.ikp.physik.tu-darmstadt.de] Sent: Wednesday, April 02, 2003 12:04 PM To: Steven Garrison Cc: wine-devel(a)winehq.com Subject: Re: glibc 2.3.2 and Xilinx Webpack 5.1 >>>>> "Steven" == Steven Garrison <Steven.Garrison(a)siimage.com> writes: ... Steven> stub fixme:advapi:RevertToSelf (), stub XIO: fatal IO error 2 Steven> (Success) on X server ":0.0" after 5251 requests (5243 known Steven> processed) with 0 events remaining. Try running with "Synchronous" = "Y" in the ~/.wine/config [x11drv] section. Perhaps you get more information that way. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Any DCOM experts?
by Bill Medland 02 Apr '03

02 Apr '03

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

Winemine colors
by Joshua Thielen 02 Apr '03

02 Apr '03

Hello, I was just going through my old mail and I noticed Shachar's email (below) on Jan. 26. Just to let you know, I do try to keep up with the wine devel discussions, but as you can see, I'm not very successful. I still have a bug assigned to me that is almost a year old now. I'd like to work on wine more, but I've been really busy with school lately. Hopefully, I'll have more time when I graduate. Anyway, I chose that green color in winemine specifically to make it annoying ;). Actually, at the time I didn't want it to have a boring old gray background, so I chose green in order to make it would look like grass (a mine field). But I guess it's pretty annoying. Do you have a color preference? Do you or anyone else have more suggestions for improving winemine? Maybe ideas for a 3D minesweeper game or something? I wrote it like four years ago, and I didn't know a whole lot about what I was doing (I was in Comp. Sci. 1 when I wrote it). I'd like it to be more fun than your typical minesweeper game. Also, when I originally submitted it, someone complained that it was slow. Is this still the case for anyone out there? Thanks, Josh -------------------------------- >From Shachar Shemesh on Jan. 26: Tom Wickline wrote: > I am in the process of updating section 3.1. ( Wine Static and > Shareable Files ) of the > Packagers Guide : > http://www.winehq.com/Docs/wine-pkg/pkg-components.shtml#PKG-STATIC > > Below is a list of what I have so far. This list is by no means done > or correct . > I would like to submit it here for overview. If you are aware of > something that > is out of place, incorrect, or just out right wrong could you please give > feed back on it. > > This could also serve to start as a mini Wine Dictionary :)) > That is not my current goal but if others think it could be of use > I could spend some time on one after the Packagers Guide is updated. > > Tom > > > -------------------------------------------- > > -- = files that are listed in this Doc but are not installed on my > system. > * = files are in this Doc and on my system > @ = files that are on my system but not in the Doc > # = files that are not in the Doc or on my System ( wineboot ) Then how do you know of their existance ;-). If wineboot is not installed, that's a bug. We should fix it. I'll try to help with the things I know. This is far from authorative on most, however. > @ regedit : A tool to browse/edit your regestory or for exporting a > windows registory to Wine. Not browse. At least, not yet. > # wineboot : A Winelib application that's executed by Wine on startup > of the first wine process of a particular user. > * wininit.ini processing > * registry RenameFiles entries > * RunServices* / RunOnce* / Run registry keys > * win.ini Load= / Run= entries > * StartUp folder processing the last two are not yet done. Also not yet done is for wineboot to automatically run when needed. Currently you have to manually run it after you install something. > @ winemine : A winmine clone "Windows Minesweeper" ??? Yep, using horrid green colors. I'm sorry if I have offended the author (Joshua Thielen, are you still with us?) > @ winepath : Specifies the path(s) in which to search for builtin dlls > and Winelib applications. I think this is an executable that, given a Unix path, will tell you what Wine sees it like (i.e. - you tell it ~/c/windows, and it tells you C:\Windows). I'm not sure on that one. > -- winesetup : This is a Tcl/Tk based front end that provides a user > friendly tool to edit and configure the WINECONFDIR/config file. Anyone knows where it is? It was never based on the winehq sources. Shachar __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

2 1

Re: PATCH: dlls/ntdll/ntdll_misc.h and struct timeval
by Dimitrie O. Paun 02 Apr '03

02 Apr '03

On Wed, 2 Apr 2003, Gerald Pfeifer wrote: > #define __WINE_NTDLL_MISC_H > > +#include <unistd.h> > #include "winnt.h" This needs something like this: +#ifdef HAVE_UNISTD_H +# include <unistd.h> +#endif -- Dimi.

1 0

glibc tracker bug
by Mike Hearn 02 Apr '03

02 Apr '03

Hi, As we've been getting quite a few reports of glibc 2.3.x related failures in bugzilla lately, it makes sense to mark them as dupes of a bug, so I've started duping them against bug #1343 http://bugs.winehq.com/show_bug.cgi?id=1343 That way, when these problems are sorted out, we won't have to go through and resolve them all manually. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 3

Re: ImageList - dirty hack
by Vitaliy Margolen 02 Apr '03

02 Apr '03

Is there are any reason why this one haven't been checked in? This is pretty close to what windows does. Vitaliy Margolen > Fix ImageList_Read. This hopefully fixes these ugly images mostly on tool bars. > I'll continue to work on ImageList since ImageList_Replace, ImageList_Add, > ImageList_GetImageInfo and perhaps some other functions doesn't work right. > Vitaliy Margolen > changelog: > - dlls/comctl32/imagelist.c > fix ImageList_Read - the root cause of ugly toolbar icons > Index: dlls/comctl32/imagelist.c > =================================================================== [skip]

1 0

Compiling Wine sources with duplicated include parameters
by Rolf Kalbermatter 02 Apr '03

02 Apr '03

While downloading and compiling the latest CVS sources I noticed that the command line for each (most?) source files reads like gcc -c -I. -I. -I../../include -I../../include ............. or similar This is not a serious problem but the duplication of the two include parameters strikes me as odd and definitely unnecessary, making the command line unnecessarily long. Seems like something in the makefile generation is causing this. Rolf Kalbermatter

5 8

Unexpected message from winebuild...
by Kevin Cousins 02 Apr '03

02 Apr '03

...when attempting to build a WineLib application. Remember, I'm attempting to get something that will run-time link against a native DLL, so I take my code, run it by "winemaker", run "./configure", then "make", all with options I believe to be appropriate. In particular, given export WINEDIR=/home/kevin/wine, the root of my Wine source tree checked out from winehq CVS yesterday, and export DLLINCDIR=/home/kevin/include, then from within the directory containing the C source code for my simple console app I execute the following: $ winemaker --cuiexe -I${DLLINCDIR} -I${WINEDIR} [...snip...] $ ./configure --with-wine=${WINEDIR} \ --with-wine-dlls=${WINEDIR}/libs/dlls --srcdir=`pwd` \ --with-wine-libraries=${WINEDIR}/libs/wine:${WINEDIR}/libs/uuid:${WINEDIR}/libs/unicode [...snip...] $ make [...snip...] Until make executes, there seems to be no obvious problem (at least to my eyes), and even then, as the compilation happens, I get a nice file called "prog.o" written. However, as "winebuild" executes, I see the following: --- LD_LIBRARY_PATH="/home/kevin/wine/libs/wine:/home/kevin/wine/libs/unicode:$LD_LIBRARY_PATH" /home/kevin/wine/tools/winebuild/winebuild -fPIC -o prog.exe.spec.c --exe prog.exe -mcui prog.o -L/home/kevin/lib -L/home/kevin/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool could not open .def file for advapi32 --- I don't believe I even need anything from advapi32.dll.so, let alone most of the other Wine DLLs mentioned on the winebuild command line. Even if I hack the generated Makefile so as to remove mention of any Wine DLLs on the winebuild command line, winebuild still complains about not opening "...a .def file for ntdll". On a related note, the configure script generated by winemaker complains about test linking against -L${WINEDIR}/dlls -lntdll.dll and subsequent equivalent builtin DLLs such as -lkernel32.dll and -luser32.dll. My quick hack is merely to clone the symbolic links in ${WINEDIR}/dlls to add a "lib" prefix, vis: $ ( cd ${WINEDIR}/dlls ; ls -l *ntdll.dll* ) lrwxrwxrwx 1 kevin 18 Apr 1 15:29 ntdll.dll.so -> ntdll/ntdll.dll.so lrwxrwxrwx 1 kevin 18 Apr 1 15:29 libntdll.dll.so -> ntdll/ntdll.dll.so $ That keeps configure happy, but I wonder what I'm doing wrong. This is Wine built from CVS as of 20030401 (i.e. yesterday). Suggestions? Particularly for the wanted .def files. They're %^*&@# builtin DLLs! -- Kevin.

2 1

Re: What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Robert Shearman 02 Apr '03

02 Apr '03

> what happend to the stdole32.tlb patch that Robert sent around 22.1? It was rejected on the grounds that we shouldn't have binary files in CVS and we can't generate the .tlb files at the moment. Rob

1 0

Agent and threads
by Rein Klazes 02 Apr '03

02 Apr '03

Hi, Agent news/email client spawns a new thread for each news/mail retrieval command. Something in the last week causes these threads not to be waited upon, leaving hundreds of <defunct> wine processes lying around. I wonder if this is a known issue with the new thread implementation work in progress, or if it is worth investigating? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

CVS Statistics for academic research
by Riccardo 'Jack' Lucchetti 02 Apr '03

02 Apr '03

Hi all, this message was originally sent to Alexandre Juilliard; I am resending this to the list on his suggestion. I am a wine user and a regular mailing list lurker. Beside that, however, I earn my living as an academic econometrician (halfway between an economist and a statistician) and I was considering the idea of doing some econometric research on open source development. At least initially, I would focus on Wine, for a number or reasons, not least the fact that the wine project is largely unknown in the economics community. My problem is that the data I need for my analysis can be theoretically extracted from the mailing list archives, but this definitely exceeds my VERY limited perl skills. The data I'd need would, ideally, be in the form of a CSV file, a typical record of which would be DATE,PN,PLA,PLD,PCN,CN,CLA,CLD where PN = number of patches received on day DATE PLA = number of code lines added in patches PLD = number of code lines deleted in patches PCN = number of patches contributors (ie number of coders submitting patches on that particular day) CN = CVS commits CLA = number of lines added in CVS CLD = number of lines deleted in CVS Of course, the longer the time span the data cover, the larger my sample, the happier I am. I understand this isn't trivial. Is there anyone out there willing to help me? I know some perl, so maybe all I need is to get started somehow. Thanks in advance, and keep up the good work! ---------------------------------------------------------- Riccardo `Jack' Lucchetti Dipartimento di Economia Università di Ancona jack(a)dea.unian.it http://www.econ.unian.it/lucchetti

1 0

Re: Unexpected message from winebuild...
by juraj 02 Apr '03

02 Apr '03

Hi Kevin, I had similar problem with winemaker when I used winemaker's --wrap option. I hacked winemaker script (see attachment) and managed to get rid of "...could not open .def file for...". If you see it, the difference is that .dll extension was removed from libnames in makefiles. I.e. there is only kernel32 instead of kernel32.dll, and so on. This helped me to get rid of problem with missing .def file.The second adjustment is related to incorrect generation of wrapper exe spec.c file. However, I'm not sure it's correct hack (that's the reason I didn't post it to wine-patches yet) since I have still troubles with running wrapped application - simple hello world example. The problem I have is that GetProcAddress couldn't find the WinMain() of my hello world app. After a little debugging and inspection of .spec.c file it seems the problem is with winebuild and not with winemaker (__wine_spec_exports is resolved to NULL and that's bad...). But I need to investigate little more yet. Anyways I got information from #winehq irc channel that winemaker is beeing deprecated, and that I should try to use winegcc with winewrap instead. But I'm not sure whether these two guys are able to cope with wrapping. I wasn't able to find some documentation about them and winewrap alone throws segmentation fault in my current build (updated & build today, about 3 hours ago). --Juraj Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.63 diff -u -r1.63 winemaker --- tools/winemaker 27 Mar 2003 18:36:27 -0000 1.63 +++ tools/winemaker 31 Mar 2003 20:53:53 -0000 @@ -1001,7 +1001,7 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32", "user32" ]; push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; @@ -1650,7 +1650,6 @@ my $path=$_[0]; my $target=$_[1]; my $app_name=@$target[$T_NAME]; - $app_name=~ s/\.exe$//; return generate_from_template("$path${app_name}_wrapper.c","wrapper.c",[ ["APP_NAME",$app_name],

1 0

What happend to the Stdole2 / Stdole32 (RESEND) patch from Robert Shearman
by Uwe Bonnes 02 Apr '03

02 Apr '03

Hallo, what happend to the stdole32.tlb patch that Robertsent around 22.1? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: FindFirstFileExW
by Mike Hearn 02 Apr '03

02 Apr '03

I ran my test case on 98, and that produced a return value of 2 as well (same as XP), so unless my test case is stuffed up, I think this patch is correct. The test is attached, it's extremely simple. On Tue, 2003-04-01 at 16:37, Mike Hearn wrote: > > That sounds awfully much like the already pretty well-known Win9x vs. NT > > incompatibility in file not found GetLastError values. > > Awwww suckage. I thought that fix was too easy. File not found > differences are new to me. Well I have a little test case for this, I'll > email it home and find out what it returns on Win98. > > If so, then, how do you find out what version of windows we're supposed > to be emulating, so I can adjust the return value accordingly? > > > Please make sure this is indeed what we should do; I really think > > you'd break some Win9x programs when simply doing such a general replacement. > > Hmm, well, the old value appeared to break some NT programs. > > > As such, I suspect you did not "Correct" the error code returned; > > instead, you only fixed it "to please the other half" of Windows programs. > > ;-) > > Right. So we need to change the return value depending on the setting of > winver? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

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

Whither specmaker?
by Kevin Cousins 01 Apr '03

01 Apr '03

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel