May 2010 - Wine-devel - list.winehq.org

Re: crypt32/tests: remove ret from testAddSerialized, where it's not really used
by Nikolay Sivov 22 May '10

22 May '10

On 5/21/2010 22:45, Austin English wrote: > Gerald's made good progress here, there's only 81 of these left in > wine-1.1.44-427-ga06a191. > > - BOOL ret; > CRYPT_DATA_BLOB blob = { 0, NULL }; > > - ret = CertSaveStore(store, X509_ASN_ENCODING, CERT_STORE_SAVE_AS_STORE, > + CertSaveStore(store, X509_ASN_ENCODING, CERT_STORE_SAVE_AS_STORE, > Why not test for it?

2 1

Re: winemp3.acm: Avoid using the long type.
by Chris Robinson 21 May '10

21 May '10

Now to the list... On Friday, May 21, 2010 9:32:17 am you wrote: > Chris Robinson wrote: > > On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote: > >> @@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi, > >> > >> if (ret == MPG123_NEW_FORMAT) > >> { > >> > >> - long rate; > >> + LONG_PTR rate; > >> > >> int channels, enc; > >> mpg123_getformat(amd->mh, &rate, &channels, &enc); > > > > I'm not sure this change is correct, when the function itself is > > expecting a pointer to an actual long. > > Yes, that's why I used LONG_PTR. That's the Win32 way of saying "I want > a real 'long' like everybody else is using" aka one that has the same > size as a pointer. A LONG_PTR is a signed integer large enough to hold a pointer value. A long may or may not be the same size. This would break if built for 64-bit Windows, for example, where a long is still 32 bits (and what the 64-bit Windows version of the lib will expect), while a LONG_PTR is 64 bits.

2 2

Fw: Re: Release plans
by James Mckenzie 21 May '10

21 May '10

To the list. -----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: May 21, 2010 8:20 AM >To: Joerg-Cyril.Hoehle(a)t-systems.com >Subject: Re: Release plans > >Joerg-Cyril.Hoehle(a)t-systems.com wrote: >> >>>> And I didn't write trivial Mac patches either, e.g. to have >>>> wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + >>>> Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. >>>> That's another (example of a) missing element. >>>> (Why didn't I write it? Because I was unsure where to put the #ifdef) >>>Isn't that linking done relative to $HOME, which should resolve to >>>/Users/xyz on Mac? >>That's not the problem. What I also don't know is whether I could hardcode >>the directories ~/Documents etc. > >AFIAK, I would not hard code them, but give a default of $HOME/Documents and $HOME/Desktop (this would allow users to change the directory, maybe through the registry or through environment variables. (these already exist in my /Users/xyz, >>but what about Tiger? > >I don't think there are many Intel Macs running Tiger anymore and Darwine is completely dead. > >>or whether I ought to call some OSX API that >>yields the name of the dir (and possibly creates it if it does not yet exist). > >This is a third idea that we may want to look at. > >>I'm not familiar at all with Mac APIs, but it sounds like an easy patch >>for somebody with a little MacOS programming knowledge. >> >Hmmm. >> >>>> What can Mac users expect from this release? >>>Hopefully, conversion to Linux :-). >>Actually, one day I was fed up with the Gnome and KDE4 GUIs, >>so I started looking for something else. The Mac Mini with >>NVidia came out right at that time: extremely silent (except >>for the CD-ROM), excellent graphics (by far better than >>any onboard Intel I knew previously) and it's a UNIX. >> >My feelings exactly. If Gnome and KDE were so good, why are there other Linux windows management tools? > >James McKenzie

1 0

[website] German translation of Only support Ubuntu 9.10 and 10.04
by André Hentschel 21 May '10

21 May '10

--- templates/de/download.template | 2 +- templates/de/download/deb.template | 77 +++++++---------------------------- 2 files changed, 17 insertions(+), 62 deletions(-) -- Best Regards, André Hentschel

1 0

Re: software built and worked under wine but not in vista?
by Hin-Tak Leung 21 May '10

21 May '10

--- On Fri, 21/5/10, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > Krasuckas <saulius2(a)ar.fi.lt> > wrote: > > > > > > http://www.ghostscript.com/~hintak/setupgs-vista.exe > > > > http://www.ghostscript.com/~hintak/setupgs-wine.exe > > > > > > There are a few differences I spotted between the > two > > executables: > > > 1) setupgs-wine.exe has wrong image size, > changing it > > from 0x2b200 to > > > 0x2b000 makes the executable working under win7. But that has to be a bug in wine - that it doesn't check the image size and loads PE with an invalid image size? (how that end up being invalid is a different issue).

2 1

Re: winemp3.acm: Avoid using the long type.
by Chris Robinson 21 May '10

21 May '10

On Friday, May 21, 2010 3:13:36 am Michael Stefaniuc wrote: > @@ -191,7 +191,7 @@ static void mp3_horse(PACMDRVSTREAMINSTANCE adsi, > > if (ret == MPG123_NEW_FORMAT) > { > - long rate; > + LONG_PTR rate; > int channels, enc; > mpg123_getformat(amd->mh, &rate, &channels, &enc); I'm not sure this change is correct, when the function itself is expecting a pointer to an actual long.

2 1

dinput2
by David Adam 21 May '10

21 May '10

Hello many distro ship the X-server with dinput2. More and more old games work pretty well now with Wine, but the mouse. Does anyone plan to work on the infamous bug 6971? It would be great if it could be implemented for the official release of Wine. It would do a big buzz :D Cheers David

6 6

Re: taskmgr: Update Slovenian translation [resend]
by Paul Vriens 21 May '10

21 May '10

On 05/21/2010 05:48 PM, Matej Špindler wrote: > Anything wrong with this patch? I sent it a week ago and didn't receive > any comments. > > > > Hi Matej, If you look at http://source.winehq.org/patches/ you will see that your patch (number 61589) had an apply failure. I tried your patch just now and I don't have an apply failure here, so I'm not sure what went wrong. -- Cheers, Paul.

1 0

Fw: Re: Release plans
by James Mckenzie 21 May '10

21 May '10

To the list.... -----Forwarded Message----- >From: James Mckenzie <jjmckenzie51(a)earthlink.net> >Sent: May 20, 2010 12:49 PM >To: Damjan Jovanovic <damjan.jov(a)gmail.com> >Subject: Re: Release plans > >> >>On Fri, May 14, 2010 at 12:31 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: >>> Hi, >> >>Hi >> >>>>The 64-bit support is now more or less complete >>> I hope I can finish my MCI parser patches in time. Without them, >>> every 64bit app using MCI string commands is likely to crash (OTOH >>> MCI commands work (those using the MCI_*_PARAMS structures)). >>> >>> >>> What can Mac users expect from this release? >> >>Hopefully, conversion to Linux :-). >> >No. BTW, I've used: > >TRSDOS (Model III) >MS-DOS 1.0/2.0/3.0/4.0/5.0/6.0 (6.22) and updates >DR-DOS 4.0/5.0 >Windows 3.1, 3.11WFW, 95, 98, NT 3.51, NT 4.0, XP and Vista >OS/2 >Linux, Linux and more Linux (it is still user unfriendly) >Mac Classic >MacOSX 10.3/.4/.5 > >I consider MacOSX the most polished as a User Experience of all of them. > >>> Yesterday I installed an app with wine-1.1.44 on Mac OS (instead of >>> moving it from a Linux install). It was disappointing from a user POV: >>> >>> - Wine created .desktop files that work on Linux but don't make sense >>> on Mac OS. Here I've been thinking about a simple patch that would >>> instead generate a .command file like I've described in the FAQ. >>> OTOH, Steven Edwards IIRC once had a much more elaborate patch about >>> better Mac OS integration, rejected last year. >>> >>> - In the hidden directory ~/.local/share/icons/ it created .xpm files >>> that the Finder does not display. .png would be displayed. >> >>winemenubuilder generates .png only for 24 and 32 bits-per-pixel >>icons, all other resolutions get converted to .xpm. I am planning to >>change it to make .png's for everything, since thumbnailing .lnk files >>requires .png as output, and then keep .xpm only as a fallback when >>libpng is not installed and we're not thumbnailing. This should help >>you on MacOS too. > >Thank you. It is not a good thing that MacOSX cannot use .xpm files "out of the box". >> >>> I have no idea how the other packages built atop Wine behave on MacOS behave: >>> - Kronenberg's WineBottler >>> - doh's WineSkin >>> - Macports build >>> - CodeWeaver's CrossOver4Mac >>> I assume they create nice icons that the user can click after an install. >>> >>> Regarding the former 2 packages, I've always been wondering why >>> there's some sort of split in the Wine+Mac user community. Obviously >>> the stock Wine fails to meet the Mac user's expectations, such that >>> several people start and write something better integrated with the >>> GUI -- but not integrated into the Wine source. >> >>From visiting the websites, I see Kronenberg's Winebottler doesn't >>provide source (the source link takes you to an empty repository; >>interestingly the LGPL requires you to provide the changed source if >>you distribute the software...) > >That's because Mike no longer makes any changes directly to the Wine code. He states that on the site (or did.) >>Wineskin is a complete installation >>wrapper that I would guess does the desktop integration itself, > >That's what doh123 states. It is a wrapper program that builds an exportable .app product that will start Wine and then any program that you wrap with it. He also gets the files for specific programs using winetricks. > >>macports.org is down but http://wine.darwinports.com/ doesn't have any >>relevant patches, and I don't have CrossOver4Mac or a Mac to test it >>and see what it does. >> >CrossOver Mac is and will remain a commercial product. They do all sorts of magic to fix the brokenness of Apple/XQuartz(s) X11's inability to display full screen and other enhancements specific to making Wine work better on the MacOSX platform. > >>Maybe it's that Linux users generally expect the free software to be >>good, while Mac users generally expect good software to cost money, so >>when someone develops the extra bits for Wine on Mac, they either keep >>them to themselves or sell them? Also, I think more Wine developers >>use Linux than Mac, so there's less interest in fixing Wine on Mac. >> >No. Mac users expect Mac software to just damn work. We don't want to 'tweek' and 'twist' and apply patch after patch after patch. If it don't work, out of the box, it goes. We don't have time to 'play'. So, many of us use Crossover. We pay for others to fix that which is broken. That being said, there are those of us that really like the challange of making Windows software work on the Mac as well as making Linux software work on the Mac. And we EXPECT to get paid for it. > >Please be aware that 'free' software NEVER IS. The phrase "You get what you pay for" really applies here. Again, Mac users have been conditioned to 'it works'. Wine is not, at the present time, ready for this level of acceptance and may never be. And no, Mac users are not going to switch to Linux. Some may run Ubuntu, but a vast majority unpack the system, plug it in and go to work. > >>> And I didn't write trivial Mac patches either, e.g. to have >>> wineprefixcreate symlink c:\users\xyz\ Desktop + Videos + Documents + >>> Music to /Users/xyz/Desktop/ etc. This happens on Linux, not on MacOS. >>> That's another (example of a) missing element. >>> (Why didn't I write it? Because I was unsure where to put the #ifdef) >> >>Isn't that linking done relative to $HOME, which should resolve to >>/Users/xyz on Mac? >> >Correct. When a new user is created on the Mac, the user name, less spaces and special characters, is used for the folder name. The Desktop folder IS the Mac Aqua desktop and I highly suggest NOT placing .desktop and .lnk files there. Unlike Windows users, most Mac users like to keep their desktops 'clean'. Doing what you desire will take more work and a good poll of the Mac community before implementation. This is part of the reason that Apple has used the Dock and created Documents/Download folders on it. Maybe that would be a good place to put Wine application icons. > >Please keep in mind that this is not to bash Linux or Windows users. Each category of user has their own method of OS and system use. > >James McKenzie

1 0

TRACE(...., debugstr_w(uninitialised data))?
by Joerg-Cyril.Hoehle＠t-systems.com 21 May '10

21 May '10

Hi, winmm/mci.c contains some code like this: TRACE("=> 1/ %x (%s)\n", dwRet, debugstr_w(lpstrRet)); However, in case of error, the lpstrRet buffer is likely not initialised. This could cause 1. debugstr_w to choke on bad/unconvertible data (not even 0-terminated); 2. Valgrind errors (I don't know whether the Valgrind warnings I observe are due to this line of code). Am I worrying too much or should any such piece of code be protected by TRACE("=> 1/ %x (%s)\n", dwRet, LOWORD(dwRet) ? "" : debugstr_w(lpstrRet)); (actually, an even more convoluted test is needed because of MCI_INTEGER_RETURNED) Or is it not worth careing about because it's within TRACE() only? I assume that debugstr_w is not executed when that channel is not traced. Correct? Regards, Jörg Höhle

2 1