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 30, 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 30, 2006