July 2002 - Wine-Devel - list.winehq.org

Re: winedbg again :-)

by Eric Pouech

Max a écrit : > > Some questions about winedbg usability ! > > 1) - Would it difficult to add an options (something like SHOWREGS=on/off) > that allows to have regs displayed automatically after a breakpoint AND > after a NEXTI command ? I find it painful to have to issue NEXTI and > then INFO REGS each time.... remember old good ms-dos debugger !!! :-) the best way would be to enhance the display functions with somethings like display $regs not difficult > 2)- What about the possibility to set off-code breakpoints ? It happens often > that I must set a break (in asm code) that is in a DLL which isn't > already loaded... That gives a BAD ADRESS, of course. > Borland debugger accepts the breakpoints and set it when the code > gets loaded. Now the only way is to set breaks in dll-loading routine, > wait up to the wanted dll gets loaded and then put the break... awful ! OTOH, it's also very awful to set a bp on memory which isn't mapped yet... you cannot write on it :-) anyway, we could do something like we do now for bp setting (expressed as a string) and automatically set the bp on DLL loading (if we can) rather easy (just follow what's done for deferred bp) > 3)- And now the difficultest ! After solving the point 2, what about a way to > store/retrieve breakpoints settings from disk ? Finding a bug in asm code > often requires days (hmmm... nights !) of stepping, and a way to save > breakpoints settings would spare tons of notes on paper :-) that's a bit harder (especially, since we don't want the user to interact), but basically it's just setting the parser to read from a file stream instead of stdin A+

July 22, 2002

Re: winedbg again :-)

by David Laight

On Mon, Jul 22, 2002 at 11:36:38PM +0200, Max wrote: > Some questions about winedbg usability ! > > 1) - Would it difficult to add an options (something like SHOWREGS=on/off) > that allows to have regs displayed automatically after a breakpoint AND > after a NEXTI command ? I find it painful to have to issue NEXTI and > then INFO REGS each time.... remember old good ms-dos debugger !!! :-) >From recent experiences with a different debugger, displaying the changed register would probably be fine - and remind you what the intruction actually did (when you misread it). David -- David Laight: david(a)l8s.co.uk

July 22, 2002

Re: [Bug 889] - WINPOS_GetWinOffset() yields wrong offset

by Uwe Bonnes

>>>>> "Tony" == Tony Lambregts <tony_lambregts(a)telusplanet.net> writes: Tony> Alexandre Julliard wrote: >> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >>> No, >>> >>> it happens that patches get silently dropped... >>> >>> >> In which case you have to resubmit, until it either gets included or >> you get an explanation. We may someday have a patch tracking system >> that makes sure nothing ever gets dropped, but in the meantime people >> are expected to keep track of the patches they submit. >> >> >> Tony> Perhaps I was overly optomistic about having (constructive) Tony> comments. However I see no real problem with the current system Tony> of having each person keep track of their own patches. A silent Tony> drop may not be ideal but it is less of a hassle than a review Tony> process for each patch. At least at this point. I feel the thread was constructive... We now have clear instructions what to do and two resubmits, at least one triggered by that thread. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 22, 2002

Re: Winsock 2 functions

by Martin Wilck

Am Sam, 2002-07-20 um 22.35 schrieb Peter Lord: > But, the stumbling block is when the application starts to use network > operations, specifically WPUCompleteOverlappedRequest and > WSAAddressToStringA. Right now, these are unimplimented and the java > app crashes when trying to call them. > > Before I start looking into these in more detail (I've really no idea > what overlapped I/O is all about ...), does anyone plan to implement > these in the near future ? Overlapped IO means that you can schedule an IO request, keep on doing work, and receive the IO results later (unlike non-blocking IO, where you have to retry until data is available for reading or writing). There is overlapped IO in wine, although the operations are not strictly asynchronous (they seem to be, from the application's point of view). I took an effort a few months ago to implement the basics of Winsock2 overlapped IO, and AFAIK it works ok. WSAAddressToStringA() should be relatively trivial to code. WPU... functions are a different animal. They are at the downside of Winsock2, which is AFAIK completely unimplemented in Wine. In Winsock2 it is possible to register protocols as separate drivers. Actually, the Winsock2 API only works as a generic interface that passes requests to the respective protocol driver(s). Protocol drivers can be stacked and pass information up and down. In some situations a protocol driver needs to obtain information or use services from the generic layer, that's where the "WPU..." ("Winsock Provider Upcall") calls come into play. That is, WPU* functions are only relevant for externally registered protocols which are non-existent under Wine. It wouldn't make much sense to support them actually, because which network protocols are supported under Wine is dependent on what protocols the OS it is running on supports. This could be worked around by using raw sockets and re-implement the whole TCP/IP stack in Wine, but I guess this is not what we currently want to do. You should find out under which circumstances your app calls WPU... functions. Normally this should never happen because Wine has no registered Protocol drivers, all protocol handling is done internally, and WPU... is called from "below" Winsock where control flow should never get. It may be possible to setup a hackish primitive WSP/WPU interface in Wine that avoids crashing at calls of these functions while not really providing functionality. Even this, though, would require a fundamental clean-up of the current Winsock code. Ooops... after writing all this, I just read that WPUCompleteOverlappedRequest() is unique in that it is the only WPU... function directly exported by WS2_32.DLL... talk to me about consistency. Still I think calling the function is restricted to service providers, it is not for user-land. Does you code require special protocols to be installed, or does Java register some? Check the installed protocols on your Windows box in the Network control panel. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

July 22, 2002

configure broken

by Gerald Pfeifer

The following patch has broken configure revision 1.320 date: 2002/07/19 03:16:51; author: julliard; state: Exp; lines: +210 -80 Gregg Mattinson <gm138242(a)scot.canada.sun.com> - X11/extensions/shape.h requires X11/Xutil.h. - X11/XKBlib.h requires X11/Xlib.h. - net/if.h requires sys/socket.h. - netinet/ip.h requires sys/socket.h and sys/in_systm.h. - resolv.h requires sys/socket.h. which now fails to properly set HAVE_NET_IF_H on FreeBSD 4.6, even though there we *do* have /usr/include/sys/socket.h. This is, because on BSD one must not #include <sys/socket.h> without having #included <sys/types.h> before. Something like the following should fix this problem: Index: configure.ac =================================================================== RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.61 diff -u -3 -p -r1.61 configure.ac --- configure.ac 20 Jul 2002 20:17:13 -0000 1.61 +++ configure.ac 22 Jul 2002 06:58:49 -0000 @@ -983,7 +983,10 @@ AC_HEADER_STAT() dnl *** Check for net/if.h AC_CHECK_HEADERS(net/if.h,,, - [#if HAVE_SYS_SOCKET_H + [#if HAVE_SYS_TYPES_H + # include <sys/types.h> + #endif + #if HAVE_SYS_SOCKET_H # include <sys/socket.h> #endif]) Gerald

July 22, 2002

Re: ShellExecute patch

by Steven Edwards

> Hmm, the WinExec looks fairly easy but the WinExec16 appears to be a bit > more difficult to handle. Perhaps it could be handled more easily with > some sort of ifdef around those parts? Any suggestions? Sounds cool but it really depends on if Alexandre will accept the patch or not. At some point I will be add the configure option --no-win16 so just doing a #ifdef NO_WIN16 should be fine. Building on mingw already requires not including shell.c so I need to make the Makefile and configure changes anyway. Its not that important ATM so if it will be a problem we can wait till more ReactOS developers are interested in fixing it. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 21, 2002

Re: [Bug 889] - WINPOS_GetWinOffset() yields wrong offset

by Tony Lambregts

Alexandre Julliard wrote: >Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > >>No, >> >>it happens that patches get silently dropped... >> >> > >In which case you have to resubmit, until it either gets included or >you get an explanation. We may someday have a patch tracking system >that makes sure nothing ever gets dropped, but in the meantime people >are expected to keep track of the patches they submit. > > > Perhaps I was overly optomistic about having (constructive) comments. However I see no real problem with the current system of having each person keep track of their own patches. A silent drop may not be ideal but it is less of a hassle than a review process for each patch. At least at this point. Certainly having a patch for someone to look at will increase the likelyhood of some helpfull hints (or possiblely a better solution). If its really a hack job and totaly unacceptable then maybe you risk a flame, but it's probably still better than no patch. Tony Lambregts

July 21, 2002

Re: ShellExecute patch

by Duane Clark

Steven Edwards wrote: >> I guess I am not sure what the problem is with WinExec. Originally >> ShellExecuteEx used CreateProcessA and ShellExecute used WinExec, >> which simply calls CreateProcessA. I could certainly directly call >> CreateProcessA if that is preferable. > > > Yes, I tried to do that once before but could not get it to work > quite right as I am still learning how to program. Mingw cant import > from the Win16 api so CreateProcess needs to be used if we want to > have shell32 for testing under mingw or use under ReactOS. Hmm, the WinExec looks fairly easy but the WinExec16 appears to be a bit more difficult to handle. Perhaps it could be handled more easily with some sort of ifdef around those parts? Any suggestions?

July 21, 2002

Re: [Bug 889] - WINPOS_GetWinOffset() yields wrong offset

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > No, > > it happens that patches get silently dropped... In which case you have to resubmit, until it either gets included or you get an explanation. We may someday have a patch tracking system that makes sure nothing ever gets dropped, but in the meantime people are expected to keep track of the patches they submit. -- Alexandre Julliard julliard(a)winehq.com

July 21, 2002

Re: [Bug 889] - WINPOS_GetWinOffset() yields wrong offset

by Uwe Bonnes

>>>>> "wine-bugs" == wine-bugs <wine-bugs(a)winehq.com> writes: wine-bugs> http://bugs.winehq.com/show_bug.cgi?id=889 ------- Additional wine-bugs> Comments From tony_lambregts(a)telusplanet.net 2002-07-21 09:59 wine-bugs> ------- I am not that familiar with wine internals either, wine-bugs> but if you submit a patch to wine_patches(a)winehq.com, I'm wine-bugs> sure that if there is something wrong with it someone will wine-bugs> point it out. No, it happens that patches get silently dropped... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 21, 2002