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

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Tony Lambregts

Augusto Arcoverde da Rocha wrote: > But... I have a request... ;-) > > Please apply the patch that I have sent to fix bug 2400 [1], because > the <del> + <comma> key bug is too annoying ... and, at least, the > problem is reduced until we can deliver a new keyboard driver. > > --- > [1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html > This problem has been around for quite a while (since at least August 2004) I think it would be a good idea to apply this patch as well. This problem has been around for quite a while (since at least August 2004). It does what it is supposed to do and does not cause regressions. If it were up to me it would have been applied a while ago. However it is not up to me It is up to Alexandre. Alexandre is there a reason that this patch is not acceptable for you? -- Tony Lambregts

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Tom Spear

On 3/31/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > > > On 3/31/06, Tom Spear <speeddymon(a)gmail.com> wrote: > [cut] > > I think that rewriting the keyboard code in this way is a very good > thing, > > and will be more than happy to help coordinate testing of it, although I > > can't test any myself. Rewriting the code should allow us to close many > of > > the keyboard related bugs in bugzilla, which will be a big BIG plus in > my > > book. > > > > Like I said, if you want me to, I will coordinate testing of new > code. I'll > > start a new thread called keyboard rewrite and ask for volunteers with > > different keyboard layouts to reply to that thread to test new > code. I'm > > also going to create an offspring of the main wiki page for this > project, > > once given confirmation that you will do the rewrite. > > > > Tom > > Tom, > > "I offer a hand and you grab my arm?" ;-) > (in Portuguese this is a funny quote...) Thats pretty funny even in english! lol Sorry if that is what I did. I just said that I *started thinking* in rewriting the code, and I am > still thinking... Nevertheless, I'm not an experience C programmer -- > like many programmers in this list -- and I don't know the X server > API and what vkey, keycode and keyscan mean until the last month when > I tried to solve bug 2400 ("Issue with Delete when NumLock active"). Yes I understand, which is why I said even if you can only contribute a little bit. I'm not expecting a complete rewrite overnight.. Heck, even Alexandre's window management rewrite has been ongoing for several months if not over the last year. I just figured that if you could do some of it, then other developers with more experience might take notice and start submitting patches, or might offer more tips on what is right and what needs to be changed about your patches.. I have looked at the rdesktop code and found an approach completely > different of my ideas, a sign that I may be wrong (and probably am) > about "keysym2vkey". :-/ I see. Personally I think even if the approach is wrong, we could see the differences between it and our code and figure out what to do to make ours work like theirs does (100% all the time) without using the same approach (hope that makes sense).. If Wine Devel Community has no problem in putting this task on new > hands -- even though I can dedicate full time to that task -- I also > haven't got a problem! 8D I'm sure that others will step up to the plate shortly. It has only been a couple of hours since I posted. Hopefully nobody forces me to make this a call to arms for developers! ;-D I will get very happy if some more programmers offer some *arms* (or > some comments) to help me. :-) > > But... I have a request... ;-) > > Please apply the patch that I have sent to fix bug 2400 [1], because > the <del> + <comma> key bug is too annoying ... and, at least, the > problem is reduced until we can deliver a new keyboard driver. Alexandre? Can you comment please? --- > [1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html Thanks so much guys Tom

March 31, 2006

Re: Keyboard Rewrite

by Tom Spear

On 3/31/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > Am Freitag, 31. März 2006 21:33 schrieb Tom Spear: > > Hi all, this is a call for volunteers. I am hoping that certain > developers > > participating in another thread are willing to rewrite the keyboard > code, > > but we need people to test. If you are interested, please reply here > > saying that you are interested, and what kind of keyboard you use, as > well > > as the layout you use under X. I will be creating a wiki page for this > > project once the people who will be taking on this rewrite confirm that > > they will do so, and will post the link to this thread as soon as it is > > created. > > > > The purpose of this rewrite is to (hopefully) fix all of the problems > > people have with key mappings, characters not showing up as expected, > race > > conditions, characters not showing up at all, etc, and hopefully allow > us > > to close out many of the bugs in bugzilla having to do with the > keyboard. > > > > Thanks all in advance > > > > Tom > > If this is about testing, I'll gladly help. I use a German SUN Type6 > keyboard > (only one control key, Compose key, SUN keys instead of Windows keys, no > menu > key) with German layout and swapcaps. I also used to use an application > that > crashes due to a regression in Wine's keyboard handling it seems - could > be a > nice test app. > > -- > Willie Sippel > > //////// | Tritium Studios > // | ______________________________ > //// /// | http://www.tritium-studios.com > > <willie(a)froq.net> > > > Thank you all for your submissions. Please keep 'em coming. I am headed home now, and will organize all emails for this thread into a different folder on my machine so I can keep track of them. If some devs come forward and agree to start cracking on a keyboard rewrite, I will take my sorted emails and create the wiki page. I have the layout figured out in my head, but it is kinda hard to describe. You will see it in a few days, and I think you will like it. I do have a question for anyone who knows though. There are 2 distinct variations on the most common keyboard bugs. Keyboard output gets sent to console, or doesnt work at all; and these keys on my keyboard don't work or dont work as expected, or this layout isn't recognized by wine and wine said to report it here. Is the first variation a bug in the keyboard code, or is it something to do with some other component of wine? I ask because we already have a metabug in bugzilla, and I don't want to link those bugs to the metabug if they arent a bug in the keyboard code.. I'd rather link it to a directx metabug (if there is one) or so forth. Tom

March 31, 2006

Re: Update on Software Freedom Law Center work

by Kai Blin

* Alexandre Julliard <julliard(a)winehq.org> [31/03/06, 23:27:51]: > 2. Non-profit organization > > There are many advantages to having a non-profit organization for a > project, for instance to allow tax-exempt donations, or hold assets > like trademarks. However it's a lot of paperwork to do, so we never > went to the trouble of setting one up. > > Now the SFLC is starting an organization called the Software Freedom > Conservancy, that will be officially launched on Monday. It's > basically an umbrella non-profit that provides services to free > software projects. By joining that organization, we will get all the > advantages of having our own non-profit, without having to do any of > the work, so that seems like a good deal... > > There will also be the possibility of assigning our copyrights to that > organization, which would make it easier to enforce the license, and > provide some liability protection for developers. However this will > only be done if most developers are comfortable with it, so I'd be > interested to hear your feedback on this issue. I'm still unsure about this "assigning the copyright to someone else" thing. I'm living in the EU, where the copyright is split into "usage rights" and "creator's rights" and only the usage rights are transferable. I'm not into that legal stuff too much, so I'd leave that to experts to decide on, but I'd like to see a conclusive explanation on how this will apply to all of us new and old Europeans. Cheers, Kai -- Kai Blin, (blin at gmx dot net) I haven't lost my mind; I know exactly where I left it.

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Augusto Arcoverde da Rocha

> On 3/31/06, Tom Spear <speeddymon(a)gmail.com> wrote: [cut] > I think that rewriting the keyboard code in this way is a very good thing, > and will be more than happy to help coordinate testing of it, although I > can't test any myself. Rewriting the code should allow us to close many of > the keyboard related bugs in bugzilla, which will be a big BIG plus in my > book. > > Like I said, if you want me to, I will coordinate testing of new code. I'll > start a new thread called keyboard rewrite and ask for volunteers with > different keyboard layouts to reply to that thread to test new code. I'm > also going to create an offspring of the main wiki page for this project, > once given confirmation that you will do the rewrite. > > Tom Tom, "I offer a hand and you grab my arm?" ;-) (in Portuguese this is a funny quote...) I just said that I *started thinking* in rewriting the code, and I am still thinking... Nevertheless, I'm not an experience C programmer -- like many programmers in this list -- and I don't know the X server API and what vkey, keycode and keyscan mean until the last month when I tried to solve bug 2400 ("Issue with Delete when NumLock active"). I have looked at the rdesktop code and found an approach completely different of my ideas, a sign that I may be wrong (and probably am) about "keysym2vkey". :-/ If Wine Devel Community has no problem in putting this task on new hands -- even though I can dedicate full time to that task -- I also haven't got a problem! 8D I will get very happy if some more programmers offer some *arms* (or some comments) to help me. :-) But... I have a request... ;-) Please apply the patch that I have sent to fix bug 2400 [1], because the <del> + <comma> key bug is too annoying ... and, at least, the problem is reduced until we can deliver a new keyboard driver. --- [1] http://www.winehq.org/pipermail/wine-patches/2006-March/024891.html Cheers, Augusto Arcoverde da Rocha

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Chris Morgan

Just using the jack audio driver won't ensure that we won't see stuttering sound. If dsound is performing hardware emulation then it has its own internal thread that is performing mixing and other dsound events. If this thread gets held off then you'll have no sound to give to the jack audio drive when it runs. Increasing the size of this dsound buffer and ensuring that it runs seems like the easiest ways to fix issues with the dsound thread being held off and should work for all audio interfaces assuming their threads also run reliably. Chris On 3/31/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn: > > > Until it crashes your box of course... > > > > If a Windows program has a habit of hard freezing the system then the > > user will learn not to run that program. > > > > As it is, right now _many_ games suffer this problem with corrupted > > audio and it's very unpleasant (loud bursts of white noise). Makes the > > games unplayable, in fact. > > > > I'd rather make the games playable and give developers an incentive to > > find a better privilege model than leave this to coast along for another > > few years with only a bunch of talk, ideas and non-mainline patches. > > > > Right now there are no good solutions for this we can implement in Wine > > itself (except maybe making wineserver suid root and drop privs), and > > SCHED_ISO isn't merged into the mainline kernel, so telling users to > > upgrade won't solve much. > > > I'm probably wrong, but in theory, if Wine used the Jack audio driver, and > jackd is suid root, the sound shouldn't stutter but Wine/ a Windows app still > couldn't hard-lock the system, as Wine would run with standard user > privileges? If that's the case, wouldn't fixing the Jack driver and making it > the preferred output plugin solve the issue? I mean, it's at least as > conveniant as suggesting to run Wine as root... ;-) > > -- > Willie Sippel > > //////// | Tritium Studios > // | ______________________________ > //// /// | http://www.tritium-studios.com > > <willie(a)froq.net> > > >

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Willie Sippel

Am Freitag, 31. März 2006 23:38 schrieb Mike Hearn: > > Until it crashes your box of course... > > If a Windows program has a habit of hard freezing the system then the > user will learn not to run that program. > > As it is, right now _many_ games suffer this problem with corrupted > audio and it's very unpleasant (loud bursts of white noise). Makes the > games unplayable, in fact. > > I'd rather make the games playable and give developers an incentive to > find a better privilege model than leave this to coast along for another > few years with only a bunch of talk, ideas and non-mainline patches. > > Right now there are no good solutions for this we can implement in Wine > itself (except maybe making wineserver suid root and drop privs), and > SCHED_ISO isn't merged into the mainline kernel, so telling users to > upgrade won't solve much. > I'm probably wrong, but in theory, if Wine used the Jack audio driver, and jackd is suid root, the sound shouldn't stutter but Wine/ a Windows app still couldn't hard-lock the system, as Wine would run with standard user privileges? If that's the case, wouldn't fixing the Jack driver and making it the preferred output plugin solve the issue? I mean, it's at least as conveniant as suggesting to run Wine as root... ;-) -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Chris Morgan

Can't we use kernel capabilities to let people do this without having to run as root? Thats what jack audio server users are advised to do to ensure SCHED_FIFO. Chris On 3/31/06, Mike Hearn <mike(a)plan99.net> wrote: > > Until it crashes your box of course... > > If a Windows program has a habit of hard freezing the system then the > user will learn not to run that program. > > As it is, right now _many_ games suffer this problem with corrupted > audio and it's very unpleasant (loud bursts of white noise). Makes the > games unplayable, in fact. > > I'd rather make the games playable and give developers an incentive to > find a better privilege model than leave this to coast along for another > few years with only a bunch of talk, ideas and non-mainline patches. > > Right now there are no good solutions for this we can implement in Wine > itself (except maybe making wineserver suid root and drop privs), and > SCHED_ISO isn't merged into the mainline kernel, so telling users to > upgrade won't solve much. > > > If we have to require people to upgrade their kernel to get > > the feature that's fine; at least then when the box dies we can blame > > the kernel guys ;-) > > I agree that it's not good, but this patch makes the best of a bad > situation and it's better for the users this way. If they don't want to > run as root, they don't have to, and if - like me - they know the game > is safe and wish to have some fun this evening then they can. > > thanks -mike > > >

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Mike Hearn

> Until it crashes your box of course... If a Windows program has a habit of hard freezing the system then the user will learn not to run that program. As it is, right now _many_ games suffer this problem with corrupted audio and it's very unpleasant (loud bursts of white noise). Makes the games unplayable, in fact. I'd rather make the games playable and give developers an incentive to find a better privilege model than leave this to coast along for another few years with only a bunch of talk, ideas and non-mainline patches. Right now there are no good solutions for this we can implement in Wine itself (except maybe making wineserver suid root and drop privs), and SCHED_ISO isn't merged into the mainline kernel, so telling users to upgrade won't solve much. > If we have to require people to upgrade their kernel to get > the feature that's fine; at least then when the box dies we can blame > the kernel guys ;-) I agree that it's not good, but this patch makes the best of a bad situation and it's better for the users this way. If they don't want to run as root, they don't have to, and if - like me - they know the game is safe and wish to have some fun this evening then they can. thanks -mike

March 31, 2006

Re: Keyboard Rewrite

by Segin

Tom Spear wrote: > Hi all, this is a call for volunteers. I am hoping that certain > developers participating in another thread are willing to rewrite the > keyboard code, but we need people to test. If you are interested, > please reply here saying that you are interested, and what kind of > keyboard you use, as well as the layout you use under X. I will be > creating a wiki page for this project once the people who will be > taking on this rewrite confirm that they will do so, and will post the > link to this thread as soon as it is created. > > The purpose of this rewrite is to (hopefully) fix all of the problems > people have with key mappings, characters not showing up as expected, > race conditions, characters not showing up at all, etc, and hopefully > allow us to close out many of the bugs in bugzilla having to do with > the keyboard. > > Thanks all in advance > > Tom > >------------------------------------------------------------------------ > > > > Sure, I'll help. Let me go fetch my X settings... (opens nedit on /etc/X11/xorg.conf....) I don't know what this qualifies as, but it's 'hp5181' (my keyboard is a HP5181), The keyboard rules appear to be pc104 with extra code for extended keys, XF86Audio[InsetKeyHere], example, XF86AudioPlay (or whatever the name for it is, i know that XF86Audio part is right) My X config for the keyboard subject: Section "InputDevice" # miles of xorgcfg comments stripped for breverty, never removed them # ... Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "500 30" # Specify which keyboard LEDs can be user-controlled (eg, with xset(1)) Option "XkbRules" "xorg" Option "XkbModel" "hp5181" Option "XkbLayout" "en_US" EndSection

March 31, 2006

Re: Update on Software Freedom Law Center work

by Mike Hearn

> There will also be the possibility of assigning our copyrights to that > organization, which would make it easier to enforce the license Copyright assignment in other projects has been tricky, and it can't be done retroactively. It usually requires developers to submit paperwork - we don't really want that .... do we? thanks -mike

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: >> Not to mention that SCHED_FIFO requires root, which is an absolute PITA. > > Not really. > > su -c 'wine IG2.exe' > > It's not all that inconvenient :) Until it crashes your box of course... I really don't think we want to encourage running as root, or give Windows apps a way to screw up the system. If we have to require people to upgrade their kernel to get the feature that's fine; at least then when the box dies we can blame the kernel guys ;-) -- Alexandre Julliard julliard(a)winehq.org

March 31, 2006

Update on Software Freedom Law Center work

by Alexandre Julliard

Folks, As announced at the last Wineconf, Jeremy and myself have been working for a few months now with the Software Freedom Law Center on a number of legal issues concerning Wine. We've been mostly quiet about it, so I thought I'd post a status update. There are two major tasks going on at the moment: 1. Code audit We are doing an audit of the code base, to make sure we have proper records of all contributions, and spot any potentially troublesome code. The goal is to be able to show to people who don't want to dig through the source that we have done our development properly, and that they can use Wine without fear of legal trouble. Currently, a survey is being sent out to people we have identified as major contributors, so that we can collect some information from them, like employers, license agreements, that sort of thing. This will enable us to build a complete track record for all contributions. We are still processing the results, at this point the responses we received cover approximately half of the code base (many thanks to everybody who took the time to answer!). We'll be sending the survey to more contributors in the near future to try to get as close to 100% coverage as we can. 2. Non-profit organization There are many advantages to having a non-profit organization for a project, for instance to allow tax-exempt donations, or hold assets like trademarks. However it's a lot of paperwork to do, so we never went to the trouble of setting one up. Now the SFLC is starting an organization called the Software Freedom Conservancy, that will be officially launched on Monday. It's basically an umbrella non-profit that provides services to free software projects. By joining that organization, we will get all the advantages of having our own non-profit, without having to do any of the work, so that seems like a good deal... There will also be the possibility of assigning our copyrights to that organization, which would make it easier to enforce the license, and provide some liability protection for developers. However this will only be done if most developers are comfortable with it, so I'd be interested to hear your feedback on this issue. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2006

Re: Keyboard Rewrite

by Willie Sippel

Am Freitag, 31. März 2006 21:33 schrieb Tom Spear: > Hi all, this is a call for volunteers. I am hoping that certain developers > participating in another thread are willing to rewrite the keyboard code, > but we need people to test. If you are interested, please reply here > saying that you are interested, and what kind of keyboard you use, as well > as the layout you use under X. I will be creating a wiki page for this > project once the people who will be taking on this rewrite confirm that > they will do so, and will post the link to this thread as soon as it is > created. > > The purpose of this rewrite is to (hopefully) fix all of the problems > people have with key mappings, characters not showing up as expected, race > conditions, characters not showing up at all, etc, and hopefully allow us > to close out many of the bugs in bugzilla having to do with the keyboard. > > Thanks all in advance > > Tom If this is about testing, I'll gladly help. I use a German SUN Type6 keyboard (only one control key, Compose key, SUN keys instead of Windows keys, no menu key) with German layout and swapcaps. I also used to use an application that crashes due to a regression in Wine's keyboard handling it seems - could be a nice test app. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Mike Hearn

On Fri, 31 Mar 2006 15:21:51 +0200, Andreas Mohr wrote: > IMHO we should really add some smart detection of SCHED_ISO kernel capability > and *much* prefer to use that one then. One really wouldn't want to hang > the box... Sure, feel free to add it after this basic universal support has gone in :) Right now SCHED_ISO is only available in the -ck kernels right? > Not to mention that SCHED_FIFO requires root, which is an absolute PITA. Not really. su -c 'wine IG2.exe' It's not all that inconvenient :) > Nice To Have would be support for stuff such as SCHED_IDLEPRIO and > SCHED_BATCH... Sure. But for now this will start off OK. > Make that > static int already_warned; /* static: = 0! */ > > Since static uses 0 as default and you don't want to waste space in the > .bss(?) segment for an explicit 1 init. Good catch. Alexandre, could you modify that as you commit? thanks -mike

March 31, 2006

Re: Keyboard Rewrite

by Molle Bestefich

I have a couple of Danish keyboards. I'll gladly spend some time testing with those. (I even have one with A1-A4 keys...)

March 31, 2006

Keyboard Rewrite

by Tom Spear

Hi all, this is a call for volunteers. I am hoping that certain developers participating in another thread are willing to rewrite the keyboard code, but we need people to test. If you are interested, please reply here saying that you are interested, and what kind of keyboard you use, as well as the layout you use under X. I will be creating a wiki page for this project once the people who will be taking on this rewrite confirm that they will do so, and will post the link to this thread as soon as it is created. The purpose of this rewrite is to (hopefully) fix all of the problems people have with key mappings, characters not showing up as expected, race conditions, characters not showing up at all, etc, and hopefully allow us to close out many of the bugs in bugzilla having to do with the keyboard. Thanks all in advance Tom

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Tom Spear

On 3/31/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > > On 3/30/06, Peter Åstrand <astrand(a)cendio.se> wrote: > > > > On Thu, 30 Mar 2006, Wine Bugs wrote: > > > http://bugs.winehq.org/show_bug.cgi?id=1181 > > > > > > ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 > 10:26 ------- > [cut] > I don't know the problem with the bug 4923 [1], but when we fix the > bug 1181 [2] and make Wine use KeySym, this race condition won't occur > since X11DRV_ToUnicodeEx function will not use AltGrMask or any other > global variable concerning the keyboard state, only a table like > "ksym2vkey". Besides, applications that use X server API directly > don't have this behavior. > --- > [1] http://bugs.winehq.org/show_bug.cgi?id=4923 > [2] http://bugs.winehq.org/show_bug.cgi?id=1181 > > I'm trying to solve the bug 2400 [3] and looking more closely the code > in dlls/x11drv/keyboard.c I started thinking in rewriting this code to > use directly keysyms sent by X server to translate XEvents to vkeys > instead of the currently > "xevent->keycode->keysym->keycode->vkey/character" way as implemented > from the X11DRV_KeyEvent to X11DRV_ToUnicodeEx functions. > --- > [3] http://bugs.winehq.org/show_bug.cgi?id=2400 > > I think that rewriting the keyboard code in this way is a very good thing, and will be more than happy to help coordinate testing of it, although I can't test any myself. Rewriting the code should allow us to close many of the keyboard related bugs in bugzilla, which will be a big BIG plus in my book. Like I said, if you want me to, I will coordinate testing of new code. I'll start a new thread called keyboard rewrite and ask for volunteers with different keyboard layouts to reply to that thread to test new code. I'm also going to create an offspring of the main wiki page for this project, once given confirmation that you will do the rewrite. Tom

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Kuba Ober

On Friday 31 March 2006 10:24, Dan Kegel wrote: > On 3/31/06, Dan Kegel <dank(a)kegel.com> wrote: > > > > Incidentally, the port of PSPI used winelib for no obvious reason. > > > > Wouldn't it have been more robust just to use Wine? > > > > > > But it is using wine, that's what Winelib does :) [. . .] > > If a distribution ships this and a matching copy of Wine, > > and stays up to date, perhaps. > > A worse problem is that PSPI can't be built without > a closed source, non-redistributable SDK (IIRC). You're correct. Someone needs to start a project to write an open source replacement for that SDK, then. I hope it's less of a job than say wine is :) Probably whoever has that SDK could write documentation for the underlying API, someone else would write the headers, link libs and whatever glue code needed, and would post it under BSD or somesuch. Cheers, Kuba

March 31, 2006

Re: getwinegit.sh 0.31 released!

by Christian Lachner

There will be a new version soon since i found some things to change. What can you expect: All stdout and stderr gets into the logfile. (expecting getwinegit.sh's outputs) some small improvements :) greets On 3/29/06, Christian Lachner <gladiac.lists(a)gmail.com> wrote: > OK, I'm tired now but this is a new release an it owns ;). It should > be quite stable but I didn't test it. So what has changed: > > 0.31 One more Release, I'm glad about this one > - Some smaller an greater Fixes > - After Compiling, the Script creates a helperfile to help mode 4 > - Sections in Logfile > - Trap included to handle ctrl+c > - Implemented a small sleeper to give you a chance to stop the > script before it starts to clean the source > > This is one of the last versions. The last version will be called 1.0. > (maybe the next one?) > > If you miss a feature... write to the mailinglist. > > >

March 31, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Jesse Allen

On 3/30/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > Troy Rollo <wine(a)troy.rollo.name> writes: > > > The brute-force approach of changing this to the following makes the > > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > > change I thought it best left to people with more familiarity with it. > > I committed a few fixes that should help, please give it a try. > Ok, those patches didn't seem to help. I tried to compare more closely my stack in my program with his. Instead of DestroyWindow, my app is calling ShowWindow, so during a SendMessageW I believe of WM_NCACTIVATE, it gets stuck. The instruction is int 80 so I believe that means it is going to do a system call? If 0x8 thread gets killed or you step until it ends, the other thread will start working again. If you try cont, it remains stuck. Well you can see the my winedbg session at this link. ftp://resnet.dnip.net/ShowWindowProblem.txt Jesse

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dimi Paun

From: "Marcus Meissner" <meissner(a)suse.de> > As far as I understood you need Photoshop SDK headers to build it, > right? Indeed, I forgot about that. Hey, at least Tor seemed to had fun compiling the thing via Winelib :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 31, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Augusto Arcoverde da Rocha

On 3/30/06, Peter Åstrand <astrand(a)cendio.se> wrote: > > On Thu, 30 Mar 2006, Wine Bugs wrote: > > http://bugs.winehq.org/show_bug.cgi?id=1181 > > > > ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 10:26 ------- [cut] > > Hi, now you know about this bug. As the comment says, it might be possible > to reuse some parts from the rdesktop implementation. > > I'm not saying that it will be easy, though. To be honest, I think bug > 4923, and many others, are more important. Instead of fixing Wine, it > might be possible to enhance Xvnc so that it can "emulate" a physical > Xserver with a certain physical keyboard. > I don't know the problem with the bug 4923 [1], but when we fix the bug 1181 [2] and make Wine use KeySym, this race condition won't occur since X11DRV_ToUnicodeEx function will not use AltGrMask or any other global variable concerning the keyboard state, only a table like "ksym2vkey". Besides, applications that use X server API directly don't have this behavior. --- [1] http://bugs.winehq.org/show_bug.cgi?id=4923 [2] http://bugs.winehq.org/show_bug.cgi?id=1181 I'm trying to solve the bug 2400 [3] and looking more closely the code in dlls/x11drv/keyboard.c I started thinking in rewriting this code to use directly keysyms sent by X server to translate XEvents to vkeys instead of the currently "xevent->keycode->keysym->keycode->vkey/character" way as implemented from the X11DRV_KeyEvent to X11DRV_ToUnicodeEx functions. --- [3] http://bugs.winehq.org/show_bug.cgi?id=2400 > Regards, > -- > Peter Åstrand ThinLinc Chief Developer > Cendio http://www.cendio.se > Teknikringen 3 > 583 30 Linköping Phone: +46-13-21 46 00 > Cheers, Augusto Arcoverde da Rocha

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Marcus Meissner

On Fri, Mar 31, 2006 at 10:15:20AM -0500, Dimi Paun wrote: > From: "Dan Kegel" <dank(a)kegel.com> > > Incidentally, the port of PSPI used winelib for no obvious reason. > > Wouldn't it have been more robust just to use Wine? > > But it is using wine, that's what Winelib does :) > One can try with the PE version of PSPI I suppose... > But this way it is fully buildable on Linux, without > the need to have MingW installed. This is likely > important for distributions. As far as I understood you need Photoshop SDK headers to build it, right? Ciao, Marcus

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dan Kegel

On 3/31/06, Dan Kegel <dank(a)kegel.com> wrote: > > > Incidentally, the port of PSPI used winelib for no obvious reason. > > > Wouldn't it have been more robust just to use Wine? > > > > But it is using wine, that's what Winelib does :) > > One can try with the PE version of PSPI I suppose... > > But this way it is fully buildable on Linux, without > > the need to have MingW installed. This is likely > > important for distributions. > > If a distribution ships this and a matching copy of Wine, > and stays up to date, perhaps. A worse problem is that PSPI can't be built without a closed source, non-redistributable SDK (IIRC). So there's not even a buildability advantage to using Winelib in this caase. - Dan

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dan Kegel

On 3/31/06, Dimi Paun <dimi(a)lattica.com> wrote: > > Incidentally, the port of PSPI used winelib for no obvious reason. > > Wouldn't it have been more robust just to use Wine? > > But it is using wine, that's what Winelib does :) > One can try with the PE version of PSPI I suppose... > But this way it is fully buildable on Linux, without > the need to have MingW installed. This is likely > important for distributions. If a distribution ships this and a matching copy of Wine, and stays up to date, perhaps. But the more common situation at the moment is that the Wine from the distribution is way old and crappy, and the user has to install a newer Wine, which is (surprise!) incompatible with any Winelib apps they have installed. MUCH more robust from the user's point of view to use the PE (.exe) vesion of PSPI; then it would work even if the user has the audacity to update Wine. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dimi Paun

From: "Dan Kegel" <dank(a)kegel.com> > Incidentally, the port of PSPI used winelib for no obvious reason. > Wouldn't it have been more robust just to use Wine? But it is using wine, that's what Winelib does :) One can try with the PE version of PSPI I suppose... But this way it is fully buildable on Linux, without the need to have MingW installed. This is likely important for distributions. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dan Kegel

On 3/31/06, Dimi Paun <dimi(a)lattica.com> wrote: > On Thu, 2006-03-30 at 22:46 -0800, Dan Kegel wrote: > > http://www.gimp.org/~tml/gimp/win32/pspi.html > > Have a look. Congratulations, Wine! > > This is really great! I wanted to do this some time ago, > but without looking at GIMP, I thought that GIMP plugins > are .so's which would have made it a lot harder. But since > they are processes, simply recompiling with winegcc should > do the trick. And indeed it does! > > We should start keeping track on the wiki (or the Winelib page) > of these porting efforts. FWIW, I have a page of success stories at http://kegel.com/wine/isv/#case-studies and I've added this to it. Incidentally, the port of PSPI used winelib for no obvious reason. Wouldn't it have been more robust just to use Wine? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 31, 2006

Re: new to wine, Guild Wars don't display correctly

by Stefan Dösinger

Hello, > Yes, without displaying the mouse and it's very slow (as if you were > playing a game with direct rendering to No). But with dri, i have 1200fps > and with ati 1900fps for common glxgears, there is a significative > difference. glxgears isn't a benchmark... If you set Option "AGPMode" "4" Option "EnablePageFlip" "1" Option "BackingStore" "1" in your device section of the dri driver, then the performance should be equal to fglrx(~2000 fps). If you install driconf and enable HyperZ, then you should get another boost. Alternatively, you can create a file /etc/drirc with the following content: <driconf> <device screen="0" driver="r200"> <application name="all"> <option name="arb_vertex_program" value="true" /> <option name="texture_level_hack" value="true" /> <option name="hyperz" value="true" /> </application> </device> </driconf> The first option enables software emulated vertex shaders, but I don't know if they work. The secound option enables a hack which increases the maximum texture size by a factor of 4 (1024x1024 -> 2048x2048) if you have the dxtn decompression libary installed. google for libtxc_dxtn050908.tar.gz, it should be the first entry. Installing this library enables compressed textures too, which can improve the performance drastically in some games which support it. The "hyperz" option enables hyperz, which also increases the performance, especially in glxgears. With all the options enabled, I get about 3670 fps in glxgears(Acer travelmate 803, 1.6 Ghz pentium M, radeon mobility 9000, Xorg 7.0 with the dri driver). But again, glxgears isn't a benchmark. My experience is that the open source driver offers equal performance since Xorg 7.0, quite often it's faster, but only in unreal tournament 2004 it's significantly slower(general > 40fps, but sometimes only 15-20 fps, which makes ut unplayable. Surprisingly, this doesn't depend on the settings, so I think it's a driver bug) > So, i have just reported them the problem and explain that it works with > dri, so i hope they will make something to correct it.... Don't expect too much from at :( Just have a look at the linux driver forum at www.rage3d.com Stefan

March 31, 2006

Re: Photoshop plugins in Gimp on Linux using Wine!

by Dimi Paun

On Thu, 2006-03-30 at 22:46 -0800, Dan Kegel wrote: > http://www.gimp.org/~tml/gimp/win32/pspi.html > Have a look. Congratulations, Wine! This is really great! I wanted to do this some time ago, but without looking at GIMP, I thought that GIMP plugins are .so's which would have made it a lot harder. But since they are processes, simply recompiling with winegcc should do the trick. And indeed it does! We should start keeping track on the wiki (or the Winelib page) of these porting efforts. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 31, 2006

Re: Implement THREAD_PRIORITY_TIME_CRITICAL

by Andreas Mohr

Hi, On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote: > This patch gives me rock solid audio in Imperium Galactica 2, so now the > game works perfectly. > > There has been discussion around this issue with respect to security in > the past, however, regardless of what approach is adopted this code will > have to be written anyway. Ah, thanks, nice to see that it actually helps. > + scheduler = SCHED_FIFO; IMHO we should really add some smart detection of SCHED_ISO kernel capability and *much* prefer to use that one then. One really wouldn't want to hang the box... Not to mention that SCHED_FIFO requires root, which is an absolute PITA. Nice To Have would be support for stuff such as SCHED_IDLEPRIO and SCHED_BATCH... > + if (result == -EPERM) > + { > + static int need_warning = 1; > + > + if (need_warning) > + { > + fprintf( stderr, "\nwineserver: Failed to promote the priority of a time critical thread.\n" ); > + fprintf( stderr, "Audio may destabilise. To fix this re-run the application as root.\n\n" ); > + need_warning = 0; > + } > + > + return; > + } Make that static int already_warned; /* static: = 0! */ Since static uses 0 as default and you don't want to waste space in the .bss(?) segment for an explicit 1 init. Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)

March 31, 2006

Re: [RESEND][x11drv] cleanup: Move x11drv escape codes to one common header file.

by Tomas Carnecky

Alexandre Julliard wrote: > Tomas Carnecky <tom(a)dbservice.com> writes: > >> This patch doesn't change any logic or C sourcecode, it only moves the >> X11DRV escape code definition to one common header file. Currently the >> definitions are spread over several C source files, and even there the >> definitions differ from file to file. I don't see anything wrong with >> this patch unless you *want* to have it difficult to maintain the code. > > Actually, that's more or less what we want. That sort of inter-dll > dependencies should be strongly discouraged, and we don't want to add > more of it than strictly necessary; as far as possible we also don't > want dlls to depend on private headers, so copying a few things across > is the preferred approach. If it becomes a problem it means something > is wrong with our implementation. > It's not that I've added a new inter-dll dependency, at least that's how I think. The dependency already *is* there, all these dlls depend on the ExtEscape() function. What about putitng the x11drv escape codes into the header where the ExtEscape() prototype is? These escape codes belong to the ExtEscape() function, that's what that function understands/supports. tom

March 31, 2006

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

by Petr Tesarik

Hi, I'm not online too often. :( So, I thought the patch for Linux must already be in CVS. It is not. The patch can be found here: http://www.winehq.org/pipermail/wine-patches/2006-March/025228.html However, the patch only works for Linux. Please, let me know if you're using a different platform, as it is very likely that it can be made to work too, but I won't send patches which I can't test. To the wine-devel list: Why was the patch rejected, anyway? Petr Tesarik On 03/29/06 at 09:35:04 (-0800), Dan Kegel wrote: > On 3/29/06, Petr Tesarik <hat(a)tesarici.cz> wrote: > > No, this is not normal. This problem was introduced on the i386 > > architecture, when floating point registers were added to winedbg. > > Currently, there are two pending patches by me, one which fixes the > > problem on Linux, and another which fixes it on all platforms but is > > most likely wrong. > >... > > Anyway, see also my next email. > > Looking forward to it. > Can you give me the URL of the i386 patche in the wine-patches archive? > Thanks, > Dan >

March 31, 2006

[PATCH] Don't enforce process handle access rights in Win98 mode (fixes dcom98 ncalrpc)

by Mike Hearn

Sending here until wine-patches stops eating my email. IMHO this would best be done in get_obj_from_handle in the server, but this approach is what the registry APIs do and what Rob suggested, so here it is. diff --git a/dlls/kernel/process.c b/dlls/kernel/process.c index 4263a22..d5017c4 100644 --- a/dlls/kernel/process.c +++ b/dlls/kernel/process.c @@ -2265,6 +2265,8 @@ HANDLE WINAPI OpenProcess( DWORD access, attr.SecurityQualityOfService = NULL; attr.ObjectName = NULL; + if (GetVersion() & 0x80000000) access = PROCESS_ALL_ACCESS; + status = NtOpenProcess(&handle, access, &attr, &cid); if (status != STATUS_SUCCESS) {

March 31, 2006

winspool: [1/2] implement EnumMonitorsW

by Detlef Riekenberg

Our Tests will work, when both Patches are in the Tree Changelog: - winspool: implement EnumMonitorsW -- By By ... ... Detlef

March 31, 2006

Re: [WIDL] Implement support for unique strings

by Eric Kohl

Robert Shearman wrote: > Counter-example with the following IDL: > void ConformantString2Out([in] long size, [in, out, string, > size_is(size)] char **pszString); > void Test([in] long size, [in, out, size_is(size)] char **pszArray); > > Both generate NdrPointerFree calls and I believe both are satisfied by > the test you introduced: These example include arrays of strings which I have not tested yet and are not officially supported yet. I'll fix these later. My focus is making the Wine-WIDL compatible with ReactOS-WIDL as quickly as possible. Additional features will be added or fixed later. Regards, Eric

March 31, 2006

Re: [WIDL] Implement support for unique strings

by Robert Shearman

Eric Kohl wrote: > Robert Shearman wrote: > >>> case PASS_OUT: >>> + if (in_attr && has_size && pointer_type == RPC_FC_UP && >>> phase == PHASE_FREE) >>> + break; >>> if (!out_attr) >>> continue; >>> break; >>> >>> >> >> I don't think this is correct. Firstly, it should continue, not >> break. Secondly, I think it only doesn't need to free the string if >> it has a size. I'm pretty sure it shouldn't depend on being a unique >> string. >> > > Robert, > this is exactly what I want! WIDL must generate a call to > NdrPointerFree for 'in', 'unique', sized pointers to strings. Other > 'in' pointers don't need to be freed. > > Why? Because three different versions of MIDL do it this way. > Counter-example with the following IDL: void ConformantString2Out([in] long size, [in, out, string, size_is(size)] char **pszString); void Test([in] long size, [in, out, size_is(size)] char **pszArray); Both generate NdrPointerFree calls and I believe both are satisfied by the test you introduced: void __RPC_STUB Tests_ConformantString2Out( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszString; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszString = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[44] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept ConformantString2Out(size,pszString); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszString, &__MIDL_TypeFormatString.Format[40] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } void __RPC_STUB Tests_Test( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszArray; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszArray = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[52] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept Test(size,pszArray); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszArray, &__MIDL_TypeFormatString.Format[74] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } -- Rob Shearman

March 31, 2006

Re: advpack: Implement LaunchINFSectionEx [resend]

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR get_parameter(LPWSTR parameters, WCHAR separator, DWORD index) > +{ > + LPWSTR param = NULL, ptr = parameters; > + DWORD i = 0; > + > + while (*parameters && i < index) > + { > + if (*parameters == separator) > + { > + ptr = parameters; > + i++; > + } > + > + parameters++; > + } > + > + if (!*parameters || *parameters == separator) > + return NULL; > + > + param = HeapAlloc(GetProcessHeap(), 0, (parameters - ptr) * sizeof(WCHAR)); > + lstrcpynW(param, parameters, parameters - ptr); > + > + return param; > +} That's a very inefficient way of splitting a string. It's much better to allocate a copy of the whole string and go through it just once, inserting nulls to separate the tokens. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2006

Re: advpack: The Plan

by Markus Amsler

James Hawkins wrote: >Internally, there will be three main install functions: install_init, >which will open the INF, make sure it's legit, and other >initializations, spapi_install, which will call setupapi to install >the base INF commands, and adv_install, which will parse the install >section and run the provided commands. > I'm quite sure RunPreSetupCommands gets executed before the base INF commands. I'm not sure wether there are others (BeginPrompt, BackupReg comes to mind). So you need two install functions like adv_install_pre and adv_install_post. >This is The Plan so far, so if anyone has any ideas or suggestions, >I'd love to hear from you. > > Why not simply use the same mechanism as in setupapi [1]? My patch [2] back in january was using it, and it looked like a good idea. Markus [1] http://source.winehq.org/source/dlls/setupapi/install.c [2] http://www.winehq.org/pipermail/wine-devel/2006-January/044083.html

March 31, 2006

Re: advpack: The Plan

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Internally, there will be three main install functions: install_init, > which will open the INF, make sure it's legit, and other > initializations, spapi_install, which will call setupapi to install > the base INF commands, and adv_install, which will parse the install > section and run the provided commands. Each advanced command will be > implemented by a function of similar name, e.g., RegisterOCXs would be > implemented by the function register_ocxs, etc. All the command > functions will be in a hash map, the key being the command name, the > value being a pointer to the function that implements the command. > adv_install will use setupapi to parse the entries of the install > section, calling the function returned by a query to the hash map. > According to INF Web [1], some commands are run before others, so > there will probably be three or four maps, the functions in the maps > grouped according to the order in which the commands should be run. > For example, RunPreSetupCommands is to be executed after the > BeginPrompt command, so begin_prompt would be in the phase 1 map, and > run_pre_setup_commands would be in the phase 2 map. We would call the > parser like so: > > run_adv_commands("InstallSection", phase1_map); > run_adv_commands("InstallSection", phase2_map); > run_adv_commands("InstallSection", phase3_map); > > If a command in the install section is not in the map, we just ignore it. That hash map thing sounds like overkill to me. You have only a few sections you know you will handle, you can just look for these explicitly, like setupapi does. And if you look them up in the order they should be executed you don't need the different phases either. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > The problem is fixed (so the app now works) although I am still getting the > pack_message FIXMEs - it is possible though that this is a different problem > that was masked by the earlier one. I will investigate further. Yes, the pack_message thing is a different problem. It shouldn't cause any harm, except maybe causing the desktop window to not be repainted properly in desktop mode. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2006

Re: new to wine, Guild Wars don't display correctly

by BONNEL Christophe

March 31, 2006

Re: advpack: The Plan

by James Hawkins

On 3/31/06, Dimi Paun <dimi(a)lattica.com> wrote: > > Or maybe simpler, instead of storing just the function pointer as > the value for the map, store a structure that has 2 fields: > -- priority > -- function > > So than you just call things as: > for (i=0; i < MAX_PRIO; i++) > run_adv_commands("InstallSection", i, phase_map); > > And ignore entries with incorrect priorities. > Thanks Dimi, that's a really good idea! I'll incorporate that into the design. -- James Hawkins

March 31, 2006

Re: new to wine, Guild Wars don't display correctly

by H. Verbeet

On 31/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > > glStencilOp(...) @ device.c / 3809 > > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > > glStencilOp(...) @ device.c / 3809 > > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > > glStencilOp(...) @ device.c / 3809 > These are harmless, they are fixmes from the direct3d initialization. Some > render states aren't supported by wines d3d implementation, but when wined3d > initializes, it sets them to the default value, which causes such messages. > The last three fixmes are fixed in the current cvs version, and they are > harmless too. Unfortunately, no, that's not fixed yet. I suspect the problem is the three glGetIntegerv call slightly above that call, since they use constants only defined in OpenGL 2.0.

March 31, 2006

Re: new to wine, Guild Wars don't display correctly

by Stefan Dösinger

Am Freitag, 31. März 2006 09:12 schrieb BONNEL Christophe: > Hi everyone, > > Sorry in advance not to know where to post, but I'm new to wine. It would be better to post requests like this to wine-users(a)winehq.com > First of all, I'm under debian stable and i'm using the debian package > wine_0.9.10~winehq1-2_i386.deb. My kernel is 2.6.8 and my graphic card is > an ati radeon 9000pro (I know ...ouch...) The fglrx driver you mentioned doesn't work any more on those cards. PPracer has problems too: Start the "Doing" course. Head to the yellow arrows on the left. They will disapper when you come really close. > So i first try with the dri driver and , although my 3D was ok(openGL1.2 > it seems), it was too slow to be playable and my mouse didn't appear. So it basically worked with the open source driver? > So i use now the official ati last driver(openGL 1.3 it seems). Now, most > of the images doesn't appear. If you know guild wars, in the login screen, > i have only rocks, the background image behind rocks and the "window" for > login in front of rocks don't appear. You hit the bug ati introduced with 8.19.10. I think it's related to opengl display lists, and I've reported it to ati months ago. Didn't get a reply so far > I can send you the lasts many "fixmes" that appears but for some seconds, > i have approximatively 1Mo file. However, i have no "err". The lasts line > are : fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(190,15) > not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(191,15) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(192,15) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(193,-1) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(194,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(198,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(199,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(200,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(201,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(202,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(203,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(204,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(205,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(206,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(207,2) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(208,1) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(209,1) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(162,-1) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(163,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(164,1065353216) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(165,1) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(172,3) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(173,1) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(178,1065353216) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(179,1065353216) > not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(180,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(181,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(182,1065353216) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(183,0) not > handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState > (0x4d290020)->(184,0) not handled yet > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > glStencilOp(...) @ device.c / 3809 > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > glStencilOp(...) @ device.c / 3809 > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from > glStencilOp(...) @ device.c / 3809 These are harmless, they are fixmes from the direct3d initialization. Some render states aren't supported by wines d3d implementation, but when wined3d initializes, it sets them to the default value, which causes such messages. The last three fixmes are fixed in the current cvs version, and they are harmless too. > There are also in the upper-middle of the log file many : > fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x4d290020) : stub EvictManagedTextures is a windows-related video memory management thing, and it won't have much impact too. If it has, then it will only show slightly reduced performance for a few secounds after loading. It should remove the managed textures from the video card, to make the memory free for new textures. > Hope this can help a bit.... > My command line to launch the games is : > wine "E:/toph/games/GUILD WARS/Gw.exe" 2>gw.wine > I use win98 version per default because sometimes with win2k i have some > ntdll errors when connecting to internet(areanet). I don't use anything > else. I try display by hardware or emulation, with simple or double buffer, > in a window or in directly, with pixel shader or not, but nothing works. > Per default, my screen is 1024*768*24bits Should be fine > Note that tuxracer (or ppracer) works so i don't think it comes from the > driver, but i can make mistakes... See above WineD3D has serious performance problems, somehow related to textures. I hope that I can debug them during the weekend, but I can't give garantees. These problems seem to be related to textures. My tests with 3dmark2000 show that texture rendering should be 10 times faster than it is. I hope I could help you, Stefan

March 31, 2006

new to wine, Guild Wars don't display correctly

by BONNEL Christophe

March 31, 2006

Photoshop plugins in Gimp on Linux using Wine!

by Dan Kegel

I've been hearing rumblings about people using Wine to run windows photoshop plugins on Linux Gimp, but hadn't seen anything concrete. Well, here it is: http://www.gimp.org/~tml/gimp/win32/pspi.html Have a look. Congratulations, Wine! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 31, 2006

Re: advpack: The Plan

by Dimi Paun

On Thu, 2006-03-30 at 23:12 -0600, James Hawkins wrote: > there will probably be three or four maps, the functions in the maps > grouped according to the order in which the commands should be run. Or maybe simpler, instead of storing just the function pointer as the value for the map, store a structure that has 2 fields: -- priority -- function So than you just call things as: for (i=0; i < MAX_PRIO; i++) run_adv_commands("InstallSection", i, phase_map); And ignore entries with incorrect priorities. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 31, 2006

advpack: The Plan

by James Hawkins

Hey, As you've probably noticed, I've been working on implementing advpack for a couple months now; a lot of progress has been made, and I'm glad to say that the end is in sight. The rest of this email details the game plan for finishing advpack. advpack has five main install functions: DoInfInstall, ExecuteCab, LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all basically do the same thing with minor differences in functionality. ExecuteCab extracts the files to install from a cab archive, LaunchINFSectionEx provides backup and rollback capability, and RunSetupCommand can also launch executables. When installing an INF section, advpack calls setupapi to install the base INF commands, such as CopyFiles and AddReg. After this, advpack parses the Advanced INF for advanced commands that are only installable when using advpack. These commands include: Values: RequiredEngine - Use either setupapi or setupx, we will ignore it. CustomDestination - assigns ldids to extra directories. SmartReboot - same reboot options as LaunchINFSection. Cleanup - deletes the INF when the install/uninstall is finished if this is 1. CheckAdminRights - check if the user is admin if this is 1. Actions: RegisterOCXs UnregisterOCXs BeginPrompt EndPrompt RunPreSetupCommands RunPostSetupCommands DelDirs PerUserInstall Backup/Rollback: ComponentName ComponentVersion BackupReg PreRollBack BackupPath Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. Each advanced command will be implemented by a function of similar name, e.g., RegisterOCXs would be implemented by the function register_ocxs, etc. All the command functions will be in a hash map, the key being the command name, the value being a pointer to the function that implements the command. adv_install will use setupapi to parse the entries of the install section, calling the function returned by a query to the hash map. According to INF Web [1], some commands are run before others, so there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. For example, RunPreSetupCommands is to be executed after the BeginPrompt command, so begin_prompt would be in the phase 1 map, and run_pre_setup_commands would be in the phase 2 map. We would call the parser like so: run_adv_commands("InstallSection", phase1_map); run_adv_commands("InstallSection", phase2_map); run_adv_commands("InstallSection", phase3_map); If a command in the install section is not in the map, we just ignore it. This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you. Thanks, James Hawkins [1] http://www.winpack.org/petr/INF_web/

March 31, 2006

Very old Windows programs and Wine

by Segin

I have come forth with a Windows program -- complete with source and binary -- designed for Windows 2.03 (as from the binary headers, i learned a bit about NE headers trying to hack Win9x 16-bit apps onto windows 3.1, i did manage to get Defrag to work that way) Case and point, would anyone like to take a look at what all Wine can do with the source (winelib) and the binary (admittedly designed for a 8086.)

March 31, 2006

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.

by Mike McCormack

Vitaly Lipatov wrote: > I do not agree with this patch. There is broken code in WINE's comctl32 > realization (in treeview/listview code) and we need overrides builtin dll by > native for get differences... Sure. You can still do that using WINEDLLOVERRIDES=comctl32=n, so it doesn't impede testing. Mike

March 31, 2006

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

by Dominic Wise

On Mon, 2006-03-27 at 21:32 -0500, 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. Thought it might be interesting to refer back to the email that kicked all of this off and try to look at it in detail. > There is one reason, inarguable Anything is arguable, if one has arguments that can be backed up with evidence. > (if you reply to this you have a IQ of 0) Everyone has an IQ of more than 0. If they didn't, it is unlikely they would be able to read and so would not be in a position to respond. I also believe that anyone who reads this list has demonstrated a remarkable degree of intelligence in trying to move as far away from Windows as possible. The inference of this statement seems to be 'I am right because I am. I deny you the right to disagree - if you do I have already marked you out as an imbecile and you are not worthy of any consideration' - sounds rather fascist to me. > as to why WineTools is useless. I have used Winetools when necessary, when there was no other easily available option. IE is required for me to use online banking. I have complained to my bank, and asked them to support FireFox and they have declined. Winetools helped me achieve what I needed. For my specific needs, winetools was useful. > Most of the WineTools 'magic' Implication by use of quotation marks - winetools claims to be magic. It does not, as far as I know. > is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, Ignoring the poor spelling and concentrating on the details, I have used versions of winetools that supported the config file, and more recently, versions that support the newer registry configuration. Given my understanding of current wine configuration I think the statement may be misleading. If I am wrong, I am happy to be corrected, preferably in a private email. >WineTools is utterly useless and has no point in existing AT ALL, >PERIOD. I have already described at least one reason for it to exist. Shouting isn't necessary, but if it makes segin feel better, that's entirely up to him. The point of this email is not to argue as to whether winetools is good for Wine or not - I can see both sides of the argument. Neither do I believe that any form of banning is necessary. I'm opposed to censorship generally, and given that no individual attack was made such sanctions could be counterproductive, given that segin has offered to submit code to wine in the future. All I can suggest is that when individuals have an opinion they believe strongly in, perhaps it might be a good idea to read though any open message they send before hitting 'Send' to see if it is readable and stands up to rational criticism. I have the greatest of respect for the entire wine community (no exceptions) and know that with rational debate and argument wine will be a huge (maybe the biggest) factor in ending the Windows monopoly.

March 31, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Troy Rollo

On Friday 31 March 2006 02:41, Alexandre Julliard wrote: > I committed a few fixes that should help, please give it a try. The problem is fixed (so the app now works) although I am still getting the pack_message FIXMEs - it is possible though that this is a different problem that was masked by the earlier one. I will investigate further. -- Troy Rollo - wine(a)troy.rollo.name

March 30, 2006

Re: [WIDL] Implement support for unique strings

by Robert Shearman

Eric Kohl wrote: > case PASS_OUT: >+ if (in_attr && has_size && pointer_type == RPC_FC_UP && phase == PHASE_FREE) >+ break; > if (!out_attr) > continue; > break; > > I don't think this is correct. Firstly, it should continue, not break. Secondly, I think it only doesn't need to free the string if it has a size. I'm pretty sure it shouldn't depend on being a unique string. -- Rob Shearman

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Tim Schmidt

Sounds like a good project to hack on occasionally while putting the majority of effort into improving the current implementation. In other words, some effort is warranted because of the benefits of sharing code, however, wine can always transition to the new layout after it has a complete and (mostly) correct DirectX implementation. There's no reason the GDI and win32k.sys couldn't be going into the wine tree at the same time as improvements to the current system. --tim

March 30, 2006

Re: [RESEND][x11drv] cleanup: Move x11drv escape codes to one common header file.

by Alexandre Julliard

Tomas Carnecky <tom(a)dbservice.com> writes: > This patch doesn't change any logic or C sourcecode, it only moves the > X11DRV escape code definition to one common header file. Currently the > definitions are spread over several C source files, and even there the > definitions differ from file to file. I don't see anything wrong with > this patch unless you *want* to have it difficult to maintain the code. Actually, that's more or less what we want. That sort of inter-dll dependencies should be strongly discouraged, and we don't want to add more of it than strictly necessary; as far as possible we also don't want dlls to depend on private headers, so copying a few things across is the preferred approach. If it becomes a problem it means something is wrong with our implementation. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2006

Need Help for IniFileMapping

by Detlef Riekenberg

Hi all. I need your Help to see, how IniFileMapping works on different NT-Versions. An updated kernel32_crosstest.exe, that prints a lot of informations and a detailed description is here: http://bugs.winehq.org/show_bug.cgi?id=4096 Thanks for your Help (IniFile is the redirection from "*.ini" - Files to the Registry, by GetPrivateProfileString() and Friends.) -- By By ... ... Detlef

March 30, 2006

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.

by Vitaly Lipatov

I do not agree with this patch. There is broken code in WINE's comctl32 realization (in treeview/listview code) and we need overrides builtin dll by native for get differences... В сообщении от 30 марта 2006 07:56 Mike McCormack написал(a): > --- > > dlls/ntdll/loadorder.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 30, 2006

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes

by Peter Åstrand

On Thu, 30 Mar 2006, Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=1181 > > ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 10:26 ------- > Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention > that wine could possibly reuse parts of your keysym implementation. Could you > email the list (even if you dont scubscribe) and let them know about this bug, > and see if anyone is willing to take a look at it. Just make sure you let them > know you aren't subscribed, if you aren't, and to CC you on replies. Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation. I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can "emulate" a physical Xserver with a certain physical keyboard. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

March 30, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. I committed a few fixes that should help, please give it a try. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Christoph Frick

On Thu, Mar 30, 2006 at 08:29:03AM -0500, Kuba Ober wrote: > Technically sufficient, maybe, but it might be actually illegal to install > Direct X on anything non-windows. Might be or is? Or will be like dcom? At least with dcom ms made the point clear. they just dont provide it beside the os. but i can not remember a single game in my collection, that does came with the dx-package needed to run it (i hardly remember anything that came with dcom98.exe). so does anybody knows the actual license or is there anything known what ms has in mind in the near future? > I bet there are non-gaming 3D applications that use it. CAD systems > come to mind. I think that for example Solid Edge uses Direct X (no, > didn't try to get it running under wine yet). yeah i am sure there are lots of non-game applications that utilize directx - dsound for sound apps, d3d for cad, office, 3d, ... and so on. all in all i know close to nothing what goes on the various dlls - but from a point of view like this it seems to be a lot of work to redo the work of others if there is no real need for it, like e.g. accessing hardware or operating system stuff. license issues aside i would only a consider a massive performance gain something that is worth it (and there still remains the question, why is that original dll so much slower with the underlying framework then). and of course its a lot easier to implement something that is *cough* well documented than something that is totally unknown to mankind. -- cu

March 30, 2006

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

by Tom Spear

On 3/29/06, Segin <segin2005(a)gmail.com> wrote: > > Saulius Krasuckas wrote: > > * On Tue, 28 Mar 2006, Karl Lattimer wrote: > > And also, accusing people of having an IQ of 0 for replying to a flame > isn't in the slightest constructive, > > Hardly. I have actually done something good. I got people to addresses the > Winetools problem a bit early. Sure, it would have gotten adressed anyways, > but only after enough complains come rolling in, months or years from now. > When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end > result was nothing but good, so why shun me? I was just getting a matter > addressed before we have no choice but to address it. We can't just put it > off forever, you know. > It was already being addressed in the wine tools -> wine doors thread. So your flame (more like attack) did nothing good at all that wasnt already being done. Next time you have something that you want done (or addressed) just bring it up in a new thread, and dont be so rude about it. You will find a much more positive result (as opposed to 3 threads all going on about how bad of you it was to say what you said to the doc in private). I haven't written any patches, namely because my eariler code changes i find > cause signal 11. Recently I am working on something that will be offloaded > months from now (if i dont find it to be too fustrating) as a huge diff, so > keep your eyes peeled. If it doesn't work on either of my systems, it's > broken, and sending a diff is a waste of everybody's time. > I wouldn't do it in a huge diff. Break it up, because I have noticed that AJ usually wont commit huge diffs as is. Tom

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Tom Spear

On 3/29/06, Chris Morgan <chmorgan(a)gmail.com> wrote: > > How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? > > Segin doesn't speak for the entire community and he isn't a lead on > the project. If that were the case this would be a more serious > matter. If people quit because of him then what are we to do? Given > the lack of relationship between wine and Segin they might as well > have quit wine development because of some Nigerian money transfer > email or other spam. > > My point is that the solution isn't trying to enforce censorship where > you simply cannot and where it doesn't impact the community. As long > as he doesn't abuse his list membership we have no reason to become > involved in this issue. You won't find me supporting any kind of > restrictions on what he says or which mailing lists he can belong to > at this point in time. > > Chris > Ok, but here is a point for you to chew on. Say that I go on a business trip for my company, and that while on this trip, I meet with some clients, and we go out for a business dinner. A few days later, while still out of town, I run into those clients again, and we all decide to go to a billiard. While at said billiard we all start drinking. No problems there. But if I continue drinking, eventually I am going to get drunk, and need assistance getting back to my hotel room. Mind you I am on a business trip and with some clients, but I am not at a business meeting. Even though I am (at the time) not representing the company, it still looks bad for them that an employee would do that in front of the client. The same principle applies here. It looks bad on the wine project as a whole that someone who participates in the devel list would email someone (even off list) and say the things that were said. Ordinarily I am against censorship myself, but I do believe in moderation, and I believe that people should be held accountable for their actions even if they are speaking only for themself, if it makes other people or things look bad. To answer your question, there isnt really a way, and I wasnt trying to say that we should prevent him from emailing others directly, or filtering his emails, I was saying that a lot of the things he does for the project should be restricted. AFAICT he has some high level permissions on bugzilla, and the appdb. Maybe those could (should?) be suspended temporarily, I dunno, I will leave it up to the big wigs here to decide if he should be punished in any way, and if so, what that punishment should be. As I said though, it is his opinion, and he is entitled to that opinion (at least in the US), but I think he should have kept it to himself, or at least not used such strong wording like "****ing dumb***"....

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Kuba Ober

On Thursday 30 March 2006 06:51, Christoph Frick wrote: > On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: > > My long term suggestion is to move the Direct3D->OpenGL translation > > code from WineD3D to gdi and a win32k sys, and write ddraw.dll, > > d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be > > shared with Reactos, and from a technical point of view, even > > Microsoft's DirectX dlls can be used on Wine(including the hardware > > emulation layer). > > first of all excuse my ignorance of the d3d interface and so on - but > this sounds to me like wine should not deal with the userland dlls at > all then? once all the hardware is handled in the kernel parts what is > the gain in having our own implementations? installing dx with the games > should be sufficient then? Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Of course the blame is shifted to the user, but if one thinks about corporate wine deployments, they wouldn't want to do illegal things. They might as well deploy pirated Windows, you know. And mind you, Direct X is not for games only. I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet). Cheers, Kuba

March 30, 2006

Re: advpack: Forward ExecuteCabA to its unicode counterpart

by Robert Shearman

James Hawkins wrote: >@@ -86,6 +87,43 @@ HRESULT WINAPI DoInfInstall(const SETUPC > > /*********************************************************************** > * ExecuteCabA (ADVPACK.@) >+ * >+ * See ExecuteCabW. >+ */ >+HRESULT WINAPI ExecuteCabA(HWND hwnd, CABINFOA* pCab, LPVOID pReserved) >+{ >+ UNICODE_STRING cab, inf, section; >+ CABINFOW cabinfo; >+ HRESULT hr; >+ >+ TRACE("(%p, %p, %p)\n", hwnd, pCab, pReserved); >+ >+ if (!pCab) >+ return E_INVALIDARG; >+ >+ RtlCreateUnicodeStringFromAsciiz(&cab, pCab->pszCab); > > pCab->pszCab can be NULL, right? I don't think RtlCreateUnicodeStringFromAsciiz handles that case in the way you expect. -- Rob Shearman

March 30, 2006

Re: Direct3D, the kernel and ReactOS

by Christoph Frick

On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: > My long term suggestion is to move the Direct3D->OpenGL translation > code from WineD3D to gdi and a win32k sys, and write ddraw.dll, > d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be > shared with Reactos, and from a technical point of view, even > Microsoft's DirectX dlls can be used on Wine(including the hardware > emulation layer). first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then? on the other hand, if the interface of the kernel parts is hardly documented why not stick with the current implementation that does a good job with what it does and implement/stub the kernel things once an app crashes? -- cu

March 30, 2006

Re: Improper message recursion revealed by recent desktop window changes

by Jesse Allen

On 3/29/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The recent changes to the desktop have revealed a problem with recursive > processing of X messages. The problem started to manifest with commit > 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack > that looks like this: > > <application Window procedure> > WINPROC_wrapper > ... > CallWindowProcW > ... > SendMessageW > X11DRV_SetWindowPos > SetWindowPos > X11DRV_ConfigureNotify > process_events > X11DRV_MsgWaitForMultipleObjectsEx > wait_message_reply > send_inter_thread_message > SendMessageTimeoutW > SendMessageW > send_parent_notify > DestroyWindow > > In other words, a destroy notification is being sent to the parent window with > SendMessageW, and before that message returns an unrelated X message is > processed. Under Windows the equivalent could never happen - if a thread is > in SendMessage(), the only messages that can be delivered to it are ones sent > by SendMessage() from another thread. > > The consequences of this can be unpleasant if the code that processes (in this > case a window movement notification) the message interferes with state that > is being dealt with in earlier stack frames. Yep, that's why the launching of War3 seems to only paint explorer or the launch window depending on how I hacked wine. This is the problem exhibited in bugs 4948, 4897, and 4847. > > wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: > > res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, > INFINITE, QS_ALLINPUT, 0 ); > > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. > > -- > Troy Rollo - wine(a)troy.rollo.name > > > Last thing I did today was looking at the message passing and signal handling. The signal handling doesn't look any different than before. I figured something could be up with the message handling as it seemed one thread was stomping on another but I don't know anything about wineserver. I'll take a better look tomorrow! Jesse

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Hiji

On Wednesday 29 March 2006 7:31 pm, Hiji wrote: > > How do you propose we prevent people from emailing people that post to > > wine-devel? How do we choose who gets to email people directly and > > who doesn't? How do we filter the contents of their email? > > I want to chime in and say that I'm with Tom and the ole Doc here. I don't > think there's any way to filter somebody's contents, but I think it's > important for the community to speak up when somebody is out of line. Chris Morgan wrote: > Perhaps you didn't actually read the emails that were sent. This might > explain the discrepancy between your comment about "thinking its important > for the community to speak up when somebody is out of line" and this email > from Tom, the one I was replying to: I read all the emails, and I know exactly what I am referring to; so, there is no discrepancy. ;) I had in mind Segin's initial email (which was sent to the entire list): --- Segin <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. To which I responded: > Dude, you need a bit more constructive in your > comments, or you'll be getting a lot of resentment on > this list REAL fast. Per your comment "What he said on the list seemed pretty reasonable to me.", if you don't see anything wrong with what Segin said, then so be it. Others, meanwhile, have recognized his misplaced behavior. Cheers, Hiji

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Chris Morgan

On Wednesday 29 March 2006 7:31 pm, Hiji wrote: > > How do you propose we prevent people from emailing people that post to > > wine-devel? How do we choose who gets to email people directly and > > who doesn't? How do we filter the contents of their email? > > I want to chime in and say that I'm with Tom and the ole Doc here. I don't > think there's any way to filter somebody's contents, but I think it's > important for the community to speak up when somebody is out of line. > Perhaps you didn't actually read the emails that were sent. This might explain the discrepancy between your comment about "thinking its important for the community to speak up when somebody is out of line" and this email from Tom, the one I was replying to: > From: > "Tom Spear" <speeddymon(a)gmail.com> > To: > "Wine Developers List" <wine-devel(a)winehq.com> > Date: > Today 5:12:33 pm > >Totally agreed. Segin > needs to be not just kick/banned from the list, he needs to be K-Lined, if > not G-Lined from all things wine! With respect to his comments though, on > behalf of everyone involved with the project, and with the community as a > whole, I sincerely apologize. Sounds to me like this is advocating censorship. > I know I was the first to respond to Sergin's email by asking that he be > more constructive in his feedback, but past that, none of the regulars on > this thread said much. Now, his thread has spawned into something that is > soooo far out there that it almost has no relevancy to this list. I want > to note that I don't see how Sergin's comments and behavior could have been > interpreted as anything but inappropriate; however, with the majority of > people not saying anything, I can only imagine that Sergin felt that what > he did was perfectly okay and acceptable on this list. > What he said on the list seemed pretty reasonable to me. Note that in the headers forwarded by Dr J A Gow the email from Segin appears to be directly from him and not to the list at all. It isn't our place to even care what Segin emails to people, as long as he isn't abusing the mailing list to do so. Chris

March 30, 2006

Interesting D3D testapp

by Willie Sippel

Hi there. I think I just found a very nice D3D testapp: fr-025 by Farbrausch. A nice, small (8.2MB) graphics demo, already works somewhat with Wine (starts, plays, music and everything works, good performance), but lots and lots of effects are simply missing or wrong. It does quite a bit interesting stuff wined3d doesn't seem to handle: strange viewport handling, glow, blending, reflections, blur(?). So many unimplemented features I won't even dare to file bugreports for every single one... :) It's the all-time most popular demo on pouet.net (obviously, given it's called "fr-025 - the.popular.demo" ;) ) You can get it at: http://www.pouet.net/prod.php?which=9450 -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 30, 2006

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

by Segin

Saulius Krasuckas wrote: >* On Tue, 28 Mar 2006, Karl Lattimer wrote: > > >>And also, accusing people of having an IQ of 0 for replying to a flame >>isn't in the slightest constructive, >> >> Hardly. I have actually done something good. I got people to addresses the Winetools problem a bit early. Sure, it would have gotten adressed anyways, but only after enough complains come rolling in, months or years from now. When I sent the flame, i had a purpose, a plan, and a hoped outcome. The end result was nothing but good, so why shun me? I was just getting a matter addressed before we have no choice but to address it. We can't just put it off forever, you know. > >Yes, he didn't write any single patch yet that was accepted, still he >manages to joke calling one of the developers being a monkey. (Given that >monkeys can't even distinguish between MUAs and MTAs nowadays) > > I haven't written any patches, namely because my eariler code changes i find cause signal 11. Recently I am working on something that will be offloaded months from now (if i dont find it to be too fustrating) as a huge diff, so keep your eyes peeled. If it doesn't work on either of my systems, it's broken, and sending a diff is a waste of everybody's time. >Being of sensitive nature I'd remove him from the list so he will find >appropriate lists to talk constructively in. (Be I wine-devel moderator) > >

March 30, 2006

Improper message recursion revealed by recent desktop window changes

by Troy Rollo

The recent changes to the desktop have revealed a problem with recursive processing of X messages. The problem started to manifest with commit 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack that looks like this: <application Window procedure> WINPROC_wrapper ... CallWindowProcW ... SendMessageW X11DRV_SetWindowPos SetWindowPos X11DRV_ConfigureNotify process_events X11DRV_MsgWaitForMultipleObjectsEx wait_message_reply send_inter_thread_message SendMessageTimeoutW SendMessageW send_parent_notify DestroyWindow In other words, a destroy notification is being sent to the parent window with SendMessageW, and before that message returns an unrelated X message is processed. Under Windows the equivalent could never happen - if a thread is in SendMessage(), the only messages that can be delivered to it are ones sent by SendMessage() from another thread. The consequences of this can be unpleasant if the code that processes (in this case a window movement notification) the message interferes with state that is being dealt with in earlier stack frames. wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, INFINITE, QS_ALLINPUT, 0 ); The brute-force approach of changing this to the following makes the application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - wine(a)troy.rollo.name

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Mike McCormack

Hiji wrote: > I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. It's more about not feeding the trolls that agreeing with him. In my mind, Jon is a much more respectable member of the Wine community than "segin". It would be disappointing to see a real contributor scared off by a troll. Personally, I think Winetools has it's place, but it would be more helpful to the Wine community if it was a bit better supported, and used builtin dlls in preference to natives ones whenever possible. Mike

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Hiji

> How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. I'm trying to say two things here: 1) If somebody says/ does something that is not okay, say something to that person. Of course, be constructive about it. For example, when I first joined this list, people got upset that I was top-posting - I learned that it was not ok in this community because people said someting. So, I try to bottom post (when I remember.) 2) I've always said Wine is an awesome thing - probably the best thing to come out of the Linux community since ... well, Linux and its desktops. Now, more than ever, Wine need as many developers as possible to keep it improve b/c as Linux adoption continues people will look to Wine and CrossOver for application cross-compatibility. And, I'm not talking about the developer who pops in with a patch every 6 months (I see that person as a patch submitter), but instead, I'm talking about a developer who dedicated him/herself to the Wine project. And with that, the team can't afford to lose that good talent b/c the "newbie talent" was mistreated in this community. Those are my 2 cents that I think will go a long way. Thanks, Hiji

March 30, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Chris Morgan

> > I'm pretty sure people are capable of filtering their own email. > > Afaict the offending emails were between two individuals. You may not > > like them but that has no bearing on whether they should be allowed to > > post to the mailing list given that those emails to the mailing list > > are appropriate. > > > > Chris > > > > Be that as it may, the person who made those comments made them as a direct > attack on someone who posted to the list. Regardless of whether or not the > insults were posted to the list, he shouldn't have made them. As the person > who reported the incident said, had it been a new developer interested in > helping wine (either directly by contributing code to the project, or > indirectly by writing a support app), he probably would have said screw > this, I'm not going to help out a project that has developers who verbally > attack me. I know I would have. > How do you propose we prevent people from emailing people that post to wine-devel? How do we choose who gets to email people directly and who doesn't? How do we filter the contents of their email? Segin doesn't speak for the entire community and he isn't a lead on the project. If that were the case this would be a more serious matter. If people quit because of him then what are we to do? Given the lack of relationship between wine and Segin they might as well have quit wine development because of some Nigerian money transfer email or other spam. My point is that the solution isn't trying to enforce censorship where you simply cannot and where it doesn't impact the community. As long as he doesn't abuse his list membership we have no reason to become involved in this issue. You won't find me supporting any kind of restrictions on what he says or which mailing lists he can belong to at this point in time. Chris

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Tom Spear

On 3/29/06, Chris Morgan <chmorgan(a)gmail.com> wrote: > > I'm pretty sure people are capable of filtering their own email. > Afaict the offending emails were between two individuals. You may not > like them but that has no bearing on whether they should be allowed to > post to the mailing list given that those emails to the mailing list > are appropriate. > > Chris Be that as it may, the person who made those comments made them as a direct attack on someone who posted to the list. Regardless of whether or not the insults were posted to the list, he shouldn't have made them. As the person who reported the incident said, had it been a new developer interested in helping wine (either directly by contributing code to the project, or indirectly by writing a support app), he probably would have said screw this, I'm not going to help out a project that has developers who verbally attack me. I know I would have. Sure we all have to deal with someone who is annoyed at a stupid comment or question every now and then, but those were not stupid (not in my opinion), and had some very valid points. If the "attacker" had done some research instead of spouting off because he was tired of users complaining about something not working and it turning out to be because of winetools, we wouldnt be having this convo. With all of that being said and trying to get back on topic, sure winetools breaks a lot of things, but from what I can see, it also gets a lot of things working. If we have better documentation and if (here is the key) the users took the time to read thru all of the docs, which I admittedly don't, there wouldnt be any need for winetools. Honestly, I think that winetools should have been (from the beginning) something that creates a second installation of wine, from source, and that plays with registry files outside of the main wine install. IOW a user who uses wine doors should have a directory structure like this / -wine-source --all the uncompiled and unlinked files -wine --all the binaries and dll's, etc for a proper wine install (including wineprefixcreate, the wine executable, etc) -~/.wine --all the files outside of binaries -wine-doors --all the binaries and dll's etc for a proper wine install (like wine-doors instead of wine, and wineprefixcreate-doors, etc) -~/.wine-doors --all the files outside of binaries modified to work with different apps Then a user can run ./wine-tools and it will present them a prompt saying "Detecting app to be run... Internet Explorer" "Merging changes to wine registry to allow running of internet explorer" "Changes Merged" "Running Internet Explorer" Then boom.. Up pops IE.. That is what winetools should have done. But since it doesn't, we are working on wine doors. A much more user friendly wine tool that will have more features. Of course, I'm not sure how it's going to look, and since I don't speak fluently in C, I won't be contributing, but hopefully it will be better than winetools without all of the problems of winetools... Tom,

March 29, 2006

Re: Direct3D, the kernel and ReactOS

by H. Verbeet

On 29/03/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > I know that this is not easy to achieve. The kernel interface is poorly > documented, and Greatlord has spent a lot of effort to verify the docs and to > write a better documentation of the interface. Apps using the kernel > interface should be considered broken, and I don't give them a long lifetime > as the interface changes from Windows version to Windows version(According to > Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this > way and implement the kernel Direct3D interface? If so, I consider this > something post-1.0, and we should definitely see what changes Vista brings. Personally, unless it really becomes an issue, I'd rather not. It think it's hard enough to figure out what a particular d3d call is supposed to do as it is.

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Chris Morgan

I'm pretty sure people are capable of filtering their own email. Afaict the offending emails were between two individuals. You may not like them but that has no bearing on whether they should be allowed to post to the mailing list given that those emails to the mailing list are appropriate. Chris On 3/29/06, Tom Spear <speeddymon(a)gmail.com> wrote: > Totally agreed. Segin needs to be not just kick/banned from the list, he > needs to be K-Lined, if not G-Lined from all things wine! With respect to > his comments though, on behalf of everyone involved with the project, and > with the community as a whole, I sincerely apologize. > > Tom > > > On 3/29/06, Jason Green <jave27(a)gmail.com> wrote: > > On 3/29/06, Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> wrote: > > > I was interested to read several comments on this list in respect of > such > > > comments as 'IQ of zero'. Such comments were the final straw in leading > me to > > > take this action. > > > > Thank you. It sometimes takes a thick skin to ignore the petty and > > childish rants that are prevalent online. Anonymity (or > > pseudo-anonymity in this case) often leads to childishness, and has > > done so since the beginnings of the Net. It gives the impression to > > potential new users and developers that the "community" is hostile and > > unwelcoming. I experienced a little bit of myself when asking my > > first couple of [naive] questions in IRC at #winehq. > > > > While it's completely understandable that people will get tired of > > seeing the same questions posted over and over again, there's no need > > to get hostile about it unless the user asking the questions gets > > hostile or demanding themselves (and even then, restraint or kick/ban > > would be preferable). If someone asks a "stupid question" (entirely > > subjective, remember), just ignore it or point to a place where they > > can learn the answer themselves. Please don't be a jerk. > > > > Thanks. > > > > > > > > > > > >

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Tom Spear

Totally agreed. Segin needs to be not just kick/banned from the list, he needs to be K-Lined, if not G-Lined from all things wine! With respect to his comments though, on behalf of everyone involved with the project, and with the community as a whole, I sincerely apologize. Tom On 3/29/06, Jason Green <jave27(a)gmail.com> wrote: > > On 3/29/06, Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> wrote: > > I was interested to read several comments on this list in respect of > such > > comments as 'IQ of zero'. Such comments were the final straw in leading > me to > > take this action. > > Thank you. It sometimes takes a thick skin to ignore the petty and > childish rants that are prevalent online. Anonymity (or > pseudo-anonymity in this case) often leads to childishness, and has > done so since the beginnings of the Net. It gives the impression to > potential new users and developers that the "community" is hostile and > unwelcoming. I experienced a little bit of myself when asking my > first couple of [naive] questions in IRC at #winehq. > > While it's completely understandable that people will get tired of > seeing the same questions posted over and over again, there's no need > to get hostile about it unless the user asking the questions gets > hostile or demanding themselves (and even then, restraint or kick/ban > would be preferable). If someone asks a "stupid question" (entirely > subjective, remember), just ignore it or point to a place where they > can learn the answer themselves. Please don't be a jerk. > > Thanks. > > >

March 29, 2006

getwinegit.sh 0.31 released!

by Christian Lachner

OK, I'm tired now but this is a new release an it owns ;). It should be quite stable but I didn't test it. So what has changed: 0.31 One more Release, I'm glad about this one - Some smaller an greater Fixes - After Compiling, the Script creates a helperfile to help mode 4 - Sections in Logfile - Trap included to handle ctrl+c - Implemented a small sleeper to give you a chance to stop the script before it starts to clean the source This is one of the last versions. The last version will be called 1.0. (maybe the next one?) If you miss a feature... write to the mailinglist.

March 29, 2006

Direct3D, the kernel and ReactOS

by Stefan Dösinger

Hello List, I had a talk to the DirectX developers of reactos on their irc channel to discuss how Reactos and Wine can share efforts on DirectX. (Please leave the legal issues asside for now, let us concentrate on the technical part for now). I didn't expect much possibility for a cooperation in such a hw-related thing as DirextX, but Greatlord told me about the gdi / win32k problem Wine is heading to with the current DirectX code. According to Greatlord, Microsoft's DirectX implementation basically consists of a kernel-side part in gdi.dll and win32k.sys, and a user-mode part in ddraw.dll, d3d8.dll and d3d9.dll. The user dlls contain the Hardware emulation layer code, and calls to the kernel for the Hardware abstraction layer. Now that wouldn't be a problem for Wine, as applications are expected to use the user mode dlls, and using the kernel interface is highly discouraged by Microsoft. However, there are a few apps out there which access the kernel interface directly, and Greatlord told me that he knew about a few companies which plan to use it to gain speed improvement. Expectedly, such apps won't work on Wine. My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings. Another thing we discussed was DirectInput. ReactOS uses wines dinput.dll, with improvements which gets the sdk demos and some nasty games working. I can see if I can merge the changes to Wine.

March 29, 2006

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Jason Green

On 3/29/06, Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> wrote: > I was interested to read several comments on this list in respect of such > comments as 'IQ of zero'. Such comments were the final straw in leading me to > take this action. Thank you. It sometimes takes a thick skin to ignore the petty and childish rants that are prevalent online. Anonymity (or pseudo-anonymity in this case) often leads to childishness, and has done so since the beginnings of the Net. It gives the impression to potential new users and developers that the "community" is hostile and unwelcoming. I experienced a little bit of myself when asking my first couple of [naive] questions in IRC at #winehq. While it's completely understandable that people will get tired of seeing the same questions posted over and over again, there's no need to get hostile about it unless the user asking the questions gets hostile or demanding themselves (and even then, restraint or kick/ban would be preferable). If someone asks a "stupid question" (entirely subjective, remember), just ignore it or point to a place where they can learn the answer themselves. Please don't be a jerk. Thanks.

March 29, 2006

OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')

by Dr J A Gow

I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. A few days ago I sent a comment to the list. Nothing really sinister, just an observation and an experience. Before long I had a particularly vicious and vile diatribe sent in reply to my comment - to my private email address. I have appended the lower headers and the bulk of the message I received at the end of this message (trimming the html from the bottom). I thought long and hard before taking this action. It is not something I would normally do, but in this instance I was so incensed at this individual's behaviour that I felt that 'naming and shaming' was the only way forward. Not even so much as to the fact that he directed his comments to me, but more the fact that had I been a new prospective developer, the effect such diatribe would have would not in any way be positive. It certainly would taint their perception of the open-source community. Furthermore I sincerely doubt that I am the only one to experience this behaviour. Others may just suffer in silence. I have worked with many smaller community projects, on OS/2 and latterly on Linux, and never been subjected to this kind of abuse from members of the community. I joined this list because I felt that there was something I could contribute to Wine, and in the instance it turned out that there was. I did not join it to receive unsolicited email of an abusive nature from members of the community. Had he done this by telephone I could have had him prosecuted, at least in the UK. But he hides behind a gmail.com address and makes comments I seriously suspect he would not have the balls to say to my face. No, I do not believe that we need a 'net police force'. Common decency between individuals, however, is essential. Diversity, discussion, criticism, expression, even annoyance are all valuable when driving a project forward. Blatant personal abuse is not tolerable. It is not tolerable in society, it should not be tolerated in the developer community. The community needs to police itself, rather than be policed, and individuals who bring the community into disrepute need to be dealt with by the community. That is why I bring this into the open. How to prevent such actions? I do not think it that this is possible in its entirety. I can (and have) simply add this individual's address to my blocked list. However, I may have been a newcomer to open-source development who would not have been so tolerant, and whose opinions of the community may have been changed by this action. May I suggest that whoever is responsible for the hosting of the mailing list change the configuration so that email addresses are not placed in the header? (I am no expert on mailing-list software but it does not immediately seem to be impractical.) That way all replies have to go to the list and this would prevent such unsolicited email being sent. This is my last word on this matter. Make of it what you will. I refuse to be prevented from contributing to vital projects such as Wine when I can by the antics of some depraved individual. It has left a sour taste in my mouth though, and like it or not, it does not portray Wine developers in a good light. ------------------------------------------------------------------------------- Disposition-Notification-To: Segin <segin2005(a)gmail.com> Date: Fri, 24 Mar 2006 15:01:11 -0500 From: Segin <segin2005(a)gmail.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> Subject: Re: Winetools -> wine doors References: <1143192770.25116.22.camel(a)despair.kent-music.com> <442441D7.7020107(a)furrybubble.co.uk> In-Reply-To: <442441D7.7020107(a)furrybubble.co.uk> Content-Type: multipart/alternative; boundary="------------010900050103010506060607" X-BV-Spam-Score: 0.4 (/) X-Envelope-From: segin2005(a)gmail.com X-Virus-Scanned: by amavisd-new This is a multi-part message in MIME format. --------------010900050103010506060607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dr J A Gow wrote: > >> I've looked through the winetools code and it is a clusterf*ck of >> nonsense. It appears to be in the final stages of code rot, however > > > This "clusterf*ck of nonsense" helped me to get a microcontroller > development suite running under Wine, which otherwise would not install You're a fucking retard, RTFM! You'd learn you need to use DLLOverrides in Winecfg. > natively. After over ten years designing and developing embedded systems, > there is one thing that stands out. That you're a dumbfuck? > Code that is 'nonsense' does not work > at all. That's 100% definitive of Winetools. > Code that works may not be elegant, it may not be pretty and > you may hate the style, but it _works_ Nope, wine doesn't do ~/.wine/config, which makes winetools COMPLETELY useless. **WINETOOLS DOES NOT DO A DAMN REDEEMING THING FOR WINE USERS THAT ARE UP TO DATE!!!!** > and therefore it is not nonsense. Yes, it is. > This code works, is useful and serves a purpose. Just because you don't > like the way it is written does not make it nonsense. Language, please! > No IT DOES NOT! > John. > > So you're saying that you don't know how to use dlloverrides on winecfg, right? that's basically the same thing winetools does except that wine now ignores the config file (makine winetools utterly useless, 100%, no questions asked). please just install all the native DLLs that winetools installs, and set a dlloverride in winecfg of * (native, builtin) for your exe file. Please stop spouting your mis-infomation.

March 29, 2006

Here is an RSS feed for front page of www.winehq.com

by Daniel Schwarz

I've long wondered why winehq.com does not provide an RSS feed. I've created one using the feed43.com sitescraping tool. Works well and it should be very low impact to your webserver (it only hits the URL at most once every 6 hours and caches the result for subsequent queries) Feel free to post this RSS link on the winehq homepage. http://feed43.com/winehq.xml Best Regards, Dan Schwarz

March 29, 2006

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

by Eric Pouech

Dan Kegel wrote: > See the winedbg session below. > Is it normal for winedbg to complain about > floating point stuff when the program, run normally, doesn't? > Using either 'cont' or 'pass' at this point just repeats the same message. > Hints welcome. > Thanks, > Dan > > 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) that's rather strange... even if the support for FPU is still lagging (see Petr's latest patches on the subject), the pass command should make it work (or at least not stay where the exception occured) I'd be interested in a +seh trace with a pass command issued in the debugger A+ -- Eric Pouech

March 29, 2006

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

by Kuba Ober

Typos, typos everywhere :) > I've resisted switching from Pascal to C/C++ my whole high school, as I > considered C too have too convoluted a syntax. My opinion hasn't changed, > it's just that for a long time gcc was a tool of choice for a while and > learning C was a necessity, pure and simple. C++ is better as you can should have been > I've resisted switching from Pascal to C/C++ my whole high school, as I > considered C to have too convoluted a syntax. My opinion hasn't changed, > it's just that gcc was a tool of choice for a while and > learning C was a necessity, pure and simple. C++ is better as you can Cheers, Kuba

March 29, 2006

Re: server: Fix FPU registers in get_thread_context()

by Petr Tesarik

Dne 03/27/06 v 17:19:47 (+0200), Petr Tesarik napsal(a): > Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a): > > Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > > > [skip] > > > > > * Look at ContextFlags to see which registers are saved in > > > thread->context. > > > > Sorry this is not correct. Exception handler should get full context > > including FPU context. If we not saving it that's the problem on the > > other end. > > I don't think so. A real 80386 without a math coprocessor does not > even have an FPU context. I guess this is why CONTEXT_FULL does not > include CONTEXT_FLOATING_POINT. As I'm re-thinking it once more, I'm no longer sure about my point. You're right that the signal handler must definitely save the FPU state if there is one. Otherwise, it can't restore the context correctly if the exception handler uses the FPU (which it is AFAIK allowed to do). And at least under Linux, there is always an FPU state (either from a real FPU, or emulated). So, I'll change my question: Is there a platform, where FPU instructions can't be invoked unless there is a real FPU? To kick the answers off, I'm providing a table of possible operating systems we run on the x86 architecture. Whoever knows for sure that floating point instructions can or can not be safely run even without a real (hardware) FPU, please help complete the chart. Also, feel free to add any other systems which can run Wine. Linux: OK FreeBSD: ??? NetBSD: ??? OpenBSD: ??? Solaris: ??? OS/X: ??? Petr Tesarik

March 29, 2006

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

by Joachim von Thadden

Am Di, Mär 28, 2006 at 03:21:01 -0500 schrieb Segin: > How? The biggest thing that makes WineTools work is it's ability to set > DLLOverrides via a config file that Wine no longer acknoleges, therfore As this myth is floating around on this list since a long time I have to repeat: WineTools is not using a deprecated config file. It uses the regular registry way since a long time. > that is gone, and only a few things will work via WineTools, if at all. So this is also not true. > You can't install IE with WineTools (You can with IEs4Linux, and if you > are good enough, you can merge the ies4linux wine setup into the main If you use IEs4Linux you are actually using the overrides setup of WineTools as they took it from us. This also means that you have the most critisized *=native override included. We are working on this so you will probably have this on IEs4Linux soon after we fixed that. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 29, 2006

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

by Robert Shearman

Willie Sippel wrote: >OK, maybe I got something completely wrong. I'll give you an example to show >the problem I mean: > >Traktor DJ Player, by Native Instruments > >On Windows: >The main application window has no borders, appears in the taskbar, can be >minimized and moved like any regular window. > >On Wine (Kwin handles Wine windows): >The main application has a KDE window decoration that hides the top part of >the interface. Everything else works as espected, but there should be no Kwin >decoration, especially as it hides parts of the interface, making the >application unusable. > >On Wine (Wine handles windows): >The application window looks as expected, no borders, can be moved around and >stuff. But it's always on top, always on all desktops and does not appear in >the taskbar. Which is completely wrong. Also, if minimized, you'll get a >stupid icon somewhere on the desktop, on all desktops, always on top, hiding >the K-Menu... > >The perfect solution would be to let Kwin (or whatever window manager) handle >the borderless windows, but don't draw any window decorations if the >applications doesn't want to. That's what I expected to achieve with Motif >hints (but I'm obviously too stupid, all I get are nice crashes)... > > It sounds like the borders being present is a separate problem. Without knowing what windows styles the application is using (it could be using a weird combination that doesn't set the correct hints), it sounds like the application is handling the WM_NCCALCSIZE message and overriding the non-client top border to 0 and drawing its own part of that interface. The trouble is that detecting this is rather hard. A solution is possible where after it is detected that the non-client size has been altered and the MWM flags adjusted appropriately, but this would be based on heuristics like the existing managed/unmanaged problem and sometimes the heuristics get it wrong. This is just another case where if we do the right case for one problem then another problem crops up and it appears as though we are introducing regressions. In reality, fixing the managed/unmanaged window problem would be a huge step forward for everyone even if further work is necessary to make windows appear as expected. -- Rob Shearman

March 29, 2006

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

by Willie Sippel

Am Mittwoch, 29. März 2006 16:26 schrieb Robert Shearman: > Willie Sippel wrote: > >However, I ranted enough I think. Back to the real problem. AFAIU, there's > >only a single common/ feasible/ intelligent way to create borderless > > windows on X11 - managed windows with 'no decoration' Motif hints (the > > way GTK handles borderless windows). The example I found looks easy > > enough, only a few lines of code, but I was once again reminded that Wine > > really is way over my head - I have no idea how to hack that in to at > > least test it... :-( > > The code is already in dlls/x11drv/window.c and it works well. The > trouble is that managed mode windows steal input focus when they are > created. To give you an example, you click on a text box in IE to put > your email address into a form and you're half-way through typing it in > when a tooltip appears. This steals input focus away from the text box > and you carry on typing without noticing until you look back at the > screen and notice only half of your email address is present. The same > problems occur for menus and "toast" notifications. > OK, maybe I got something completely wrong. I'll give you an example to show the problem I mean: Traktor DJ Player, by Native Instruments On Windows: The main application window has no borders, appears in the taskbar, can be minimized and moved like any regular window. On Wine (Kwin handles Wine windows): The main application has a KDE window decoration that hides the top part of the interface. Everything else works as espected, but there should be no Kwin decoration, especially as it hides parts of the interface, making the application unusable. On Wine (Wine handles windows): The application window looks as expected, no borders, can be moved around and stuff. But it's always on top, always on all desktops and does not appear in the taskbar. Which is completely wrong. Also, if minimized, you'll get a stupid icon somewhere on the desktop, on all desktops, always on top, hiding the K-Menu... The perfect solution would be to let Kwin (or whatever window manager) handle the borderless windows, but don't draw any window decorations if the applications doesn't want to. That's what I expected to achieve with Motif hints (but I'm obviously too stupid, all I get are nice crashes)... -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 29, 2006

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

by Tom Spear

On 3/29/06, Ray Jones <rayjones(a)gmx.net> wrote: > > > > Being of sensitive nature I'd remove him from the list so he will find > > appropriate lists to talk constructively in. (Be I wine-devel moderator) > > > > Poppycock. The discussion he initiated ain't that useless, and as I see > it, he > was rather addressing a possible reply denying the (read: /his/) fact, > that this > one reason (why it is useless) is inargueable, than a certain person > (sarcasm, > anyone?). > > So, Inargueable, eh? > > Well. Depends. > > I use both Sidenet and Winetools, they both provide an easy way to have a > quick > and simple (more or less basic) setup for wine established. > > But in reality those (original) scripts are pretty much useless to me > since I > don't use the ~/.wine path, because I > a) have multiple versions of wine installed (compiled) and > b) need to use multiple instances of those wine-versions. > Of course, after modifying the scripts, everything works as supposed. > > Also, Winetools give you the ability to install several additional > applications > per button, but I don't think that should be the future. > If I want to install > Office then it has to work via double clicking the setup.exe. /Period/. > > Wine should provide an own beautiful setup (something like > wineprefixcreate+), > to install the directory structure and whatnot, > the rest has to be considered as working out of the box. > And if not, there is still the AppDB. > > > In the end, one will find Winetools/Sidenet or any derivates useful, the > other > not. > But those tools *should* become useless one day. And that is inargueable, > despite of any IQ. > > > > -Ray > > > > > > > This is the most well said email I have seen on this topic yet. Yes I am saying mine were pointless, including this one :-D Tom

March 29, 2006

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

by Robert Shearman

Willie Sippel wrote: >However, I ranted enough I think. Back to the real problem. AFAIU, there's >only a single common/ feasible/ intelligent way to create borderless windows >on X11 - managed windows with 'no decoration' Motif hints (the way GTK >handles borderless windows). The example I found looks easy enough, only a >few lines of code, but I was once again reminded that Wine really is way over >my head - I have no idea how to hack that in to at least test it... :-( > The code is already in dlls/x11drv/window.c and it works well. The trouble is that managed mode windows steal input focus when they are created. To give you an example, you click on a text box in IE to put your email address into a form and you're half-way through typing it in when a tooltip appears. This steals input focus away from the text box and you carry on typing without noticing until you look back at the screen and notice only half of your email address is present. The same problems occur for menus and "toast" notifications. Let's examine the properties of unmanaged windows (there may be others that I'm unaware of): They: 1. Have no window decorations 2. Are always on top 3. Appear on all virtual desktops. Properties (1) and (2) have equal properties in the Win32 world. However, currently only (1) is implemented. AFAIK, the reason (2) isn't implemented is because it isn't set at window creation time, only after window creation (and we cannot switch from managed to unmanaged after creation). Therefore, the solution is to allow managed windows to be converted to unmanaged windows after creation and then we can implement (2) and have an almost exact match of the desired properties of the window with the actual properties that the window manager gives us. Then we can remove the other hacks based on the window style that make Steam end up with an unmanaged window. -- Rob Shearman

March 29, 2006

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

by Dimi Paun

From: "Mike McCormack" <mike(a)codeweavers.com> > Yep. Just large enough for people to complain about, and demand that > somebody else take care of the problem, Now! ;) One of those things :) Now, don't misunderstand me, I'm glad Alexandre got around to move the desktop to the explorer process. My comments where of a more general nature, not about this particular patch. Overall, we're much better off with the desktop in explorer and fewer features, than the situation we were in before, which blocked all sorts of cool integration tasks. Sometimes you need a step back to be able to sustain future development. This is one of those situations. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 29, 2006

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

by Mike McCormack

Dimi Paun wrote: > Problem is that the breakage is not large enough to motivate > people. Yep. Just large enough for people to complain about, and demand that somebody else take care of the problem, Now! ;) Mike

March 29, 2006

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

by Ray Jones

> Being of sensitive nature I'd remove him from the list so he will find > appropriate lists to talk constructively in. (Be I wine-devel moderator) > Poppycock. The discussion he initiated ain't that useless, and as I see it, he was rather addressing a possible reply denying the (read: /his/) fact, that this one reason (why it is useless) is inargueable, than a certain person (sarcasm, anyone?). So, Inargueable, eh? Well. Depends. I use both Sidenet and Winetools, they both provide an easy way to have a quick and simple (more or less basic) setup for wine established. But in reality those (original) scripts are pretty much useless to me since I don't use the ~/.wine path, because I a) have multiple versions of wine installed (compiled) and b) need to use multiple instances of those wine-versions. Of course, after modifying the scripts, everything works as supposed. Also, Winetools give you the ability to install several additional applications per button, but I don't think that should be the future. If I want to install Office then it has to work via double clicking the setup.exe. /Period/. Wine should provide an own beautiful setup (something like wineprefixcreate+), to install the directory structure and whatnot, the rest has to be considered as working out of the box. And if not, there is still the AppDB. In the end, one will find Winetools/Sidenet or any derivates useful, the other not. But those tools *should* become useless one day. And that is inargueable, despite of any IQ. -Ray

March 29, 2006

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

by Willie Sippel

Am Mittwoch, 29. März 2006 15:14 schrieb Marcus Meissner: > On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote: > ... > > > > Isn't it just better to start with a patch that is "right", but will > > > still show regressions, then fix those regressions, as opposed to > > > starting with a patch that is wrong, and then hacking on it forever > > > trying to solve the unsolvable problems that causes? > > > > You are right, of course. I'm all for doing stuff right, and I'm not a > > friend of quick-and-dirty hacks myself. I simply can't understand why > > most serious regressions introduced in the last two years are seemingly > > not worked on at all - they simply seem to get ignored. I'm sorry if my > > mail sounded like a > > Simple. > > No one is paying to get it fixed ;) (And it requires a lot of effort > for Joe Random Coder.) > > Thats just OpenSource for you. > O RLY? ;-D I know how that stuff works, I'm part of a few projects myself. Still, I'm the 'I broke it, I'll fix it' kinda guy, but I know it's wrong to expect everyone to be the same. Especially in the case of Wine, as I'm sure the fixes that introduced the regression did more good than harm, in general. However, I ranted enough I think. Back to the real problem. AFAIU, there's only a single common/ feasible/ intelligent way to create borderless windows on X11 - managed windows with 'no decoration' Motif hints (the way GTK handles borderless windows). The example I found looks easy enough, only a few lines of code, but I was once again reminded that Wine really is way over my head - I have no idea how to hack that in to at least test it... :-( -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 29, 2006

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

by Dimi Paun

From: "Mike McCormack" <mike(a)codeweavers.com> > Wouldn't be much motivation for somebody to come up with a real fix if > there was already a half-baked fix in Wine already, would there? But neither does the keep-it-borken approach work, does it? :) Problem is that the breakage is not large enough to motivate people. I think we have to come to terms with the fact that Wine is big, and doing things right is not always an option. I seems to me that we'd be better off to have a working but not-so-perfect solution, rather than wait for years to have the perfect one. Of course, I agree that you can not merge any solution in, that road leads to madness. But we have to balance that with the fact that we have to be useful by offering the functionality that people need or want. Otherwise wine will become irrelevant before it becomes useful. And that would be a shame. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 29, 2006

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

by Kuba Ober

On Tuesday 28 March 2006 23:30, Joseph Garvin wrote: > On Tue, 2006-03-28 at 17:22 -0500, Kuba Ober wrote: > > I was pretty serious when I said about Lisp. Once you get to know it, > > it's an extremely agile and productive programming language that has way > > more power than Python does. > > Even if that statement were true (I seriously doubt you can qualify it > with any actual evidence), 'power' isn't the only concern in choosing a > programming language for a project. Python has excellent community > support, tons of third party modules, several mature IDEs, and most of > all is easier for a new programmer to pickup than any other language > I've tried. Only after you were exposed to C/Modula-like languages in the first place. For someone who never programmed before it's easier to pick up Scheme than C, and I could hardly agree more with Natasha: http://www.inf.hs-zigr.de/~wagenkn/Natasha_Chen.html I've resisted switching from Pascal to C/C++ my whole high school, as I considered C too have too convoluted a syntax. My opinion hasn't changed, it's just that for a long time gcc was a tool of choice for a while and learning C was a necessity, pure and simple. C++ is better as you can essentially make a living not having to use a single pointer-to-function for a month at a time. But again, C++ is not C. > I'm also curious how you think that Lisp can somehow more concisely > represent the logic for this app. I haven't looked at any GUI bindings > for Lisp, but if they look anything like the OCaml ones it's just going > to be a dump of imperative code, which mostly defeats the point of using > a functional language in the first place. You can program in Lisp in both functional and imperative styles, and I guess that most Lisp programs have both styles in them. It mostly depends on what's handy at the moment :) > Python stole from Lisp what most people like about Lisp anyway. Well, functions aren't exactly first class citizens in Python, they were on their way to becoming so for some time AFAIK (more and more every release). That's something that was in Lisp since day one, OTOH. > > Lisp might be considered more obscure, that's sure, but > > that's due to people mostly being clueless (sorry, had to say that). For > > example there's no Python implementation that I know of that would even > > remotely compare (performance-wise) to Frantz Lisp, when running "dirty > > first-cut" code. > > The Python community pretty openly states that if performance is a major > concern for your project that Python is the wrong choice. You can code > part of your project in C (the performance critical parts) and the rest > in Python in some cases. If your app has a flat performance profile then > it's well known that Python isn't the best choice. Then again, no one is > going to use Lisp in that case either. IIRC the only reason that Orbitz became so good is because they had their flight search logic coded initially in Lisp. That's not only a fairly hardcore CPU-bound task, the choice of language made them way more agile feature-wise in their startup years. Right now they ported most of the code to C++, but I bet it was only feasible to do so after they got the architecture figured out and kinda settled down after hacking away in Lisp initially. > Bottom line -- this is a configurer. It's not run super often and what > it does isn't that computationally intensive anyway. Performance isn't a > concern. I know. I'm not overly concerned about that. I mainly wanted to redirect the flamewar elsewhere and have some fun at the same time. Yay :) > > Making it C implies not using Qt*, and I just can't see why anyone would > > *not* want to use Qt. I'm dead serious. It's probably the only framework > > right now that has any future, besides .net offerings and whatever is > > available for Java. Everything else (gtk, wxWidgets, . . .) simply has no > > support (compared to Qt). It's stupid to use dead solutions. > > Although I agree that Qt is the best choice, I'd have to disagree that > gtk is dead. wxWidgets will probably be around for some time too, Hanging around for some time vs. having full backing by a company are two different things. Last time I checked there was no single company of the size of Trolltech, or bigger :), whose bread and butter was developing gtk or wxWidgets, and who would have real good reason to develop either one of them further. I know that there are other thriving open source projects (Linux kernel, anyone?) where there is no single controlling company in charge, but those projects have achieved their critical mass long time ago and are past the infant stage. I don't see gtk or wxW anywhere near a critical mass. > if for > no other reason than that using Qt in C++ is a bit annoying because it > needlessly reinvents the wheel (there's a lot of overlap between Qt and > boost and even standard lib). Which is mainly of historical origin, as there was simply no decent implementation of boost or standard lib in the times when Qt began shipping. With model/view architecture supported so well by Qt4, you can have all your data in whatever containers you want, there's a tiny bit of interface code to write to get it to the widgets, that's all. I.e. Qt doesn't force you not to use boost, C++ library and so on. Cheers, Kuba

March 29, 2006

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

by Marcus Meissner

On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote: ... > > Isn't it just better to start with a patch that is "right", but will > > still show regressions, then fix those regressions, as opposed to > > starting with a patch that is wrong, and then hacking on it forever > > trying to solve the unsolvable problems that causes? > > > You are right, of course. I'm all for doing stuff right, and I'm not a friend > of quick-and-dirty hacks myself. I simply can't understand why most serious > regressions introduced in the last two years are seemingly not worked on at > all - they simply seem to get ignored. I'm sorry if my mail sounded like a Simple. No one is paying to get it fixed ;) (And it requires a lot of effort for Joe Random Coder.) Thats just OpenSource for you. Ciao, Marcus

March 29, 2006

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

by Willie Sippel

Am Mittwoch, 29. März 2006 12:19 schrieb Stefan Dösinger: > Hello, > > > > You announced working on the unmanaged window problem in September 2001 > > > IIRC, but I guess you didn't so far? Wouldn't, for the time being, a > > > Cedega-like approach be feasible? They seem to ignore 'chromeless' > > > windows and handle them just like regular windows (with window > > > decoration and all, for Steam for example) - this is obviously not > > > correct, but it would at least work 'till someone comes up with a real > > > fix...? > > > > Wouldn't be much motivation for somebody to come up with a real fix if > > there was already a half-baked fix in Wine already, would there? > > I've sent 2 patches addressing this issue to wine-devel last year. The > first > patch(http://www.winehq.org/pipermail/wine-patches/2005-March/016558.html) > made children of the desktop managed, the other patch made > WM_SYSMENU(Sorry, can't find this one in the archives) windows managed. > Both patches were neighter applied nor discussed further. > Did you check this[1] solution for borderless SDL applications? Looks somewhat hacky, but not too complicated. Maybe the basic idea is feasible for Wine as well? GTK (XMMS) seems to use the same approach ([2], Motif WM hints) to disable borders, and this concept works with pretty much every window manager... [1]: http://www.libsdl.org/pipermail/sdl/2000-January/023704.html [2]: http://www.pygtk.org/pygtk2reference/class-gdkwindow.html#method-gdkwindow-… -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 29, 2006

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

Re: I have a complaint about the website

by Segin

Robert van Herk wrote: > >> sorry for my bad english i am not feeling well and it is affecting my >> corrdination, i can't walk right or type correctly. i can barely see >> the monitor, it's that bad. > > Don't worry, probably it's just a virus. > > Regards, > > Robert > > > > yeah, i think i got the karma-sutra or code-red when i hooked my brain to the internet.

March 27, 2006

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

by Tony Lambregts

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

March 27, 2006

Re: I have a complaint about the website

by Segin

Jason Green wrote: >On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > > >>Due to the current state of Wine, plus it's archjitechure, Even if a >>virus was found, it is much easier to remove. >> >>If the virus is a memory-resident kind, you can do pkill -9 wine as root >>or your user and shut down ile essentially killing said virus. >> >>A lot of viruses, in order to keep small, attempt to make fnction calls >>based on a DLL function absolute address. This has a 1 in 256 million >>cnahce in working, because each time you recodmile wine, the function >>entry points change. all that aill result in is a segmentation fault. >> >> > >I agree that running viruses are much more difficult in Wine than in >Windows, however, by default, Wine maps Z:\ to your entire Linux tree. > If the user running Wine has write-access to any other folders in the >Linux system tree and runs a virus which randomly deletes or modifies >files on any accessible drive letter, that is still a problem. Plus, >some users don't use "rm -rf .wine/" on a daily basis like most devs >do, and they may actually store useful things under their .wine/ >folder. In the (albeit, unlikely) event of "succesfully" running a >Windows virus, those files are at risk. > >There are plenty of distros that install some version of Wine by >default and automatically associate .exe's and the like with Wine, so >users that aren't careful are still at risk. Granted, that risk is >minimized by not being fully compatible with everything Windows does >[yet], but it's still a risk. > > > maybe if we put in a md5sum database of viruses and refuse to run those that are viruses? it's not as good as a real a/v app, but it's a start.

March 27, 2006

Re: I have a complaint about the website

by Segin

Philip V. Neves wrote: > On the website there is an article that talks about homogenious > populations being a threat to society and to the computer industry. > 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. So theoretically a virus could > spread just as easily through a wine system as well as a Windows > system. That virus could spread even if the security in Linux is in > place. The wine installation could be affected and we have to > reinstall the wine directory. > > I'd appreciate it if you guys would take that out of the website. I > feel it hurts the credibility of your project by having it there. The > fact is if a company has a wine installation they could have a large > number of appications that could be affected by a virus. Wine running > on a different system won't fix that. Although the security system in > Linux could provide some security against accessing more vital parts > of the system, the wine installation is still vulnerable due to the > fact its implementing windows system calls. > > I have infact found viruses with Clam after installing wine. So I > don't feel that this statement is true. > > > Due to the current state of Wine, plus it's archjitechure, Even if a virus was found, it is much easier to remove. If the virus is a memory-resident kind, you can do pkill -9 wine as root or your user and shut down ile essentially killing said virus. A lot of viruses, in order to keep small, attempt to make fnction calls based on a DLL function absolute address. This has a 1 in 256 million cnahce in working, because each time you recodmile wine, the function entry points change. all that aill result in is a segmentation fault. sorry for my bad english i am not feeling well and it is affecting my corrdination, i can't walk right or type correctly. i can barely see the monitor, it's that bad.

March 27, 2006

Re: I have a complaint about the website

by Robert van Herk

> sorry for my bad english i am not feeling well and it is affecting my > corrdination, i can't walk right or type correctly. i can barely see > the monitor, it's that bad. Don't worry, probably it's just a virus. Regards, Robert

March 27, 2006

Re: I have a complaint about the website

by Kuba Ober

> maybe if we put in a md5sum database of viruses and refuse to run those > that are viruses? You mean worms? Viruses modify existing files and thus it's pointless to check whole-file checksums. Signature checking has significant runtime impact (say a second just to get one .exe checked), so it's not something you'd want to do each time an .exe is about to be run. Then there are many variations of signature checks, as some virii are polymorphic and so on. I'd say it's best not to reinvent the wheel, and providing a false sense of security is pretty bad. The only real solution for the users is to run a virus scanner at regular intervals, and additionally to maybe run wine in a chroot jail (that's a packaging issue). Cheers, Kuba

March 27, 2006

Re: I have a complaint about the website

by Jason Green

On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > Due to the current state of Wine, plus it's archjitechure, Even if a > virus was found, it is much easier to remove. > > If the virus is a memory-resident kind, you can do pkill -9 wine as root > or your user and shut down ile essentially killing said virus. > > A lot of viruses, in order to keep small, attempt to make fnction calls > based on a DLL function absolute address. This has a 1 in 256 million > cnahce in working, because each time you recodmile wine, the function > entry points change. all that aill result in is a segmentation fault. I agree that running viruses are much more difficult in Wine than in Windows, however, by default, Wine maps Z:\ to your entire Linux tree. If the user running Wine has write-access to any other folders in the Linux system tree and runs a virus which randomly deletes or modifies files on any accessible drive letter, that is still a problem. Plus, some users don't use "rm -rf .wine/" on a daily basis like most devs do, and they may actually store useful things under their .wine/ folder. In the (albeit, unlikely) event of "succesfully" running a Windows virus, those files are at risk. There are plenty of distros that install some version of Wine by default and automatically associate .exe's and the like with Wine, so users that aren't careful are still at risk. Granted, that risk is minimized by not being fully compatible with everything Windows does [yet], but it's still a risk.

March 27, 2006

Re: I have a complaint about the website

by Hiji

> So theoretically a virus could spread just as > easily through a wine system as well as a Windows > system. That virus could spread even if the > security in Linux is in place. The wine > installation could be affected and we have to > reinstall the wine directory. Take a look at this. It's a good read: http://winehq.org/?issue=259#Wine%20&%20Viruses Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 27, 2006

Winetools -> wine doors

by penna＠bb.com.br

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) 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. 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 27, 2006

I have a complaint about the website

by Philip V. Neves

On the website there is an article that talks about homogenious populations being a threat to society and to the computer industry. 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. So theoretically a virus could spread just as easily through a wine system as well as a Windows system. That virus could spread even if the security in Linux is in place. The wine installation could be affected and we have to reinstall the wine directory. I'd appreciate it if you guys would take that out of the website. I feel it hurts the credibility of your project by having it there. The fact is if a company has a wine installation they could have a large number of appications that could be affected by a virus. Wine running on a different system won't fix that. Although the security system in Linux could provide some security against accessing more vital parts of the system, the wine installation is still vulnerable due to the fact its implementing windows system calls. I have infact found viruses with Clam after installing wine. So I don't feel that this statement is true.

March 27, 2006

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

by Tomas Carnecky

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

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

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

by Huw D M Davies

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. Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

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

by Tom Spear (Dustin Booker, Dustin Navea)

Tomas Carnecky wrote: > I don't know if it even runs.. I mean, if it works correctly. > > http://dbservice.com/tom/LinuxTest.exe > > It creates LinuxTest.log in the same directory as the executable, and > prints out whether pbuffers are supported and which drawbuffers are > activated.. > > tom > > Well, I ran the file, and it did create the log, but in my case it said that pbuffers weren't supported in either spec. Tom

March 27, 2006

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

by Huw D M Davies

On Mon, Mar 27, 2006 at 05:32:12PM +0200, Tomas Carnecky wrote: > Huw D M Davies wrote: > > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. > >> And I don't think PBuffers or Pixmaps can be stereo, so is there any > >> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? > > > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > > buffer of the resulting rendering area, so we make sure that we're > > rendering into the X pixmap, not some dummy buffer created by > > glXCreateGLXPixmap. > > > > Ok, but see what happens if an application has one rendering context, > one window (doublebuffered) and one pbuffer (doublebuffered or not), > activates the window (per default the backbuffer is selected for > rendering), then activates the pbuffer (together with the same context), > now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the > frontbuffer is selected for rendering, and now the application again > activates the window and now it suddenly renders into the frontbuffer, > instead of the backbuffer like it thinks. > > wglMakeCurrent() isn't supposed to change the rendering context state > (someone prove me wrong, I couldn't find any good description of this > function, but neither does glXMakeCurrent) and application can make > assumptions according to that. > > I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't > run (and won't for a looong time, sadly). And one application to test it > with apparently isn't enough. > > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. Ah right, glDrawBuffer alters the rendering state, that's bad. We should presumably be calling glXSwapBuffers here (but only in the GLXPixmap case). Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

March 27, 2006

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

by Tom Spear (Dustin Booker, Dustin Navea)

Tomas Carnecky wrote: > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. > > tom > > > > I have a GF FX5700. Does that support pbuffers? If so, I'll run the test.... Tom

March 27, 2006

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

by Tomas Carnecky

Huw D M Davies wrote: > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. >> And I don't think PBuffers or Pixmaps can be stereo, so is there any >> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > buffer of the resulting rendering area, so we make sure that we're > rendering into the X pixmap, not some dummy buffer created by > glXCreateGLXPixmap. > Ok, but see what happens if an application has one rendering context, one window (doublebuffered) and one pbuffer (doublebuffered or not), activates the window (per default the backbuffer is selected for rendering), then activates the pbuffer (together with the same context), now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the frontbuffer is selected for rendering, and now the application again activates the window and now it suddenly renders into the frontbuffer, instead of the backbuffer like it thinks. wglMakeCurrent() isn't supposed to change the rendering context state (someone prove me wrong, I couldn't find any good description of this function, but neither does glXMakeCurrent) and application can make assumptions according to that. I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't run (and won't for a looong time, sadly). And one application to test it with apparently isn't enough. I have written a test for windows (to test whether wglMakeCurrent changes the drawbuffer or not), but nobody of my friends has a graphics card that supportd pbuffers. tom

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 08:13:23 (-0700), Vitaliy Margolen napsal(a): > > There is no other way to detect a hardware breakpoint than to look > > at DR6. Additionally, since the bits would get stuck for all > > subsequent SIGTRAPs, we need to clear them. > > [skip] > > Please don't forget here that we are not inventing something new. We can > not deviate from what native does, or it will brake some applications. If > you have a test case that shows that windows does what you trying to do - > I would like to see it. Or you could write your own test to test this on > windows. Maybe, you're missing my point. I'm trying to avoid DR6 altogether. And I can do it on some platforms. However, some Unixes seem to be crippled and I'm trying to provide a reasonable fallback for them. BTW if we forbid sending SIGTRAP to a Wine process, there will be more such platforms. AFAIK SIGTRAP is only sent internally by wineserver for DebugBreakProcess(). I'll have a look at it. Petr Tesarik

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Petr Tesarik

Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a): > Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > > > Hi, > > > this patch fixes a bug in get_thread_context(). Currently, this > > routine assumes that all registers except debug registers are saved in > thread->>context if it exists. However, it does not include FPU > > registers. > > > IMO, we should not blindly assume which registers are present in > thread->>context but look at ContextFlags. > > > BTW I found this bug when winedbg stopped working with programs using > > the FPU. > > > ChangeLog: > > > * Look at ContextFlags to see which registers are saved in > > thread->context. > > Sorry this is not correct. Exception handler should get full context > including FPU context. If we not saving it that's the problem on the > other end. I don't think so. A real 80386 without a math coprocessor does not even have an FPU context. I guess this is why CONTEXT_FULL does not include CONTEXT_FLOATING_POINT. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > Oh, I forgot to mention another thing. I didn't start all this for > nothing. I made my changes to raise_trap_exception() to make an > existing application (Kindler Lexikon) work. Sure, I'm not saying you did this for no reason. I just have the feeling you are changing a lot of things that don't need to be changed. This is a sensitive area of the code that a lot of apps depend on, and we have to be very careful about making changes. > [...] > Pretty long, huh? The thing is that all of this is necessary because you want to handle a SIGTRAP sent with kill(). But obviously no Windows application is going to send us a SIGTRAP; the only way this will happen is when we do it ourselves in DebugBreakProcess, and there's nothing that says that we can't use a different mechanism here if it works better. I'd say that somehow reusing the existing SIGUSR1 support is probably a better choice. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:49:13 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > In my opinion, the solution is reasonable because if any application > > is really interested in the DR6 register (i.e. it is a debugger), it > > will clear the status register (DR6) anyway, since the processor never > > clears the bits and unless you clear them manually, the register gets > > pretty useless. > > There are applications other than debuggers that care about debug > registers, notably copy protection code. We can't afford to do things > differently even if they sound reasonable. I'm afraid I can't understand you. At first, you're advocating the wrong test for the TF bit by the fact that it's 99.9 % correct and then you're criticizing clearing DR6 which is also 99.9 % correct. Not enough on that, I've provided a patch already which is 100 % correct on most platforms and only 99.9 % correct on the remaining ones. If you talk about copy protection schemes, I've seen code like this (while debugging self, of course): pushf pop %eax orl $0x100,%eax push %eax popf ; some code pushf pop %eax andl ~$0x100,%eax push %eax popf Now, native Windows will generate EXCEPTION_SINGLE_STEP after the last popf. In Wine you'll get a SIGTRAP (possibly with get_trap_code() == TRAP_x86_TRCTRAP, if TRAP_sig is defined for the platform). This will check the TF bit in context->EFlags. Since this is not set, it will fetch the debug registers and check the lowest 4 bits. These will be zero, so Wine generates an EXCEPTION_BREAKPOINT. I've already explained in another email that it's not possible to get the correct behavior in any other way than the way I've proposed. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Vitaliy Margolen

Monday, March 27, 2006, 7:58:38 AM, Petr Tesarik wrote: > Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): >> Petr Tesarik <hat(a)tesarici.cz> writes: >> >> > No, Windows need not do things like that, because the Windows kernel >> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do >> > not give us that information reliably. >> >> I'm afraid it's not acceptable to do things differently, especially >> not things like the checking of the previous instruction that may >> cause extra exceptions. Also stuff like the clearing of DR6 needs a >> test case, that's something that's visible from the application. [skip] > There is no other way to detect a hardware breakpoint than to look > at DR6. Additionally, since the bits would get stuck for all > subsequent SIGTRAPs, we need to clear them. [skip] If you need a program that uses DR6 for copy protection and will brake if you touch anything in it look here: http://bugs.winehq.org/show_bug.cgi?id=4036 It's using hardware breakpoints for lots of nasty things. And depends on the _exact_ content of the DR* registers when exception handler is called. Also it sets those registers only once. So if you alter any of the DR* registers in any way, this copy protection will brake. Please don't forget here that we are not inventing something new. We can not deviate from what native does, or it will brake some applications. If you have a test case that shows that windows does what you trying to do - I would like to see it. Or you could write your own test to test this on windows. Vitaliy.

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Vitaliy Margolen

Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > Hi, > this patch fixes a bug in get_thread_context(). Currently, this > routine assumes that all registers except debug registers are saved in thread->>context if it exists. However, it does not include FPU > registers. > IMO, we should not blindly assume which registers are present in thread->>context but look at ContextFlags. > BTW I found this bug when winedbg stopped working with programs using > the FPU. > ChangeLog: > * Look at ContextFlags to see which registers are saved in > thread->context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. Vitaliy Margolen

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. Oh, I forgot to mention another thing. I didn't start all this for nothing. I made my changes to raise_trap_exception() to make an existing application (Kindler Lexikon) work. Now, the copy protection mechanism in Kindler Lexikon uses a DOS application (no kidding!), so if you accept the VM86-related stuff that I posted earlier, so that raise_trap_exception() is not used for VM86-generated debug traps, it would probably be enough. However, as a side effect I noticed that the code does not work well, so I fixed it. If my fix is not good enough, well, then the UNIX ABI is not good enough, because: 1. A SIGTRAP can be delivered as a result of: a. INT 1 (single step or hardware breakpoint) b. INT 3 (INT3 or INT 03) c. kill() or tgkill() on the process 2. sc_trapno in sigcontext is set correctly by Linux only for 1a and 1b. The value of sc_trapno for 1c is undefined (and it may be even 1 or 3; I can provide a test case if needed). 3. Since you want to raise a BREAKPOINT exception for 1c, a BREAKPOINT exception with ExceptionAddress decremented by 1 for 1b and a SINGLE_STEP exception for 1a, you have to distinguish between those three cases. 4. You can tell the 1c case from 1b or 1c from the si_code in siginfo. However, this field might not be available. Things are even worse, because even TRAP_sig might be unavailable on some platforms! 5. Since the kernel does not provide enough information to distinguish between 1a, 1b and 1c, you have to investigate the reason yourself. There is no other way to detect a hardware breakpoint than to look at DR6. Additionally, since the bits would get stuck for all subsequent SIGTRAPs, we need to clear them. There is no other way to detect an INT3 breakpoint than to look at the code that immediately precedes the exception address. However, there is no guarantee that this address is mapped at all (a hardware breakpoint may occur anywhere, even at the first opcode of a page). Since native Windows won't crash in such cases, neither should we. That's why the whole thing is in a TRY block. Pretty long, huh? Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > In my opinion, the solution is reasonable because if any application > is really interested in the DR6 register (i.e. it is a debugger), it > will clear the status register (DR6) anyway, since the processor never > clears the bits and unless you clear them manually, the register gets > pretty useless. There are applications other than debuggers that care about debug registers, notably copy protection code. We can't afford to do things differently even if they sound reasonable. > I wonder why you haven't been bothered by the fact that the current > implementation silently drops the TF bit, which is even worse! :O I'm sure there are bugs in the current implementation, but that's not a reason for introducing different ones... If you find anything that the current code is doing wrong, please provide a test case demonstrating the bug, and I'll be more than happy to fix it (or to accept a fix if you have one). -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. I don't want to cause unnecessary conflicts, so I _have_ written a test case, where Wine does a lot of application-visible things differently. Anyway, I've provided an improvement which only needs to do such things as a fallback on platforms, where the cause of the SIGTRAP cannot be determined easily. In my opinion, the solution is reasonable because if any application is really interested in the DR6 register (i.e. it is a debugger), it will clear the status register (DR6) anyway, since the processor never clears the bits and unless you clear them manually, the register gets pretty useless. I wonder why you haven't been bothered by the fact that the current implementation silently drops the TF bit, which is even worse! :O Petr Tesarik

March 27, 2006

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

by Huw D M Davies

On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. > And I don't think PBuffers or Pixmaps can be stereo, so is there any > special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? See man glXCreateGLXPixmap. The X pixmap is used as the front left buffer of the resulting rendering area, so we make sure that we're rendering into the X pixmap, not some dummy buffer created by glXCreateGLXPixmap. Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > 2. The x86 spec states that a single-step interrupt (INT 1) is > generated if the TF bit was set when the execution of the > instruction BEGAN. This means that if the instruction changes the > TF bit (e.g. popf), there is an INT 1, but the TF bit is not set > any more. The only way to check whether the interrupt was > generated because of the TF bit, is to check bit 15 in DR6. I don't see why you can't still check the TF bit, it will be set 99% of the time, and fetching the DR6 register is quite expensive. > The following patch fixes all of these issues. I'd really like to see test cases showing that Windows does things this way. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: advpack: Add initial tests for RunSetupCommand

by Detlef Riekenberg

Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins: > * Add initial tests for RunSetupCommand. > dlls/advpack/tests/install.c | 106 ++++++++++++++++++++++++++++++++++++++++ Hi. Your tests used a fixed Path, resulting to failure on: - win95, win98 and winme (c:\windows\system) - NT3.51 (c:\winnt35\system32) - NT4 and w2k (c:\winnt\system32) - Every Installation, that use a non-default Installation-Directory - Every update of an NT < winxp (I don't know about the default Path in Versions > winxp) Your Patch is already in the tree, so expect many tests to fail. -- By By ... ... Detlef

March 27, 2006

FPU context in signal handlers

by Petr Tesarik

Hi, I've just submitted a patch that handles the FPU state in signal handlers. However, the FPU_sig() macro is only defined for Linux, so other architectures won't benefit from that patch. I doubt that i387 FPU state is left untouched by the kernel on other architectures, but I have no access to any such box (*BSD, BSDI, SCO, Apple), I cannot investigate into that, and the FPU handling is most likely broken on those architectures. This has become more serious now that winedbg tries to fetch (and restore!) the FPU state on the i386 architecture. I guess that architectures with (context)->uc_mcontext also define (context)->uc_mcontext.fpregs (SCO), but since I can't test it, I won't send such a patch to wine-patches. Is there anything I might do about it? Anybody wants to help? Petr

March 27, 2006

Re: Regression in wine made 2006/03/23

by James Hawkins

On 3/27/06, Pavel Troller <patrol(a)sinus.cz> wrote: > Hi! > I would like to report a regression made by commits issued 2006/03/23 at the > evening. Just now I don't have bisecting environment available, I've just made > a simple CVS regression testing and found the above commit (it modifies > multiple areas) guilty. > The problem is that DC++ gui is totally screwed up now. It tries to render, > but mostly unsuccessfully, it's full of garbage and doesn't display, what it > should. It doesn't update when necessary. DC++ is simply unusable now. > I should leave my testing machine now. I can try to pinpoint a particular > patch responsible for this regression later in the evening today, or tomorrow. > If anybody has an idea, what change could cause this, please let me know, > it will be more easy for me. > With regards, Pavel Troller Works fine for me with CVS. Are you fully up to date? What version of DC++ are you using? -- James Hawkins

March 27, 2006

Re: [Wine] Wine/Interix -- The pros and cons.

by Geoff Streeter

At 2006-03-24 22:26 -0500, Segin wrote: >I was thinking about running Wine on Interix (the POSIX layer of >Microsoft's Services for Unix). There are a few apparent unknows: > >Would Wine load the .dll.so's? Since Interix uses PE for it's native >format (running on Windows, duh), Would Wine load the .dll.so's? Would it >reject them being in PE format and having the 'POSIX Layer' attribute set, >or could we hack on a patch to detect if Wine itself is running in said >layer, and load them if it is? Would that even *work*? And how about >detecting Winelib applications? It might get detected as a regular Windows >app, and ... uh-oh... (let's just say it isn't pretty) > >There are several obvious pros: You can test Wine almost fully under >Windows without mingling with Windows's native componets. This would allow >for better and faster compatability tests. We could also see what >"unknowns" exist in Interix -- Althought not nessessrarly useful to Wine >developers itself, it could mean a whole new generation of applications >which are half-Unix, half-Windows, if the right holes are found. > >I am sure this will spark a LOT of debate. > >_______________________________________________ >wine-users mailing list >wine-users(a)winehq.org >http://www.winehq.org/mailman/listinfo/wine-users Bear in mind that SFU won't install on XP Home or XP64. It seems to be XP Pro only. I haven't tried installing on the Vista Beta (either 32 or 64 bit). Geoff

March 27, 2006

Regression in wine made 2006/03/23

by Pavel Troller

Hi! I would like to report a regression made by commits issued 2006/03/23 at the evening. Just now I don't have bisecting environment available, I've just made a simple CVS regression testing and found the above commit (it modifies multiple areas) guilty. The problem is that DC++ gui is totally screwed up now. It tries to render, but mostly unsuccessfully, it's full of garbage and doesn't display, what it should. It doesn't update when necessary. DC++ is simply unusable now. I should leave my testing machine now. I can try to pinpoint a particular patch responsible for this regression later in the evening today, or tomorrow. If anybody has an idea, what change could cause this, please let me know, it will be more easy for me. With regards, Pavel Troller

March 27, 2006

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > Any word on why this patch wasn't applied? There's a test marked todo_wine > by Stefan Leichter that demonstrates this behaviour. And here's the relevant > part of a relay log: QueryDosDevice needs to be fixed to return real device names instead of just reading the symlink. We can't require people to name their directories harddisk something. I'm working on it but it needs a bit more device infrastructure first. -- Alexandre Julliard julliard(a)winehq.org

March 26, 2006

Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.

by Alasdair Sinclair

Hi This patch breaks firefox-1.5 on fedora core 4 (x86-64). err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine: Unhandled page fault on write access to 0x0000001a at address 0x6033e436 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x0000001a in 32-bit code (0x6033e436). fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\xpcom\build\xpcom_core.pdb' Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0063 EIP:6033e436 ESP:7fa0f790 EBP:7fa0f7c0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000001 EBX:7f5e866c ECX:00000000 EDX:7fa0f704 ESI:00000000 EDI:7fa0fd18 Stack dump: 0x7fa0f790: 0001002a 7f5c580a 0001002a 00000113 0x7fa0f7a0: 00000000 0000139c 7fca1cf9 7f5e866c 0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18 0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a 0x7fa0f7d0: 00000113 00000000 0000139c 7e270598 0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 00000113 0200: sel=1007 base=7fe6a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x6033e436 in xpcom_core (+0x2e436) (0x6033e436) 2 0x7f5c6490 WINPROC_CallWndProc+0x70(hwnd=<register not in topmost frame>, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dlls /user/winproc.c:418] in user32 (0x7f5c6490) 3 0x7f5cd2de CallWindowProcW+0x12e(func=0x7f624c34, hwnd=0x1002a, msg=0x113, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dll s/user/winproc.c:3095] in user32 (0x7f5cd2de) 4 0x7f5926ff DispatchMessageW+0xaf(msg=0x7fa0fd18) [/ppp/wine/wine-git/dlls/user/message.c:3001] in user32 (0x7f5926ff) fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\browser\app\firefox.pdb' 5 0x0051866b in firefox (+0x11866b) (0x0051866b) 6 0x007fd417 in firefox (+0x3fd417) (0x007fd417) 7 0x00401012 in firefox (+0x1012) (0x00401012) 8 0x7fc8a00c start_process+0xec(arg=0x0) [/ppp/wine/wine-git/dlls/kernel/process.c:845] in kernel32 (0x7fc8a00c) 9 0xf7fcc4f7 wine_switch_to_stack+0x17 in libwine.so.1 (0xf7fcc4f7) Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 9873494ced8405113381266b4d99c2a9f3002cb1 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9873494ced8405113381266… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Mar 22 22:13:40 2006 +0100 > > server: Class and global atoms should not be local to a window station. > > --- > > dlls/user/tests/winstation.c | 43 +++++++++++++++++++++++++++++++++++++++++- > server/atom.c | 27 ++++++++++++++++---------- > server/class.c | 24 ++++------------------- > 3 files changed, 62 insertions(+), 32 deletions(-) > > diff --git a/dlls/user/tests/winstation.c b/dlls/user/tests/winstation.c > index 4bc1941..a595718 100644 > --- a/dlls/user/tests/winstation.c > +++ b/dlls/user/tests/winstation.c

March 26, 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+ I'll try incorporating your patch into the gentoo ebuild and report back if it helped my situation. Gramt

March 26, 2006

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c

by Hans Leidekker

Any word on why this patch wasn't applied? There's a test marked todo_wine by Stefan Leichter that demonstrates this behaviour. And here's the relevant part of a relay log: 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "a:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "b:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "c:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=0000000c ret=0100503a 0009:Call ntdll._strlwr(7fb0f8c8 "..\\drive_c") ret=01005053 0009:Ret ntdll._strlwr() retval=7fb0f8c8 ret=01005053 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002638 "harddisk") ret=01005069 0009:Ret ntdll.strstr() retval=00000000 ret=01005069 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002630 "ramdisk") ret=0100507d 0009:Ret ntdll.strstr() retval=00000000 ret=0100507d 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "d:",7fb0f8c8,00000400) ret=0100503a ... I know this affects the IE7 and MSI 3.1 installer, but probably more. ------------------ I've seen installers from Microsoft call QueryDosDevice on the whole alphabet and search any returned object name for the substrings "harddisk" and "ramdisk". On Wine they normally won't find any and quit with the following error: "Unable to find a volume for file extraction" QueryDosDevice on Wine returns the filename pointed to by the drive link beneath the dosdevices directory. In a default Wine installation this is ../drive_c. So a simple fix for this problem is to use the a different name for that directory, for example the name used for the first harddisk in the NT object namespace: harddiskvolume1. -Hans Changelog Use directory harddiskvolume1 for mapping drive C instead of drive_c.

March 26, 2006

stir stir stir

by Mike Hearn

Deprived of patch-writing time lately I can do little more than cheer the team on. And of course, take pot-shots at our partners over the wall, the Windows team themselves ;) Hello there if you're reading this! In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team: http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c1… in which the following totally astonishing claim is made: "Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing. Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this? Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is. Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :) thanks -mike

March 26, 2006

Re: Wine/Interix -- The pros and cons.

by Steven Edwards

Hi, In short it wont work. In long see inline. On 3/24/06, Segin <segin2005(a)gmail.com> wrote: > Would Wine load the .dll.so's? Since Interix uses PE for it's native > format (running on Windows, duh), Would Wine load the .dll.so's? Would > it reject them being in PE format and having the 'POSIX Layer' attribute > set, or could we hack on a patch to detect if Wine itself is running in > said layer, and load them if it is? Would that even *work*? And how > about detecting Winelib applications? It might get detected as a regular > Windows app, and ... uh-oh... (let's just say it isn't pretty) Wine should still load its builtin libs first. Your going to need to add some configure magic to detect interix/SFU and get it building. The last time I tried I ran in to conflicts with headers. It seems what Microsoft has for basic types in the POSIX headers does not match what windows has. > There are several obvious pros: You can test Wine almost fully under > Windows without mingling with Windows's native componets. This would > allow for better and faster compatability tests. We could also see what > "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine > developers itself, it could mean a whole new generation of applications > which are half-Unix, half-Windows, if the right holes are found. You can already test any of the pure Win32 Wine dlls if you do a mingw build. Trying to to a port is a good bit of work. A port to SFU has the same problems as a Cygwin port. Your going to have to implement support in ntdll and wineserver for get/setthreadcontext. For simple Win32 apps that can just be stubbed but then you have the harder task of implementing or working around the lack of send/recvmsg. I think there was a hack to emulate it for cygwin but I never got around to testing it so you might be able to come up with a creative solution that will work for both targets. My advice would be to get it working on cygwin first and then port to SFU. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

March 26, 2006

Speed demon: Mozilla 1.7.12 and Wine.

by Segin

This is possibly the best news the Wine development team has recieved since getting Solitare to run on Wine in 1994: Wine and Mozilla are *faster* than IE on native Windows, on the same harware. I am not joking you. I used to have a Windows partition until it was corrupted recently, and my "personalized" Google homepage comes up in 2.31 seconds in IE. Note that Windows is running native (not a VM). Mozilla 1.7.12 in Wine pulls up the same page in under a second. I will continue to test. The only thing that is missing is Java support, and most of us can live without that. It's nice to know that we are mopping the floor with the World's Worst Webbrowser.

March 25, 2006

Re: Page fault xmlspy 2006 wine .9.10

by Eric Pouech

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+ -- Eric Pouech

March 25, 2006

WGL_PBUFFER_LOST_ARB implementation

by Tomas Carnecky

This patch implements 'WGL_PBUFFER_LOST_ARB'. It creates a new field in 'X11DRV_PDEVICE' which is used to store flags (currently only one: X11DRV_FLAG_DAMAGED). This flag indicates that the drawable (PBuffer) is damaged and no longer valid. As soon as the x11 driver receives the GLX_DAMAGED event it calls X11DRV_GLX_Event() which then set the flag. wglQueryPbufferARB() uses ExtEscape() to retrieve this flag and can decide whether the PBuffer is lost or not. This patch depends on one I've sent earlier to the wine-patches mailing list: '[x11drv] Move x11drv ExtEscape() codes to one common header file.'. Please look through this patch and tell me if I've done something horribly wrong or missed an important aspect. I'm very new to wine and I don't know what I am allowed to touch and what not. tom

March 25, 2006

Re: Winetools -> wine doors

by Segin

Also note that most of Winetools prior usefullness was killed when we killed ~/.wine/config Dr J A Gow wrote: > Karl Lattimer wrote: > >> Fair point that it has been useful to you, it has been useful to me >> also. Here's what I see. >> >> * An over complicated bash script, with way too many difficult to >> maintain parts >> * An inflexible application, which can only have new applications added >> to it by the maintainer >> * A terrible confusing GUI >> >> My choice of words was strong I admit, but I think this application is >> ready to go to silicone heaven. > > > Your points are quite true. I was only really pointing out that something > that enables individuals to Get Work Done Quickly (however bad the tool > might be technically) is of considerable value. That, of course, does not > mean that the tool shouldn't be replaced when it starts to suffer from > 'bit-rot'. But let's not completely can it until a viable replacement is > available otherwise we could undermine the perceived 'usefulness' of Wine > when it comes to a necessary rush-job. > > I should add I don't use Winetools as a matter of course - I used it once > to get me out of a hole, and it did! > >> What I am proposing and indeed working on is; >> >> * An appdb integrated application manager >> * A clean UI which fits with gnome HIG >> * A flexible, expandable, small and simple application which is easily >> maintained but can do everything winetools does. > > > This sounds like an excellent idea. > >> >> Maybe nostalgia will keep some people using winetools, or trying to fix >> something which is broken. Or maybe a couple people could lend a hand >> with this and we could have something better ;) >> >> K, >> >> >> > > > >

March 25, 2006

Re: Wine/Interix -- The pros and cons.

by Kuba Ober

On Saturday 25 March 2006 14:04, you wrote: > I have hands-on experience with it. I know that if you get the > abandonware X11 server, XDeep/32, and symlink the xdeep40.exe file (i > think that's it) to /usr/X11R6/bin/X (/dev/fs/C/xdeep32/bin/xdeep40.exe > -> /usr/X11R6/bin/X) you can use startx... > > And by the way, I use NetBSD pkgsrc on Interix (which is a supported > platform per the NetBSD pkgsrc site.) Interesting! One only hopes it's not bait-and-switch on MS's side. Cheers, Kuba

March 25, 2006

Re: Winetools -> wine doors

by Karl Lattimer

On Sat, 2006-03-25 at 14:02 -0500, Segin wrote: > Also note that most of Winetools prior usefullness was killed when we > killed ~/.wine/config Now we rely on winereg? is that correct (I should know this ;) I've been making some steady progress today, managed to get CD auto detection working (from some freevo code) and I've added basic SAX parsing for package lists. I hope I can get a base shell working soon. 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. Some clarification i need is on how wine executes applications. AFAIK this is how it works. wine runs the wineserver and wine-pthread and when the application exits cleanly wineserver goes too, otherwise winedbg starts. I have code waiting for wine exit (similar to winetools) which currently works but I'd like to make sure i'm on the right track ;) I'd also like to know what is the best way to kill a wine process and when it should be killed (currently I'm waiting indefinitely for wine to exit, then waiting 5 minutes on the wineserver). When is the best time to use wineboot? What purpose does it serve, what can it break. Cheers, K,

March 25, 2006

Re: What happened to the Fedora packages?

by Kuba Ober

On Thursday 23 March 2006 19:07, Neal Gompa wrote: > I just decided to use the yum packages suggested earlier... and yes, it > fails, then crashes! anyway, thanks! You might be speaking chinese as well. Care to post actual messages? Being vague when asking for help is rude. Cheers, Kuba

March 25, 2006

Re: What happened to the Fedora packages?

by Kuba Ober

> Compiling WINE always crashes my computer, so I prefer to > use the RPMs... You'd better figure out why compilation crashes your computer. It might be a hardware or kernel problem. Anyway, you first have to get such compilations to run stably, only then try actually running wine. Software builds are good system stress tests (or turn out to be). Cheers, Kuba

March 25, 2006

Re: Wine/Interix -- The pros and cons.

by Kuba Ober

On Friday 24 March 2006 22:26, Segin wrote: > I was thinking about running Wine on Interix (the POSIX layer of > Microsoft's Services for Unix). There are a few apparent unknows: [. . .] IIRC the POSIX layer that M$ implemented was there just to get government contracts and it's supposedly not very useful for real development. Does anyone have some hands-on experience with it? Another thing is that you'd need an X server running on Windows to get anything graphical. Not that it's a problem, just an observation. Cheers, Kuba

March 25, 2006

Bug 4806 - CpuDetect.dll missing (need help)

by Tom Spear

When trying to load up various apps, users are having problems with wine causing the program to say that certain files are missing, even when run from within the program directory (where the file that is supposedly missing is).. The problem has been narrowed down to this patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html ..It seems to be that wine thinks the header is bigger than the file to be read. Louis Lenders and Tony Lambregts have narrowed it down to one line, which commenting out causes the programs to work.. After they added some traces to the code, it appears that the st.st_size variable is correct but the header_size variable is incorrect.. My question is where is wine pulling the header size from to fill into that variable to have given it the value that it is getting? And is there a simple (as well as proper) solution for this? Tom

March 25, 2006