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

Re: Debugging X errors?

by Segin

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

March 28, 2006

Re: Debugging X errors?

by Phil Krylov

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

March 28, 2006

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

by Kuba Ober

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

March 28, 2006

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

by Segin

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

March 28, 2006

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

by Segin

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

March 28, 2006

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

by Karl Lattimer

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

March 28, 2006

Re: Russian translation for uninstall application

by Dmitry Timoshkov

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

March 28, 2006

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

by Dan Kegel

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

March 28, 2006

Re: Debugging X errors?

by Andreas Mohr

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

March 28, 2006

Debugging X errors?

by Dan Kegel

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

March 28, 2006

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

by Joachim von Thadden

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

March 28, 2006

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

by Kai Blin

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

March 28, 2006

Re: I have a complaint about the website

by Francois Gouget

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

March 28, 2006

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

by Marcus Meissner

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

March 28, 2006

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

by Joris Huizer

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

March 28, 2006

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

by Alexandre Julliard

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

March 28, 2006

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

by Alexandre Julliard

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

March 28, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

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

March 28, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

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

March 28, 2006

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

by Hiji

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

March 28, 2006

Why winetools is utterly useless, once and for all.

by Segin

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

March 28, 2006

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

by Vitaly Budovski

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

March 28, 2006

Re: Winetools -> wine doors

by Tony Lambregts

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

March 28, 2006

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

by Vitaliy Margolen

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

March 28, 2006

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

by Tom Spear (Dustin Booker, Dustin Navea)

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

March 27, 2006