December 2008 - Wine-Devel - list.winehq.org

Re: A nicer icon for shell32 folder

by King InuYasha

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 <mpartap(a)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 > > > >

Dec. 12, 2008

RE: winmm: Sign-compare warning fix (Resend)

by Peter Rosin

> 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

Dec. 12, 2008

Re: kernel32: Remove _hread16() as it is not used. Move _hwrite16() next to the other related functions.

by Alexandre Julliard

Francois Gouget <fgouget(a)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 julliard(a)winehq.org

Dec. 12, 2008

Re: winmm: Sign-compare warning fix (Resend)

by Michael Stefaniuc

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

Dec. 12, 2008

Re: winmm: Sign-compare warning fix (Resend)

by Chris Spencer

> 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.

Dec. 12, 2008

Re: winmm: Sign-compare warning fix (Resend)

by Andrew Talbot

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.

Dec. 12, 2008

Re: Translating to winehq.org

by Scott Ritchie

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

Dec. 12, 2008

Re: winmm: Sign-compare warning fix (Resend)

by Michael Stefaniuc

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 > --- > Changelog: > winmm: Sign-compare warning fix. > > diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c > index 794c117..946d0d0 100644 > --- a/dlls/winmm/lolvldrv.c > +++ b/dlls/winmm/lolvldrv.c > @@ -737,7 +737,7 @@ static BOOL MMDRV_ExitPerType(LPWINE_MM_DRIVER lpDrv, UINT type) > */ > void MMDRV_Exit(void) > { > - int i; > + unsigned int i; > TRACE("()\n"); > > for (i = 0; i < sizeof(MM_MLDrvs) / sizeof(MM_MLDrvs[0]); i++) > @@ -753,8 +753,11 @@ void MMDRV_Exit(void) > } > > /* unload driver, in reverse order of loading */ > - for (i = sizeof(MMDrvs) / sizeof(MMDrvs[0]) - 1; i >= 0; i--) > + i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > + while (i > 0) > { > + --i; > + > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_MIXER); > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_MIDIIN); > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Dec. 12, 2008

Re: Canonical and wine

by Ben Klein

2008/12/11 Remco <remco47(a)gmail.com>: > Canonical doesn't want to include Wine, because they are trying to > provide a complete desktop experience. Wine is a necessity for many > people, but Canonical wants to market Ubuntu as the Linux distribution > that works well for normal usage. Including a half-working > Windows-emulator (functionality emulator) doesn't fall within that > mission. It gives the message that Ubuntu on its own isn't ready (true > or not). Why would they want to switch from a good product (Windows) > to an inferior one with spotty support for Windows applications? I agree that Wine should not be a part of *buntu as standard. We have enough problems in #winehq with new users already. So many people think that Wine will "just work" for them, and are annoyed at Wine devs when they discover it doesn't. What Wine needs before being considered as suitable for a distro like *buntu is: 1) Near-completeness so that things "just work" 2) When things don't work, some way for a newbie to fix it easily (with minimal assistance), or 3) Some easy-to-read, attractive basic *nix command line tutorial. "How do I get the console output?" is one question being asked too often by newbies, and the other day someone asked if they should change the "cd /media/cdrom0" command to read "dvd" for their particular installer. I think it's fair to say that all three things in that list will happen somewhere between a long time from now and never. 2008/12/12 Steven Edwards <sedwards(a)bordeauxgroup.com>: > On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote: >> I believe it has been proposed before to have .debs for things like >> Adobe Photoshop which first install Wine (or create a new prefix etc.) >> and then ask for the Photoshop CD; sort of like application specific >> bundlings of Wine. > > This has been the long term plan we've had with Bordeaux. We > ultimately want to give the user the ablity to just do something along > the lines of > > sudo apt-get install photoshopcs > > and have it find the correct version of Wine, if its missing install > that deb, install the photoshopcs deb and then start the install > process. Why does this sound like a bad idea? The first thing that comes to mind is when Wine gets updated, the system's Wine-version/application compatibility list would have to be updated with it. I'm also not too keen on the idea of adding a bunch of packages for proprietary software arbitrarily. Perhaps a separate Wine applications manager would be a solution (and this idea sounds like Cedega/PlayOnLinux)? > There are a few key pieces missing for this to work > well for the end user though. > > 1. Wine Prefix Management > <-- snip --> > /usr/local/wineprefixes for the global prefixes One word: permissions. Current wine refuses to run if its wineprefix is not owned by the current user. Though this problem could be solved by creating a special "wine" user and group for the global prefixes, and su'ing into that user before a global prefix is used, it could get messy to manage when there are local prefixes too. > Also when dealing with things like deb/rpm packages the prefix manager > will need to know how to handle these. It should be relatively simple to have the package call an appropriate script for generating a prefix with a sensible name etc. The problem would come when trying to install Windows software manually, or perhaps a wrapper script/tool could be supplied for this too. > 2. Templates > The ultimate goal is of course that it will just install out of the > box with no dependencies, fonts or wine dlloverride tricks. This is of > course not possible in every case and so we need to take this in to > account. This is PlayOnLinux-type stuff and subject to my earlier comment about when Wine gets updated. > 3. We need some sort of tool like you said that prompts for a CD. Some > sort of autorun.exe like tool. Ubuntu has been working on this so that > a Wine CD is identified and offered to start the setup.exe or > whatever. Its very generic and not very effective. We need a better > way. Remember: it's not safe or *nix-like to automagically run software on media that has just been installed. Fortunately we're talking about on-demand install disc here (install the package, package says "Please insert <application name> install disc"). 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). With this concept, would hacky-patched Wine versions be supported, e.g. the ddraw hack to get Worms Armageddon and Diablo 1 working, or the capabilities hack to get Call of Duty and 3dmark working? My guess is probably not :)

Dec. 11, 2008

RE: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?

by Michael Karcher

Am Donnerstag, den 11.12.2008, 20:13 +0000 schrieb foobarbaz biffblaff: > Unfortunately, I will not be able to use wineg++ for a variety of > political reasons. Too bad. Do you understand that wineg++ is not completely different compiler, but just a 21K binary (stripped) that does the needed option magic to invoke g++ with the right options? It is perfectly OK to use winegcc/wineg++ to link unix libraries into your windows program. It is not possible to generate a library any unix program can just open and use this way, as winelib code needs special startup code. winegcc / wineg++ takes care of it in the final linking step. > Is there anyway, even if it involves some non-standard hacking, to get > the Windows functions defined in > <wine_install_dir>/include/wine/windows to be compiled in a library > that I can directly link to with g++ without using wineg++? The functions are in libraries that g++ can link. These libraries are in /usr{/local}/lib/wine and called foo.dll.so, where foo is the name of the Windows DLL you need. > I mean, wine is all c code right? And it's compiled with the g++ on my > system? The wine build system uses winegcc, which in turn uses gcc. > Has no one ever wanted to do this before? No one ever feeled inclined to duplicate the functionality of winegcc because it is small, quick readily available and just works. I'm sorry that I can't really help you, but I don't understand your motivation to go that way and what problems you are trying to solve. Regards, Michael Karcher

Dec. 11, 2008

Re: Canonical and wine

by Marcus Meissner

> It would be useful to have winetricks distributed in a deb/rpm > package, so that you could install it easily to have it > updated/managed by the package manager. This would provide the core > support for installing applications run on wine via deb/rpm packages > (that would depend on winetricks and wine). Just for the record, the SUSE rpms contain the newest winetricks ;) Ciao, Marcus

Dec. 11, 2008

RE: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?

by foobarbaz biffblaff

Roderick, Thanks for your answer. Unfortunately, I will not be able to use wineg++ for a variety of political reasons. Is there anyway, even if it involves some non-standard hacking, to get the Windows functions defined in <wine_install_dir>/include/wine/windows to be compiled in a library that I can directly link to with g++ without using wineg++? I mean, wine is all c code right? And it's compiled with the g++ on my system? Has no one ever wanted to do this before? Jeff > Date: Thu, 11 Dec 2008 09:32:53 +0100 > From: thunderbird2k(a)gmx.net > Subject: Re: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it? > To: foobarbaz99(a)hotmail.com; wine-devel(a)winehq.org > > > > > Hi, > > > > I have a huge amount of Windows code that I'm porting to Linux. > > > > Wine is turning out to be a read godsend, thank you guys! > > > > Anyway, I've had tons of luck including the directory > > <wine_dir>/include/wine/windows in my include path. All my Windows types are there and > > everything is wonderful. I've even been able to link against the libraries by > > renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ > > command line. > > > > I actually haven't got all my functions defined so I don't know if this > > will actually run yet because the link isn't complete yet. > > > > My first question is whether this will work. Will all my Windows functions > > with function declarations defined in the windows directory and code > > compiled into foo.dll.so actually run? > > > > Second, I see that some of the functions I want to use are actually > > defined by headers in the msvcrt directory. However, this directory contains tons > > of header files that my system (and gcc) also have under /usr/include and > > gcc's own directories. I understand that msvcrt is Windows lib c, but I > > wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to > > gcc, but the number of errors I get is enormous. > > > > It's not the end of the world if I can't use Wine's msvcrt, but if I could > > use it, it would define dozens more functions on which my program relies, > > or if its use was mandatory in order to get the functions implemented in > > foo.dll.so to work, then obviously I wonder how I'm supposed to compile my > > Windows code with Wine to make everything work? > > > > I'm sorry if this is a dumb question. I can't find a way to search the > > wine-devel mailing list other than with google and I can't find anything on > > there or other docs that answer this question, which I'm sure has been asked > > a million times and has a simple answer. > > > > Thank you thank you, > > > > Jeff > > > > _________________________________________________________________ > > Send e-mail faster without improving your typing skills. > > http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_… > > Just compiling your program using g++ won't work as Wine needs to perform a lot of magic. For that reason Wine ships with its own gcc/g++ wrapper programs called winegcc/wineg++ both are mingw compatible. You should build your program using that and it won't have issues linking with wine libraries and it also allows you to link against linux libraries. > > Roderick > -- > Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL > für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a _________________________________________________________________ Suspicious message? There’s an alert for that. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2…

Dec. 11, 2008

Re: website : http://www.winehq.org/site/who gives a 404

by Jeremy Newman

I just put in a redirect for the old URL. I'll go ahead and update the link in that template as well. -Newman Paul Vriens wrote: > Austin English wrote: >> On Thu, Dec 11, 2008 at 1:30 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >>> Hi, >>> >>> Just noticed that the Who is Who page is still referenced >>> (from http://www.winehq.org/acknowledgement for example) as being on >>> winehq.org. Wasn't this moved to the wiki? >>> >>> -- >>> Cheers, >>> >>> Paul. >>> >>> >>> >>> >>> >> Yes: >> >> http://wiki.winehq.org/WhosWho >> >> the acknowledgment page references that wiki page (albeit via a >> redirect from http://www.winehq.org/site/who) >> > Weird, I got a 404 before. Now it's working. >

Dec. 11, 2008

Re: website : http://www.winehq.org/site/who gives a 404

by Paul Vriens

Austin English wrote: > On Thu, Dec 11, 2008 at 1:30 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> Hi, >> >> Just noticed that the Who is Who page is still referenced >> (from http://www.winehq.org/acknowledgement for example) as being on >> winehq.org. Wasn't this moved to the wiki? >> >> -- >> Cheers, >> >> Paul. >> >> >> >> >> > > Yes: > > http://wiki.winehq.org/WhosWho > > the acknowledgment page references that wiki page (albeit via a > redirect from http://www.winehq.org/site/who) > Weird, I got a 404 before. Now it's working. -- Cheers, Paul.

Dec. 11, 2008

Re: website : http://www.winehq.org/site/who gives a 404

by Austin English

On Thu, Dec 11, 2008 at 1:30 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Just noticed that the Who is Who page is still referenced > (from http://www.winehq.org/acknowledgement for example) as being on > winehq.org. Wasn't this moved to the wiki? > > -- > Cheers, > > Paul. > > > > > Yes: http://wiki.winehq.org/WhosWho the acknowledgment page references that wiki page (albeit via a redirect from http://www.winehq.org/site/who) -- -Austin

Dec. 11, 2008

Re: wintrust: Sign-compare warnings fix

by Andrew Talbot

Hi Juan, Juan Lang wrote: > The case I objected to is a curious one. I had a look at K&R's type > promotion rules (2nd edition, section A6.5) and I'm confused what the > compiler is doing here. The if-block is: > > if (pbEncoded[1] + 1 > cbEncoded) > > Rewriting the parenthesized expression as types rather than > variables/values yields: > > unsigned char + int > unsigned int > > According to K&R, the unsigned char should get promoted to unsigned > int (I think), hence: > > unsigned int + int > unsigned int > Actually, I think it is true to say that "integral promotion" is first applied to each operand of the addition, giving: int + int > unsigned int since an int is large enough to hold all possible values of an unsigned char. So the warning is correct, since, in the general case, bad things would happen if the left-hand sum were to produce a negative value. > When an unsigned type and a signed type are together in an expression, > the signed type is promoted to unsigned: > > unsigned int + unsigned int > unsigned int > True, unless the signed operand has more bits than the unsigned one (e.g. on a system with 32-bit intS and 64-bit longS). The "usual arithmetic conversions" are rather complicated, but, in our example, the int sum will get promoted to an unsigned int. So here int > unsigned int becomes unsigned int > unsigned int An example of where this could go wrong is where the comparison (-1 > 0) [should be false] might be evaluated as (UINT_MAX > 0) [always true]. > The promotion of unsigned char to signed/unsigned int is > platform-dependent, so perhaps gcc's analysis assumes it's signed? In > any case, by my reading the gcc warning is simply wrong. I could be > wrong of course. Integral promotion dictates that an anything whose type is of lower rank than an int will be promoted to an int if that is big enough to hold all possible values of the original type, else it will be promoted to an unsigned int. So an unsigned char (always eight bits wide) will always promote to an int (always >= sixteen bits wide). But the promotion of unsigned short to signed/unsigned int will depend on the relative widths involved, so will be platform dependent, as will the usual arithmetic conversion of int to signed/unsigned long. (I hope I managed to get all of that right.) > > Anyway, good luck with your warning-crushing war ;-) > --Juan Thank you and keep up the good work, too! -- Andy.

Dec. 11, 2008

re: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?

by Dan Kegel

Glad Wine is being helpful to you. If you're targeting plain old 32 bit intel-compatible linux or unix, have you considered simply using wine to run your windows binaries? That plus a very few tweaks in your source tree could get you what you want with potentially less effort. - Dan

Dec. 11, 2008

website : http://www.winehq.org/site/who gives a 404

by Paul Vriens

Hi, Just noticed that the Who is Who page is still referenced (from http://www.winehq.org/acknowledgement for example) as being on winehq.org. Wasn't this moved to the wiki? -- Cheers, Paul.

Dec. 11, 2008

Re: Canonical and wine

by Reece Dunn

2008/12/11 Steven Edwards <sedwards(a)bordeauxgroup.com>: > On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote: >> I believe it has been proposed before to have .debs for things like >> Adobe Photoshop which first install Wine (or create a new prefix etc.) >> and then ask for the Photoshop CD; sort of like application specific >> bundlings of Wine. > > This has been the long term plan we've had with Bordeaux. We > ultimately want to give the user the ablity to just do something along > the lines of > > sudo apt-get install photoshopcs > > ... > > 2. Templates > The ultimate goal is of course that it will just install out of the > box with no dependencies, fonts or wine dlloverride tricks. This is of > course not possible in every case and so we need to take this in to > account. The PlayOnLinux (http://www.playonlinux.com) team have install scripts for various applications. I don't know how good these are or how reliable they are. > 4. Most of the backend to support this is already in place. Now that > my IE6 changes are in winetricks, I could TODAY create a ie6.deb > package. Thanks to other users that have made winetricks steps in the > appdb we could do this for a host of other packages. It would be useful to have winetricks distributed in a deb/rpm package, so that you could install it easily to have it updated/managed by the package manager. This would provide the core support for installing applications run on wine via deb/rpm packages (that would depend on winetricks and wine). Each application would then use winetricks (and any support scripts that it provides, similar to what PlayOnLinux does), and support an install.sh and uninstall.sh script. These scripts can then be run via the pre/post install/uninstall hooks in the deb/rpm packages to do the installation. For the install.sh and uninstall.sh scripts, it could be useful to provide a mechanism in AppDB to create and modify these so that the maintainers/users of the application could create these scripts. There would need to be a way to aggregate the scripts and to version control them. Also, to simplify package creation we could have a configuration file that then generates the deb or rpm data and builds the corresponding package output using the package manager tools. This information (and what version of wine the app works well on) could even be extracted from AppDB itself and thus remove the need to have a wine-specific package configuration format. - Reece

Dec. 11, 2008

Re: Canonical and wine

by Steven Edwards

On Wed, Dec 10, 2008 at 3:42 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote: > I agree with Canonical that perhaps it doesn't make sense to make a > Winebuntu or a new Ubuntu with Wine as a bigger focus for exactly that > reason, it doesn't work for everything and that isn't a great > experience. (Anything thats inconsistent is bad for something like > Ubuntu. We love Wine but fact is fact, it isn't univerally perfect so > they can't advertise 'Full Windows Application Support!' etc. etc. > They could advertise 'Will Work with Some Windows Apps!' but then > users ask which ones and it gets confusing from there and yada > yada...) > > However perhaps it does make more sense to think about using Wine for > application specific scenarios. > > I believe it has been proposed before to have .debs for things like > Adobe Photoshop which first install Wine (or create a new prefix etc.) > and then ask for the Photoshop CD; sort of like application specific > bundlings of Wine. This has been the long term plan we've had with Bordeaux. We ultimately want to give the user the ablity to just do something along the lines of sudo apt-get install photoshopcs and have it find the correct version of Wine, if its missing install that deb, install the photoshopcs deb and then start the install process. There are a few key pieces missing for this to work well for the end user though. 1. Wine Prefix Management Alexandre and I have discussed this a bit and it needs to be well thought out. I'm partial to having something like ~/.wineprefixes for the private prefixes and /usr/local/wineprefixes for the global prefixes Alexandre likes the idea of having a winelib tool that can do this, and I think thats a great idea. Unfortunately the tool I wrote is GTK+. Also I believe we might need to add some enhancements to libwines support for detecting and maintaining the wineprefix variable, perhaps adding a function for handling the prefixes folder. I've got something like this in the Bordeaux cellar manager. Also when dealing with things like deb/rpm packages the prefix manager will need to know how to handle these. 2. Templates The ultimate goal is of course that it will just install out of the box with no dependencies, fonts or wine dlloverride tricks. This is of course not possible in every case and so we need to take this in to account. 3. We need some sort of tool like you said that prompts for a CD. Some sort of autorun.exe like tool. Ubuntu has been working on this so that a Wine CD is identified and offered to start the setup.exe or whatever. Its very generic and not very effective. We need a better way. 4. Most of the backend to support this is already in place. Now that my IE6 changes are in winetricks, I could TODAY create a ie6.deb package. Thanks to other users that have made winetricks steps in the appdb we could do this for a host of other packages. 5. Finally if Cannonical won't host the application debs directly we need to see if Scott will do it or have someone else host them. Thanks Steven -- 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

Dec. 11, 2008

Re: A nicer icon for shell32 folder

by Marcel Partap

> 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

Dec. 11, 2008

Re: German translation for winehq.org

by Jeremy Newman

Excellent work! -Newman Maik Schulz wrote: > Hi, > > please find attached a patch for the beginning of a German translation > of the new winehq.org. More patches to follow as I go through the > remaining templates. > > Cheers, > -Maik > > > ------------------------------------------------------------------------ > >

Dec. 11, 2008

Re: A nicer icon for shell32 folder

by Juan Lang

> You haven't done any mess, the svg icons are a nice improvement. The > reason they don't look as good as they should is because Wine doesn't > support the alpha channel, we need to fix that. 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

Dec. 11, 2008

Re: wintrust: Sign-compare warnings fix

by Juan Lang

Hi Andy, > I was curious to see how this one would fly. I fully take your point, of > course. If it were a good idea, the point would be to reduce the noise when > looking for real sign-compare problems and without introducing a cast. In a > similar vein, quite a lot of warnings are generated by code like this > > if (dwSomething == -1) > { Often in these cases, there's some predefined constant that should be used in lieu of -1. You introduced such a change in the same patch: - if (SetFilePointer(pSubjectInfo->hFile, 0, NULL, SEEK_END) == -1) + if (SetFilePointer(pSubjectInfo->hFile, 0, NULL, SEEK_END) == INVALID_SET_FILE_POINTER) This sort of change makes the code better, in my opinion, because the return type is being compared against something defined in the interface's documentation. The case I objected to is a curious one. I had a look at K&R's type promotion rules (2nd edition, section A6.5) and I'm confused what the compiler is doing here. The if-block is: if (pbEncoded[1] + 1 > cbEncoded) Rewriting the parenthesized expression as types rather than variables/values yields: unsigned char + int > unsigned int According to K&R, the unsigned char should get promoted to unsigned int (I think), hence: unsigned int + int > unsigned int When an unsigned type and a signed type are together in an expression, the signed type is promoted to unsigned: unsigned int + unsigned int > unsigned int Thus the comparison shouldn't have a signed/unsigned mismatch. The promotion of unsigned char to signed/unsigned int is platform-dependent, so perhaps gcc's analysis assumes it's signed? In any case, by my reading the gcc warning is simply wrong. I could be wrong of course. Anyway, good luck with your warning-crushing war ;-) --Juan

Dec. 11, 2008

RE: [2/4] WineD3D: Set up the shaders when delaying fixed func applying

by Stefan Dösinger

Here's an updated patch that fixes the compile issues > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Thursday, December 11, 2008 11:53 AM > To: wine-patches(a)winehq.org > Subject: [2/4] WineD3D: Set up the shaders when delaying fixed func > applying > > I skipped the original 2/5 patch because I found a last minute bug in > it. It should not affect the other patches though. > > Just fyi, this is my roadmap for cleaning up the fog mess this patch is > related to: > 1) Get rid of the GL_EXT_fog_coord-is-not-supported fallback and fake > the GL extension > 2) Remove the different pixel shader fog start and end optimization(and > probably reintroduce it in a cleaner way once the state_fog function is > sane) > 3) Separate the current fog state block into > fogenable+fogvertexmode+fogtablemode and fogstart-fogend > 4) Move the separated fog states into the fragment pipeline(since GLSL > and ARBfp override fog) > 5) Put the fog mode into the ps_compile_args structure to generate > shaders that can disable fog properly and support exponential fog > 6) Find some way to deal with glFogi(GL_FOG_COORDINATE_SOURCE_EXT, ...). > That part still belongs into the vertex pipe I think. > 7) the optimization removed in (2) is only needed for GLSL. We can > easilly reintroduce it once we have a full GLSL pipeline because then > the fog start and end stays independent of the pixel shader.

Dec. 11, 2008

RE: [2/5] wined3d: baseShader.functionLength should be 0 when a NULL pFunction is passed.

by Stefan Dösinger

> I'm not completely sure, but probably not. I'd like to get rid of this > check, but these patches are really just preparation for the 5th patch > in this series. I know there are other places where we check for a > NULL pFunction (including use_vs()), I'd like to remove those all at > once. Fair enough

Dec. 11, 2008

Re: [2/5] wined3d: baseShader.functionLength should be 0 when a NULL pFunction is passed.

by Henri Verbeet

2008/12/11 Stefan Dösinger <stefan(a)codeweavers.com>: > Do we still have a case where a shader is created with a NULL function? I > think we filter that in d3d8 now and just create a vdecl > I'm not completely sure, but probably not. I'd like to get rid of this check, but these patches are really just preparation for the 5th patch in this series. I know there are other places where we check for a NULL pFunction (including use_vs()), I'd like to remove those all at once.

Dec. 11, 2008

RE: [2/4] WineD3D: Set up the shaders when delaying fixed func applying

by Stefan Dösinger

Don't apply this patch, it has a bug and will cause a compile error > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Thursday, December 11, 2008 11:53 AM > To: wine-patches(a)winehq.org > Subject: [2/4] WineD3D: Set up the shaders when delaying fixed func > applying > > I skipped the original 2/5 patch because I found a last minute bug in > it. It should not affect the other patches though. > > Just fyi, this is my roadmap for cleaning up the fog mess this patch is > related to: > 1) Get rid of the GL_EXT_fog_coord-is-not-supported fallback and fake > the GL extension > 2) Remove the different pixel shader fog start and end optimization(and > probably reintroduce it in a cleaner way once the state_fog function is > sane) > 3) Separate the current fog state block into > fogenable+fogvertexmode+fogtablemode and fogstart-fogend > 4) Move the separated fog states into the fragment pipeline(since GLSL > and ARBfp override fog) > 5) Put the fog mode into the ps_compile_args structure to generate > shaders that can disable fog properly and support exponential fog > 6) Find some way to deal with glFogi(GL_FOG_COORDINATE_SOURCE_EXT, ...). > That part still belongs into the vertex pipe I think. > 7) the optimization removed in (2) is only needed for GLSL. We can > easilly reintroduce it once we have a full GLSL pipeline because then > the fog start and end stays independent of the pixel shader.

Dec. 11, 2008

RE: [2/5] wined3d: baseShader.functionLength should be 0 when a NULL pFunction is passed.

by Stefan Dösinger

Do we still have a case where a shader is created with a NULL function? I think we filter that in d3d8 now and just create a vdecl > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Henri Verbeet > Sent: Thursday, December 11, 2008 11:58 AM > To: wine-patches(a)winehq.org > Subject: [2/5] wined3d: baseShader.functionLength should be 0 when a > NULL pFunction is passed. >

Dec. 11, 2008

Re: A nicer icon for shell32 folder

by Alexandre Julliard

Hervÿffffe9 Chanal <chanal_herve(a)yahoo.fr> writes: > It's (may) be a nicer icon for the "folder icon" of shell32. comments are welcome. I think you should keep the yellow color scheme, that's what all other folder-style icons use. > Sorry for all the mess I seem to have done. I'll try to revert my old > icons patch to the previous ones as soon as I have the time. You haven't done any mess, the svg icons are a nice improvement. The reason they don't look as good as they should is because Wine doesn't support the alpha channel, we need to fix that. -- Alexandre Julliard julliard(a)winehq.org

Dec. 11, 2008

Re: jscript: Implement multiple Math functions.

by Jacek Caban

Hi Patrick, Patrick Rudolph wrote: > From 0903060f5acac3bcadc4198bd59eb2ef87f78818 Mon Sep 17 00:00:00 2001 > From: Patrick Rudolph <patrick1804(a)web.de> > Date: Wed, 10 Dec 2008 16:51:19 +0100 > Subject: jscript: Implement multiple Math functions. > > modified: math.c > modified: tests/api.js > --- > dlls/jscript/math.c | 293 +++++++++++++++++++++++++++++++++++++++------ > dlls/jscript/tests/api.js | 32 +++++ > 2 files changed, 287 insertions(+), 38 deletions(-) > > diff --git a/dlls/jscript/math.c b/dlls/jscript/math.c > index e6b7202..56ba9cf 100644 > --- a/dlls/jscript/math.c > +++ b/dlls/jscript/math.c > @@ -20,6 +20,7 @@ > #include "wine/port.h" > > #include <math.h> > +#include <sys/time.h> > > #include "jscript.h" > > @@ -57,57 +58,105 @@ static const WCHAR tanW[] = {'t','a','n',0}; > static HRESULT Math_E(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, > VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp) > { > - FIXME("\n"); > - return E_NOTIMPL; > + if(arg_cnt(dp) > 0) { > + FIXME("invalid arg_cnt %d\n", arg_cnt(dp)); > + return E_NOTIMPL; > + } > + > + if(retv) > + num_set_val(retv, exp(1)); > + return S_OK; > } > It's a JavaScript constant, not a function (and you've implemented it as if it would be a function). The same for other constants. [...] Please send smaller patches, preferable one patch per function, and add more tests. And first of all, make sure that tests are correct... > diff --git a/dlls/jscript/tests/api.js b/dlls/jscript/tests/api.js > index 2868c0f..6430397 100644 > --- a/dlls/jscript/tests/api.js > +++ b/dlls/jscript/tests/api.js > @@ -585,6 +585,38 @@ ok(tmp === 2, "Math.pow(2, 2) = " + tmp); > tmp = Math.pow(2, 2, 3); > ok(tmp === 4, "Math.pow(2, 2, 3) = " + tmp); > > +tmp = Math.PI(); > What makes you think this test will work? Jacek

Dec. 11, 2008

Re: Coverity Telco coming up

by Paul Vriens

Kai Blin wrote: > Hi folks, > > Coverity is hosting a telco tomorrow about some new technology they're going > to roll out to projects. I'm planning to attend, and would like to bring up > any issues we're currently having in the Q&A session. > > Issues I'm currently seeing with our Coverity experience: > - Adding new developers to the access list is painfully slow > - Builds are pretty outdated (They seem to be working on this) > > Anything else? > > Cheers, > Kai > > > > ------------------------------------------------------------------------ > > Hi Kai, Anything interesting to report from the teleconference? -- Cheers, Paul.

Dec. 11, 2008

Re: compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?

by Roderick Colenbrander

> > Hi, > > I have a huge amount of Windows code that I'm porting to Linux. > > Wine is turning out to be a read godsend, thank you guys! > > Anyway, I've had tons of luck including the directory > <wine_dir>/include/wine/windows in my include path. All my Windows types are there and > everything is wonderful. I've even been able to link against the libraries by > renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ > command line. > > I actually haven't got all my functions defined so I don't know if this > will actually run yet because the link isn't complete yet. > > My first question is whether this will work. Will all my Windows functions > with function declarations defined in the windows directory and code > compiled into foo.dll.so actually run? > > Second, I see that some of the functions I want to use are actually > defined by headers in the msvcrt directory. However, this directory contains tons > of header files that my system (and gcc) also have under /usr/include and > gcc's own directories. I understand that msvcrt is Windows lib c, but I > wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to > gcc, but the number of errors I get is enormous. > > It's not the end of the world if I can't use Wine's msvcrt, but if I could > use it, it would define dozens more functions on which my program relies, > or if its use was mandatory in order to get the functions implemented in > foo.dll.so to work, then obviously I wonder how I'm supposed to compile my > Windows code with Wine to make everything work? > > I'm sorry if this is a dumb question. I can't find a way to search the > wine-devel mailing list other than with google and I can't find anything on > there or other docs that answer this question, which I'm sure has been asked > a million times and has a simple answer. > > Thank you thank you, > > Jeff > > _________________________________________________________________ > Send e-mail faster without improving your typing skills. > http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_… Just compiling your program using g++ won't work as Wine needs to perform a lot of magic. For that reason Wine ships with its own gcc/g++ wrapper programs called winegcc/wineg++ both are mingw compatible. You should build your program using that and it won't have issues linking with wine libraries and it also allows you to link against linux libraries. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 11, 2008

Re: wintrust: Sign-compare warnings fix

by Andrew Talbot

Juan Lang wrote: > Hi Andy, > > - if (pbEncoded[1] + 1 > cbEncoded) > + if (pbEncoded[1] + 1U > cbEncoded) > > Is this change necessary? The resulting code is less clear than the > original, IMO. It's clearly a spurious warning: a BYTE (max value > 255) + 1 can't yield a value that overflows an unsigned int, so this > comparison will always do what's wanted. > > Same with the change here: > - else if (lenLen + 2 > cbEncoded) > + else if (lenLen + 2U > cbEncoded) > > Otherwise, this patch looks fine to me. > --Juan Hi Juan, I was curious to see how this one would fly. I fully take your point, of course. If it were a good idea, the point would be to reduce the noise when looking for real sign-compare problems and without introducing a cast. In a similar vein, quite a lot of warnings are generated by code like this if (dwSomething == -1) { ... Maybe, in this case the code actually is "wrong", since a variable that operates in the range 0 to UINT_MAX (on a non-MSC system) can never be strictly equal to -1, but in these cases I have resisted comparing against "~0U", because there may be places where an internal function could/should be rewritten not to use "minus one unsigned" as a return value, for example, and this "fix" would tend to hide those opportunities. I shall see how the patch fares and resubmit without the "U"s if it gets rejected. Thanks for the feedback. -- Andy.

Dec. 11, 2008

compiling Windows code with g++ on Linux using msvcrt - good idea? if so, how do you do it?

by foobarbaz biffblaff

Hi, I have a huge amount of Windows code that I'm porting to Linux. Wine is turning out to be a read godsend, thank you guys! Anyway, I've had tons of luck including the directory <wine_dir>/include/wine/windows in my include path. All my Windows types are there and everything is wonderful. I've even been able to link against the libraries by renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ command line. I actually haven't got all my functions defined so I don't know if this will actually run yet because the link isn't complete yet. My first question is whether this will work. Will all my Windows functions with function declarations defined in the windows directory and code compiled into foo.dll.so actually run? Second, I see that some of the functions I want to use are actually defined by headers in the msvcrt directory. However, this directory contains tons of header files that my system (and gcc) also have under /usr/include and gcc's own directories. I understand that msvcrt is Windows lib c, but I wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to gcc, but the number of errors I get is enormous. It's not the end of the world if I can't use Wine's msvcrt, but if I could use it, it would define dozens more functions on which my program relies, or if its use was mandatory in order to get the functions implemented in foo.dll.so to work, then obviously I wonder how I'm supposed to compile my Windows code with Wine to make everything work? I'm sorry if this is a dumb question. I can't find a way to search the wine-devel mailing list other than with google and I can't find anything on there or other docs that answer this question, which I'm sure has been asked a million times and has a simple answer. Thank you thank you, Jeff _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_…

Dec. 11, 2008

(no subject)

by foobarbaz biffblaff

Hi, I have a huge amount of Windows code that I'm porting to Linux. Wine is turning out to be a read godsend, thank you guys! Anyway, I've had tons of luck including the directory <wine_dir>/include/wine/windows in my include path. All my Windows types are there and everything is wonderful. I've even been able to link against the libraries by renaming, for example, foo.dll.so to libfoo.so and using -lfoo on the g++ command line. I actually haven't got all my functions defined so I don't know if this will actually run yet because the link isn't complete yet. My first question is whether this will work. Will all my Windows functions with function declarations defined in the windows directory and code compiled into foo.dll.so actually run? Second, I see that some of the functions I want to use are actually defined by headers in the msvcrt directory. However, this directory contains tons of header files that my system (and gcc) also have under /usr/include and gcc's own directories. I understand that msvcrt is Windows lib c, but I wonder how I'm supposed to use it with gcc to compile? I've tried -nostdinc to gcc, but the number of errors I get is enormous. It's not the end of the world if I can't use Wine's msvcrt, but if I could use it, it would define dozens more functions on which my program relies, or if its use was mandatory in order to get the functions implemented in foo.dll.so to work, then obviously I wonder how I'm supposed to compile my Windows code with Wine to make everything work? I'm sorry if this is a dumb question. I can't find a way to search the wine-devel mailing list other than with google and I can't find anything on there or other docs that answer this question, which I'm sure has been asked a million times and has a simple answer. Thank you thank you, Jeff _________________________________________________________________ Send e-mail faster without improving your typing skills. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_…

Dec. 11, 2008

Re: wintrust: Sign-compare warnings fix

by Juan Lang

Hi Andy, - if (pbEncoded[1] + 1 > cbEncoded) + if (pbEncoded[1] + 1U > cbEncoded) Is this change necessary? The resulting code is less clear than the original, IMO. It's clearly a spurious warning: a BYTE (max value 255) + 1 can't yield a value that overflows an unsigned int, so this comparison will always do what's wanted. Same with the change here: - else if (lenLen + 2 > cbEncoded) + else if (lenLen + 2U > cbEncoded) Otherwise, this patch looks fine to me. --Juan

Dec. 11, 2008

Re: Canonical and wine

by Remco

Canonical doesn't want to include Wine, because they are trying to provide a complete desktop experience. Wine is a necessity for many people, but Canonical wants to market Ubuntu as the Linux distribution that works well for normal usage. Including a half-working Windows-emulator (functionality emulator) doesn't fall within that mission. It gives the message that Ubuntu on its own isn't ready (true or not). Why would they want to switch from a good product (Windows) to an inferior one with spotty support for Windows applications? I don't see them providing packages for proprietary applications. Not for the Ubuntu project, which is completely free (except drivers). Maybe through the Canonical store, which also provides a legal but proprietary DVD player. Remco

Dec. 11, 2008

Re: Translating to winehq.org

by Jeremy Newman

One at a time is fine. As you can see from our Spanish translation, it does not need to be complete. The site will fall back to english when it can't find the template. I would start with home.template and branch out from there. If you see obsolete content, you can send patches to update the english as well. This will be a challenge, but luckily most of the content does not change often. -Newman Maik Schulz wrote: > Hi, > > I just started translating the new winehq.org to German. How would you > like to receive the git patches for the translated template files? One > at a time whenever I have them ready, or at the end in one batch? > > Also, what about obsolete content? E.g. contributing.template still > lists Wine 1.x tasks (with a link to an empty Bugzilla list) as well > as an empty Wine 0.9.x tasks list. > > Cheers, > -Maik > >

Dec. 10, 2008

Translating to winehq.org

by Maik Schulz

Hi, I just started translating the new winehq.org to German. How would you like to receive the git patches for the translated template files? One at a time whenever I have them ready, or at the end in one batch? Also, what about obsolete content? E.g. contributing.template still lists Wine 1.x tasks (with a link to an empty Bugzilla list) as well as an empty Wine 0.9.x tasks list. Cheers, -Maik

Dec. 10, 2008

Re : RFC: Wine Icons

by Hervÿffffe9 Chanal

> On Friday 14 November 2008 19:13:32 Juan Lang wrote: > > > > I find that a bit alarming. I'm sure he's working very hard, and doing > > > good stuff, but I don't think Wine should be redrawing anything. Not > > > when we have Tango around - it's designed to try create some consistency > > > through standardisation. IMO standards are really good! - we use them if > > > we possibly can. > > > > The trouble is that the Tango icon set doesn't cover all the icons > > Wine needs. There's no Tango icon for regedit, for instance. > > IIRC there's Tango icon sets for specific applications. If we're doing our own > icons anyway, we could try to keep them coherent with the rest of the Tango > look and get the icons upstream to Tango. > > This seems like the most reasonable approach. Of course the only things I > usually paint are walls so I'd have no idea how easy it is to match the Tango > specs when designing icons. > > Cheers, > Kai First of all, sorry to not have answered before and for my poor English, but I was quite busy these past months and I didn't see all these messages since today. I realize that the two patch I sent an hour ago are not the best answer to all these issues (I think these two newer icons look nicer in the open dialog boxes anyway) and that all theses points have to be discussed. When remaking icons, I tried to add a bit of consistency while improving a bit the icons. Obviously, I missed something. Reading all theses remarks, I agree that a better way to handle these icons are to use the Tango ones when they are available. As it was stated, including them is not straightforward and I haven't the skill to work on including these libraries into the wine tree. I hope somebody will work on these issues. In the meanwhile, maybe I'll try to improve the others shell32 icons as the bin or the computer which I found awful in this size but I don't know if it's a good idea. Cheers, Hervé

Dec. 10, 2008

Re: Canonical and wine

by Zachary Goldberg

> On Wednesday 10 December 2008 19:09:16 Dan Kegel wrote: > http://www.technewsworld.com/rsstory/65431.html > quotes Gerry Carr, marketing manager at Canonical: > "We aren't considering a pitch about using Wine or Parallels like on a > Mac. There is no real look at Wine. It doesn't always work well. So > this won't win over users to the benefits of Linux," > > So there you go. Canonical will think about Wine once it always works > well. I agree with Canonical that perhaps it doesn't make sense to make a Winebuntu or a new Ubuntu with Wine as a bigger focus for exactly that reason, it doesn't work for everything and that isn't a great experience. (Anything thats inconsistent is bad for something like Ubuntu. We love Wine but fact is fact, it isn't univerally perfect so they can't advertise 'Full Windows Application Support!' etc. etc. They could advertise 'Will Work with Some Windows Apps!' but then users ask which ones and it gets confusing from there and yada yada...) However perhaps it does make more sense to think about using Wine for application specific scenarios. I believe it has been proposed before to have .debs for things like Adobe Photoshop which first install Wine (or create a new prefix etc.) and then ask for the Photoshop CD; sort of like application specific bundlings of Wine. Do we know Canonical's stance on that? That scenario could be consistent and provide real end user benefit sans confusion.

Dec. 10, 2008

Re: Canonical and wine

by Kai Blin

On Wednesday 10 December 2008 19:09:16 Dan Kegel wrote: > http://www.technewsworld.com/rsstory/65431.html > quotes Gerry Carr, marketing manager at Canonical: > "We aren't considering a pitch about using Wine or Parallels like on a > Mac. There is no real look at Wine. It doesn't always work well. So > this won't win over users to the benefits of Linux," > > So there you go. Canonical will think about Wine once it always works > well. Sure. because only 'hardcore Linux users' use Wine. That's just what I see every day when I look into #winehq. Hardcore Linux users who never need help with the basic questions of compiling Wine from source or updating to the latest Wine release, but who are stopped from running their games^Wprograms by Wine. Excuse me while I rush out to catch one of these flying pigs, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 10, 2008

Canonical and wine

by Dan Kegel

http://www.technewsworld.com/rsstory/65431.html quotes Gerry Carr, marketing manager at Canonical: "We aren't considering a pitch about using Wine or Parallels like on a Mac. There is no real look at Wine. It doesn't always work well. So this won't win over users to the benefits of Linux," So there you go. Canonical will think about Wine once it always works well.

Dec. 10, 2008

Re: wininet/tests: Use new test URLs on test.winehq.org.

by Paul Vriens

Hi Alexandre, These changes introduce 15 errors on all platforms. -- Cheers, Paul.

Dec. 10, 2008

Re: [PATCH 14/14] msi: Add tests for MsiGetProductProperty.

by James Hawkins

On Wed, Dec 10, 2008 at 8:49 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > James Hawkins wrote: >> >> --- >> dlls/msi/tests/package.c | 232 >> ++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 232 insertions(+), 0 deletions(-) >> >> >> ------------------------------------------------------------------------ >> >> > Hi James, > > These fail on Win9x as we are relying on some registry keys that are NT+ > specific: > > 9574 lstrcpyA(keypath, > "Software\\Microsoft\\Windows\\CurrentVersion\\"); > 9575 lstrcatA(keypath, "Installer\\UserData\\S-1-5-18\\Products\\"); > 9576 lstrcatA(keypath, prod_squashed); > > Can we skip these tests, like we do with some others: > > scm = OpenSCManager(NULL, NULL, GENERIC_ALL); > if (!scm && (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)) > { > win_skip("Different registry keys on Win9x and WinMe\n"); > return; > } > Doesn't matter to me. -- James Hawkins

Dec. 10, 2008

Re: [PATCH 14/14] msi: Add tests for MsiGetProductProperty.

by Paul Vriens

James Hawkins wrote: > --- > dlls/msi/tests/package.c | 232 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 232 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, These fail on Win9x as we are relying on some registry keys that are NT+ specific: 9574 lstrcpyA(keypath, "Software\\Microsoft\\Windows\\CurrentVersion\\"); 9575 lstrcatA(keypath, "Installer\\UserData\\S-1-5-18\\Products\\"); 9576 lstrcatA(keypath, prod_squashed); Can we skip these tests, like we do with some others: scm = OpenSCManager(NULL, NULL, GENERIC_ALL); if (!scm && (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)) { win_skip("Different registry keys on Win9x and WinMe\n"); return; } -- Cheers, Paul.

Dec. 10, 2008

Re: [5/8] jscript: Implement the String.anchor() method.

by Jacek Caban

Hi Andrew, Andrew Nguyen wrote: > --- > dlls/jscript/string.c | 58 ++++++++++++++++++++++++++++++++++++++++++ > dlls/jscript/tests/api.js | 17 +++++++++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) > +static HRESULT do_attribute_tag_format(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, + VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp, const WCHAR *tagname, const WCHAR *attrname) +{ + static const WCHAR attrtagfmtW[] = {'<','%','s',' ','%','s','=','"','%','s','"','>','%','s','<','/','%','s','>',0}; + static const WCHAR undefinedW[] = {'u','n','d','e','f','i','n','e','d',0}; + StringInstance *string; + BSTR ret; + BSTR attrval = NULL; + DWORD len; + HRESULT hres = S_OK; + + TRACE("\n"); IMO it would be better to change FIXME to TRACE in String_anchor instead of adding TRACE here. You use this function in a few places, and this TRACE doesn't tell us, which function is called. + + if(!is_class(dispex, JSCLASS_STRING)) { + WARN("this is not a string object\n"); + hres = E_NOTIMPL; + goto cleanup; You may just return E_NOTIMPL here. + } + + string = (StringInstance*)dispex; + + if(retv) { + if(arg_cnt(dp)) { + hres = to_string(dispex->ctx, get_arg(dp, 0), ei, &attrval); You should call to_string even if retv is NULL. Although it looks like a nice optimization, we can't do this. Eg, if to_string throws exception, we have to throw it here. + if (FAILED(hres)) + goto cleanup; You may just return hres here. + } + + len = string->length + 2*strlenW(tagname) + strlenW(attrname) + 9; + + if (attrval) + len += SysStringLen(attrval); + else + len += sizeof(undefinedW)/sizeof(WCHAR) - 1; + + ret = SysAllocStringLen(NULL, len); + + if(!ret) + { + hres = E_OUTOFMEMORY; + goto cleanup; Perhaps it's just me, but in cases that don't make the code cleaner by using gotos, I'd avoid them. How about: if(ret) { sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); V_VT(retv) = VT_BSTR; V_BSTR(retv) = ret; }else { hres = E_OUTOFMEMORY; } + } + + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + } + cleanup: + SysFreeString(attrval); + return hres; +} Jacek

Dec. 10, 2008

Re: [5/8] jscript: Implement the String.anchor() method.

by Jacek Caban

Hi Andrew, Andrew Nguyen wrote: > --- > dlls/jscript/string.c | 58 ++++++++++++++++++++++++++++++++++++++++++ > dlls/jscript/tests/api.js | 17 +++++++++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) > +static HRESULT do_attribute_tag_format(DispatchEx *dispex, LCID lcid, WORD flags, DISPPARAMS *dp, + VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp, const WCHAR *tagname, const WCHAR *attrname) +{ + static const WCHAR attrtagfmtW[] = {'<','%','s',' ','%','s','=','"','%','s','"','>','%','s','<','/','%','s','>',0}; + static const WCHAR undefinedW[] = {'u','n','d','e','f','i','n','e','d',0}; + StringInstance *string; + BSTR ret; + BSTR attrval = NULL; + DWORD len; + HRESULT hres = S_OK; + + TRACE("\n"); IMO it would be better to change FIXME to TRACE in String_anchor instead of adding TRACE here. You use this function in a few places, and this TRACE doesn't tell us, which function is called. + + if(!is_class(dispex, JSCLASS_STRING)) { + WARN("this is not a string object\n"); + hres = E_NOTIMPL; + goto cleanup; You may just return E_NOTIMPL here. + } + + string = (StringInstance*)dispex; + + if(retv) { + if(arg_cnt(dp)) { + hres = to_string(dispex->ctx, get_arg(dp, 0), ei, &attrval); You should call to_string even if retv is NULL. Although it looks like a nice optimization, we can't do this. Eg, if to_string throws exception, we have to throw it here. + if (FAILED(hres)) + goto cleanup; You may just return hres here. + } + + len = string->length + 2*strlenW(tagname) + strlenW(attrname) + 9; + + if (attrval) + len += SysStringLen(attrval); + else + len += sizeof(undefinedW)/sizeof(WCHAR) - 1; + + ret = SysAllocStringLen(NULL, len); + + if(!ret) + { + hres = E_OUTOFMEMORY; + goto cleanup; Perhaps it's just me, but in cases that don't make the code cleaner by using gotos, I'd avoid them. How about: if(ret) { sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); V_VT(retv) = VT_BSTR; V_BSTR(retv) = ret; }else { hres = E_OUTOFMEMORY; } + } + + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + } + cleanup: + SysFreeString(attrval); + return hres; +}

Dec. 10, 2008

Re: oleaut32: added PICTYPE_NONE and PICTYPE_UNINITIALIZED to IPicture::Render with test (try3)

by Nikolay Sivov

Paul Vriens wrote: > Nikolay Sivov wrote: >> Changelog(try3): >> - fixed identation in testlist >> Changelog(try2): >> - added PICTYPE_NONE and PICTYPE_UNINITIALIZED to >> IPicture::Render with test >> - added test for zero dimensions >> >> P.S. Render with this types spotted in traces of bugs 6799 and 10050 >> >>> From 3386e8674380390c3b60c6247443c605ffe6ff6a Mon Sep 17 00:00:00 2001 >> From: Nikolay Sivov <bunglehead(a)gmail.com> >> Date: Wed, 10 Dec 2008 13:41:09 +0300 >> Subject: added PICTYPE_NONE and PICTYPE_UNINITIALIZED to >> IPicture::Render >> >> --- >> dlls/oleaut32/olepicture.c | 8 +++++ >> dlls/oleaut32/tests/olepicture.c | 64 >> ++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 72 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/oleaut32/olepicture.c b/dlls/oleaut32/olepicture.c >> index 498ee53..bdce729 100644 >> --- a/dlls/oleaut32/olepicture.c >> +++ b/dlls/oleaut32/olepicture.c >> @@ -637,6 +637,10 @@ static HRESULT WINAPI >> OLEPictureImpl_Render(IPicture *iface, HDC hdc, >> TRACE("prcWBounds (%d,%d) - (%d,%d)\n", prcWBounds->left, >> prcWBounds->top, >> prcWBounds->right, prcWBounds->bottom); >> >> + if(cx == 0 || cy == 0 || cxSrc == 0 || cySrc == 0){ >> + return CTL_E_INVALIDPROPERTYVALUE; >> + } >> + >> /* >> * While the documentation suggests this to be here (or after >> rendering?) >> * it does cause an endless recursion in my sample app. -MM 20010804 >> @@ -644,6 +648,10 @@ static HRESULT WINAPI >> OLEPictureImpl_Render(IPicture *iface, HDC hdc, >> */ >> >> switch(This->desc.picType) { >> + case PICTYPE_UNINITIALIZED: >> + case PICTYPE_NONE: >> + /* nothing to do */ >> + return S_OK; >> case PICTYPE_BITMAP: >> { >> HBITMAP hbmpOld; >> diff --git a/dlls/oleaut32/tests/olepicture.c >> b/dlls/oleaut32/tests/olepicture.c >> index f81c419..9e33121 100644 >> --- a/dlls/oleaut32/tests/olepicture.c >> +++ b/dlls/oleaut32/tests/olepicture.c >> @@ -25,6 +25,7 @@ >> #include <float.h> >> >> #define COBJMACROS >> +#define NONAMELESSUNION >> >> #include "wine/test.h" >> #include <windef.h> >> @@ -587,6 +588,68 @@ static void test_enhmetafile(void) >> GlobalFree(hglob); >> } >> >> +static void test_Render(void) >> +{ >> + IPicture *pic; >> + HRESULT hres; >> + short type; >> + PICTDESC desc; >> + HDC hdc = GetDC(0); >> + >> + /* test IPicture::Render return code on uninitialized picture */ >> + OleCreatePictureIndirect(NULL, &IID_IPicture, TRUE, (VOID**)&pic); >> + hres = IPicture_get_Type(pic, &type); >> + ok(hres == S_OK, "IPicture_get_Type does not return S_OK, but >> 0x%08x\n", hres); >> + ok(type == PICTYPE_UNINITIALIZED, "Expected type = >> PICTYPE_UNINITIALIZED, got = %d\n", type); >> + /* zero dimensions */ >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 0, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 10, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 0, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + /* nonzero dimensions, PICTYPE_UNINITIALIZED */ >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 10, NULL); >> + ole_expect(hres, S_OK); >> + IPicture_Release(pic); >> + >> + desc.cbSizeofstruct = sizeof(PICTDESC); >> + desc.picType = PICTYPE_ICON; >> + desc.u.icon.hicon = LoadIcon(NULL, IDI_APPLICATION); >> + if(!desc.u.icon.hicon){ >> + win_skip("LoadIcon failed. Skipping...\n"); > > Shouldn't you also use ReleaseDC() here for consistency sake? > >> + return; >> + } >> + >> + OleCreatePictureIndirect(&desc, &IID_IPicture, TRUE, (VOID**)&pic); >> + /* zero dimensions, PICTYPE_ICON */ >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 0, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 10, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 10, 0, 0, 0, 0, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 10, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 10, 0, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + hres = IPicture_Render(pic, hdc, 0, 0, 0, 0, 0, 0, 10, 10, NULL); >> + ole_expect(hres, CTL_E_INVALIDPROPERTYVALUE); >> + IPicture_Release(pic); >> + >> + ReleaseDC(NULL, hdc); > > Thank you for spotting this.

Dec. 10, 2008