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

Re: Page fault xmlspy 2006 wine .9.10

by Mike McCormack

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

March 29, 2006

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

by Willie Sippel

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 <willie(a)froq.net>

March 29, 2006

Re: advpack: Open the INF file if the RSC_FLAG_INF flag is specified

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> 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 julliard(a)winehq.org

March 29, 2006

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

by 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? 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

March 29, 2006

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

by Willie Sippel

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 <willie(a)froq.net>

March 29, 2006

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

by 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. 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.

March 29, 2006

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

by Jakob Eriksson

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

March 29, 2006

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

by 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? Mike

March 29, 2006

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

by Saulius Krasuckas

* 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)

March 29, 2006

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

by Willie Sippel

Am Dienstag, 28. März 2006 11:31 schrieb Alexandre Julliard: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > > Ok so now say with Steam and all of it's games - it will be almost 100% > > unusable! Because we still haven't fixes managed/unmamaged windows. And > > Steam itself would be on top of everything. So the way people were able > > to work-around this is by putting Steam into virtual desktop. Now that > > means their game will run in the same desktop as well. > > We could add some sort of per-app setting again, though it wouldn't > work quite the same, apps in different desktops are a lot more > isolated now. But if the only use for it is to work around managed > mode bugs then it's probably not worth it, better to spend time fixing > the real problem. > 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 <willie(a)froq.net>

March 29, 2006

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

by Karl Lattimer

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,

March 29, 2006

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

by Segin

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 > > > > >

March 29, 2006

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

by Tom Williams

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

March 28, 2006

Re: Page fault xmlspy 2006 wine .9.10

by Grant Lewis

I have a new page fault from xmlspy in .9.10... Unhandled exception: page fault on write access to 0x0000001f in 32-bit code (0x007d62d6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:007d62d6 ESP:7fbff5d0 EBP:00002ce0 EFLAGS:00210206( - 00 - RIP1) EAX:0000001f EBX:00002cfc ECX:7f9d2720 EDX:00000001 ESI:7fbff638 EDI:7e2f0372 Stack dump: 0x7fbff5d0: 7fbff6bc 7fbff7dc 7daa5800 7deceee8 0x7fbff5e0: 019c0000 00000000 7daaba01 00ffffff 0x7fbff5f0: 7e2f0372 0000006c 00000000 000000cd 0x7fbff600: 00000024 0000019a 00100001 00000000 0x7fbff610: 00000028 000000cd 00000024 00100001 0x7fbff620: 00000003 000039f0 00000000 00000000 Backtrace: =>1 0x007d62d6 in xmlspy (+0x3d62d6) (0x007d62d6) 2 0x00000000 (0x00000000) 0x007d62d6: movl $0x1,0x0(%eax) Modules: Module Address Debug info Name (98 modules) PE 0x00400000-014eb000 Export xmlspy PE 0x10000000-1002e000 Deferred ssce5332 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7e9ac000-7e9c0000 Deferred msimg32<elf> \-PE 0x7e9b0000-7e9c0000 \ msimg32 ELF 0x7ed0b000-7ed20000 Deferred midimap<elf> \-PE 0x7ed10000-7ed20000 \ midimap ELF 0x7ee3e000-7ee5f000 Deferred msacm32<elf> \-PE 0x7ee50000-7ee5f000 \ msacm32 ELF 0x7ee5f000-7ee76000 Deferred msacm<elf> \-PE 0x7ee70000-7ee76000 \ msacm ELF 0x7ee76000-7ef4a000 Deferred libcrypto.so.0.9.7 ELF 0x7ef4a000-7ef72000 Deferred libssl.so.0.9.7 ELF 0x7ef72000-7ef8a000 Deferred libcups.so.2 ELF 0x7f093000-7f0c2000 Deferred uxtheme<elf> \-PE 0x7f0a0000-7f0c2000 \ uxtheme ELF 0x7f0c2000-7f0da000 Deferred ximcp.so.2 ELF 0x7f0da000-7f138000 Deferred libgl.so.1 ELF 0x7f14e000-7f1fd000 Deferred libx11.so.6 ELF 0x7f1fd000-7f211000 Deferred libice.so.6 ELF 0x7f211000-7f282000 Deferred winex11<elf> \-PE 0x7f220000-7f282000 \ winex11 ELF 0x7f282000-7f29d000 Deferred libexpat.so.0 ELF 0x7f29d000-7f2bf000 Deferred libfontconfig.so.1 ELF 0x7f2bf000-7f321000 Deferred libfreetype.so.6 ELF 0x7f328000-7f330000 Deferred libxcursor.so.1.0.2 ELF 0x7f330000-7f337000 Deferred libxrender.so.1 ELF 0x7f337000-7f390000 Deferred msvcrt<elf> \-PE 0x7f350000-7f390000 \ msvcrt PE 0x7f390000-7f3cb000 Deferred oraclm32 ELF 0x7f3cc000-7f3cf000 Deferred xlcdef.so.2 ELF 0x7f3cf000-7f3da000 Deferred libxext.so.6 ELF 0x7f3da000-7f3f4000 Deferred imm32<elf> \-PE 0x7f3e0000-7f3f4000 \ imm32 ELF 0x7f3f4000-7f46d000 Deferred winmm<elf> \-PE 0x7f400000-7f46d000 \ winmm ELF 0x7f46d000-7f48d000 Deferred odbc32<elf> \-PE 0x7f480000-7f48d000 \ odbc32 ELF 0x7f48d000-7f4b2000 Deferred ws2_32<elf> \-PE 0x7f4a0000-7f4b2000 \ ws2_32 ELF 0x7f4b2000-7f4cb000 Deferred wsock32<elf> \-PE 0x7f4c0000-7f4cb000 \ wsock32 ELF 0x7f4cb000-7f4e7000 Deferred mpr<elf> \-PE 0x7f4d0000-7f4e7000 \ mpr ELF 0x7f4e7000-7f522000 Deferred wininet<elf> \-PE 0x7f4f0000-7f522000 \ wininet ELF 0x7f522000-7f541000 Deferred cabinet<elf> \-PE 0x7f530000-7f541000 \ cabinet ELF 0x7f541000-7f56d000 Deferred urlmon<elf> \-PE 0x7f550000-7f56d000 \ urlmon ELF 0x7f56d000-7f5e6000 Deferred oleaut32<elf> \-PE 0x7f580000-7f5e6000 \ oleaut32 ELF 0x7f5e6000-7f5fa000 Deferred olepro32<elf> \-PE 0x7f5f0000-7f5fa000 \ olepro32 ELF 0x7f5fa000-7f613000 Deferred oledlg<elf> \-PE 0x7f600000-7f613000 \ oledlg ELF 0x7f613000-7f639000 Deferred winspool<elf> \-PE 0x7f620000-7f639000 \ winspool ELF 0x7f639000-7f6d2000 Deferred comctl32<elf> \-PE 0x7f640000-7f6d2000 \ comctl32 ELF 0x7f6d2000-7f6ee000 Deferred iphlpapi<elf> \-PE 0x7f6e0000-7f6ee000 \ iphlpapi ELF 0x7f6ee000-7f729000 Deferred rpcrt4<elf> \-PE 0x7f700000-7f729000 \ rpcrt4 ELF 0x7f729000-7f79b000 Deferred ole32<elf> \-PE 0x7f740000-7f79b000 \ ole32 ELF 0x7f79b000-7f7e7000 Deferred shlwapi<elf> \-PE 0x7f7b0000-7f7e7000 \ shlwapi ELF 0x7f7e7000-7f896000 Deferred shell32<elf> \-PE 0x7f800000-7f896000 \ shell32 ELF 0x7f896000-7f92c000 Deferred comdlg32<elf> \-PE 0x7f8a0000-7f92c000 \ comdlg32 ELF 0x7f92c000-7f963000 Deferred advapi32<elf> \-PE 0x7f940000-7f963000 \ advapi32 ELF 0x7f963000-7f9e3000 Deferred gdi32<elf> \-PE 0x7f970000-7f9e3000 \ gdi32 ELF 0x7f9e3000-7faf0000 Deferred user32<elf> \-PE 0x7fa00000-7faf0000 \ user32 ELF 0x7fc02000-7fc05000 Deferred libxrandr.so.2 ELF 0x7fc05000-7fcf0000 Deferred kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe01000-7fe10000 Deferred libz.so.1 ELF 0x7fe10000-7fe1a000 Deferred libnss_files.so.2 ELF 0x7fe1a000-7fe24000 Deferred libnss_nis.so.2 ELF 0x7fe24000-7fe39000 Deferred libnsl.so.1 ELF 0x7fe39000-7fe42000 Deferred libnss_compat.so.2 ELF 0x7fe44000-7fe48000 Deferred libxxf86vm.so.1 ELF 0x7fe48000-7fe50000 Deferred libsm.so.6 ELF 0x7fe53000-7fe58000 Deferred libxxf86dga.so.1 ELF 0x7fe5b000-7fe7e000 Deferred libm.so.6 ELF 0x7fe7e000-7ff74000 Deferred libwine_unicode.so.1 ELF 0x7ff74000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7e18000-b7e1c000 Deferred libdl.so.2 ELF 0xb7e1c000-b7f37000 Deferred libc.so.6 ELF 0xb7f37000-b7f89000 Deferred libpthread.so.0 ELF 0xb7f9f000-b7fb9000 Deferred libwine.so.1 ELF 0xb7fba000-b7fd1000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 0000000f -1 0000000e 0 0000000d 0 0000000c 0 0000000a 0000000b 0 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 00000009 0 <==

March 28, 2006

Re: Page fault xmlspy 2006 wine .9.10

by Grant Lewis

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 0x0000001f at address >> 0x7d62d6 (th >> read 0009), starting debugger... >> WineDbg starting on pid 0x8 >> First chance exception: page fault on read access to 0x00000000 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

March 28, 2006

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

by Joseph Garvin

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.

March 28, 2006

Re: What happened to the Fedora packages?

by Neal Gompa

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 <ngompa13(a)gmail.com> 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 < fgouget(a)free.fr> 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 fails.... > > > > Oh, the compilation fails? That's not the same as the computer > > crashing... > > > > Maybe you can send us the error message and then we can help you. > > > > -- > > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > > Demander si un ordinateur peut penser revient à demander > > si un sous-marin peut nager. > > > >

March 28, 2006

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

by Kuba Ober

> > > 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.

March 28, 2006

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

by Stefan Dösinger

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

March 28, 2006

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

by Alexandre Julliard

"Jesse Allen" <the3dfxdude(a)gmail.com> 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 julliard(a)winehq.org

March 28, 2006

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

by Stefan Dösinger

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

March 28, 2006

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

by Jesse Allen

On 3/27/06, Tony Lambregts <tony.lambregts(a)gmail.com> wrote: > Alexandre Julliard wrote: > > Module: wine > > Branch: refs/heads/master > > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… > > > > Author: Alexandre Julliard <julliard(a)winehq.org> > > Date: Mon Mar 27 22:43:03 2006 +0200 > > > > x11drv: Moved desktop mode handling to the explorer process. > > > > Per-application desktop mode settings are no longer supported. Apps > > can be launched in a specific desktop window by using: > > > > explorer /desktop=name[,widthxheight] app.exe [args] > > 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

March 28, 2006

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

by Tom Spear

On 3/28/06, Kuba Ober <kuba(a)mareimbrium.org> 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 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 > > > 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

March 28, 2006

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

by Segin

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?

March 28, 2006

Re: Debugging X errors?

by Segin

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

March 28, 2006