Re: [Fwd: Wine-Wiki.org]
Francois Gouget wrote: On Thu, 27 Jan 2005 [EMAIL PROTECTED] wrote: Wine's release cycle is simply irrelevant to the Application Maintainer's Guide. No, it is not important to you. To me its about what is resonable to ask a maintainer to do. At some point in time we will be stable and we will need these guys to ensure that their application works from one release to the next. In anticipation of that time I tried to see what we could do today. I know that your responce is going to go something like this. So I will stop banging my head for now. -- Tony Lambregts Francois Gouget wrote: > > That the problem: a "Stable Wine release" has been six months away since > 1998 and even before. But we still don't have one, have no idea when > there will be one and thus we should not do stuff that will only makes > sense once we will have a stable release and are just confusing and > meaningless until then.
Re: unicode "tables"
On Fri, 2005-01-28 at 23:47 +0800, Dmitry Timoshkov wrote: > "Mike McCormack" <[EMAIL PROTECTED]> wrote: > > > Jonathan Wilson wrote: > > > I remember some people talking about some kind of "unicode tables" that > > > WINE has but that dont match with the MS implementation. > > > What are the tables for? > > > And what API call(s) are involved? > > > > StringCompareA/W and related functions won't do the exactly the same > > thing as Windows, as Wine uses standard Unicode collation tables. > > Actually everything else under libs/unicode has lots of differences > with microsoft's implementation. Just so you know, Samba has and uses the Microsoft tables, extracted (in short) over the network by performing operations that cause the Microsoft servers to use those tables. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: MSVCRT: Re-implement *printf
On Fri, 28 Jan 2005 12:48:12 +, Aneurin Price <[EMAIL PROTECTED]> wrote: > Changelog: > > > Re-implement all *printf functions in msvcrt.dll, according to > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp > > > > and descriptions of appropriate functions. > > This should fix, among other things, bugs 321 and 2075. > > > > Nobody has any comments about this? > > Sorry for being late at responding. I took a look at it finally like a week ago. You can definately break up the patch. I'd say make the moving of the functions from file.c into printf.c a seperate patch, the last one really. It's extra noise right now. You could also handle the wide-char printf changes seperate as well as changes to the fprintfish functions. Maybe if you do this, you can migrate printf in steps. wide-char printf and fprintf's already work for what they do, so we can impliment the standard printf first, test it out itself and then moving in the other patches should be dead simple. I'm not sure 100% on this, because... I've never done this before! But since I've been studying this for some time I think I can least make the suggestion =). Jesse
Re: [IWineD3d + d3d9] bogus query implemetation
While we're being picky about silly details, normal > Wine code style is to > have a space between the comment markers and the > comment, ie > > /* foo */ > > not > > /*foo*/ > > thanks -mike > > opps, missed this in v3, I'll send up a incremental with cosmetics in later, and try to make sure everything else conforms a bit better in feature. I've got another few days worth of patches ahead, so I expect there will be a few more mistakes and non standards bits coming up until I get used to breaking patches properly. ___ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com
Re: Slick build output
Vincent Béron wrote: Le ven 28/01/2005 à 12:22, Robert Shearman a écrit : [snip] write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used It doesn't give the path, so that approach is useless except when building one directory on its own. It's not like there are 10 write_msft.c files in the Wine source, so it's not useless. I was going to do an example with regsvr.c, but I thought people would get the point. Even if find finds multiple instances of a similarly named file, it's usually pretty easy to find the originating file of a warning. I prefer to leave the gambling at the casino. Rob
Re: Slick build output
Le ven 28/01/2005 à 12:22, Robert Shearman a écrit : [snip] > write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used > write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used > write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used > > It doesn't give the path, so that approach is useless except when > building one directory on its own. It's not like there are 10 write_msft.c files in the Wine source, so it's not useless. Even if find finds multiple instances of a similarly named file, it's usually pretty easy to find the originating file of a warning. Vincent
Re: MSVCRT: Re-implement *printf
Hi Aneurin, > Nobody has any comments about this? Well, I held off thinking I'd give Alexandre a chance to chime in. As it's a large patch, I knew it could take a while. But since he hasn't.. My advice isn't going to be as specific as it has been in the past. You've obviously done a lot on this, and it looks like useful and well-done work. A couple tips to improve its chances then: 1. Write some test cases. For example, in the code you comment: /* Further size specifiers are swallowed; this isn't specified, but was determined from testing. * Thus "ll", for example, does not mean "long long" (I64 should be used instead), but "long" */ Writing a test case that checks this is better than commenting the code, because it really ensures future changes won't break it. Generally, test cases help demonstrate the correctness of the patch (and the incorrectness of what's already there.) Once you're written one, they get pretty simple to do. 2. I'm troubled a bit by the memory allocation. It seems as though it should be possible to output characters or formatted output one at a time, keeping track of where you are in the format string and how many characters you are allowed to output. I realize it's a bit difficult since you may be outputting to either a file pointer or to a buffer, but modulo that complication you should be able to avoid allocating temporary buffers. I know, somewhere in the FAQ it says something about correctness before efficiency, but this bit of inefficiency seems pretty avoidable ;) Hope that helps, --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Slick build output
Hi Jason, --- Jason But <[EMAIL PROTECTED]> wrote: > This patch doesn't do the complete job, instead only produces output for the > compile (gcc) stages. In fact, (make install) will produce no output at all! > > If people think this is a good idea, simple extensions will lead to complete > output, just add the necessary > > $(NICE_ECHO) "whatever" > > to the proper places in each Make*.in file > > I am willing to do this if it is deemed to be good. I for one like the quite output during builds that the kernel has. Send a patch...maybe julliard will accept it. Thanks Steven __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Re: v2.: [IWineD3d + d3d9] bogus query implemetation
Hi again Oliver,
> this should be better.
Yeah, but this function is still borked, I think:
+HRESULT WINAPI IWineD3DDeviceImpl_CreateQuery(IWineD3DDevice *iface,
D3DQUERYTYPE Type, IWineD3DQuery** ppQuery){
+IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
+
+if(NULL == ppQuery){
+/*Just a check to see if we support this type of query*/
+HRESULT hr = D3DERR_NOTAVAILABLE;
+/*Lie and say everything is good (we can return ok fake data from
a stub)*/
+switch(Type){
+case WINED3DQUERYTYPE_VCACHE:
+hr = D3D_OK;
+case WINED3DQUERYTYPE_RESOURCEMANAGER:
+hr = D3D_OK;
(a bunch more)
+default:
+FIXME("(%p) Unhandled query type %d\n",This , Type);
+}
Do you mean to print a fixme for every one? If so, why not just do it
once before or after the switch? Or if you don't, something like this
would be better:
+switch(Type){
+case WINED3DQUERYTYPE_VCACHE:
+case WINED3DQUERYTYPE_RESOURCEMANAGER:
(all the other supported ones)
+hr = D3D_OK;
+break;
+default:
+FIXME("(%p) Unhandled query type %d\n",This , Type);
+}
Notice the added break. Also, for conciseness, I wouldn't duplicate the
hr = D3D_OK assignment for each supported type; I'd just let all the
supported ones fall through to one assignment statement, like I show here.
--Juan
__
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
Re: Can winedbg --auto backtrace all threads?
On Fri, 28 Jan 2005 13:09:26 -0800, Michael Ost wrote: > PS: thanks for that 'bt all' command. It's not in the winedbg man page > and will save me a lot of typing when I use winedbg in the future. Correct, it is not. That's because I suck. If you want to submit a patch for that then great. BTW you can use something like wine --auto --command 'bt all' which might work. thanks -mike
Re: [IWineD3d + d3d9] bogus query implemetation
On Fri, 28 Jan 2005 11:39:53 -0800, Juan Lang wrote: > +/*Just a check to see if we support this type of query*/ > +HRESULT hr = D3DERR_NOTAVAILABLE; While we're being picky about silly details, normal Wine code style is to have a space between the comment markers and the comment, ie /* foo */ not /*foo*/ thanks -mike
Re: Can winedbg --auto backtrace all threads?
On Fri, 2005-01-28 at 12:58, Eric Pouech wrote: > IMO, the cleanest way would be to add an option (like the --command in gdb) > which would execute commands out of a file (almost everything is in place, > you > just need to pass the name of the file in the call to parser() in winedbg.c). > Then, set up the aedebug registry to something where you execute the proper > commands for your specific settings OK. I'll take a look at it. So to mirror --auto's output, but include a backtrace of all threads, my debugger commands file would be: info reg info stack info share bt all quit Is that right? ... mo PS: thanks for that 'bt all' command. It's not in the winedbg man page and will save me a lot of typing when I use winedbg in the future.
Re: Can winedbg --auto backtrace all threads?
Michael Ost a Ãcrit : On Fri, 2005-01-28 at 12:13, Eric Pouech wrote: Michael Ost a Ãcrit : In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. don't use the --auto flag and use the 'bt all' command at the prompt A+ Well, that won't work for us. We need --auto. There isn't a console or prompt in this setup. The program is auto-started by X. So I guess I could look through the 'bt all' code and do something similar in response to, say, --auto-all on the command line...? actually, there's actually a (badly hacked) --command option to winedbg to pass commands from winedbg's arguments so you should set the aedebug key to something like winedbg --command bt\ all HTH A+ -- Eric Pouech
Re: Q: porting driver for USB scanner - where to start?
> Interfacing directly with the scanner might work using Wine's brand new > and very incomplete USB interface (I believe part of it is in setupapi) > but that would probably be more code and you would still end up writing > what is essentially a driver. Nope. On "client" side it would be just the regular windows application + its usb driver. On wine side, it would be the WDM hooks to forward usb requests and replies to libusb. I presume that a good starting point would be to have a look at ndiswrapper.sourceforge.net. They implement USB WDM (amongst others) from scratch, so maybe even the code would be compatible with wine (dunno about licensing, though). > In other words in either case you will > probably need the hardware specifications. Hardware specs are unexistent for most of today's scanner hardware. For reasons known to them, the manufacturers won't ever release them. I.e. good luck if you feel like getting the specs. I presume that everything that wine needs could be implemented using libusb. Just forward the libusb functionality over via the WDM to clients running in wine. That's the only sensible approach I see. Kuba
Re: Can winedbg --auto backtrace all threads?
Michael Ost a Ãcrit : On Fri, 2005-01-28 at 12:13, Eric Pouech wrote: Michael Ost a Ãcrit : In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. don't use the --auto flag and use the 'bt all' command at the prompt A+ Well, that won't work for us. We need --auto. There isn't a console or prompt in this setup. The program is auto-started by X. So I guess I could look through the 'bt all' code and do something similar in response to, say, --auto-all on the command line...? IMO, the cleanest way would be to add an option (like the --command in gdb) which would execute commands out of a file (almost everything is in place, you just need to pass the name of the file in the call to parser() in winedbg.c). Then, set up the aedebug registry to something where you execute the proper commands for your specific settings A+ -- Eric Pouech
Re: Can winedbg --auto backtrace all threads?
On Fri, 2005-01-28 at 12:13, Eric Pouech wrote: > Michael Ost a Ãcrit : > > In order to help track down sporadic runtime crashes in our testing > > process, I have turned on winedbg --auto when wine handles exceptions > > via the AeDebug registry entry. > don't use the --auto flag and use the 'bt all' command at the prompt > A+ Well, that won't work for us. We need --auto. There isn't a console or prompt in this setup. The program is auto-started by X. So I guess I could look through the 'bt all' code and do something similar in response to, say, --auto-all on the command line...? - mo
Re: Can winedbg --auto backtrace all threads?
Michael Ost a écrit : Is there a way to have winedbg --auto do a backtrace of all the threads in an app at exception time? In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. This is working pretty well except that often winedbg does a backtrace on a thread that I know is not the problem. If I could see a backtrace of all the threads --- lots of data, I know --- the tool might be more useful. Is this already possible? How about advisable %) ? Or must I patch winedbg to do it? Sometimes winedbg appears to hang when handling the exception, or at least doesn't print out any information. When could this happen? Is there something I could do to improve winedbg's chances of working? Cheers... mo PS: our system is using wine-20040914 don't use the --auto flag and use the 'bt all' command at the prompt A+ -- Eric Pouech
Re: PRESS: run windows viruses with wine ...
David D. Hagood wrote:
On 01/27/2005 03:03 PM, Troy Rollo wrote:
Even if they don't run Outlook Express, with Linux 2.6 there is a
facility to have the kernel recognise foreign executable file formats
and run them by means of another executable. If used to run Wine
executables (and somebody on /. yesterday indicated they had done
this), it makes Windows executables as easy to run as native Linux
executables ("program.exe" works just as well as "wine program.exe" in
such a case).
Yes, but then the kernel will only execute the file IF it has execute
permissions - so when the worm drops BackOriface.exe on your drive and
tries to run it, it won't as it won't have had the +x bit set.
And a worm smart enough to realize it is running under Wine and able to
make the syscall to set the +x bit probably will be smart enough to get
a native executable for the infection.
I see I've stirred up a lot of different opinions and interesting points
regarding this particular topic :)
Anyway - I can see that a few of my statements weren't completely true.
More of my intention was to make it a point that such information
should probably be made more publicly known. I'm well aware that the
status of wine is constantly changing - and that the more windows
applications we are able to run - the more viruses we are also able to
run, however, I have explained the current status of wine's potential
risk of being infected by a virus to more than a few people - and it
appears to be very important information(which it should be) to many
businesses and the like.
I know there is a lot of things currently going on with wine, and such a
task is not a top priority - especially for the developers, however, I'd
be happy to work with someone to put together a summary of this
information that could be put on the site - if it's at all feasible to
do such a thing.
Thank you all who took the time to read my post and reply - I appreciate it.
--Brad DeMorrow
Re: MSVCRT: Re-implement *printf
Changelog: Re-implement all *printf functions in msvcrt.dll, according to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_format_specification_fields_.2d_.printf_and_wprintf_functions.asp and descriptions of appropriate functions. This should fix, among other things, bugs 321 and 2075. Nobody has any comments about this?
Re: [IWineD3d + d3d9] bogus query implemetation
Hi Oliver,
+HRESULT WINAPI IWineD3DDeviceImpl_CreateQuery(IWineD3DDevice *iface,
D3DQUERYTYPE Type, IWineD3DQuery** ppQuery){
+IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
+
+if(NULL == ppQuery){
+/*Just a check to see if we support this type of query*/
+HRESULT hr = D3DERR_NOTAVAILABLE;
+/*Lie and say everything is good (we can return ok fake data from
a stub)*/
+switch(Type){
+case WINED3DQUERYTYPE_VCACHE:
+hr = D3D_OK;
+case WINED3DQUERYTYPE_RESOURCEMANAGER:
+hr = D3D_OK;
These are missing a break statement. Better style would be to take
advantage of the fallthrough like so:
+switch(Type){
+case WINED3DQUERYTYPE_VCACHE:
+case WINED3DQUERYTYPE_RESOURCEMANAGER:
(all the other WINED3DQUERYTYPE_ cases)
+hr = D3D_OK;
+break;
+struct IWineD3DQueryImpl
+{
+IWineD3DQueryVtbl*lpVtbl;
+DWORD ref; /* Note: Ref counting not required
*/
+IWineD3DDeviceImpl *wineD3DDevice;
+/* IWineD3DQuery fields */
+D3DQUERYTYPE type;
+void *data;
+int dataSize;
+
+
+};
What's with the couple of blank lines in the struct declaration? Yeah, so
I'm picky ;)
+DWORD WINAPI IWineD3DQueryImpl_GetDataSize(IWineD3DQuery* iface){
+IWineD3DQueryImpl *This = (IWineD3DQueryImpl *)iface;
+FIXME("(%p) : stub \n", This);
+int dataSize = 0;
+switch(This->type){
+case WINED3DQUERYTYPE_VCACHE:
+dataSize = sizeof(D3DDEVINFO_VCACHE);
+case WINED3DQUERYTYPE_RESOURCEMANAGER:
Aren't these case statements missing a break statement too?
--Juan
__
Do you Yahoo!?
All your favorites on one personal page Try My Yahoo!
http://my.yahoo.com
Re: Slick build output
Dmitry Timoshkov wrote: "Robert Shearman" <[EMAIL PROTECTED]> wrote: How many developers need to see the command line being passed to gcc? I would argue that it would be more useful if there was a short "[CC] regsvr.c" rather than the multi-line output there is now which makes warnings more difficult to spot. It's always helpful to see full command lines especially after configure or makefile changes. I haven't had any need for that, but on the rare occasion that you might need that there is "make VERBOSE=yes". Personally I usually do 'make 2>build.log' if I want to see warnings or errors. write_msft.c:590: warning: 'ctl2_alloc_importinfo' defined but not used write_msft.c:628: warning: 'ctl2_alloc_importfile' defined but not used write_msft.c:1048: warning: 'ctl2_find_nth_reference' defined but not used It doesn't give the path, so that approach is useless except when building one directory on its own. Rob
Re: Slick build output
"Robert Shearman" <[EMAIL PROTECTED]> wrote: > How many developers need to see the command line being passed to gcc? I > would argue that it would be more useful if there was a short "[CC] > regsvr.c" rather than the multi-line output there is now which makes > warnings more difficult to spot. It's always helpful to see full command lines especially after configure or makefile changes. Personally I usually do 'make 2>build.log' if I want to see warnings or errors. -- Dmitry.
Re: Slick build output
Alexandre Julliard wrote: Jason But <[EMAIL PROTECTED]> writes: Not really related to the actual wine development but more to the make/build/install environment. Remembering the most wine users will not necessarily be developers we should consider improving the output of running (./configure && make) to make it more user friendly. Hopefully it should also be less confronting and confusing to non developers. I think it's a lot more important to make it useful for developers, which is what it is now. How many developers need to see the command line being passed to gcc? I would argue that it would be more useful if there was a short "[CC] regsvr.c" rather than the multi-line output there is now which makes warnings more difficult to spot. Rob
Re: Slick build output
Jason But <[EMAIL PROTECTED]> writes: > Not really related to the actual wine development but more to the > make/build/install environment. > > Remembering the most wine users will not necessarily be developers we should > consider improving the output of running (./configure && make) to make it > more user friendly. Hopefully it should also be less confronting and > confusing to non developers. I think it's a lot more important to make it useful for developers, which is what it is now. Users who get intimidated by the make output should use a binary package. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Slick build output
Jason But wrote: Hello all, Not really related to the actual wine development but more to the make/build/install environment. Remembering the most wine users will not necessarily be developers we should consider improving the output of running (./configure && make) to make it more user friendly. Hopefully it should also be less confronting and confusing to non developers. I propose something similar to the way the Linux kernel currently compiles. The included patch changes make so that a regular make will produce much nicer output while for those die-hards who prefer the original output this can be achieved by executing make VERBOSE=yes I personally prefer the neater output even for development work, the compile output doesn't scroll off the screen as quickly and warnings/errors can be more easily spotted. This patch doesn't do the complete job, instead only produces output for the compile (gcc) stages. In fact, (make install) will produce no output at all! If people think this is a good idea, simple extensions will lead to complete output, just add the necessary $(NICE_ECHO) "whatever" to the proper places in each Make*.in file I am willing to do this if it is deemed to be good. I think this would be really good for the reasons you have already stated. Though, you don't seem to have included the patch that you refer to above. Please continue your work on this! Thanks, Rob
Re: unicode "tables"
"Mike McCormack" <[EMAIL PROTECTED]> wrote: > Jonathan Wilson wrote: > > I remember some people talking about some kind of "unicode tables" that > > WINE has but that dont match with the MS implementation. > > What are the tables for? > > And what API call(s) are involved? > > StringCompareA/W and related functions won't do the exactly the same > thing as Windows, as Wine uses standard Unicode collation tables. Actually everything else under libs/unicode has lots of differences with microsoft's implementation. -- Dmitry.
Re: [WINETEST] How is a visible desktop detected
On Fri, 2005-01-28 at 13:52, Ferenc Wagner wrote:
> Paul Vriens <[EMAIL PROTECTED]> writes:
> Hmm, services use an invisible desktop by default AFAIK.
> It shouldn't matter how you started winrash (the service),
> but how you started winetest itself. If it's started by
> winrash, it runs on an invisible desktop; if you start it,
> it runs on a visible desktop.
How does an invisible desktop explain the fact that when I'm logged in,
I see a Windows Explorer Window being opened by one of the tests
(through winrash).
>
> It's either buggy or misnamed, reality suggests. It was
> invented to account for metafile test failures, which
> require a visible desktop, see eg.
>
> http://test.winehq.org/data/200501271000/nt4_IvanLeo/gdi32:metafile.txt
>
> Now it looks it depends on something else instead, and you
> are in a pretty good position to find out what! I haven't
> got a clue, including this flag was suggested by others.
>
I will try and figure out.
> > What's the criteria for 'running on a visible desktop'?
>
> programs/winetest/main.c (as offered by Dmitry Timoshkov):
>
> static int running_on_visible_desktop ()
> {
> return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE !=
> 0);
> }
Yeah, I should have looked better!
Paul.
Re: unicode "tables"
Jonathan Wilson wrote: I remember some people talking about some kind of "unicode tables" that WINE has but that dont match with the MS implementation. What are the tables for? And what API call(s) are involved? StringCompareA/W and related functions won't do the exactly the same thing as Windows, as Wine uses standard Unicode collation tables. Mike
unicode "tables"
I remember some people talking about some kind of "unicode tables" that WINE has but that dont match with the MS implementation. What are the tables for? And what API call(s) are involved?
Re: [WINETEST] How is a visible desktop detected
Paul Vriens <[EMAIL PROTECTED]> writes:
> I have a Win98/WNT/W2K (on VMWare) and a XP Home
> system. All are running the winrash service. All were
> started when I was logged in but only the W98 and WNT were
> considered running on a visible desktop.
Hmm, services use an invisible desktop by default AFAIK.
It shouldn't matter how you started winrash (the service),
but how you started winetest itself. If it's started by
winrash, it runs on an invisible desktop; if you start it,
it runs on a visible desktop.
It's either buggy or misnamed, reality suggests. It was
invented to account for metafile test failures, which
require a visible desktop, see eg.
http://test.winehq.org/data/200501271000/nt4_IvanLeo/gdi32:metafile.txt
Now it looks it depends on something else instead, and you
are in a pretty good position to find out what! I haven't
got a clue, including this flag was suggested by others.
> What's the criteria for 'running on a visible desktop'?
programs/winetest/main.c (as offered by Dmitry Timoshkov):
static int running_on_visible_desktop ()
{
return (GetWindowLongA (GetDesktopWindow (), GWL_STYLE) & WS_VISIBLE != 0);
}
--
Feri.
Re: X11DRV: Fix to incorrect detection and other bugs of keyboard driver in XKB presence
"Oleh R. Nykyforchyn" <[EMAIL PROTECTED]> writes: > Add alternative (alpha) code to keyboard driver in x11drv that can handle > correct detection and switching of keyboard layout both with and without > XKB extension. Add temporary --enable-xkb feature to configure script > to enable compilation with new code instead of existing one. You really need to get rid of these #ifdefs. If the patch is not working well enough to be enabled by default it won't go in at all. Most likely you need to split it in smaller parts that can be tested and applied separately. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcrt: translate name to locate program
Michael Wu <[EMAIL PROTECTED]> writes: > Would passing an empty path (eg. ".") to the function solve the problem? > SearchPath does a lot of what spawn needs to find the real filename, and I'd > like to avoid duplicating what SearchPath does. If all you need is to append ".exe" calling SearchPath doesn't seem necessary at all. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Re: [winecfg] Show detected audio systems, and offer selection
So in the end we will just keep it all the same for now? Or did I lost you all. Or do we want to follow Chris suggestion by offering a frontend to the driver load order list? Thanks, Paul
Re: [Fwd: Wine-Wiki.org]
Am Donnerstag, 27. Januar 2005 10:30 schrieb Jonathan Ernst: > > > > So these 'supported' applications are no different from any other > > application and the medals mean nothing more than the old rating system. > > They just have 4 levels instead of 6. > > I think having more than 3-4 levels is too much by the way; it's much > too hard to rate an application in such small quality steps. maybe it is a good idea to seperate the installation rating from how well the program runs. I often had problems to install apps that run perfectly if you get past the installer ;-). just my 2 cents ... > > As for application that could regress from gold to another rating, I > think that's not a problem as when a maintainer rates an application he > states what version of Wine he was using (next drop down box after the > maintainer rating). > > I even started to track an history of application ratings for the apps I > maintain: each time I retest an application I update the application > rating AND the history table so that someone can figure out that an > application was working better with an older wine release. > > See here for examples: > http://appdb.winehq.org/appview.php?appId=1533&versionId=2230 > http://appdb.winehq.org/appview.php?appId=2&versionId=764 that's a very good idea and i think the rating system in general should be linked to a wine version otherwise it's relatively useless. I always read the comments to figure out wether the (hopefully good ;-) rating of an app maybe is based on a wine version from 2001. cu, Stefan
Re: [Fwd: Wine-Wiki.org]
On Thu, 27 Jan 2005 [EMAIL PROTECTED] wrote:
Francois Gouget wrote:
[Snip]
* Test the application on a regular basis.
Ideally you would test it once a week so that you can quickly notify the
Wine developers of any regression. The earlier a Wine regression is
noticed, the easier it will be to locate the change that causing it and the
more likely it is to be fixed.
At the very least you should test the application with each Wine
release. If you detect a regression at that point it is likely you will
have to go through regression testing to identify the patch causing the
problem.
Also mention any stability problem.
I thought I was :-)
No, I'm not talking about your concept of stability here. Maybe you
realised that but just in case to make things clear, here I'm asking the
maintainer to mention in his report whether the application tends to
crash or freeze seemingly randomly (if it's a specific action that
causes trouble it would go in the list of things that don't work).
So instead of answering the question you avoid the question entirly.
Wine's release cycle is simply irrelevant to the Application
Maintainer's Guide.
--
Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/
$live{free} || die "";
