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

Re: Debugging X errors?

by Segin

Andreas Mohr wrote: >Hi, > >On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: > > >>OK, I've had it. The X errors I'm running into are keeping >>me from getting work done. They might be due to >>bugs in my X server (ubuntu 05.10), but while I wait >>for the next release of ubuntu, maybe I could try >>to track them down anyway. >> >> >Good idea ;) > > > >>It looks like the procedure for diagnosing X errors such as >> >>X Error of failed request: BadAtom (invalid Atom parameter) >> Major opcode of failed request: 17 (X_GetAtomName) >> Atom id in failed request: 0x0 >> Serial number of failed request: 468 >> Current serial number in output stream: 470 >>in Wine is to do >> WINEDEBUG=+synchronous >> export WINEDEBUG >>and then use winedbg to run the apps, and get a backtrace >>when the error occurs. I'll try that. >> >> > >Random semi-helpful notes I've been writing down about that: >---------- >SOLUTION: > > gdb: b _XError > b wxXErrorHandler > > How do I trace the cause of an X11 error such as BadMatch? > > When a fatal X11 error occurs, the application quits with no stack trace. > To find out where the problem is, put a breakpoint on g_log (b g_log in > gdb). > > >Unexpected async reply" is commonly due to a multi-threaded app with >Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from >a signal handler. > >http://www.rahul.net/kenton/perrors.html > >try: >XSynchronize(display, True); >for debugging > > >Maybe can happen if app is overwriting Xlib-owned memory... >---------- > > >Andreas Mohr > > > > > Do this as either your user or as root (via sudo): V -version Email us the ful output (drag the mouse over the top line to the next line that is your shell and middle click in yor email client to paste) sorry if i treated you like a idiot, but some people don't realize that X has 2 clipboards per se, one done by X itself, and another handled by QT/GTK+/Wine (Try this: select some text in Wine, and middle click in a Xterm, nothing happens! Go back to the Windows app, tell it to copy the text, and try to paste it into the xterm, nothing again! I think it's a bug IMHO)

March 28, 2006

Re: Debugging X errors?

by Phil Krylov

On Tue, 28 Mar 2006 15:25:26 -0500 Segin <segin2005(a)gmail.com> wrote: >(Try this: select some text in Wine, and middle click in a > Xterm, nothing happens! Go back to the Windows app, tell it to copy the > text, and try to paste it into the xterm, nothing again! I think it's a > bug IMHO) You need to set the Wine registry entry X11 Driver/UsePrimarySelection to 'Y'. I submitted a patch for Winecfg to do it, but it wasn't accepted and it was a long time ago... -- Ph.

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Kuba Ober

> Python!!?! i almost did a C | N > K (that would be cola, pepsi rather, > through nose to keyboard) > > ok ok ok ok although i almos-t ruined a perfectly free and good > keyboard, i don't like python cause i don't know it, and the learning > curve has been... dreadful. > > Can't we do this in C? I hope you meant C++, unless you think it's productive to do a poorly documented and bug-ridden reimplementation of half of C++ standard library* everytime you want to do something other than a hello world application. Actually, for tools like wine doors it'd be more concise to do the logic in Lisp, rather than Python or C++. The problem is that wine-hackers-wise, I would bet we have way more people skilled in C++ than people skilled in Python than people skilled in Lisp, so methinks that C++ is the right way to go, just because of the sheer number of developers available C++ (and Python) gives you an advantage of being able to directly** leverage Qt to have wine doors that can either work as a regular unix application, or a windows application under wine itself. Heck, it'd work just fine on Intel Mac boxen, and on PPC Mac boxen whenever wine will utilize some emulator platform. Cheers, Kuba * yes, it's a slightly modified quote from somewhere else ;) ** as opposed to say doing only the GUI in C++ and logic in Lisp

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Segin

Kai Blin wrote: >* Segin <segin2005(a)gmail.com> [27/03/06, 21:32:29]: > > >>There is one reason, inarguable (if you reply to this you have a IQ of >>0) as to why WineTools is useless: Most of the WineTools 'magic' is in >>it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, >>WineTools is utterly useless and has no point in existing AT ALL, PERIOD. >> >> > >So, I seem to have an IQ of 0, but still I at least seem to be able to >use a mail client. Seems like these things really are easy to use these >days. > > Erm, no, you have a typing monkey using the mail client for you :-P >I haven't used winetools in a long while, but back when I did, I could >use it to run programs I couldn't run on plain wine myself. If I'm >running an older system, I can still use that exact version of wine a >winetools, and that program is still running. Could you explain on how >that gives it "no point in existing AT ALL, PERIOD"? > > > How? The biggest thing that makes WineTools work is it's ability to set DLLOverrides via a config file that Wine no longer acknoleges, therfore that is gone, and only a few things will work via WineTools, if at all. You can't install IE with WineTools (You can with IEs4Linux, and if you are good enough, you can merge the ies4linux wine setup into the main one without fubaring it. I did. I wouldn't suggest that regular user do this, though.) I digress, and let you know that the programs installable via it's 'database' are outdated, and some have broken URLs! >Could I assume that the 2.4 Linux Kernel I'm running on my router >doesn't have any point of existing, either, just because it's outdated? > > > LOLFAIL. 2.4 is no more "older" than 2.6 in reflect that is it still in active development, and the developers will respond to commentary about it. The same cannot be said about winetools. >Sheesh, if people spent as much time fixing winetools (or wine, for that >matter) as they did writing emails about why winetools is bad, this >discussion would be utterly useless and without a point AT ALL, PERIOD. > > > Hey!! That's my line! >Kai > Segin

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Segin

Marcus Meissner wrote: >On Tue, Mar 28, 2006 at 11:50:17AM +0200, Joris Huizer wrote: > > >>Segin wrote: >> >> >>>There is one reason, inarguable (if you reply to this you have a IQ of >>>0) as to why WineTools is useless: Most of the WineTools 'magic' is in >>>it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, >>>WineTools is utterly useless and has no point in existing AT ALL, PERIOD. >>> >>> >>> >>:-) I'd think the more likely conclusion is, winetools really needs some >>upgrading; (it seems, as long as it's hard for newbies to use wine with >>commonly-used windows apps, there is a need for some tool to ease >>installing them such that they can use it - in the current situation >>there is probably still a need for such tool) >> >> > >The original statement is not true, the magic done by winetools is not just >in the config file. > >Ciao, Marcus > > > > > I know that, which is why i was careful in choosing the word 'most' :-)

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Karl Lattimer

> Am Mo, Mär 27, 2006 at 09:32:29 -0500 schrieb Segin: >> There is one reason, inarguable (if you reply to this you have a >> IQ of >> 0) as to why WineTools is useless: Most of the WineTools 'magic' >> is in >> it's ~/.wine/config file, which Wine no longer uses/acknoleges, >> thefore, >> WineTools is utterly useless and has no point in existing AT ALL, >> PERIOD. IMHO winetools has a still useful feature, and that is it allows users to easily create an initial wine drive, configure and install some applications and otherwise assist in new wine users to get to grips with wine in an easy and I use this term loosely 'user friendly' way. The problem is that wine tools hasn't adhered to any usability guides and doesn't provide a community orientated feedback, or use the community to gain information about applications. The design of winetools was created initially by frank of frankscorner but he isn't a UI programmer, just an every day hacker. The fact that the whole application is written in bash using Xdialog is a bad start, the code scared me, 3000+ lines of bash. I'm aiming to change this, I welcome any help especially in python. The main aim of the project I am working on with a couple of new found friends, is to improve accessibility of wine to new linux users to help get people switch from windows to linux. This aim is shared among the wine developers and users I believe. And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, and I would rebut that you are in fact the one of lower than average intellect as it requires a certain type of stupidity to insult your peers in general terms. K, PS, a little about the projects I have worked on before, I wrote gnome-settings-visualeffects a while back, and got too many flames and crank emails too many eye candy enthusiasts asking dumb questions so eventually i scrapped it. I also worked on the new freevo webserver2 code which was displayed this year at CeBIT. I work on human interfaces every day and I'm looking to bring some gnome HIG zen to winetools, oh and a snappy new name... wine doors ;) (say it quickly three times)

March 28, 2006

Re: Russian translation for uninstall application

by Dmitry Timoshkov

"Anatoly A. Kazantsev" <jim-crow(a)rambler.ru> wrote: > + * Uninstaller (Russain Resources) Please fix the above typo and the translation of the word "registry" to match the commonly used russian word and resend the patch. -- Dmitry.

March 28, 2006

"Unhandled exception: floating point stack check" early in program?

by Dan Kegel

See the winedbg session below. Is it normal for winedbg to complain about floating point stuff when the program, run normally, doesn't? Using either 'cont' or 'pass' at this point just repeats the same message. Hints welcome. Thanks, Dan dank(a)lappy:~$ ~/wine/programs/winedbg/winedbg ~/.wine/drive_c/putty/putty.exe WineDbg starting on pid 0x42 start_process () at /home/dank/wine/dlls/kernel/process.c:845 0x7fcbd259 start_process+0xb9 [/home/dank/wine/dlls/kernel/process.c:845] in ker nel32: subl $12,%esp 845 ExitProcess( entry( peb ) ); Wine-dbg>c First chance exception: floating point stack check in 32-bit code (0x7f7a0d90). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7f7a0d90 ESP:7fafea58 EBP:7fafea90 EFLAGS:00010246( - 00 -RIZP1) EAX:7fdc2400 EBX:7f7c00b0 ECX:00000000 EDX:7fdc2400 ESI:7fafeaac EDI:00000002 Stack dump: 0x7fafea58: 7fafeb40 0000ffff 7fafea90 7f7c00b0 0x7fafea68: 0000005c 0000007c 7fafea90 7f79e0c6 0x7fafea78: 7f7c8f40 7fd868e8 0000005c 7f34e09c 0x7fafea88: 63656a62 0000007c 7fafeac0 7f31a40f 0x7fafea98: 000002e4 7fafeaac 00000002 7fafeb40 0x7fafeaa8: 7fafeb78 00000000 00000000 00000007 0200: sel=1007 base=7fec2000 limit=00001fff 32-bit rw- Backtrace: =>1 0x7f7a0d90 LPtoDP+0x50(hdc=0x2e4, points=0x7fafeaac, count=0x2) [/home/dank/wine/dlls/gdi/mapping.c:132] in gdi32 (0x7f7a0d90) 2 0x7f31a40f X11DRV_XWStoDS+0x3f(physDev=0x7fdc2558, width=0x7) [/home/dank/wine/dlls/x11drv/graphics.c:307] in winex11 (0x7f31a40f) 3 0x7f33e89d X11DRV_XRender_SelectFont+0x5d(physDev=0x7fdc2558, hfont=0x7c) [/home/dank/wine/dlls/x11drv/xrender.c:554] in winex11 (0x7f33e89d) 4 0x7f3390e0 X11DRV_SelectFont+0xce0(physDev=0x7fdc2558, hfont=0x7c, gdiFont=0x7fdb7110) [/home/dank/wine/dlls/x11drv/xfont.c:3234] in winex11 (0x7f3390e0) 5 0x7f78c52f FONT_SelectObject+0x6f(handle=0x7c, obj=0x7fd868d8, hdc=0x2e4) [/home/dank/wine/dlls/gdi/font.c:587] in gdi32 (0x7f78c52f) 6 0x7f79fb20 SelectObject+0x70(hdc=0x2e4, hObj=0x7c) [/home/dank/wine/dlls/gdi/gdiobj.c:1168] in gdi32 (0x7f79fb20) 7 0x7f77e9f7 DC_InitDC+0x77(dc=0x7fdc2400) [/home/dank/wine/dlls/gdi/dc.c:204] in gdi32 (0x7f77e9f7) 8 0x7f7801e9 CreateDCW+0x129(driver=0x7f34146c, device=0x0, output=0x0, initData=0x0) [/home/dank/wine/dlls/gdi/dc.c:655] in gdi32 (0x7f7801e9) 9 0x7f304f27 X11DRV_GetDCEx+0x387(hwnd=0x10020, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/x11drv/dce.c:214] in winex11 (0x7f304f27) 10 0x7f86acaa GetDCEx+0x3a(hwnd=0x0, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/user/painting.c:476] in user32 (0x7f86acaa) 11 0x7f86ad6c GetDC+0x3c(hwnd=0x0) [/home/dank/wine/dlls/user/painting.c:490] in user32 (0x7f86ad6c) 12 0x7f82ed0a GetDialogBaseUnits+0x3a [/home/dank/wine/dlls/user/dialog.c:1411] in user32 (0x7f82ed0a) 13 0x7f830c8b DIALOG_CreateIndirect+0x2b(dlgTemplate=<register not in topmost frame>, dlgProc=0x4340e2, param=0x0, unicode=0x0, modal=0x0) [/home/dank/wine/dlls/user/dialog.c:474] in user32 (0x7f830c8b) 14 0x7f83254e CreateDialogIndirectParamAorW+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0, flags=0x2) [/home/dank/wine/dlls/user/dialog.c:697] in user32 (0x7f83254e) 15 0x7f83264e CreateDialogIndirectParamA+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:706] in user32 (0x7f83264e) 16 0x7f8326c6 CreateDialogParamA+0x66(hInst=0x400000, name=0x6f, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:670] in user32 (0x7f8326c6) 17 0x00434801 in putty (+0x34801) (0x00434801) 18 0x442922a7 (0x442922a7) 19 0x00000000 (0x00000000) 20 0x00000000 (0x00000000) Wine-dbg> ? -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 28, 2006

Re: Debugging X errors?

by Andreas Mohr

Hi, On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: > OK, I've had it. The X errors I'm running into are keeping > me from getting work done. They might be due to > bugs in my X server (ubuntu 05.10), but while I wait > for the next release of ubuntu, maybe I could try > to track them down anyway. Good idea ;) > It looks like the procedure for diagnosing X errors such as > > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 17 (X_GetAtomName) > Atom id in failed request: 0x0 > Serial number of failed request: 468 > Current serial number in output stream: 470 > in Wine is to do > WINEDEBUG=+synchronous > export WINEDEBUG > and then use winedbg to run the apps, and get a backtrace > when the error occurs. I'll try that. Random semi-helpful notes I've been writing down about that: ---------- SOLUTION: gdb: b _XError b wxXErrorHandler How do I trace the cause of an X11 error such as BadMatch? When a fatal X11 error occurs, the application quits with no stack trace. To find out where the problem is, put a breakpoint on g_log (b g_log in gdb). Unexpected async reply" is commonly due to a multi-threaded app with Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from a signal handler. http://www.rahul.net/kenton/perrors.html try: XSynchronize(display, True); for debugging Maybe can happen if app is overwriting Xlib-owned memory... ---------- Andreas Mohr

March 28, 2006

Debugging X errors?

by Dan Kegel

OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Joachim von Thadden

Am Mo, Mär 27, 2006 at 09:32:29 -0500 schrieb Segin: > There is one reason, inarguable (if you reply to this you have a IQ of > 0) as to why WineTools is useless: Most of the WineTools 'magic' is in > it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, > WineTools is utterly useless and has no point in existing AT ALL, PERIOD. No need to BELLOW! What you are writing is definitely not true. WineTools does not use a config. It uses the registry. Otherwise it would work like plain Wine as this is ignoring the config. And then there would not be a thread about the DLLOverrides it uses. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Kai Blin

* Segin <segin2005(a)gmail.com> [27/03/06, 21:32:29]: > There is one reason, inarguable (if you reply to this you have a IQ of > 0) as to why WineTools is useless: Most of the WineTools 'magic' is in > it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, > WineTools is utterly useless and has no point in existing AT ALL, PERIOD. So, I seem to have an IQ of 0, but still I at least seem to be able to use a mail client. Seems like these things really are easy to use these days. I haven't used winetools in a long while, but back when I did, I could use it to run programs I couldn't run on plain wine myself. If I'm running an older system, I can still use that exact version of wine a winetools, and that program is still running. Could you explain on how that gives it "no point in existing AT ALL, PERIOD"? Could I assume that the 2.4 Linux Kernel I'm running on my router doesn't have any point of existing, either, just because it's outdated? Sheesh, if people spent as much time fixing winetools (or wine, for that matter) as they did writing emails about why winetools is bad, this discussion would be utterly useless and without a point AT ALL, PERIOD. Kai -- Kai Blin, (blin at gmx dot net) Conversation enriches the understanding, but solitude is the school of genius.

March 28, 2006

Re: I have a complaint about the website

by Francois Gouget

On Mon, 27 Mar 2006, Philip V. Neves wrote: [...] > Although I accept the fact that this is mostly true I believe that is > a good argument for creating the Linux OS and other OS's not for > creating wine. With the wine project you are bringing the homogenious > population to the Linux community. I agree with you that operating system diversity is only part of the equation, and that application diversity is important too. But even so I think Wine is good for diversity. * Promoting application diversity means promoting alternatives to the most popular Windows applications. That's a good argument for the development of, not Linux, but Firefox, Open Office, etc. But it does not mean that it is bad to run more obscure Windows applications, whether in Wine or on Windows, especially if they are alternatives to near Monopoly ones. In fact, running Open Office or WordPerfect Office on Windows is good for application diversity too. * There would be a good argument against Wine, from an application diversity point of view, if it was only meant to run monopoly applications. But this is not the case. While interest in getting popular Windows applications is inevitably higher than interest in getting obscure Windows applications running, Wine can and is used to run some fairly obscure Windows applications. My favorite example being MDL Chime<g> (http://www.codeweavers.com/compatibility/browse/name/?app_id=95) * Without Wine, anyone who needs a even a single Windows application has no choice but to run it on Windows. This reinforces the >90% operating system Windows monoculture. It also reinforces the Internet Explorer, Outlook Express, Windows Media Player and MSN Messenger monocultures because if you're running Windows they're just there, so why not use them too? At least if you are running a Windows application on Linux, you are more likely to just run this one application you need in Linux and prefer native applications for the rest of your activities. And that's good for application diversity. * Viruses and worms don't just exploit application bugs. They also exploit security bugs in the OS libraries used by the applications. While Wine strives to be API compatible, being security-bug compatible has never been a goal and is not needed. Security-bug compatibility is not even likely as providing the same buffer overflows would require work and an intent to do so (though I'll grant you that security-bug-by-design issues are more likely to be replicated, *cough* EMF *cough*). So even running a monopoly application in Wine increases the ecosystem's diversity, if only a bit. * Finally, even if they manage to run in Wine, a lot of Windows malware will see their nastiness greatly reduced. For instance, on Windows, keyboard loggers arrange to be started at boot time. On Linux they will not be started until you start Wine, and even then, only if we ever decide to simulate a Windows boot before starting any Windows application. In other words, even once installed, a Windows keyboard logger would essentially never be run in a Wine environment. Similarly, Windows rootkits would only be able to hide themselves and their payload from other Windows applications, not from the Unix user. In effect this means they would fail to 'work as advertised' (i.e. hide from the user) even if they did run properly in Wine. And that's a big if: since rootkits mostly work by patching the Windows kernel it is highly unlikely that they would ever manage to run at all in the first place. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Marcus Meissner

On Tue, Mar 28, 2006 at 11:50:17AM +0200, Joris Huizer wrote: > Segin wrote: > >There is one reason, inarguable (if you reply to this you have a IQ of > >0) as to why WineTools is useless: Most of the WineTools 'magic' is in > >it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, > >WineTools is utterly useless and has no point in existing AT ALL, PERIOD. > > > > :-) I'd think the more likely conclusion is, winetools really needs some > upgrading; (it seems, as long as it's hard for newbies to use wine with > commonly-used windows apps, there is a need for some tool to ease > installing them such that they can use it - in the current situation > there is probably still a need for such tool) The original statement is not true, the magic done by winetools is not just in the config file. Ciao, Marcus

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Joris Huizer

Segin wrote: > There is one reason, inarguable (if you reply to this you have a IQ of > 0) as to why WineTools is useless: Most of the WineTools 'magic' is in > it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, > WineTools is utterly useless and has no point in existing AT ALL, PERIOD. > :-) I'd think the more likely conclusion is, winetools really needs some upgrading; (it seems, as long as it's hard for newbies to use wine with commonly-used windows apps, there is a need for some tool to ease installing them such that they can use it - in the current situation there is probably still a need for such tool)

March 28, 2006

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Ok so now say with Steam and all of it's games - it will be almost 100% > unusable! Because we still haven't fixes managed/unmamaged windows. And > Steam itself would be on top of everything. So the way people were able > to work-around this is by putting Steam into virtual desktop. Now that > means their game will run in the same desktop as well. We could add some sort of per-app setting again, though it wouldn't work quite the same, apps in different desktops are a lot more isolated now. But if the only use for it is to work around managed mode bugs then it's probably not worth it, better to spend time fixing the real problem. > Also I remember some users were using other two parameters of the desktop > (top left corner - changing manually in the registry). I didn't seen > anything that indicates they are still supported with this patch. No, that's no longer supported. It shouldn't be too hard to add it back if you want it. -- Alexandre Julliard julliard(a)winehq.org

March 28, 2006

Re: setupapi: Test loading an exe from the system directory with SetupOpenInfFile

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > All the handling is in place for this to (mostly) work in > SetupOpenInfFileW. We call > CreateFile("c:\\windows\\system32\\winver.exe", ..., > OPEN_EXISTING...), but that fails, returning INVALID_HANDLE_VALUE. > winver.exe is in drive_c/windows/system32 as a symlink to the > installed winver.exe.so. Should a call to CreateFile on a symlink > fail? If the symlink is broken, yes. Note that it's no longer supposed to be a symlink, you should probably remove it and re-run wineprefixcreate. That said, I'm not quite sure why you'd want to open an exe with SetupOpenInfFile... -- Alexandre Julliard julliard(a)winehq.org

March 28, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > Anyway, I'm not familiar enough with the Wine protocol to write such > code, not at least without much help from you. So, should I try it, > or is it easy enough for you to code it yourself? Well, it's not a trivial fix, I don't think I'll have time to work on that in the near future, so you'll probably have to do it yourself... -- Alexandre Julliard julliard(a)winehq.org

March 28, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

On 06/03/27 at 18:19:44 (+0200), Alexandre Julliard wrote: > Petr Tesarik <hat(a)tesarici.cz> writes: > > > That means that Windows XP creates a new thread in the given process > > and breaks it at DbgBreak(). > > > > Does this mean that we may avoid sending SIGTRAP altogether? > > Creating a new thread is probably even harder, but yes we can > certainly avoid SIGTRAP. One possible way is to use SIGUSR1 to change > the thread context to simulate a call to DbgBreakPoint. I'm afraid one day we'll have to provide a way to create threads in other processes (this functionality is already missing from RtlCreateUserThread), but I guess this is not a current issue. That means that for the time being, we could write the DbgBreakPoint() hack and add a FIXME to the code that in fact a thread should have been created. You know, the trouble is that under Windows XP, you would call GetThreadContext() on the original thread (not the newly created one) and get the correct register values (including EIP), but this way you get the EIP of DbgBreakPoint(). Or, do I miss something? Anyway, I'm not familiar enough with the Wine protocol to write such code, not at least without much help from you. So, should I try it, or is it easy enough for you to code it yourself? Petr Tesarik

March 28, 2006

Re: Why winetools is utterly useless, once and for all.

by Hiji

--- Segin <segin2005(a)gmail.com> wrote: > There is one reason, inarguable (if you reply to > this you have a IQ of > 0) as to why WineTools is useless: Most of the > WineTools 'magic' is in > it's ~/.wine/config file, which Wine no longer > uses/acknoleges, thefore, > WineTools is utterly useless and has no point in > existing AT ALL, PERIOD. Dude, you need a bit more constructive in your comments, or you'll be getting a lot of resentment on this list REAL fast. Just a word of advice, Hiji M-Halo: Electronic Rock http://www.mhalo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 28, 2006

Why winetools is utterly useless, once and for all.

by Segin

There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.

March 28, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Vitaly Budovski

Tomas Carnecky wrote: > Huw D M Davies wrote: >> On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: >>> Ah right, glDrawBuffer alters the rendering state, that's bad. We >>> should presumably be calling glXSwapBuffers here (but only in the >>> GLXPixmap case). >> Which of course won't work either. >> >> We need to find out what happens to the render state under Windows >> when we make call wglMakeCurrent on a bitmap (I know that even with >> the rendering state set for GL_BACK then the bitmap gets drawn on) and >> whether we restore the rendering context when we switch back to using >> some other dc afterwards. We probably shouldn't do anything in the >> pbuffer case (which is what's causing your problem I guess). >> >> The big issue is that pbuffers and bitmap rendering are getting >> confused all over the place. >> > > Feel free to take http://dbservice.com/tom/LinuxTest.cpp, change it and > test it.. it's a win32 application, despite its name :) > > tom > > > You need to call wglMakeCurrent right before you test for the presence of ARB/EXT wgl functions. On windows I get the following result: initial drawBuffer: 0x405 after setting back buffer: 0x405 after activating pbuffer: 0x405 On wine I get (NVidia Geforce 6800): X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 135 Current serial number in output stream: 136 and the log is partially filled to: initial drawBuffer: 0x405 after setting back buffer: 0x405

March 28, 2006

Re: Winetools -> wine doors

by Tony Lambregts

penna(a)bb.com.br wrote: > Hi Karl, > >> I would love it if people would get involved, a few good coders can have >> SVN/trac access I'll work on opening up to the public soon. >> >> pygtk/pyxml/wine hackers/shell scripters very welcome. > > Maybe I can help with bash scripting (very good skill) .... I know > nothing about python ... 8( ... but can learn quickly. > BTW, I would like to point out two suggestions: > > 1) you (we) should set up a winedoors-devel list. This discussion should > be out of the wine-devel list (we should not mix things up and wine devel > folks are already too busy) I do not agree Wine developers can ignore threads that they are not interested in if they wish. However they may be interested in development of these resources. I look at it as being the same as discussions on bugzilla, winecfg, the AppDB or the Wiki. > 2) the winedoors should return some information to the AppDB in order to > keep that information for the wine devel folks get some feedback what is > going on with, for example, DLL overrides. For example, if the AppDB keeps > track of the most overriden DLLs (information "feeded" by winedoors - or > winetools 8)) I think wine developers could query the database in order to > see which DLL needs some improvement because its is the most one > overriden. I agree that this would be useful to wine developers if the AppDB had this, even if nothing else comes out of this discussion. One other consideration to take into account when dealing with dll overrides is that we cannot assume that everyone is legally entitled to use just any dll. It should be the is the responsibility of each individual to make. sure they are entitled to use them. > > One more thing, I like Winetools. It helped me a lot. Does it need > improvement? Yes, it needs, but it is not the reason we may "burn" it. > > Regards (I am not subscribed at wine-devel list, so please cc me) > --------------------------------------------------------- > Ulisses de Sousa Penna > Analista Consultor - Banco do Brasil > Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 > --------------------------------------------------------- > > >

March 28, 2006

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

by Vitaliy Margolen

Monday, March 27, 2006, 3:17:12 PM, Tom Spear (Dustin Booker, Dustin Navea) wrote: > Tony Lambregts wrote: >> Alexandre Julliard wrote: >>> Module: wine >>> Branch: refs/heads/master >>> Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f >>> URL: >>> http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… >>> >>> >>> Author: Alexandre Julliard <julliard(a)winehq.org> >>> Date: Mon Mar 27 22:43:03 2006 +0200 >>> >>> x11drv: Moved desktop mode handling to the explorer process. >>> >>> Per-application desktop mode settings are no longer supported. Apps >>> can be launched in a specific desktop window by using: >>> >>> explorer /desktop=name[,widthxheight] app.exe [args] >>> >>> If the named desktop already exists the app is launched inside it. The >>> default desktop is cleverly named "default". >>> >> So if I understand this correctly all programs will share the same >> desktop. Is it also true that I cannot specify in winecfg that one >> program can run full screen and another in a desktop window. >> >> If this is the case we will have a fair amount of crying over this one. >> >> At the very least we need to put a note in winecfg. (preferabley befor >> next release). >> >> -- >> >> Tony Lambregts >> > Not in winecfg, but users can always modify their shortcuts to the > application to run wine with the /desktop command like shown above. > Doing it that way does conform to windows, so if users liked the old > way, unfortunately, they are outta luck.. > Tom Ok so now say with Steam and all of it's games - it will be almost 100% unusable! Because we still haven't fixes managed/unmamaged windows. And Steam itself would be on top of everything. So the way people were able to work-around this is by putting Steam into virtual desktop. Now that means their game will run in the same desktop as well. We really really really have to fix managed/unmanaged mode then. I can't even imagine how many people will stay with current or older Wine because of this patch. Also I remember some users were using other two parameters of the desktop (top left corner - changing manually in the registry). I didn't seen anything that indicates they are still supported with this patch. Vitaliy

March 28, 2006

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

by Tom Spear (Dustin Booker, Dustin Navea)

Tony Lambregts wrote: > Alexandre Julliard wrote: >> Module: wine >> Branch: refs/heads/master >> Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f >> URL: >> http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… >> >> >> Author: Alexandre Julliard <julliard(a)winehq.org> >> Date: Mon Mar 27 22:43:03 2006 +0200 >> >> x11drv: Moved desktop mode handling to the explorer process. >> >> Per-application desktop mode settings are no longer supported. Apps >> can be launched in a specific desktop window by using: >> >> explorer /desktop=name[,widthxheight] app.exe [args] >> >> If the named desktop already exists the app is launched inside it. The >> default desktop is cleverly named "default". >> > So if I understand this correctly all programs will share the same > desktop. Is it also true that I cannot specify in winecfg that one > program can run full screen and another in a desktop window. > > If this is the case we will have a fair amount of crying over this one. > > At the very least we need to put a note in winecfg. (preferabley befor > next release). > > -- > > Tony Lambregts > Not in winecfg, but users can always modify their shortcuts to the application to run wine with the /desktop command like shown above. Doing it that way does conform to windows, so if users liked the old way, unfortunately, they are outta luck.. Tom

March 27, 2006