[OT] Re: Why winetools is utterly useless, once and for all.
* On Tue, 28 Mar 2006, Karl Lattimer wrote: And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays) Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Willie Sippel wrote: You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...? Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there? Mike
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Dienstag, 28. März 2006 11:31 schrieb Alexandre Julliard:
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.
You announced working on the unmanaged window problem in September 2001 IIRC,
but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like
approach be feasible? They seem to ignore 'chromeless' windows and handle
them just like regular windows (with window decoration and all, for Steam for
example) - this is obviously not correct, but it would at least work 'till
someone comes up with a real fix...?
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Hello, You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...? Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there? I've sent 2 patches addressing this issue to wine-devel last year. The first patch(http://www.winehq.org/pipermail/wine-patches/2005-March/016558.html) made children of the desktop managed, the other patch made WM_SYSMENU(Sorry, can't find this one in the archives) windows managed. Both patches were neighter applied nor discussed further. My observation was that all affected windows have a WM_SYSMENU | WM_POPUP style, but do not set WM_CAPTION | WM_EX_APPWINDOW or any other styles which would make them managed. Making WM_SYSMENU windows managed fixed a few apps, like Steam, Quicktime Half-life(parts not managed, can't navigate through the menus). I didn't notice any side effects(The windows had no decoration, which is completely correct), except that Steam and QuickTime seem to provide their own window movement code which conflicts with KDEs window movement handling. So if you move a Steam window to the corner of the screen, it won't move out of the screen, but Steam expects it to and mouse clicks are placed incorrectly. Quicktime can't be moved at all. I am not sure if this the direct fault of making those windows managed, or if there are some other bugs. pgpd8FPV5oM2C.pgp Description: PGP signature
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Mittwoch, 29. März 2006 11:39 schrieb Mike McCormack:
Willie Sippel wrote:
You announced working on the unmanaged window problem in September 2001
IIRC, but I guess you didn't so far? Wouldn't, for the time being, a
Cedega-like approach be feasible? They seem to ignore 'chromeless'
windows and handle them just like regular windows (with window decoration
and all, for Steam for example) - this is obviously not correct, but it
would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if
there was already a half-baked fix in Wine already, would there?
Probably true. But Wine has several problems where a 'real' fix is so very
complicated that we won't see something anytime soon, probably for years to
come (like the DIB engine, planned for years, but nobody seems to even work
on it). In the recent two years, Wine became unusable for many users - I even
know some guys that switched back to Windows because of 'fixes' to Wine that
render lots of application unusable, due to regressions expected when those
fixes were commited. Those 'fixes' should never make it into CVS if there's
not even a realistic timeframe for fixing the regressions.
The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering
many applications unusable - stuff that used to work in the past. There are
probably 'easy' ways to hack around the problem (making the old window
handling an option, or maybe create a hybrid that uses extra X11-windows for
OpenGL viewports only), but the proposed 'correct' approaches will most
likely take a few years and/ or kill the performance, if they are even
feasible (GLX extension - completely worthless without ATI/ Nvidia
support)...
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Willie Sippel wrote: Probably true. But Wine has several problems where a 'real' fix is so very complicated that we won't see something anytime soon, probably for years to come (like the DIB engine, planned for years, but nobody seems to even work on it). In the recent two years, Wine became unusable for many users - I even know some guys that switched back to Windows because of 'fixes' to Wine that render lots of application unusable, due to regressions expected when those fixes were commited. Those 'fixes' should never make it into CVS if there's not even a realistic timeframe for fixing the regressions. How do you propose that we figure out if there's going to be regressions or not before the patches are committed? Isn't it just better to start with a patch that is right, but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes? The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering My counter example is richedit. As a half-baked wrapper around the edit control, it rotted in the CVS for at least 4 years until Krzysztof finally rewrote the whole thing. If the half-baked version never existed in the first place we would have had a working richedit control alot sooner. It might be a little bit harder to get things done by avoiding hacks at the start, but it's *alot* harder to get rid of the hacks once they're there. People will complain and complain forever that the hacky version worked for them once for one application, even if the new version does alot better for all applications. Mike
Re: advpack: Open the INF file if the RSC_FLAG_INF flag is specified
James Hawkins [EMAIL PROTECTED] writes:
@@ -72,10 +72,7 @@ static void test_RunSetupCommand()
/* try to run an exe with the RSC_FLAG_INF flag */
hexe = (HANDLE)0xdeadbeef;
hr = pRunSetupCommand(NULL, winver.exe, Install,
c:\\windows\\system32, Title, hexe, RSC_FLAG_INF, NULL);
-todo_wine
-{
-ok(hr == SPAPI_E_WRONG_INF_STYLE, Expected SPAPI_E_WRONG_INF_STYLE,
got %ld\n, hr);
-}
+ok(hr SPAPI_E_EXPECTED_SECTION_NAME, Expected a setupapi error, got
%ld\n, hr);
This test doesn't make sense. If you want to test certain bits you
have to write that explicitly, not pick some random constant that
happens to have the right value. And in any case a simple AND won't do
what you want.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Mittwoch, 29. März 2006 13:15 schrieb Mike McCormack:
Willie Sippel wrote:
Probably true. But Wine has several problems where a 'real' fix is so
very complicated that we won't see something anytime soon, probably for
years to come (like the DIB engine, planned for years, but nobody seems
to even work on it). In the recent two years, Wine became unusable for
many users - I even know some guys that switched back to Windows because
of 'fixes' to Wine that render lots of application unusable, due to
regressions expected when those fixes were commited. Those 'fixes' should
never make it into CVS if there's not even a realistic timeframe for
fixing the regressions.
How do you propose that we figure out if there's going to be regressions
or not before the patches are committed?
Well, granted, that won't usually work. However, with the WM rewrite, I think
it was expected. And the unmanaged window problem with Steam is well known,
as is the workaround. I still don't really know what's so hard about the
unmanaged window thing, as there are unmanaged windows on Linux, too (eg,
XMMS) - but I'm not really much of coder, so I most probably missed
something...
Isn't it just better to start with a patch that is right, but will
still show regressions, then fix those regressions, as opposed to
starting with a patch that is wrong, and then hacking on it forever
trying to solve the unsolvable problems that causes?
You are right, of course. I'm all for doing stuff right, and I'm not a friend
of quick-and-dirty hacks myself. I simply can't understand why most serious
regressions introduced in the last two years are seemingly not worked on at
all - they simply seem to get ignored. I'm sorry if my mail sounded like a
rant, but I'm one of the guys obviously lucky enough to be affected by pretty
much every single regression over the last two years in some way - and that
gets really frustrating. Of all the applications I used with Wine when I
switched to Linux a few years ago, only a single one still works, while every
single bug this application shows was already in Wine in 2003.
The WM-rewrite/ broken windowed-OpenGL support is a perfect example,
rendering
My counter example is richedit. As a half-baked wrapper around the edit
control, it rotted in the CVS for at least 4 years until Krzysztof
finally rewrote the whole thing. If the half-baked version never
existed in the first place we would have had a working richedit control
alot sooner.
It might be a little bit harder to get things done by avoiding hacks at
the start, but it's *alot* harder to get rid of the hacks once they're
there. People will complain and complain forever that the hacky version
worked for them once for one application, even if the new version does
alot better for all applications.
Correct. It seems to be a matter of motivation. I don't know... An idea would
be to accept an evil hack to make unmanaged windows work, with a deadline.
Like, the patch goes in for now, but will be removed in three months. So, if
someone needs the affected applications working, either write and commit a
real fix in the next three months, or the app stops working then.
One could argue that the hack could as well be ommited then 'till someone
really fixes the issue, but in case of Steam, the hack is also needed to run
and manage Valve games. If nobody can run those applications, nobody can work
on bugs they expose as well.
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Page fault xmlspy 2006 wine .9.10
Eric Pouech wrote: Grant Lewis wrote: It's repeatable. I can launch the progam fine but when I click in certain parts of the gui I generate the page fault and the program dies. wine: Unhandled page fault on write access to 0x001f at address 0x7d62d6 (th read 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: page fault on read access to 0x in 32-bit code ( 0x7ffa7292). does the attached patch help ? A+ Thanks Eric. I recompiled with your patch and it fixed the page fault. Hopefully that's the only issue I run into besides the small font size in the gui widgets which I'm not sure if I can control through the registry; otherwise, xmlspy 2006 is running well under .9.10. Grant
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Mike McCormack wrote: Willie Sippel wrote: You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...? Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there? Mike That could be said about a lot in Wine. regards, Jakob
Re: Page fault xmlspy 2006 wine .9.10
I have a new page fault from xmlspy in .9.10... Unhandled exception: page fault on write access to 0x001f in 32-bit code (0x007d62d6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:007d62d6 ESP:7fbff5d0 EBP:2ce0 EFLAGS:00210206( - 00 - RIP1) EAX:001f EBX:2cfc ECX:7f9d2720 EDX:0001 ESI:7fbff638 EDI:7e2f0372 Stack dump: 0x7fbff5d0: 7fbff6bc 7fbff7dc 7daa5800 7deceee8 0x7fbff5e0: 019c 7daaba01 00ff 0x7fbff5f0: 7e2f0372 006c 00cd 0x7fbff600: 0024 019a 0011 0x7fbff610: 0028 00cd 0024 0011 0x7fbff620: 0003 39f0 Backtrace: =1 0x007d62d6 in xmlspy (+0x3d62d6) (0x007d62d6) 2 0x (0x) 0x007d62d6: movl$0x1,0x0(%eax) Modules: Module Address Debug info Name (98 modules) PE 0x0040-014eb000 Export xmlspy PE 0x1000-1002e000 Deferredssce5332 ELF 0x7bf0-7bf03000 Deferredwine-loader ELF 0x7e9ac000-7e9c Deferredmsimg32elf \-PE 0x7e9b-7e9c \ msimg32 ELF 0x7ed0b000-7ed2 Deferredmidimapelf \-PE 0x7ed1-7ed2 \ midimap ELF 0x7ee3e000-7ee5f000 Deferredmsacm32elf \-PE 0x7ee5-7ee5f000 \ msacm32 ELF 0x7ee5f000-7ee76000 Deferredmsacmelf \-PE 0x7ee7-7ee76000 \ msacm ELF 0x7ee76000-7ef4a000 Deferredlibcrypto.so.0.9.7 ELF 0x7ef4a000-7ef72000 Deferredlibssl.so.0.9.7 ELF 0x7ef72000-7ef8a000 Deferredlibcups.so.2 ELF 0x7f093000-7f0c2000 Deferreduxthemeelf \-PE 0x7f0a-7f0c2000 \ uxtheme ELF 0x7f0c2000-7f0da000 Deferredximcp.so.2 ELF 0x7f0da000-7f138000 Deferredlibgl.so.1 ELF 0x7f14e000-7f1fd000 Deferredlibx11.so.6 ELF 0x7f1fd000-7f211000 Deferredlibice.so.6 ELF 0x7f211000-7f282000 Deferredwinex11elf \-PE 0x7f22-7f282000 \ winex11 ELF 0x7f282000-7f29d000 Deferredlibexpat.so.0 ELF 0x7f29d000-7f2bf000 Deferredlibfontconfig.so.1 ELF 0x7f2bf000-7f321000 Deferredlibfreetype.so.6 ELF 0x7f328000-7f33 Deferredlibxcursor.so.1.0.2 ELF 0x7f33-7f337000 Deferredlibxrender.so.1 ELF 0x7f337000-7f39 Deferredmsvcrtelf \-PE 0x7f35-7f39 \ msvcrt PE 0x7f39-7f3cb000 Deferredoraclm32 ELF 0x7f3cc000-7f3cf000 Deferredxlcdef.so.2 ELF 0x7f3cf000-7f3da000 Deferredlibxext.so.6 ELF 0x7f3da000-7f3f4000 Deferredimm32elf \-PE 0x7f3e-7f3f4000 \ imm32 ELF 0x7f3f4000-7f46d000 Deferredwinmmelf \-PE 0x7f40-7f46d000 \ winmm ELF 0x7f46d000-7f48d000 Deferredodbc32elf \-PE 0x7f48-7f48d000 \ odbc32 ELF 0x7f48d000-7f4b2000 Deferredws2_32elf \-PE 0x7f4a-7f4b2000 \ ws2_32 ELF 0x7f4b2000-7f4cb000 Deferredwsock32elf \-PE 0x7f4c-7f4cb000 \ wsock32 ELF 0x7f4cb000-7f4e7000 Deferredmprelf \-PE 0x7f4d-7f4e7000 \ mpr ELF 0x7f4e7000-7f522000 Deferredwininetelf \-PE 0x7f4f-7f522000 \ wininet ELF 0x7f522000-7f541000 Deferredcabinetelf \-PE 0x7f53-7f541000 \ cabinet ELF 0x7f541000-7f56d000 Deferredurlmonelf \-PE 0x7f55-7f56d000 \ urlmon ELF 0x7f56d000-7f5e6000 Deferredoleaut32elf \-PE 0x7f58-7f5e6000 \ oleaut32 ELF 0x7f5e6000-7f5fa000 Deferredolepro32elf \-PE 0x7f5f-7f5fa000 \ olepro32 ELF 0x7f5fa000-7f613000 Deferredoledlgelf \-PE 0x7f60-7f613000 \ oledlg ELF 0x7f613000-7f639000 Deferredwinspoolelf \-PE 0x7f62-7f639000 \ winspool ELF 0x7f639000-7f6d2000 Deferredcomctl32elf \-PE 0x7f64-7f6d2000 \ comctl32 ELF 0x7f6d2000-7f6ee000 Deferrediphlpapielf \-PE 0x7f6e-7f6ee000 \ iphlpapi ELF 0x7f6ee000-7f729000 Deferredrpcrt4elf \-PE 0x7f70-7f729000 \ rpcrt4 ELF 0x7f729000-7f79b000 Deferredole32elf \-PE 0x7f74-7f79b000 \ ole32 ELF 0x7f79b000-7f7e7000 Deferredshlwapielf \-PE 0x7f7b-7f7e7000 \ shlwapi ELF 0x7f7e7000-7f896000 Deferredshell32elf \-PE 0x7f80-7f896000 \ shell32 ELF 0x7f896000-7f92c000 Deferredcomdlg32elf
Re: [OT] Re: Why winetools is utterly useless, once and for all.
On Wed, 2006-03-29 at 12:27 +0300, Saulius Krasuckas wrote: * On Tue, 28 Mar 2006, Karl Lattimer wrote: And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays) Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator) Justified, expulsion... Do we need a lynch mob or do you just mailman it? /me wraps his rope 13 times around itself Unlucky for some K,
Re: What happened to the Fedora packages?
Maybe you should put on the Fedora RPM package site a large noticable notice that says that for Fedora Core 3, 4, and 5, simply using terminal, sudo into root, and then do yum install wine to get the latest WINE packages. Also, note that Fedora Core 3 has to manually be configured for Fedora Extras. This way, people will know that it is in Fedora Extras now, and people like me won't miss it :)On 3/23/06, Neal Gompa [EMAIL PROTECTED] wrote: I just decided to use the yum packages suggested earlier... and yes, it fails, then crashes! anyway, thanks! On 3/23/06, Francois Gouget [EMAIL PROTECTED] wrote:On Wed, 22 Mar 2006, Neal Gompa wrote: Well, the system is a Pentium 4 2.8GHz HyperThreading with 512MB RAM, so that is not the problem! It just always failsOh, the compilation fails? That's not the same as the computercrashing...Maybe you can send us the error message and then we can help you. --Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
Re: Page fault xmlspy 2006 wine .9.10
Grant Lewis wrote: I have a new page fault from xmlspy in .9.10... Please file a report at bugs.winehq.org instead of posting mail to wine-devel. Mike
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Mittwoch, 29. März 2006 12:19 schrieb Stefan Dösinger:
Hello,
You announced working on the unmanaged window problem in September 2001
IIRC, but I guess you didn't so far? Wouldn't, for the time being, a
Cedega-like approach be feasible? They seem to ignore 'chromeless'
windows and handle them just like regular windows (with window
decoration and all, for Steam for example) - this is obviously not
correct, but it would at least work 'till someone comes up with a real
fix...?
Wouldn't be much motivation for somebody to come up with a real fix if
there was already a half-baked fix in Wine already, would there?
I've sent 2 patches addressing this issue to wine-devel last year. The
first
patch(http://www.winehq.org/pipermail/wine-patches/2005-March/016558.html)
made children of the desktop managed, the other patch made
WM_SYSMENU(Sorry, can't find this one in the archives) windows managed.
Both patches were neighter applied nor discussed further.
Did you check this[1] solution for borderless SDL applications? Looks somewhat
hacky, but not too complicated. Maybe the basic idea is feasible for Wine as
well? GTK (XMMS) seems to use the same approach ([2], Motif WM hints) to
disable borders, and this concept works with pretty much every window
manager...
[1]: http://www.libsdl.org/pipermail/sdl/2000-January/023704.html
[2]:
http://www.pygtk.org/pygtk2reference/class-gdkwindow.html#method-gdkwindow--set-decorations
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote: ... Isn't it just better to start with a patch that is right, but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes? You are right, of course. I'm all for doing stuff right, and I'm not a friend of quick-and-dirty hacks myself. I simply can't understand why most serious regressions introduced in the last two years are seemingly not worked on at all - they simply seem to get ignored. I'm sorry if my mail sounded like a Simple. No one is paying to get it fixed ;) (And it requires a lot of effort for Joe Random Coder.) Thats just OpenSource for you. Ciao, Marcus
Re: Why winetools is utterly useless, once and for all.
On Tuesday 28 March 2006 23:30, Joseph Garvin wrote: 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. Only after you were exposed to C/Modula-like languages in the first place. For someone who never programmed before it's easier to pick up Scheme than C, and I could hardly agree more with Natasha: http://www.inf.hs-zigr.de/~wagenkn/Natasha_Chen.html I've resisted switching from Pascal to C/C++ my whole high school, as I considered C too have too convoluted a syntax. My opinion hasn't changed, it's just that for a long time gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can essentially make a living not having to use a single pointer-to-function for a month at a time. But again, C++ is not C. 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. You can program in Lisp in both functional and imperative styles, and I guess that most Lisp programs have both styles in them. It mostly depends on what's handy at the moment :) Python stole from Lisp what most people like about Lisp anyway. Well, functions aren't exactly first class citizens in Python, they were on their way to becoming so for some time AFAIK (more and more every release). That's something that was in Lisp since day one, OTOH. 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. IIRC the only reason that Orbitz became so good is because they had their flight search logic coded initially in Lisp. That's not only a fairly hardcore CPU-bound task, the choice of language made them way more agile feature-wise in their startup years. Right now they ported most of the code to C++, but I bet it was only feasible to do so after they got the architecture figured out and kinda settled down after hacking away in Lisp initially. 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. I know. I'm not overly concerned about that. I mainly wanted to redirect the flamewar elsewhere and have some fun at the same time. Yay :) 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, Hanging around for some time vs. having full backing by a company are two different things. Last time I checked there was no single company of the size of Trolltech, or bigger :), whose bread and butter was developing gtk or wxWidgets, and who would have real good reason to develop either one of them further. I know that there are other thriving open source projects (Linux kernel, anyone?) where there is no single controlling company in charge, but those projects have achieved their critical mass long time ago and are past the infant stage. I don't see gtk or wxW anywhere near a critical mass. 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). Which is mainly of historical origin, as there was simply no decent implementation of boost or standard lib in the times when
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
From: Mike McCormack [EMAIL PROTECTED] Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there? But neither does the keep-it-borken approach work, does it? :) Problem is that the breakage is not large enough to motivate people. I think we have to come to terms with the fact that Wine is big, and doing things right is not always an option. I seems to me that we'd be better off to have a working but not-so-perfect solution, rather than wait for years to have the perfect one. Of course, I agree that you can not merge any solution in, that road leads to madness. But we have to balance that with the fact that we have to be useful by offering the functionality that people need or want. Otherwise wine will become irrelevant before it becomes useful. And that would be a shame. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Mittwoch, 29. März 2006 15:14 schrieb Marcus Meissner:
On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote:
...
Isn't it just better to start with a patch that is right, but will
still show regressions, then fix those regressions, as opposed to
starting with a patch that is wrong, and then hacking on it forever
trying to solve the unsolvable problems that causes?
You are right, of course. I'm all for doing stuff right, and I'm not a
friend of quick-and-dirty hacks myself. I simply can't understand why
most serious regressions introduced in the last two years are seemingly
not worked on at all - they simply seem to get ignored. I'm sorry if my
mail sounded like a
Simple.
No one is paying to get it fixed ;) (And it requires a lot of effort
for Joe Random Coder.)
Thats just OpenSource for you.
O RLY? ;-D
I know how that stuff works, I'm part of a few projects myself. Still, I'm the
'I broke it, I'll fix it' kinda guy, but I know it's wrong to expect everyone
to be the same. Especially in the case of Wine, as I'm sure the fixes that
introduced the regression did more good than harm, in general.
However, I ranted enough I think. Back to the real problem. AFAIU, there's
only a single common/ feasible/ intelligent way to create borderless windows
on X11 - managed windows with 'no decoration' Motif hints (the way GTK
handles borderless windows). The example I found looks easy enough, only a
few lines of code, but I was once again reminded that Wine really is way over
my head - I have no idea how to hack that in to at least test it... :-(
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: [OT] Re: Why winetools is utterly useless, once and for all.
Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator) Poppycock. The discussion he initiated ain't that useless, and as I see it, he was rather addressing a possible reply denying the (read: /his/) fact, that this one reason (why it is useless) is inargueable, than a certain person (sarcasm, anyone?). So, Inargueable, eh? Well. Depends. I use both Sidenet and Winetools, they both provide an easy way to have a quick and simple (more or less basic) setup for wine established. But in reality those (original) scripts are pretty much useless to me since I don't use the ~/.wine path, because I a) have multiple versions of wine installed (compiled) and b) need to use multiple instances of those wine-versions. Of course, after modifying the scripts, everything works as supposed. Also, Winetools give you the ability to install several additional applications per button, but I don't think that should be the future. If I want to install Office then it has to work via double clicking the setup.exe. /Period/. Wine should provide an own beautiful setup (something like wineprefixcreate+), to install the directory structure and whatnot, the rest has to be considered as working out of the box. And if not, there is still the AppDB. In the end, one will find Winetools/Sidenet or any derivates useful, the other not. But those tools *should* become useless one day. And that is inargueable, despite of any IQ. -Ray
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Dimi Paun wrote: Problem is that the breakage is not large enough to motivate people. Yep. Just large enough for people to complain about, and demand that somebody else take care of the problem, Now! ;) Mike
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
From: Mike McCormack [EMAIL PROTECTED] Yep. Just large enough for people to complain about, and demand that somebody else take care of the problem, Now! ;) One of those things :) Now, don't misunderstand me, I'm glad Alexandre got around to move the desktop to the explorer process. My comments where of a more general nature, not about this particular patch. Overall, we're much better off with the desktop in explorer and fewer features, than the situation we were in before, which blocked all sorts of cool integration tasks. Sometimes you need a step back to be able to sustain future development. This is one of those situations. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Willie Sippel wrote: However, I ranted enough I think. Back to the real problem. AFAIU, there's only a single common/ feasible/ intelligent way to create borderless windows on X11 - managed windows with 'no decoration' Motif hints (the way GTK handles borderless windows). The example I found looks easy enough, only a few lines of code, but I was once again reminded that Wine really is way over my head - I have no idea how to hack that in to at least test it... :-( The code is already in dlls/x11drv/window.c and it works well. The trouble is that managed mode windows steal input focus when they are created. To give you an example, you click on a text box in IE to put your email address into a form and you're half-way through typing it in when a tooltip appears. This steals input focus away from the text box and you carry on typing without noticing until you look back at the screen and notice only half of your email address is present. The same problems occur for menus and toast notifications. Let's examine the properties of unmanaged windows (there may be others that I'm unaware of): They: 1. Have no window decorations 2. Are always on top 3. Appear on all virtual desktops. Properties (1) and (2) have equal properties in the Win32 world. However, currently only (1) is implemented. AFAIK, the reason (2) isn't implemented is because it isn't set at window creation time, only after window creation (and we cannot switch from managed to unmanaged after creation). Therefore, the solution is to allow managed windows to be converted to unmanaged windows after creation and then we can implement (2) and have an almost exact match of the desired properties of the window with the actual properties that the window manager gives us. Then we can remove the other hacks based on the window style that make Steam end up with an unmanaged window. -- Rob Shearman
Re: [OT] Re: Why winetools is utterly useless, once and for all.
On 3/29/06, Ray Jones [EMAIL PROTECTED] wrote: Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)Poppycock. The discussion he initiated ain't that useless, and as I see it, he was rather addressing a possible reply denying the (read: /his/) fact, that thisone reason (why it is useless) is inargueable, than a certain person (sarcasm,anyone?).So, Inargueable, eh?Well. Depends. I use both Sidenet and Winetools, they both provide an easy way to have a quickand simple (more or less basic) setup for wine established.But in reality those (original) scripts are pretty much useless to me since I don't use the ~/.wine path, because Ia) have multiple versions of wine installed (compiled) andb) need to use multiple instances of those wine-versions.Of course, after modifying the scripts, everything works as supposed. Also, Winetools give you the ability to install several additional applicationsper button, but I don't think that should be the future.If I want to installOffice then it has to work via double clicking the setup.exe. /Period/.Wine should provide an own beautiful setup (something like wineprefixcreate+),to install the directory structure and whatnot,the rest has to be considered as working out of the box. And if not, there is still the AppDB.In the end, one will find Winetools/Sidenet or any derivates useful, the othernot.But those tools *should* become useless one day. And that is inargueable,despite of any IQ. -RayThis is the most well said email I have seen on this topic yet. Yes I am saying mine were pointless, including this one :-D Tom
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Am Mittwoch, 29. März 2006 16:26 schrieb Robert Shearman:
Willie Sippel wrote:
However, I ranted enough I think. Back to the real problem. AFAIU, there's
only a single common/ feasible/ intelligent way to create borderless
windows on X11 - managed windows with 'no decoration' Motif hints (the
way GTK handles borderless windows). The example I found looks easy
enough, only a few lines of code, but I was once again reminded that Wine
really is way over my head - I have no idea how to hack that in to at
least test it... :-(
The code is already in dlls/x11drv/window.c and it works well. The
trouble is that managed mode windows steal input focus when they are
created. To give you an example, you click on a text box in IE to put
your email address into a form and you're half-way through typing it in
when a tooltip appears. This steals input focus away from the text box
and you carry on typing without noticing until you look back at the
screen and notice only half of your email address is present. The same
problems occur for menus and toast notifications.
OK, maybe I got something completely wrong. I'll give you an example to show
the problem I mean:
Traktor DJ Player, by Native Instruments
On Windows:
The main application window has no borders, appears in the taskbar, can be
minimized and moved like any regular window.
On Wine (Kwin handles Wine windows):
The main application has a KDE window decoration that hides the top part of
the interface. Everything else works as espected, but there should be no Kwin
decoration, especially as it hides parts of the interface, making the
application unusable.
On Wine (Wine handles windows):
The application window looks as expected, no borders, can be moved around and
stuff. But it's always on top, always on all desktops and does not appear in
the taskbar. Which is completely wrong. Also, if minimized, you'll get a
stupid icon somewhere on the desktop, on all desktops, always on top, hiding
the K-Menu...
The perfect solution would be to let Kwin (or whatever window manager) handle
the borderless windows, but don't draw any window decorations if the
applications doesn't want to. That's what I expected to achieve with Motif
hints (but I'm obviously too stupid, all I get are nice crashes)...
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Willie Sippel wrote: OK, maybe I got something completely wrong. I'll give you an example to show the problem I mean: Traktor DJ Player, by Native Instruments On Windows: The main application window has no borders, appears in the taskbar, can be minimized and moved like any regular window. On Wine (Kwin handles Wine windows): The main application has a KDE window decoration that hides the top part of the interface. Everything else works as espected, but there should be no Kwin decoration, especially as it hides parts of the interface, making the application unusable. On Wine (Wine handles windows): The application window looks as expected, no borders, can be moved around and stuff. But it's always on top, always on all desktops and does not appear in the taskbar. Which is completely wrong. Also, if minimized, you'll get a stupid icon somewhere on the desktop, on all desktops, always on top, hiding the K-Menu... The perfect solution would be to let Kwin (or whatever window manager) handle the borderless windows, but don't draw any window decorations if the applications doesn't want to. That's what I expected to achieve with Motif hints (but I'm obviously too stupid, all I get are nice crashes)... It sounds like the borders being present is a separate problem. Without knowing what windows styles the application is using (it could be using a weird combination that doesn't set the correct hints), it sounds like the application is handling the WM_NCCALCSIZE message and overriding the non-client top border to 0 and drawing its own part of that interface. The trouble is that detecting this is rather hard. A solution is possible where after it is detected that the non-client size has been altered and the MWM flags adjusted appropriately, but this would be based on heuristics like the existing managed/unmanaged problem and sometimes the heuristics get it wrong. This is just another case where if we do the right case for one problem then another problem crops up and it appears as though we are introducing regressions. In reality, fixing the managed/unmanaged window problem would be a huge step forward for everyone even if further work is necessary to make windows appear as expected. -- Rob Shearman
Re: Why winetools is utterly useless, once and for all.
Am Di, Mär 28, 2006 at 03:21:01 -0500 schrieb Segin: 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 As this myth is floating around on this list since a long time I have to repeat: WineTools is not using a deprecated config file. It uses the regular registry way since a long time. that is gone, and only a few things will work via WineTools, if at all. So this is also not true. 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 If you use IEs4Linux you are actually using the overrides setup of WineTools as they took it from us. This also means that you have the most critisized *=native override included. We are working on this so you will probably have this on IEs4Linux soon after we fixed that. Regards Joachim von Thadden -- Never touch a running system! Never run a touching system? Never run a touchy system!!!
Re: server: Fix FPU registers in get_thread_context()
Dne 03/27/06 v 17:19:47 (+0200), Petr Tesarik napsal(a): Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a): Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: [skip] * Look at ContextFlags to see which registers are saved in thread-context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. I don't think so. A real 80386 without a math coprocessor does not even have an FPU context. I guess this is why CONTEXT_FULL does not include CONTEXT_FLOATING_POINT. As I'm re-thinking it once more, I'm no longer sure about my point. You're right that the signal handler must definitely save the FPU state if there is one. Otherwise, it can't restore the context correctly if the exception handler uses the FPU (which it is AFAIK allowed to do). And at least under Linux, there is always an FPU state (either from a real FPU, or emulated). So, I'll change my question: Is there a platform, where FPU instructions can't be invoked unless there is a real FPU? To kick the answers off, I'm providing a table of possible operating systems we run on the x86 architecture. Whoever knows for sure that floating point instructions can or can not be safely run even without a real (hardware) FPU, please help complete the chart. Also, feel free to add any other systems which can run Wine. Linux:OK FreeBSD: ??? NetBSD: ??? OpenBSD: ??? Solaris: ??? OS/X: ??? Petr Tesarik
Re: Why winetools is utterly useless, once and for all.
Typos, typos everywhere :) I've resisted switching from Pascal to C/C++ my whole high school, as I considered C too have too convoluted a syntax. My opinion hasn't changed, it's just that for a long time gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can should have been I've resisted switching from Pascal to C/C++ my whole high school, as I considered C to have too convoluted a syntax. My opinion hasn't changed, it's just that gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can Cheers, Kuba
Re: Unhandled exception: floating point stack check early in program?
Dan Kegel wrote: 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-dbgc 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=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=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) that's rather strange... even if the support for FPU is still lagging (see Petr's latest patches on the subject), the pass command should make it work (or at least not stay where the exception occured) I'd be interested in a +seh trace with a pass command issued in the debugger A+ -- Eric Pouech
OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. A few days ago I sent a comment to the list. Nothing really sinister, just an observation and an experience. Before long I had a particularly vicious and vile diatribe sent in reply to my comment - to my private email address. I have appended the lower headers and the bulk of the message I received at the end of this message (trimming the html from the bottom). I thought long and hard before taking this action. It is not something I would normally do, but in this instance I was so incensed at this individual's behaviour that I felt that 'naming and shaming' was the only way forward. Not even so much as to the fact that he directed his comments to me, but more the fact that had I been a new prospective developer, the effect such diatribe would have would not in any way be positive. It certainly would taint their perception of the open-source community. Furthermore I sincerely doubt that I am the only one to experience this behaviour. Others may just suffer in silence. I have worked with many smaller community projects, on OS/2 and latterly on Linux, and never been subjected to this kind of abuse from members of the community. I joined this list because I felt that there was something I could contribute to Wine, and in the instance it turned out that there was. I did not join it to receive unsolicited email of an abusive nature from members of the community. Had he done this by telephone I could have had him prosecuted, at least in the UK. But he hides behind a gmail.com address and makes comments I seriously suspect he would not have the balls to say to my face. No, I do not believe that we need a 'net police force'. Common decency between individuals, however, is essential. Diversity, discussion, criticism, expression, even annoyance are all valuable when driving a project forward. Blatant personal abuse is not tolerable. It is not tolerable in society, it should not be tolerated in the developer community. The community needs to police itself, rather than be policed, and individuals who bring the community into disrepute need to be dealt with by the community. That is why I bring this into the open. How to prevent such actions? I do not think it that this is possible in its entirety. I can (and have) simply add this individual's address to my blocked list. However, I may have been a newcomer to open-source development who would not have been so tolerant, and whose opinions of the community may have been changed by this action. May I suggest that whoever is responsible for the hosting of the mailing list change the configuration so that email addresses are not placed in the header? (I am no expert on mailing-list software but it does not immediately seem to be impractical.) That way all replies have to go to the list and this would prevent such unsolicited email being sent. This is my last word on this matter. Make of it what you will. I refuse to be prevented from contributing to vital projects such as Wine when I can by the antics of some depraved individual. It has left a sour taste in my mouth though, and like it or not, it does not portray Wine developers in a good light. --- Disposition-Notification-To: Segin [EMAIL PROTECTED] Date: Fri, 24 Mar 2006 15:01:11 -0500 From: Segin [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dr J A Gow [EMAIL PROTECTED] Subject: Re: Winetools - wine doors References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=010900050103010506060607 X-BV-Spam-Score: 0.4 (/) X-Envelope-From: [EMAIL PROTECTED] X-Virus-Scanned: by amavisd-new This is a multi-part message in MIME format. --010900050103010506060607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dr J A Gow wrote: I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however This clusterf*ck of nonsense helped me to get a microcontroller development suite running under Wine, which otherwise would not install You're a fucking retard, RTFM! You'd learn you need to use DLLOverrides in Winecfg. natively. After over ten years designing and developing embedded systems, there is one thing that stands out. That you're a dumbfuck? Code that is 'nonsense' does not work at all. That's 100% definitive of Winetools. Code that works may not be elegant, it may not be pretty and you may hate the style, but it _works_ Nope, wine doesn't do ~/.wine/config, which makes winetools COMPLETELY useless. **WINETOOLS DOES NOT DO A DAMN REDEEMING THING
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On 3/29/06, Dr J A Gow [EMAIL PROTECTED] wrote: I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. Thank you. It sometimes takes a thick skin to ignore the petty and childish rants that are prevalent online. Anonymity (or pseudo-anonymity in this case) often leads to childishness, and has done so since the beginnings of the Net. It gives the impression to potential new users and developers that the community is hostile and unwelcoming. I experienced a little bit of myself when asking my first couple of [naive] questions in IRC at #winehq. While it's completely understandable that people will get tired of seeing the same questions posted over and over again, there's no need to get hostile about it unless the user asking the questions gets hostile or demanding themselves (and even then, restraint or kick/ban would be preferable). If someone asks a stupid question (entirely subjective, remember), just ignore it or point to a place where they can learn the answer themselves. Please don't be a jerk. Thanks.
Direct3D, the kernel and ReactOS
Hello List, I had a talk to the DirectX developers of reactos on their irc channel to discuss how Reactos and Wine can share efforts on DirectX. (Please leave the legal issues asside for now, let us concentrate on the technical part for now). I didn't expect much possibility for a cooperation in such a hw-related thing as DirextX, but Greatlord told me about the gdi / win32k problem Wine is heading to with the current DirectX code. According to Greatlord, Microsoft's DirectX implementation basically consists of a kernel-side part in gdi.dll and win32k.sys, and a user-mode part in ddraw.dll, d3d8.dll and d3d9.dll. The user dlls contain the Hardware emulation layer code, and calls to the kernel for the Hardware abstraction layer. Now that wouldn't be a problem for Wine, as applications are expected to use the user mode dlls, and using the kernel interface is highly discouraged by Microsoft. However, there are a few apps out there which access the kernel interface directly, and Greatlord told me that he knew about a few companies which plan to use it to gain speed improvement. Expectedly, such apps won't work on Wine. My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings. Another thing we discussed was DirectInput. ReactOS uses wines dinput.dll, with improvements which gets the sdk demos and some nasty games working. I can see if I can merge the changes to Wine. pgpFt4dpgJOLX.pgp Description: PGP signature
getwinegit.sh 0.31 released!
OK, I'm tired now but this is a new release an it owns ;). It should be quite stable but I didn't test it. So what has changed: 0.31One more Release, I'm glad about this one - Some smaller an greater Fixes - After Compiling, the Script creates a helperfile to help mode 4 - Sections in Logfile - Trap included to handle ctrl+c - Implemented a small sleeper to give you a chance to stop the script before it starts to clean the source This is one of the last versions. The last version will be called 1.0. (maybe the next one?) If you miss a feature... write to the mailinglist. getwinegit.sh-0.31.tar.bz2 Description: BZip2 compressed data
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
Totally agreed. Segin needs to be not just kick/banned from the list, he needs to be K-Lined, if not G-Lined from all things wine! With respect to his comments though, on behalf of everyone involved with the project, and with the community as a whole, I sincerely apologize. TomOn 3/29/06, Jason Green [EMAIL PROTECTED] wrote: On 3/29/06, Dr J A Gow [EMAIL PROTECTED] wrote: I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action.Thank you.It sometimes takes a thick skin to ignore the petty andchildish rants that are prevalent online.Anonymity (orpseudo-anonymity in this case) often leads to childishness, and has done so since the beginnings of the Net.It gives the impression topotential new users and developers that the community is hostile andunwelcoming.I experienced a little bit of myself when asking my first couple of [naive] questions in IRC at #winehq.While it's completely understandable that people will get tired ofseeing the same questions posted over and over again, there's no needto get hostile about it unless the user asking the questions gets hostile or demanding themselves (and even then, restraint or kick/banwould be preferable).If someone asks a stupid question (entirelysubjective, remember), just ignore it or point to a place where they can learn the answer themselves.Please don't be a jerk.Thanks.
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
I'm pretty sure people are capable of filtering their own email. Afaict the offending emails were between two individuals. You may not like them but that has no bearing on whether they should be allowed to post to the mailing list given that those emails to the mailing list are appropriate. Chris On 3/29/06, Tom Spear [EMAIL PROTECTED] wrote: Totally agreed. Segin needs to be not just kick/banned from the list, he needs to be K-Lined, if not G-Lined from all things wine! With respect to his comments though, on behalf of everyone involved with the project, and with the community as a whole, I sincerely apologize. Tom On 3/29/06, Jason Green [EMAIL PROTECTED] wrote: On 3/29/06, Dr J A Gow [EMAIL PROTECTED] wrote: I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. Thank you. It sometimes takes a thick skin to ignore the petty and childish rants that are prevalent online. Anonymity (or pseudo-anonymity in this case) often leads to childishness, and has done so since the beginnings of the Net. It gives the impression to potential new users and developers that the community is hostile and unwelcoming. I experienced a little bit of myself when asking my first couple of [naive] questions in IRC at #winehq. While it's completely understandable that people will get tired of seeing the same questions posted over and over again, there's no need to get hostile about it unless the user asking the questions gets hostile or demanding themselves (and even then, restraint or kick/ban would be preferable). If someone asks a stupid question (entirely subjective, remember), just ignore it or point to a place where they can learn the answer themselves. Please don't be a jerk. Thanks.
Re: Direct3D, the kernel and ReactOS
On 29/03/06, Stefan Dösinger [EMAIL PROTECTED] wrote: I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings. Personally, unless it really becomes an issue, I'd rather not. It think it's hard enough to figure out what a particular d3d call is supposed to do as it is.
Here is an RSS feed for front page of www.winehq.com
I've long wondered why winehq.com does not provide an RSS feed. I've created one using the feed43.com sitescraping tool. Works well and it should be very low impact to your webserver (it only hits the URL at most once every 6 hours and caches the result for subsequent queries) Feel free to post this RSS link on the winehq homepage. http://feed43.com/winehq.xml Best Regards, Dan Schwarz
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On 3/29/06, Chris Morgan [EMAIL PROTECTED] wrote: I'm pretty sure people are capable of filtering their own email.Afaict the offending emails were between two individuals.You may notlike them but that has no bearing on whether they should be allowed topost to the mailing list given that those emails to the mailing list are appropriate.ChrisBe that as it may, the person who made those comments made them as a direct attack on someone who posted to the list. Regardless of whether or not the insults were posted to the list, he shouldn't have made them. As the person who reported the incident said, had it been a new developer interested in helping wine (either directly by contributing code to the project, or indirectly by writing a support app), he probably would have said screw this, I'm not going to help out a project that has developers who verbally attack me. I know I would have. Sure we all have to deal with someone who is annoyed at a stupid comment or question every now and then, but those were not stupid (not in my opinion), and had some very valid points. If the attacker had done some research instead of spouting off because he was tired of users complaining about something not working and it turning out to be because of winetools, we wouldnt be having this convo. With all of that being said and trying to get back on topic, sure winetools breaks a lot of things, but from what I can see, it also gets a lot of things working. If we have better documentation and if (here is the key) the users took the time to read thru all of the docs, which I admittedly don't, there wouldnt be any need for winetools. Honestly, I think that winetools should have been (from the beginning) something that creates a second installation of wine, from source, and that plays with registry files outside of the main wine install. IOW a user who uses wine doors should have a directory structure like this/-wine-source--all the uncompiled and unlinked files-wine--all the binaries and dll's, etc for a proper wine install (including wineprefixcreate, the wine executable, etc) -~/.wine--all the files outside of binaries-wine-doors--all the binaries and dll's etc for a proper wine install (like wine-doors instead of wine, and wineprefixcreate-doors, etc)-~/.wine-doors --all the files outside of binaries modified to work with different appsThen a user can run ./wine-tools and it will present them a prompt sayingDetecting app to be run... Internet Explorer Merging changes to wine registry to allow running of internet explorerChanges MergedRunning Internet ExplorerThen boom.. Up pops IE..That is what winetools should have done. But since it doesn't, we are working on wine doors. A much more user friendly wine tool that will have more features. Of course, I'm not sure how it's going to look, and since I don't speak fluently in C, I won't be contributing, but hopefully it will be better than winetools without all of the problems of winetools... Tom,
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
I'm pretty sure people are capable of filtering their own email. Afaict the offending emails were between two individuals. You may not like them but that has no bearing on whether they should be allowed to post to the mailing list given that those emails to the mailing list are appropriate. Chris Be that as it may, the person who made those comments made them as a direct attack on someone who posted to the list. Regardless of whether or not the insults were posted to the list, he shouldn't have made them. As the person who reported the incident said, had it been a new developer interested in helping wine (either directly by contributing code to the project, or indirectly by writing a support app), he probably would have said screw this, I'm not going to help out a project that has developers who verbally attack me. I know I would have. How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? Segin doesn't speak for the entire community and he isn't a lead on the project. If that were the case this would be a more serious matter. If people quit because of him then what are we to do? Given the lack of relationship between wine and Segin they might as well have quit wine development because of some Nigerian money transfer email or other spam. My point is that the solution isn't trying to enforce censorship where you simply cannot and where it doesn't impact the community. As long as he doesn't abuse his list membership we have no reason to become involved in this issue. You won't find me supporting any kind of restrictions on what he says or which mailing lists he can belong to at this point in time. Chris
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is s far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. I'm trying to say two things here: 1) If somebody says/ does something that is not okay, say something to that person. Of course, be constructive about it. For example, when I first joined this list, people got upset that I was top-posting - I learned that it was not ok in this community because people said someting. So, I try to bottom post (when I remember.) 2) I've always said Wine is an awesome thing - probably the best thing to come out of the Linux community since ... well, Linux and its desktops. Now, more than ever, Wine need as many developers as possible to keep it improve b/c as Linux adoption continues people will look to Wine and CrossOver for application cross-compatibility. And, I'm not talking about the developer who pops in with a patch every 6 months (I see that person as a patch submitter), but instead, I'm talking about a developer who dedicated him/herself to the Wine project. And with that, the team can't afford to lose that good talent b/c the newbie talent was mistreated in this community. Those are my 2 cents that I think will go a long way. Thanks, Hiji
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
Hiji wrote: I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is s far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. It's more about not feeding the trolls that agreeing with him. In my mind, Jon is a much more respectable member of the Wine community than segin. It would be disappointing to see a real contributor scared off by a troll. Personally, I think Winetools has it's place, but it would be more helpful to the Wine community if it was a bit better supported, and used builtin dlls in preference to natives ones whenever possible. Mike
Re: [OT] Re: Why winetools is utterly useless, once and for all.
Saulius Krasuckas wrote: * On Tue, 28 Mar 2006, Karl Lattimer wrote: And also, accusing people of having an IQ of 0 for replying to a flame isn't in the slightest constructive, Hardly. I have actually done something good. I got people to addresses the Winetools problem a bit early. Sure, it would have gotten adressed anyways, but only after enough complains come rolling in, months or years from now. When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end result was nothing but good, so why shun me? I was just getting a matter addressed before we have no choice but to address it. We can't just put it off forever, you know. Yes, he didn't write any single patch yet that was accepted, still he manages to joke calling one of the developers being a monkey. (Given that monkeys can't even distinguish between MUAs and MTAs nowadays) I haven't written any patches, namely because my eariler code changes i find cause signal 11. Recently I am working on something that will be offloaded months from now (if i dont find it to be too fustrating) as a huge diff, so keep your eyes peeled. If it doesn't work on either of my systems, it's broken, and sending a diff is a waste of everybody's time. Being of sensitive nature I'd remove him from the list so he will find appropriate lists to talk constructively in. (Be I wine-devel moderator)
Improper message recursion revealed by recent desktop window changes
The recent changes to the desktop have revealed a problem with recursive processing of X messages. The problem started to manifest with commit 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack that looks like this: application Window procedure WINPROC_wrapper ... CallWindowProcW ... SendMessageW X11DRV_SetWindowPos SetWindowPos X11DRV_ConfigureNotify process_events X11DRV_MsgWaitForMultipleObjectsEx wait_message_reply send_inter_thread_message SendMessageTimeoutW SendMessageW send_parent_notify DestroyWindow In other words, a destroy notification is being sent to the parent window with SendMessageW, and before that message returns an unrelated X message is processed. Under Windows the equivalent could never happen - if a thread is in SendMessage(), the only messages that can be delivered to it are ones sent by SendMessage() from another thread. The consequences of this can be unpleasant if the code that processes (in this case a window movement notification) the message interferes with state that is being dealt with in earlier stack frames. wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: res = USER_Driver-pMsgWaitForMultipleObjectsEx( 1, server_queue, INFINITE, QS_ALLINPUT, 0 ); The brute-force approach of changing this to the following makes the application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - [EMAIL PROTECTED]
Interesting D3D testapp
Hi there.
I think I just found a very nice D3D testapp: fr-025 by Farbrausch. A nice,
small (8.2MB) graphics demo, already works somewhat with Wine (starts, plays,
music and everything works, good performance), but lots and lots of effects
are simply missing or wrong. It does quite a bit interesting stuff wined3d
doesn't seem to handle: strange viewport handling, glow, blending,
reflections, blur(?). So many unimplemented features I won't even dare to
file bugreports for every single one... :)
It's the all-time most popular demo on pouet.net (obviously, given it's called
fr-025 - the.popular.demo ;) ) You can get it at:
http://www.pouet.net/prod.php?which=9450
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
[EMAIL PROTECTED]
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On Wednesday 29 March 2006 7:31 pm, Hiji wrote: How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. Perhaps you didn't actually read the emails that were sent. This might explain the discrepancy between your comment about thinking its important for the community to speak up when somebody is out of line and this email from Tom, the one I was replying to: From: Tom Spear [EMAIL PROTECTED] To: Wine Developers List wine-devel@winehq.com Date: Today 5:12:33 pm Totally agreed. Segin needs to be not just kick/banned from the list, he needs to be K-Lined, if not G-Lined from all things wine! With respect to his comments though, on behalf of everyone involved with the project, and with the community as a whole, I sincerely apologize. Sounds to me like this is advocating censorship. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is s far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. What he said on the list seemed pretty reasonable to me. Note that in the headers forwarded by Dr J A Gow the email from Segin appears to be directly from him and not to the list at all. It isn't our place to even care what Segin emails to people, as long as he isn't abusing the mailing list to do so. Chris
Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
On Wednesday 29 March 2006 7:31 pm, Hiji wrote: How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. Chris Morgan wrote: Perhaps you didn't actually read the emails that were sent. This might explain the discrepancy between your comment about thinking its important for the community to speak up when somebody is out of line and this email from Tom, the one I was replying to: I read all the emails, and I know exactly what I am referring to; so, there is no discrepancy. ;) I had in mind Segin's initial email (which was sent to the entire list): --- Segin [EMAIL PROTECTED] 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. To which I responded: Dude, you need a bit more constructive in your comments, or you'll be getting a lot of resentment on this list REAL fast. Per your comment What he said on the list seemed pretty reasonable to me., if you don't see anything wrong with what Segin said, then so be it. Others, meanwhile, have recognized his misplaced behavior. Cheers, Hiji
Re: Improper message recursion revealed by recent desktop window changes
On 3/29/06, Troy Rollo [EMAIL PROTECTED] wrote: The recent changes to the desktop have revealed a problem with recursive processing of X messages. The problem started to manifest with commit 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack that looks like this: application Window procedure WINPROC_wrapper ... CallWindowProcW ... SendMessageW X11DRV_SetWindowPos SetWindowPos X11DRV_ConfigureNotify process_events X11DRV_MsgWaitForMultipleObjectsEx wait_message_reply send_inter_thread_message SendMessageTimeoutW SendMessageW send_parent_notify DestroyWindow In other words, a destroy notification is being sent to the parent window with SendMessageW, and before that message returns an unrelated X message is processed. Under Windows the equivalent could never happen - if a thread is in SendMessage(), the only messages that can be delivered to it are ones sent by SendMessage() from another thread. The consequences of this can be unpleasant if the code that processes (in this case a window movement notification) the message interferes with state that is being dealt with in earlier stack frames. Yep, that's why the launching of War3 seems to only paint explorer or the launch window depending on how I hacked wine. This is the problem exhibited in bugs 4948, 4897, and 4847. wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: res = USER_Driver-pMsgWaitForMultipleObjectsEx( 1, server_queue, INFINITE, QS_ALLINPUT, 0 ); The brute-force approach of changing this to the following makes the application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - [EMAIL PROTECTED] Last thing I did today was looking at the message passing and signal handling. The signal handling doesn't look any different than before. I figured something could be up with the message handling as it seemed one thread was stomping on another but I don't know anything about wineserver. I'll take a better look tomorrow! Jesse
