Re: Why winetools is utterly useless, once and for all.
Tom Williams wrote: Tom Spear wrote: Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about... COBOL!! LMFAO gimme a break.. Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended). As for the GUI, make it C or C++, only because that is the most widely used language in linux.. What about perl? I'm not a perl programmer or anything but wouldn't that be as prevalent in a Linux environment as C or C++? I believe GTK+ could be used for the UI and I don't know if QT could also be used or not. It is possible to link to GTK+ and QT with the same binary, but it's best to use a system of modules and common calls/elements to do the GUI stuff in seperate dlopen()ed modules so that anyone that has a taste for a odd, weird, or obsolete toolkit could also make a UI plugin for such, while not modifying the core at all (Motif plugin, anyone?) I'm sitting back and watching this discussion and I just wanted to mention perl for you guys to consider. :) I'll shut up now. :) Peace... Tom
Re: Why winetools is utterly useless, once and for all.
On Tue, 2006-03-28 at 17:22 -0500, Kuba Ober wrote: > I was pretty serious when I said about Lisp. Once you get to know it, it's an > extremely agile and productive programming language that has way more power > than Python does. Even if that statement were true (I seriously doubt you can qualify it with any actual evidence), 'power' isn't the only concern in choosing a programming language for a project. Python has excellent community support, tons of third party modules, several mature IDEs, and most of all is easier for a new programmer to pickup than any other language I've tried. I'm also curious how you think that Lisp can somehow more concisely represent the logic for this app. I haven't looked at any GUI bindings for Lisp, but if they look anything like the OCaml ones it's just going to be a dump of imperative code, which mostly defeats the point of using a functional language in the first place. Python stole from Lisp what most people like about Lisp anyway. > Lisp might be considered more obscure, that's sure, but > that's due to people mostly being clueless (sorry, had to say that). For > example there's no Python implementation that I know of that would even > remotely compare (performance-wise) to Frantz Lisp, when running "dirty > first-cut" code. The Python community pretty openly states that if performance is a major concern for your project that Python is the wrong choice. You can code part of your project in C (the performance critical parts) and the rest in Python in some cases. If your app has a flat performance profile then it's well known that Python isn't the best choice. Then again, no one is going to use Lisp in that case either. Bottom line -- this is a configurer. It's not run super often and what it does isn't that computationally intensive anyway. Performance isn't a concern. > Making it C implies not using Qt*, and I just can't see why anyone would > *not* > want to use Qt. I'm dead serious. It's probably the only framework right now > that has any future, besides .net offerings and whatever is available for > Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared > to Qt). It's stupid to use dead solutions. Although I agree that Qt is the best choice, I'd have to disagree that gtk is dead. wxWidgets will probably be around for some time too, if for no other reason than that using Qt in C++ is a bit annoying because it needlessly reinvents the wheel (there's a lot of overlap between Qt and boost and even standard lib). It's the same reason gtkmm has more appeal to some C++ coders than Qt.
Re: Why winetools is utterly useless, once and for all.
Tom Spear wrote: > Java, anyone? lol oh wait wait I got one better.. Fortran... or no, > how about... COBOL!! LMFAO gimme a break.. > > Seriously though, why not break winedoors up into different > components, and then have different submaintainers, and each component > can be written in the language that that submaintainer is most > comfortable with? Obviously each piece of code would go thru the > project maintainer, and so if someone started writing another "door" > in bash, then that door could quickly be closed (pun intended). > > > As for the GUI, make it C or C++, only because that is the most widely > used language in linux.. What about perl? I'm not a perl programmer or anything but wouldn't that be as prevalent in a Linux environment as C or C++? I believe GTK+ could be used for the UI and I don't know if QT could also be used or not. I'm sitting back and watching this discussion and I just wanted to mention perl for you guys to consider. :) I'll shut up now. :) Peace... Tom
Re: Why winetools is utterly useless, once and for all.
> > > 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. > > Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how > about... COBOL!! LMFAO gimme a break.. I was pretty serious when I said about Lisp. Once you get to know it, it's an extremely agile and productive programming language that has way more power than Python does. Lisp might be considered more obscure, that's sure, but that's due to people mostly being clueless (sorry, had to say that). For example there's no Python implementation that I know of that would even remotely compare (performance-wise) to Frantz Lisp, when running "dirty first-cut" code. Fortran is about as good as C is, as there are about as good Fortran compilers as there are C compilers, so at least tool-wise those are on similar footing. Since more people know C, it's obvious that Fortran would be a bad choice. I'd say that Pascal and Ada are serious languages to consider as well, the only problem is that there are no serious bindings for any of them to Qt :) Well, there are FPC to Qt bindings, and Ada to Qt bindings, but they are nowhere near PyQt. I'll leave COBOL out because I know nothing about it. I looked for some decent and affordable tools and I couldn't find any besides Kobol from TheKompany, so that's a bit few for my liking, and with a bit of a shortish history. Frantz Lisp has been around for so much longer, and there are many decent enough free Common Lisp implementations. > Seriously though, why not break winedoors up into different components, and > then have different submaintainers, and each component can be written in > the language that that submaintainer is most comfortable with? Obviously > each piece of code would go thru the project maintainer, and so if someone > started writing another "door" in bash, then that door could quickly be > closed (pun intended). > > > As for the GUI, make it C or C++, only because that is the most widely used > language in linux.. Making it C implies not using Qt*, and I just can't see why anyone would *not* want to use Qt. I'm dead serious. It's probably the only framework right now that has any future, besides .net offerings and whatever is available for Java. Everything else (gtk, wxWidgets, . . .) simply has no support (compared to Qt). It's stupid to use dead solutions. I was also pretty serious about C being a bad language choice. C and C++ are vastly different languages that share some syntax, that's all. Saying "C or C++" is akin to saying "C or Lisp", "C or Python" etc. Cheers, Kuba * Sure, you can develop bindings from C to Qt, but what's the point? PS. I consider Tcl/Tk to be an equally dead abomination, although in widespread use. Consider that Latin is also pretty widely used (way more than Tcl/Tk methinks), yet equally dead. Dead is dead, right? :) So I covered all bases, I think.
Re: Why winetools is utterly useless, once and for all.
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)
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Hi, > I have serious problems with games with that patch. All DirectDraw games > I've tested(with the mainline ddraw code any my patches) because they fail > to set the display mode. I have a MergedFB setup with a resolution of > 1400x2074, and I disallow mode changes in my X config. With the old code, > x11drv nicely reported the standard displaymodes 640x480,800x600,... to > DDraw / opengl / d3d, and could resize the window to that resolutions. Now > it only supports 1400x2074 Never mind that rant, I must have done something wrong when updating / recompiling, now it works with my code and the old ddraw code :) > I really think a Desktop setting should be possible in winecfg. It allows > me to configure some apps to use a virtual desktop and run them from the > terminal with wine foo.exe, without a long "wine explorer > /desktop=blabla..." line. Running games in a virtual Desktop is essential > for d3d development. That works too as I like it :) I'll do more tests tomorrow if I have time. Stefan pgpMR7d2VOZZG.pgp Description: PGP signature
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
"Jesse Allen" <[EMAIL PROTECTED]> writes: > Is the explorer.exe program supposed to be in the path somewhere? The > only place it is installed is in /usr/local/lib/wine/explorer.exe.so. > That is outside my wine drive letters. I have to copy it in to drive > C to be able to run and use the /desktop option. No it's not in the path, but running it with 'wine explorer' should work no matter where it's installed. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Hello, > > > 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] I have serious problems with games with that patch. All DirectDraw games I've tested(with the mainline ddraw code any my patches) because they fail to set the display mode. I have a MergedFB setup with a resolution of 1400x2074, and I disallow mode changes in my X config. With the old code, x11drv nicely reported the standard displaymodes 640x480,800x600,... to DDraw / opengl / d3d, and could resize the window to that resolutions. Now it only supports 1400x2074 I really think a Desktop setting should be possible in winecfg. It allows me to configure some apps to use a virtual desktop and run them from the terminal with wine foo.exe, without a long "wine explorer /desktop=blabla..." line. Running games in a virtual Desktop is essential for d3d development. I don't expect that the code will affect apps like Steam, even if Steam and half-life are run in the same desktop window, because the problem only occurs if Steam is run in managed mode because the window manager can't cope with unmanaged windows. In a virtual Desktop, I expect it to work nice. But the ability to have more apps in one Desktop is nice :) Stefan pgpcyTcrZOaoL.pgp Description: PGP signature
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
On 3/27/06, Tony Lambregts <[EMAIL PROTECTED]> wrote: > Alexandre Julliard wrote: > > Module: wine > > Branch: refs/heads/master > > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > > URL: > > http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > > > > Author: Alexandre Julliard <[EMAIL PROTECTED]> > > 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] > > Is the explorer.exe program supposed to be in the path somewhere? The only place it is installed is in /usr/local/lib/wine/explorer.exe.so. That is outside my wine drive letters. I have to copy it in to drive C to be able to run and use the /desktop option. Jesse
Re: Why winetools is utterly useless, once and for all.
On 3/28/06, Kuba Ober <[EMAIL PROTECTED]> wrote: > 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 poorlydocumented 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 inLisp, 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 inPython than people skilled in Lisp, so methinks that C++ is the right way togo, just because of the sheer number of developers available C++ (and Python) gives you an advantage of being able to directly** leverageQt to have wine doors that can either work as a regular unix application, ora 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 emulatorplatform.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 Java, anyone? lol oh wait wait I got one better.. Fortran... or no, how about... COBOL!! LMFAO gimme a break..Seriously though, why not break winedoors up into different components, and then have different submaintainers, and each component can be written in the language that that submaintainer is most comfortable with? Obviously each piece of code would go thru the project maintainer, and so if someone started writing another "door" in bash, then that door could quickly be closed (pun intended). As for the GUI, make it C or C++, only because that is the most widely used language in linux..Tom
Re: Debugging X errors?
On Tue, 28 Mar 2006 15:25:26 -0500 Segin <[EMAIL PROTECTED]> 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.
Re: Why winetools is utterly useless, once and for all.
> 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
Re: Why winetools is utterly useless, once and for all.
Karl Lattimer wrote: 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) 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?
Re: Debugging X errors?
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): X -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)
Re: Debugging X errors?
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)
Re: Why winetools is utterly useless, once and for all.
Kai Blin wrote: * Segin <[EMAIL PROTECTED]> [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
Re: Why winetools is utterly useless, once and for all.
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' :-)
Re: Russian translation for uninstall application
"Anatoly A. Kazantsev" <[EMAIL PROTECTED]> 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.
"Unhandled exception: floating point stack check" early in program?
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 [EMAIL PROTECTED]:~$ ~/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: EDX:7fdc2400 ESI:7fafeaac EDI:0002 Stack dump: 0x7fafea58: 7fafeb40 7fafea90 7f7c00b0 0x7fafea68: 005c 007c 7fafea90 7f79e0c6 0x7fafea78: 7f7c8f40 7fd868e8 005c 7f34e09c 0x7fafea88: 63656a62 007c 7fafeac0 7f31a40f 0x7fafea98: 02e4 7fafeaac 0002 7fafeb40 0x7fafeaa8: 7fafeb78 0007 0200: sel=1007 base=7fec2000 limit=1fff 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=, dlgProc=0x4340e2, param=0x0, unicode=0x0, modal=0x0) [/home/dank/wine/dlls/user/dialog.c:474] in user32 (0x7f830c8b) 14 0x7f83254e CreateDialogIndirectParamAorW+0x2e(hInst=0x40, 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=0x40, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:706] in user32 (0x7f83264e) 16 0x7f8326c6 CreateDialogParamA+0x66(hInst=0x40, 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 0x (0x) 20 0x (0x) Wine-dbg> ? -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Debugging X errors?
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
Debugging X errors?
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
Re: Why winetools is utterly useless, once and for all.
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!!!"
Re: Why winetools is utterly useless, once and for all.
* Segin <[EMAIL PROTECTED]> [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.
Re: I have a complaint about the website
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 (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 <[EMAIL PROTECTED]> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?
Re: Why winetools is utterly useless, once and for all.
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
Re: Why winetools is utterly useless, once and for all.
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)
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Vitaliy Margolen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: setupapi: Test loading an exe from the system directory with SetupOpenInfFile
"James Hawkins" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
Re: ntdll: Fix SIGTRAP handling
Petr Tesarik <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: ntdll: Fix SIGTRAP handling
On 06/03/27 at 18:19:44 (+0200), Alexandre Julliard wrote: > Petr Tesarik <[EMAIL PROTECTED]> 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
