November 2001 - Wine-Devel - list.winehq.org

Re: PATCH: xterm support for wineconsole

by eric pouech

> The old engine and its control codes does work basically fine if started > within an xterm. well, some functions key (like Fx) didn't work here with xterm... > I did not have any screenbuffer/window distinction, true. well, that's not needed. you need to refresh the content of the window when you switch screenbuffer, which your patch should do fine > And I do not consider it final. I am also still unhappy with it, since > it does not work with the screenbuffer/window paradigm yet. the window isn't there, but I don't see we could to it with a TERM interface > That it is > not ncurses is mostly due to the fact that I did not program ncurses yet. neither do I, but it doesn't seem too complex ;-) > I will try an ncurses port, but my time is rather limited :( no hurry > > a command line tool and use the current TERM for interacting with it), which > > would mean in wineconsole case passing to wineconsole the handles of current > > TERM. > > TERM support? as of today, when a Win32 pgm tries to use the Console API, two situations are handled: 1 pgm is run from wineconsole (and not wine), then a new window is associated and pgm is run inside 2 pgm is run with wine, and in this case, the std in/out handles are in fact the ones of the starting TERM so, the main idea was to enhance mode 2 and handle it from within wineconsole in that case, we don't know which TERM configuration is used (hence the benefits of (n)curses)). that's what I called TERM support (but, it seems to be misleading) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Nov. 28, 2001

Re: PATCH: xterm support for wineconsole

by Marcus Meissner

On Wed, Nov 28, 2001 at 08:46:47PM +0100, eric pouech wrote: > Marcus Meissner wrote: > > > > Hi, > > > > This patch adds a XTERM backend to wineconsole. > > > > Some problems: > > - In full screen text applications (like IDA), the cursor shows sometimes > > up in the wrong spot. > > - Scrolling does not work yet (so winedbg doesn't really work). > > - Uses config.h. > I still have some questions... > > from a technical point of view, what didn't you use an ncurse (for example) > lib to handle the TERM issues ? the old code you grabbed doesn't work > correctly for all TERM configurations... rewriting everythind isn't the > solution IMO Basically I just want my application to run. I need full screen, PC font, color, mouse support and speed. xterm was the easiest method to get it in this case. The old engine and its control codes does work basically fine if started within an xterm. It only enabled 'complex' output if it could start xterm. I did not have any screenbuffer/window distinction, true. And I do not consider it final. I am also still unhappy with it, since it does not work with the screenbuffer/window paradigm yet. That it is not ncurses is mostly due to the fact that I did not program ncurses yet. I will try an ncurses port, but my time is rather limited :( > from a more usage point of view, it seemed that TERM support for wineconsole > was more intended for supporting an existing UNIX console (like when starting > a command line tool and use the current TERM for interacting with it), which > would mean in wineconsole case passing to wineconsole the handles of current > TERM. TERM support? The old driver had knowledge of complex operations and switched on the xterm in this case. > furthermore, how to you plan to choose, when starting wineconsole, from > the Win32 and the xterm backend ? Dunno. > in other words, I'm more in favor of : > - Win32 backend for normal usage > - reusing current UNIX console when run in TERM mode (and not xterm), and with > the support of text mode lib (like ncurses) I'll think on it. Please discard the patch in the meantime. Ciao, Marcus

Nov. 28, 2001

Re: PATCH: xterm support for wineconsole

by eric pouech

Marcus Meissner wrote: > > Hi, > > This patch adds a XTERM backend to wineconsole. > > Some problems: > - In full screen text applications (like IDA), the cursor shows sometimes > up in the wrong spot. > - Scrolling does not work yet (so winedbg doesn't really work). > - Uses config.h. I still have some questions... from a technical point of view, what didn't you use an ncurse (for example) lib to handle the TERM issues ? the old code you grabbed doesn't work correctly for all TERM configurations... rewriting everythind isn't the solution IMO from a more usage point of view, it seemed that TERM support for wineconsole was more intended for supporting an existing UNIX console (like when starting a command line tool and use the current TERM for interacting with it), which would mean in wineconsole case passing to wineconsole the handles of current TERM. furthermore, how to you plan to choose, when starting wineconsole, from the Win32 and the xterm backend ? in other words, I'm more in favor of : - Win32 backend for normal usage - reusing current UNIX console when run in TERM mode (and not xterm), and with the support of text mode lib (like ncurses) A+

Nov. 28, 2001

Re: (no subject)

by eric pouech

"Ryan C. Stallings" wrote: > > Hello all, > I am new to the wine scene and would like to try my hand at a little wine > hacking. Are there any bugs out there that would be easy for a newbie to fix > while letting me learn a bit about the inner workings of wine? I have read > all the material about getting started developing, but I am just lacking a > bit of direction on what to work on :) > > Thanks for your help, > ryan you can also look at François call for volunteers 3 months ago (I removed the part which have been worked on) Easy: * PrgWin95/98: System metrics differ from the Win9x values #48: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=48 One day I'll fix this one... I swear. Unless you want to work on it first. In that case I'll provide you with my test application and dumps of the metrics for Win95, Win98, NT4, 2000, ... * The doc about the command line arguments and the config file is out of date. See TextCP, XVideoPort and Synchronous for instance. I'm sure there are plenty of other things that are out of date. * Metabug: Test Wine with the Common Control Spy Samples #239: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=239 Get the Common Control Spy samples and test Wine with them. You will need the native comctl32 dll but you can do the tests without rebooting between each test or using two computers. * PrgWin95: Listbox getting a recessed border instead of a flat one #56: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=56 (I can provide you with the sample application) This one my be fixed, to check... * I think it would be nice to add a tool that displays the dlls version information like 'About' does in the windows explorer. I have some code you could use as a starting point and I think it could be merged with winver. In fact this would be almost stabdard windows programming. * Tabs are missing their inner border #243: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=243 There's a bug in the drawing of the border of the common control tabs. Fixing each of the four instances of the code is easy. It would be interesting to find a way to factorize some of this code. Medium (I expect these would take longer or be a bit harder) * Quickbooks Pro Timer does not accept date (GetCalendarInfoA error) #276: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=276 GetCalendarInfoA/W are not implemented yet. They involve quite a lot of internationalisation aspects, but providing a first implementation that at least handles the common cases should be feasible. * CreateIcon does not resize bitmaps #175: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=175 I did a similar fix somewhere some time ago. I can provide a sample application and I might be able to point you in the right direction. * winemaker: 'winemaker --nomfc' does not have the intended effect #227: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=227 * winemaker: Ignores the '--with-{mfc,wine}' options once they are cached #225: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=225 If you're familiar with autoconf and know how configure scripts should behave... * StrokePath ignores PS_JOIN_xxx #11: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=11 This should not be too difficult to fix but it would certainly help if you are familiar with GDI. * Checking the differences between what's in the Windows dlls and what's in our spec files... and fix the contents of our spec files as appropriate. I already have a list of all the APIs in each of the dlls for Win95, Win98, NT4 and Wine2000, plus a script that can show the differences. * Enhancing the above perl script. In particular it could be made smarter wrt. detecting whether an API is exported by ordinal or not. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Nov. 28, 2001

Re: fix triggers crash

by Michael Stefaniuc

Odd, to replace to myself but I found the offending bug (needed to implement ImageList_GetDragImage). The patch is on it's way to wine-patches. bye michael On Tue, Nov 27, 2001 at 01:46:29AM +0100, Michael Stefaniuc wrote: > I found a bug in ImageList_Merge (the count of the images in the > imagelist wasn't set) and the trivial fix > Index: imagelist.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v > retrieving revision 1.43 > diff -u -r1.43 imagelist.c > --- imagelist.c 2001/09/10 23:09:04 1.43 > +++ imagelist.c 2001/11/26 22:37:31 > @@ -1918,6 +1918,7 @@ > > DeleteDC (hdcSrcImage); > DeleteDC (hdcDstImage); > + himlDst->cCurImage = 1; > } > > return himlDst; > =================================================================== > triggers with FreeSolitaire (got it from tucows.com) following error > (with crash): > X Error of failed request: BadAlloc (insufficient resources for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Serial number of failed request: 19761 > Current serial number in output stream: 19852 > > This happens with the cvs code from today and I'm pretty shure that it > worked perfectly with the cvs code from two days before. And without the > patch above the error dosn't get triggered. This seems strange because > the error seems to occur in x11drv.StretchBlt and ImageList_Merge dosn't > call StretchBlt. > To reproduce the crash start FreeSolitaire with the patch above applied, > select a solitaire game and start dragging a card around and wine will > crash. With --debugmsg +relay it takes sometimes longer to trigger the > bug, just release the card I try dragging an other card (i never needed > to release the second card yet, wine crashed before). > I've attached the last 1000 lines of relay output, hope that helps. > > bye > michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Nov. 28, 2001

Re: Another pack4 issue (fwd)

by Francois Gouget

On Fri, 23 Nov 2001, Dmitry Timoshkov wrote: > "Francois Gouget" <fgouget(a)free.fr> wrote: [...] > It's because according to ntddk.h from NT4 DDK info->LastWriteTime > is LARGE_INTEGER. Please look at my patch a bit carefully. Sorry, I missed that part (I was in a hurry at the time, it's always bad). > > + UINT type; > > + LPVOID pvFilter; > > } HDITEMA, *LPHDITEMA; > > > > I don't see these two fields on Windows. Same thing for the W > > version. That's with the VC 6 headers. > > It's in July 2000 PlatformSDK as well as in MSDN online. It means that the Visual C++ 6.0 SP3 headers are too old and cannot be trusted anymore. Still, this kind of change (adding new fields) worries me. Of course we have to add these fields but it means we must be very careful not to access the extra fields unless we know they are present. For instance in HEADER_GetItemA we return information in an HDITEMA structure allocated by the application. Currently it is correct, but let's just imagine that someone adds a 'memset(phdi,0,sizeof(*phdi))' (as is quite commonly done). If the application has been compiled with an old version of the headers then we will have a buffer overflow -> crash. So the handling of such structures requires special care. It may be a good idea to record somewhere that the size of the structure has changed. Maybe in the header as follows: ... /* Fields added for IE 5 */ UINT type; LPVOID pvFilter; } HDITEMA, *LPHDITEMA; or even full-blown '#if _WIN32_IE >= xxx' though we don't do this sort of thing usually. Well, it's a pretty good work in any case and is quite likely to fix a lot of mysterious crashes. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Nov. 27, 2001

SetActiveWindow problem

by bperkins＠netspace.org

Sorry, I'm new to wine hacking, so bear with me. I was playing around a bit the other day trying to see if the tahni deskmate worked at all. I tried to run the installer (tahnisetup.exe available at tahni.com) It would run, and then crash with a stack overflow. I've attached the sequence in a backtrace that was repeated many times at the bottom. It's wine-20011108, BTW. Since I don't have the source to tahnisetup it made things a bit tricky to decipher. My guess was(is) that the program is trying to the window as active, which sends a message to the program. It sees that it's not active, so it again tries to set it as be active, which eventually causes a stack overflow. My awful hack was to just put a sanity counter in SetActiveWindow and return true after being called a certain number of times. This seems to work, as in it causes to program to get farther (it gets stuck on something else). Presumably one could check if it was being called recursively. I realize that this isn't really useful info, but I was curious to see if I was right about this, or if anyone had an insight. Am I right or did I just get lucky with the hack? 25246 0x0040266f (tahnisetup.exe..text+0x166f in E:\tahnisetup.exe) (ebp=437e6444) 25247 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6468) 25248 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6498) 25249 0x407c95ca (CallWindowProcA+0x4a(func=0x4025b8, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2623] in libuser32.so) (ebp=437e64cc) 25250 0x4097b54c (FILEDLG_CallWindowProc+0x54(lfs=0x40400dbc, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:294] in libcomdlg32.so) (ebp=437e64f4) 25251 0x4097d944 (FileOpenDlgProc+0x78(hWnd=0x1002f, wMsg=0x6, wParam=0x0, lParam=0x10026) [filedlg.c:1440] in libcomdlg32.so) (ebp=437e651c) 25252 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e6540) 25253 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e6570) 25254 0x407c91f4 (WINPROC_CallProc32WTo32A+0x80(func=0x4097d8cc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2435] in libuser32.so) (ebp=437e6598) 25255 0x407c972b (CallWindowProcW+0xab(func=0x430c0984, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2675] in libuser32.so) (ebp=437e65cc) 25256 0x4079f744 (DefDlgProcW+0x48(hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [defdlg.c:389] in libuser32.so) (ebp=437e65f8) 25257 0x407c3a67 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=437e661c) 25258 0x407c3af2 (WINPROC_CallWndProc+0x82(proc=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:173] in libuser32.so) (ebp=437e664c) 25259 0x407c9152 (WINPROC_CallProc32ATo32W+0x7e(func=0x4079f6fc, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2412] in libuser32.so) (ebp=437e6674) 25260 0x407c9647 (CallWindowProcA+0xc7(func=0x430c0259, hwnd=0x1002f, msg=0x6, wParam=0x0, lParam=0x10026) [winproc.c:2643] in libuser32.so) (ebp=437e66a8) 25261 0x4076957e (call_window_proc+0xf2(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, unicode=0x0) [message.c:1146] in libuser32.so) (ebp=437e6704) 25262 0x4076a1af (SendMessageTimeoutA+0xdf(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026, flags=0x0, timeout=0xffffffff, res_ptr=0x437e6788) [message.c:1577] in libuser32.so) (ebp=437e6764) 25263 0x4076a317 (SendMessageA+0x37(hwnd=0x1002f, msg=0x6, wparam=0x0, lparam=0x10026) [message.c:1622] in libuser32.so) (ebp=437e6798) 25264 0x407c2e92 (WINPOS_SetActiveWindow+0x196(hWnd=0x10026, fMouse=0x0, fChangeFocus=0x1) [winpos.c:1282] in libuser32.so) (ebp=437e67f0) 25265 0x407c229a (SetForegroundWindow+0x7a(hwnd=0x10026) [winpos.c:781] in libuser32.so) (ebp=437e680c) -- "Only CmdrTaco can save us now" -- The Register Brian Perkins bperkins(a)netspace.org

Nov. 27, 2001

Re: (no subject)

by David Hammerton

Its also a good idea to hang out in #winehq on irc.openprojects.net, then you can nag the more experienced developers and pick up problems that people report and attempt to fix them :). David On Tue, 27 Nov 2001 11:19:01 +0100, Andreas Mohr wrote: | On Mon, Nov 26, 2001 at 08:02:32PM -0500, Ryan C. Stallings wrote: | > Hello all, | > I am new to the wine scene and would like to try my hand at a little wine | > hacking. Are there any bugs out there that would be easy for a newbie to fix | > while letting me learn a bit about the inner workings of wine? I have read | > all the material about getting started developing, but I am just lacking a | > bit of direction on what to work on :) | Well, personally I think that trying tons of programs is the best way | to start hacking on wine. | That way you'll soon find a feature that's rather easy to implement/fix, | and thus you'll gather more experience. | See search.microsoft.com for docu. | | -- | Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany | Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/ | | | | | -- David Hammerton aka crazney Victoria, Australia http://crazney.net/

Nov. 27, 2001

Re: (no subject)

by Andreas Mohr

On Mon, Nov 26, 2001 at 08:02:32PM -0500, Ryan C. Stallings wrote: > Hello all, > I am new to the wine scene and would like to try my hand at a little wine > hacking. Are there any bugs out there that would be easy for a newbie to fix > while letting me learn a bit about the inner workings of wine? I have read > all the material about getting started developing, but I am just lacking a > bit of direction on what to work on :) Well, personally I think that trying tons of programs is the best way to start hacking on wine. That way you'll soon find a feature that's rather easy to implement/fix, and thus you'll gather more experience. See search.microsoft.com for docu. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Nov. 27, 2001

(no subject)

by Ryan C. Stallings

Hello all, I am new to the wine scene and would like to try my hand at a little wine hacking. Are there any bugs out there that would be easy for a newbie to fix while letting me learn a bit about the inner workings of wine? I have read all the material about getting started developing, but I am just lacking a bit of direction on what to work on :) Thanks for your help, ryan

Nov. 27, 2001