Re: Translating to winehq.org
Jeremy Newman wrote: This will be a challenge, but luckily most of the content does not change often. True, but the site will probably get a good once over in the coming weeks as we get around to reading it. Expect minor patches. Thanks, Scott Ritchie
Re: winmm: Sign-compare warning fix (Resend)
On Fri Dec 12 0:58 , Michael Stefaniuc sent: Andrew Talbot wrote: What is wrong with this patch, please? If I may venture a guess: You have replaced a nice and concise for loop into and ugly 4 line while loop. bye michael Hi Michael, Ugly? Andrew Koenig and Barbara Moo show a similar construct in their book Accelerated C++. ;) But how would you then fix the sign-compare violation, or would you just let this one go? -- Andy.
Re: winmm: Sign-compare warning fix (Resend)
Ugly? Andrew Koenig and Barbara Moo show a similar construct in their book Accelerated C++. ;) A little off topic, but this is on page 19, before for loops are introduced. If you look ahead to page 27 (2.5.2) that example is redone with a for loop. Chris.
Re: winmm: Sign-compare warning fix (Resend)
Andrew Talbot wrote:
On Fri Dec 12 0:58 , Michael Stefaniuc sent:
Andrew Talbot wrote:
What is wrong with this patch, please?
If I may venture a guess: You have replaced a nice and concise for loop
into and ugly 4 line while loop.
Ugly? Andrew Koenig and Barbara Moo show a similar construct in their book
Accelerated C++. ;)
Too bad that I'm not reading that book at the moment but
The Practice of Programming and that book disagrees with that ;)
But how would you then fix the sign-compare violation, or would you just let
this
one go?
I had to look twice as the initial warning was in a for loop above:
Either leave it as is for now as the warning is bogus or at least add
the decrement directly to the while like this:
i = sizeof(MMDrvs) / sizeof(MMDrvs[0]);
while (i-- 0)
{
MMDRV_ExitPerType(MMDrvs[i], MMDRV_AUX);
Though the later would still have to pass Alexandre's review.
bye
michael
Re: kernel32: Remove _hread16() as it is not used. Move _hwrite16() next to the other related functions.
Francois Gouget fgou...@free.fr writes: The krnl386.exe.spec file points _hread() to WIN16_hread() so that this _hread16() function is unused. The naming of these implementations is a bit inconsistent but it may not be worth a patch to fix it (but if it is I'll gladly send one). The reason for the inconsistent naming is that the xxx16 functions are 16-bit implementations usable from normal Wine code, while the WIN16_xxx ones have different calling sequences and are for use by the relay code only. That's why we had both WIN16_hread and hread16. Of course at this point we shouldn't be calling 16-bit functions from Wine code, so it no longer matters. -- Alexandre Julliard julli...@winehq.org
Re: A nicer icon for shell32 folder
Why not have the icons in shell32 and others link to the GNOME/KDE icon set settings?d On Thu, Dec 11, 2008 at 11:00 AM, Marcel Partap mpar...@gmx.net wrote: That's not the only reason: automatically scaling them down to small (e.g. 16x16) sizes results in very pixelated images. At such small sizes hand-drawn images often look best. --Juan True, but from my experience creating folder icons (see attached file, hereby under the public domain) very tiny changes in size and line widths can distinctly change the exported result. This is perfectly exemplified by the fact i could not reproduce the attached PNGs, which were created from the same unchanged SVG (..maybe because i updated my Inkscape SVN). Anyways keep iterating small changes Hervy and you might get a usable export. -- Obstacles are those frightful things you see when you take your eyes off your goal. -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future
Re: winmm: Sign-compare warning fix (Resend)
On Fri Dec 12 10:29 , Michael Stefaniuc mstef...@redhat.com sent:
Andrew Talbot wrote:
But how would you then fix the sign-compare violation, or would you just let
this
one go?
I had to look twice as the initial warning was in a for loop above:
Either leave it as is for now as the warning is bogus or at least add
the decrement directly to the while like this:
i = sizeof(MMDrvs) / sizeof(MMDrvs[0]);
while (i-- 0)
{
MMDRV_ExitPerType(MMDrvs[i], MMDRV_AUX);
Though the later would still have to pass Alexandre's review.
bye
michael
Come to think of it, I believe Alexandre did improve one of my earlier efforts
in
this latter way, so I might retry with the slimmer while loop you suggest.
Thanks, Michael (and Chris and Peter)!
--
Andy.
Re: mshtml: Add some interfaces in mshtml.idl (try 2) (resend)
On Thursday 11 December 2008 17:28:03 Konstantin Kondratyuk wrote: Add: ILineInfo IDisplayPointer IDisplayPointer IHTMLComputedStyle IDisplayServices IMarkupServices This patch is wrong. Please, ignore it. -- Best regards, Konstantin Kondratyuk.
RE: winmm: Sign-compare warning fix (Resend)
But how would you then fix the sign-compare violation, or would you just let this one go? If you want it to be more compact: unsigned int i; ... for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) Tested? No. Readable? Don't ask me... :-) Cheers, Peter
Re: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs
Am Friday 12 December 2008 01:42 schrieb ricardo filipe: --- a/dlls/setupapi/setupapi.spec +++ b/dlls/setupapi/setupapi.spec @@ -53,7 +53,7 @@ @ stub CM_Free_Res_Des @ stub CM_Free_Res_Des_Ex @ stub CM_Free_Res_Des_Handle -@ stub CM_Get_Child +@ stdcall CM_Get_Child(ptr long long) @ stub CM_Get_Child_Ex @ stub CM_Get_Class_Key_NameA @ stub CM_Get_Class_Key_NameW this part is wrong here as it is in the second patch too .. Stefan
RE: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs
thanks, i thought i had corrected the patches before sending... seems not... i'll resend. From: stefan.leich...@camline.com To: wine-devel@winehq.org; ricardo_barb...@hotmail.com Subject: Re: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs Date: Fri, 12 Dec 2008 16:04:36 +0100 Am Friday 12 December 2008 01:42 schrieb ricardo filipe: --- a/dlls/setupapi/setupapi.spec +++ b/dlls/setupapi/setupapi.spec @@ -53,7 +53,7 @@ @ stub CM_Free_Res_Des @ stub CM_Free_Res_Des_Ex @ stub CM_Free_Res_Des_Handle -@ stub CM_Get_Child +@ stdcall CM_Get_Child(ptr long long) @ stub CM_Get_Child_Ex @ stub CM_Get_Class_Key_NameA @ stub CM_Get_Class_Key_NameW this part is wrong here as it is in the second patch too .. Stefan _ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack
RE: winmm: Sign-compare warning fix (Resend)
Peter Rosin p...@axentia.se at: Dec 12, 2008 4:27 AM wrote about: RE: winmm: Sign-compare warning fix (Resend) But how would you then fix the sign-compare violation, or would you just let this one go? If you want it to be more compact: unsigned int i; ... for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) Tested? No. Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? The real question is why convert a for loop to a while loop? My guess is to avoid a possible empty or zero length foo. Of course, there should be a check before this for an empty or misformed foo[0] avoiding a divide by zero error. James McKenzie
RE: winmm: Sign-compare warning fix (Resend)
Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: unsigned int i; ... for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) Tested? No. Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? There is no C++ construct in that code. Still i-- would do the same and is more idiomatic C. The real question is why convert a for loop to a while loop? After the last iteration, the --i (or i--) overflows. In a for loop, the step statement (the third statement in the loop head) is always executed before the test (the second statement in the loop head), so there is no way to prevent the overflow. While this is not a problem per se, as overflow of unsigned variables is well-defined, testing for overflow just happended tends to be more confusing to the readers than testing for is at the end. If you use a while loop instead, you can arrange the test to be executed *before* the step is performed, so you have to abort on i == 0 just finished insted of i == ~0U is next, the former being easier to understand. My guess is to avoid a possible empty or zero length foo. Even in for loops, the tests is executed before the first iteration, so it would work in the for loop as well. Of course, there should be a check before this for an empty or misformed foo[0] avoiding a divide by zero error. Sorry for the strong language: Either you need to take a second look at the code we talk about or a second look at an medium-level C textbook. sizeof is a built-in operator that returns the amount of memory storage the object foo[0] directly occupies. If foo[0] is a pointer, it is the size of a pointer, not the size of the allocated memory foo[0] might point to. As there are no objects of size zero in C or C++, sizeof(foo[0]) can *never* be zero. The idiom used here sizeof(foo) / sizeof(foo[0]) yields the size of an array foo. It breaks *horribly*[1] if foo is not an array, but a pointer. If foo denotes an array, sizeof foo returns the size of the whole array, which is the size per element multiplied by the number of elements. The size of a single element is calculated by sizeof(foo[anything]), anything being zero by convention. Regards, Michael Karcher 1: breaks horribly means in that case: Returns nonsense (if foo[0] is a structure, usually zero), no compile-time error, no obvious error in that line (one needs the context to find it, and most people just assume foo to be an array reading that line).
RE: winmm: Sign-compare warning fix (Resend)
Michael Karcher w...@mkarcher.dialup.fu-berlin.de at: Dec 12, 2008 9:23 AM (MST) wrote about: RE: winmm: Sign-compare warning fix (Resend) Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: unsigned int i; ... for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) Tested? No. Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? There is no C++ construct in that code. Still i-- would do the same and is more idiomatic C. The real question is why convert a for loop to a while loop? After the last iteration, the --i (or i--) overflows. In a for loop, the step statement (the third statement in the loop head) is always executed before the test (the second statement in the loop head), so there is no way to prevent the overflow. While this is not a problem per se, as overflow of unsigned variables is well-defined, testing for overflow just happended tends to be more confusing to the readers than testing for is at the end. If you use a while loop instead, you can arrange the test to be executed *before* the step is performed, so you have to abort on i == 0 just finished insted of i == ~0U is next, the former being easier to understand. This is a definite improvement. Glad you caught it and thank you for the lesson in the use of structures vice arrays. I'll take a close look at the code and your change this weekend. I was caught by the use of sizeof(array[0]) vice sizeof(struct[0]), which do yeild different results. James McKenzie
Serial Fixes
Hello Wolfgang, nice findings and fixes around the serial driver! What application do you test against? Bye -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Canonical and wine
On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein shackl...@gmail.com wrote: One problem you missed is a sensible way to keep multiple versions of Wine on the system as needed. This could get extremely messy; the best solution would be to keep a database of all known-working Wine versions for all supported applications, and install only the minimum set required to get those applications that you install working. With each new version of Wine and application, the set will likely change, and you'd need some wrapper script in order to know which installed version of Wine to run for a particular application. Not to mention the additional manpower required to maintain the database, and any additional things required (like winetricks stuff that's required for some versions of wine but not others). Yes the wrapper script is implied by the deb package/template. I think each application package should have a hard dep on a given Wine version and the launcher script should reflect that. Then it would be up to the package maintainer to update his package for newer versions of Wine. If you did it right you could make it compatible across multiple Wine versions and just use the deb/rpm database to check to make sure version numbers are high enough and or blacklist known bad ones. Its not that hard to keep seperate versions of Wine isolated. You could have something like /usr/local/lib/wine-1.0.1 /usr/local/lib/wine-1.2.0 etc And use the variables Wine already supports to point to different Wine binaries and Wineserver versions. CodeWeavers already does this to allow CrossOver and Wine to co-exist on the same system. As far as the database resources, that information is already there in appdb. Its just a matter of getting it in the right framework to be automagically packaged. Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages. Maybe we are talking about some sort of xml importing data exchange tool to generate the deb specs and the Wine templates. I am not sure, I've not really thought the automation part through enough. That can really come later once some proof of concept debs/rpms are built for IE and Photoshop. I think the first step is to take what we've already got with IE6 in Winetricks. Find a stable version of Wine it works well with and attempt to make a package for it based upon all of the ideas already covered here. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Canonical and wine
On Fri, Dec 12, 2008 at 11:52 AM, Steven Edwards winehac...@gmail.com wrote: Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages. I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man. I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless. -- -Austin
Re: Canonical and wine
On Fri, Dec 12, 2008 at 1:34 PM, Austin English austinengl...@gmail.com wrote: I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man. I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless. It might be possible to have some sort of certification system setup whereby the maintainer of the appdb entry signs off on the information being correct. I could see a fit for some sort of tool being developed to automate this whole process for apps that are certified but this is thinking too far ahead. When I get some time I'll see if I can put together a proof of concept IE deb package. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Canonical and wine
On Fri, Dec 12, 2008 at 12:59 PM, Steven Edwards winehac...@gmail.com wrote: On Fri, Dec 12, 2008 at 1:34 PM, Austin English austinengl...@gmail.com wrote: I think you have a bit too much faith in the AppDB. If I had a nickel for every times I've seen platinum and gold ratings for apps that had dozens of native dlls or complicated scripts to work around wine bugs, I'd be a much richer man. I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless. It might be possible to have some sort of certification system setup whereby the maintainer of the appdb entry signs off on the information being correct. I could see a fit for some sort of tool being developed to automate this whole process for apps that are certified but this is thinking too far ahead. When I get some time I'll see if I can put together a proof of concept IE deb package. Many times the maintainers are the ones giving those falsely inflated ratings. I could see this being useful for really popular apps, and in a small enough number to where a developer or AppDB admin could sign off on it. -- -Austin
Re: Canonical and wine
2008/12/13 Steven Edwards winehac...@gmail.com: On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein shackl...@gmail.com wrote: Yes the wrapper script is implied by the deb package/template. I think each application package should have a hard dep on a given Wine version and the launcher script should reflect that. Then it would be up to the package maintainer to update his package for newer versions of Wine. If you did it right you could make it compatible across multiple Wine versions and just use the deb/rpm database to check to make sure version numbers are high enough and or blacklist known bad ones. If you did it wrong, you could end up with one copy of Wine per application, and have overlap in application support (e.g. foo works in 1.0.1 and 1.1.10, but has a hard dep on 1.0.1, bar has hard dep on 1.1.10). Its not that hard to keep seperate versions of Wine isolated. You could have something like /usr/local/lib/wine-1.0.1 /usr/local/lib/wine-1.2.0 etc And use the variables Wine already supports to point to different Wine binaries and Wineserver versions. CodeWeavers already does this to allow CrossOver and Wine to co-exist on the same system. I did this sort of thing myself with a wrapper script I called vineyard. I never made a big deal of it because: 1) Putting multiple versions of wine in /usr/local/wine* or /usr/wine* is ugly 2) Ideally, we don't need to have multiple concurrent Wine versions, and if I found out what apps I used to run using vineyard, I'd likely find that I only need 1.1.10 to run them all now (I know for a fact that one of them works reasonably well now) As far as the database resources, that information is already there in appdb. It's already been said before, but appdb can be hideously inaccurate. Its just a matter of getting it in the right framework to be automagically packaged. Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages. I would object to any system like what is being proposed here that doesn't have a full version compatibility database attached and some algorithm to calculate the minimum set required for your applications. Perhaps automagic appdb info would be a good start, but have the system prefer certified data by trusted testers. The biggest problem with maintaining a compatibility database is the manpower and resources required. Every time a new version of the application comes out, full range of Wine version testing would be required for a quality database. Even the idea of certifying specific appdb entries will take a lot of resources and manpower. I think the first step is to take what we've already got with IE6 in Winetricks. Find a stable version of Wine it works well with and attempt to make a package for it based upon all of the ideas already covered here. I just thought - it's not just a problem of maintaining concurrent Wines on end-user systems, it's also a problem of maintaining concurrent Wine versions in the central repositories. You wouldn't be able to use the current Wine packages because they install in /usr/, not in /usr/wine-version. And unless you do something like directly accessing older archives and manually installing (so that it's outside high-level package management), each version of Wine in the repository would need its own package *name*! This all sounds like a lot of work to me, but if people are willing to put in the time and effort to do it *properly*, it does have its merits. But I have to ask, what exactly is this system going to replace? Current equivalent method is: 1) Try your app with Wine 2) If it doesn't work, check appdb for Wine version compatibility 3) Follow any instructions on the appdb page, such as reg settings/hacks, DLL overrides, specific Wine versions 4) If it works, yay for you This proposal of packages for proprietary Windows software follows these steps, then adds a step 5) Create a package based on what you've found that automates step 3. I argue that a more correct way to deal with this is education of newbies.
Re: Canonical and wine
Am 13.12.2008 um 01:12 schrieb Ben Klein: But I have to ask, what exactly is this system going to replace? Current equivalent method is: 1) Try your app with Wine 2) If it doesn't work, check appdb for Wine version compatibility 3) Follow any instructions on the appdb page, such as reg settings/hacks, DLL overrides, specific Wine versions 4) If it works, yay for you This proposal of packages for proprietary Windows software follows these steps, then adds a step 5) Create a package based on what you've found that automates step 3. I argue that a more correct way to deal with this is education of newbies. As far as I followed the discussion, you'd replace 1) to 3). The one simple rule you'd have to teach people is Before installing Windows software, install the appropriate compatibility package. Alternatively, if you want to have something like a default Wine package, teach them: If your app doesn't work, look for a compatibility package. IMHO, the former is the better, because it's more consistent. You could name the packages like Wine for Adobe applications to avoid thousands of new packages. Also, doesn't work is a weak description, as non-working features might not be noticed by the user immediately. Third, it's likely tricky to replace Wine with a different version of Wine with the app already installed along other apps on a drive_c. BTW, how would you interact between different Windows apps running on different versions of Wine? MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
