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

Valgrind can't *quite* handle Adobe InDesign yet

by Dan Kegel

http://bugs.kde.org/show_bug.cgi?id=126389 means that valgrind can't yet handle apps that throw exceptions during regular operation. Like, say, Adobe InDesign's installer. I would like to valgrind that to track down http://bugs.winehq.org/show_bug.cgi?id=11757 but I can't because valgrind doesn't handle fxrestor. I think, anyway... - Dan

Feb. 28, 2008

schroedinger 1.0 (fast implementation of Dirac video codec) released

by Dan Kegel

http://lwn.net/Articles/271058/ "Decodes HD720/25p in real-time on a Core Duo laptop" Yum. I'd like to see free codecs like this bundled with wine sometime.

Feb. 28, 2008

Re: Alistair Leslie-Hughes : msvcrt: Implement wcscpy_s.

by James McKenzie

Alexandre Julliard wrote: > "James Hawkins" <truiken(a)gmail.com> writes: > > >> If you'll read the tests, you'll see that the first test is correct >> (although it should really be >= and he should add a test for this). >> > > No, it shouldn't be >=, there's no reason to fail if the buffer is the > same size as the data. > > The failure should be when the size of the data is more than the buffer. I think that was the case for the first check. The question was for the second chunk of code. I think that it should have been less than. If the size of the data and the size of the buffer are the same, no change to the size of the buffer is needed. James McKenzie

Feb. 28, 2008

Re: Alistair Leslie-Hughes : msvcrt: Implement wcscpy_s.

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > If you'll read the tests, you'll see that the first test is correct > (although it should really be >= and he should add a test for this). No, it shouldn't be >=, there's no reason to fail if the buffer is the same size as the data. -- Alexandre Julliard julliard(a)winehq.org

Feb. 28, 2008

Re: [AppDB] Add accessible link to front page

by James McKenzie

Alexander Nicolaysen Sørnes wrote: >> On Mi, 2008-02-27 at 14:18 +0100, Alexander Nicolaysen Sørnes wrote: >> >>> Add a 'home' link to the top of the AppDB menu to make the front page >>> more accessible. >>> >>> $g = new htmlmenu("AppDB"); >>> + $g->add('Home', BASE.'index.php'); >>> >> What is more accessible in "AppDB" -> "Home" >> compared to "WineHQ Menu" -> "AppDB"? >> >> I see no difference. >> >> >> > > I thought people would expect, or find it easier, to have a home link as the > first item in a menu. > > +1 to the Home feature. James McKenzie

Feb. 28, 2008

Re: Any graphics card y'all like to see tests run on?

by James McKenzie

Stefan Dösinger wrote: > Am Mittwoch, 27. Februar 2008 05:49:57 schrieb Austin English: > >> Thanks Carl, and to the rest of the list, sorry for the noise/false >> hope to d3d/ddraw guys. >> > Just to answer your previous questions if someone else wonders the same: Some > ATI card would be useful. I have an X1600 and a radeon mobility 9000 myself, > but other cards would be good to test as well. In the codeweavers office we > have a few other cards too(older radeons and a bunch of macs) > > Testing on Macs, especially the newer laptops would be nice :) I have a MacBookPro and a MacBook here (the latter is the other person who lives here's.) James

Feb. 28, 2008

Re: Alistair Leslie-Hughes : msvcrt: Implement wcscpy_s.

by James Hawkins

On Wed, Feb 27, 2008 at 9:03 PM, James McKenzie <jjmckenzie51(a)sprintpcs.com> wrote: > Alexandre Julliard wrote: > > Module: wine > > Branch: master > > Commit: 00609d5e7824a117084f3f4b75e1aec03b60102a > > URL: http://source.winehq.org/git/wine.git/?a=commit;h=00609d5e7824a117084f3f4b7… > > > > Author: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > > Date: Wed Feb 27 19:58:04 2008 +1100 > > > > msvcrt: Implement wcscpy_s. > > > > + > > + if(size > numElement) > > > Is this correct? I think it should be different, maybe if > > (size<numElement)? > > + { > > + wcDest[0] = 0; > > + return MSVCRT_EINVAL; > > + } > > + > > + if(size > numElement) > > > This and the one above are the same. > If you'll read the tests, you'll see that the first test is correct (although it should really be >= and he should add a test for this). The second check should be removed completely. -- James Hawkins

Feb. 28, 2008

Re: Alistair Leslie-Hughes : msvcrt: Implement wcscpy_s.

by James McKenzie

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 00609d5e7824a117084f3f4b75e1aec03b60102a > URL: http://source.winehq.org/git/wine.git/?a=commit;h=00609d5e7824a117084f3f4b7… > > Author: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Wed Feb 27 19:58:04 2008 +1100 > > msvcrt: Implement wcscpy_s. > > + > + if(size > numElement) > Is this correct? I think it should be different, maybe if (size<numElement)? > + { > + wcDest[0] = 0; > + return MSVCRT_EINVAL; > + } > + > + if(size > numElement) > This and the one above are the same. > + size = numElement; > + > + memcpy( wcDest, wcSrc, size*sizeof(WCHAR) ); > + > + return 0; > +} > > > >

Feb. 28, 2008

Re: Wineserver crash in inotify code

by Dan Kegel

On Wed, Feb 27, 2008 at 5:19 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > http://bugs.winehq.org/show_bug.cgi?id=11746 > > Please give this a try: That works, thanks. - Dan

Feb. 27, 2008

Re: [Wine] Re: Windows Kernel & Executive implementation

by Stefan Dösinger

Am Mittwoch, 27. Februar 2008 21:18:28 schrieb richardvoigt(a)gmail.com: > What is your preferred utility for > filling that niche (logging I/O calls)? I never needed that; All I am logging are d3d calls, there I am using PixWin or simple wine logs, and bugle or the apple opengl profiler on the gl side. > Those particular apps are useful to the point that every competent > Windows sysadmin knows of them. Ya, but do you expect the Windows tools to be able profile Linux processes, and know about Linux syscalls, etc? So all you could use them for is auditing Windows processes inside Wine. They are Windows system utilities and thus tied to the Windows API. Trying to use them on Wine is similar to trying to use sudo in mingw on Windows, or trying to check an NTFS partition with e2fsck. Running Windows system tools is way beyond the scope of Wine IMHO.

Feb. 27, 2008

Re: [Wine] New winetricks 20080227: new verbs vbrun3, vbrun4, vbrun5, vbrun6

by Dan Kegel

On Wed, Feb 27, 2008 at 12:19 PM, Austin English <austinenglish(a)gmail.com> wrote: > > Detlef contributed verbs vbrun3 and vbrun4, thanks! > > And I added vbrun5 and vbrun6 as the preferred synonym for > > the existing verbs vbvm5 and vbrun60. That should be easier. > > Do vbvm50/vbrun60 still work? Yes, they're still recognized. Don't want to break anybody. > Great job/many thanks for all the recent additions! Thanks to the folks who send me updates!

Feb. 27, 2008

Re: [Wine] New winetricks 20080227: new verbs vbrun3, vbrun4, vbrun5, vbrun6

by Austin English

On Wed, Feb 27, 2008 at 2:11 PM, Dan Kegel <dank(a)kegel.com> wrote: > Detlef contributed verbs vbrun3 and vbrun4, thanks! > And I added vbrun5 and vbrun6 as the preferred synonym for > the existing verbs vbvm5 and vbrun60. That should be easier. > > As always, winetricks is at > http://kegel.com/wine/winetricks > > and its source repository is at > http://winezeug.googlecode.com > > Do vbvm50/vbrun60 still work? Great job/many thanks for all the recent additions! -Austin

Feb. 27, 2008

Re: [Wine] Re: Windows Kernel & Executive implementation

by richardvoigt＠gmail.com

On Wed, Feb 27, 2008 at 8:26 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Mittwoch, 27. Februar 2008 01:52:32 schrieb richardvoigt(a)gmail.com: > > > With regard to the other things in this thread, if the sysInternals > > group at Microsoft is willing to share the interface between their > > application and driver, wine could easily implement it (ultimately far > > more secure than the Windows solution), then the tools could run on > > wine. Unless you're expecting filemon running in wine to magically > > start showing all file access even from applications not using the > > Win32 API. > What is the use of just running those tools? Aren't there Linux equivalents > for it? I don't know. Certainly procmon is lightyears ahead of strace in terms of usability, plus isn't limited to a single process. A google found that KDE will be providing a GUI app named "inspektor" but I couldn't find very much on it. What is your preferred utility for filling that niche (logging I/O calls)? > > If it was a test case for better driver support, then yeah, it is useful, but > just running those apps by cloning parts of them seems wasted effort to me > Those particular apps are useful to the point that every competent Windows sysadmin knows of them.

Feb. 27, 2008

New winetricks 20080227: new verbs vbrun3, vbrun4, vbrun5, vbrun6

by Dan Kegel

Detlef contributed verbs vbrun3 and vbrun4, thanks! And I added vbrun5 and vbrun6 as the preferred synonym for the existing verbs vbvm5 and vbrun60. That should be easier. As always, winetricks is at http://kegel.com/wine/winetricks and its source repository is at http://winezeug.googlecode.com

Feb. 27, 2008

Re: winejoystick.drv: Add axis remapping support

by Adolfo R. Brandes

Hi there, On Wed, Feb 27, 2008 at 3:44 PM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Don't do that. Keep it uniform. As-is it's a pain to configure. You want to > introduce even more? Actually, this was my shot at improving that particular aspect of the configuration. As it is in dinput/joystick_linux.c, it's a bit of a shot in the dark as to what is "Slider1", "Slider2", and so on. The way I did it, you can run jstest to find out what each of your axes are named, and use those names in regedit. I realize this introduces confusion. It's just that I think the previous standard requires a bit of a revision, in that there should be a more reliable way of determining what each axis in your joystick is called (and what wine expects it to be called). Maybe joystick_linux should be patched too? > do not mix tabs and spaces! Sorry about that, you're right. I'm used to using tabs, and have just found out the hard way that wine uses 4 spaces. ;) > The way you using this function it makes much more sense to return static > text ex: > static const char *axis_name(unsigned char type) Good idea, it really does make much more sense. > BTW what will that "?" do? I don't see you comparing it against anything. The "?"s represent gaps in the ABS_* series of constants in linux/input.h, which is the basis for the naming scheme I followed (and jstest also follows, which is the whole point). The premise is that all axes will always be properly identified by linux as one of those constants. The "?" is just a way of failing on purpose, i.e., when an axis is not properly named. > Disabling axis might not be a bad thing, especially for testing. I don't > think you need to worry about extra axis on the device that are not mapped > to anything. I was worried about having two (or more) linux axes mapped to the same wine one. That's the reason behind the fatal error. > You need both X and Y axis for [a POV] to work. You have to check that both are > present. You're right, I better improve the logic here, too. > Also what about multiple POVs? Here you checking for only one. It seems that the only pertinent JOYINFOEX constants from mmsystem.h are "JOY_HASPOV" and "JOY_RETURNPOV". No "JOY_HASPOV2" ou "JOY_RETURNPOV2". I'm assuming that more hats simply won't register. Bear with me, everything I know about the Windows joystick API has been gathered from reading this driver, and it seems like there's a fundamental difference between DirectInput devices and "regular" ones. Correct me if I'm wrong, but it looks to me like multiple POVs (or more than 6 axes) aren't supported here. However, it makes sense for the user to map HAT2X and HAT2Y to the "u" and "v" axes, for example. I'll see what I can do. > Now that you can remap axis it's not guaranteed that 6th axes is the speed > and so on. Yes, that's correct. I previously tried a different approach, basing the selection of x, y, z, r, u, and v on what the axis is actually named (i.e., "Throttle" = z, "Rudder" = r), but that actually moots the whole point. It turns out that it doesn't matter what the axis' nominal function is; what matters is the order in which they appear. For instance, my joystick's rudder is actually named "Rz", which would wrongly map to "v" (as opposed to "r"). What's important is not for wine to know the difference between "Throttle" and "Rudder", but for the user to know what each axis is named and in what order they are presented to the application, so that he can then reoder them as he pleases. I'm gonna work on a better version of the patch, and thanks for the tips! Adolfo

Feb. 27, 2008

Re: [AppDB] Add accessible link to front page

by Alexander Nicolaysen Sørnes

> On Mi, 2008-02-27 at 14:18 +0100, Alexander Nicolaysen Sørnes wrote: > > Add a 'home' link to the top of the AppDB menu to make the front page > > more accessible. > > > > $g = new htmlmenu("AppDB"); > > + $g->add('Home', BASE.'index.php'); > > What is more accessible in "AppDB" -> "Home" > compared to "WineHQ Menu" -> "AppDB"? > > I see no difference. > > I thought people would expect, or find it easier, to have a home link as the first item in a menu. > -- > > By by ... Detlef

Feb. 27, 2008

Re: [AppDB] Add accessible link to front page

by Detlef Riekenberg

On Mi, 2008-02-27 at 14:18 +0100, Alexander Nicolaysen Sørnes wrote: > Add a 'home' link to the top of the AppDB menu to make the front page > more accessible. > $g = new htmlmenu("AppDB"); > + $g->add('Home', BASE.'index.php'); What is more accessible in "AppDB" -> "Home" compared to "WineHQ Menu" -> "AppDB"? I see no difference. -- By by ... Detlef

Feb. 27, 2008

Re: winejoystick.drv: Add axis remapping support

by Vitaliy Margolen

Adolfo R. Brandes wrote: > Greetings! > > The purpose of this patch is to add registry axis remapping and POV > hat support to winejoystick.drv, much like what's already in place for > dinput/joystick_linux.c. I needed this for X-Wing Alliance > (http://appdb.winehq.org/objectManager.php?sClass=application&iId=2110) > which recognizes my Thrustmaster Top Gun Fox 2 Pro USB joystick, but > not the POV hat and with the Rudder and Throttle axes switched around. > > It uses the following conventions: > > HKCU\Software\Wine\Joystick\<joyname> = <axeslist> > > or > > HKCU\Software\Wine\AppDefaults\app.exe\Joystick\<joyname> = <axeslist> > > Where <joyname> is the device name (as shown in jstest), and > <axeslist> is a comma-separated list of axis names. However, in > contrast to joystick_linux.c, the axis names are the same as in > jstest. For example, in my case jstest reports: Don't do that. Keep it uniform. As-is it's a pain to configure. You want to introduce even more? First few general notes about your patch - do not mix tabs and spaces! Set tab width to be _always_ 8 spaces! For best results just don't use tabs. Do not change formating, of the function unless you changing big part of it and you changing it to default Wine formating (4 spaces, curly brackets on their own line). > +static char *axis_name(char *str, unsigned char type, int len) { > + switch(type) { > + case ABS_X: > + memcpy(str,"X",len - 1); > + break; > + case ABS_Y: The way you using this function it makes much more sense to return static text ex: static const char *axis_name(unsigned char type) { switch (type) { case ABS_X: return "X"; case ABS_Y: return "Y"; case ABS_Z: return "Z"; default: return "?"; } } BTW what will that "?" do? I don't see you comparing it against anything. > + else > + ERR("Not all joystick axes mapped: %d axes, %d arguments\n", nrOfAxes, j); Disabling axis might not be a bad thing, especially for testing. I don't think you need to worry about extra axis on the device that are not mapped to anything. > + for (i = 0; i < nrOfAxes; i++) > + switch(axis_map[i]) { > + case ABS_HAT0X: > + case ABS_HAT0Y: > + lpCaps->wCaps |= JOYCAPS_HASPOV; > + break; > + } You need both X and Y axis for it to work. You have to check that both are present. Also what about multiple POVs? Here you checking for only one. > switch(nrOfAxes) { > - case 6: lpCaps->wCaps |= JOYCAPS_HASV; > - case 5: lpCaps->wCaps |= JOYCAPS_HASU; > - case 4: lpCaps->wCaps |= JOYCAPS_HASR; > - case 3: lpCaps->wCaps |= JOYCAPS_HASZ; > - /* FIXME: don't know how to detect for > - JOYCAPS_HASPOV, JOYCAPS_POV4DIR, JOYCAPS_POVCTS */ > + case 6: > + lpCaps->wCaps |= JOYCAPS_HASV; > + lpCaps->wVmax = 0xFFFF; > + case 5: > + lpCaps->wCaps |= JOYCAPS_HASU; > + lpCaps->wUmax = 0xFFFF; > + case 4: > + lpCaps->wCaps |= JOYCAPS_HASR; > + lpCaps->wRmax = 0xFFFF; > + case 3: > + lpCaps->wCaps |= JOYCAPS_HASZ; > + lpCaps->wZmax = 0xFFFF; Now that you can remap axis it's not guaranteed that 6th axes is the speed and so on. Vitaliy.

Feb. 27, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

Dan Kegel wrote: > Where did you report it? I can't find a bug report. not formal report, just post to this forum days ago. > Would you like to file a Wine bug, or should I? Could you please file a Wine bug. It is easier for you to write an equivalent C script to reproduce the bug than I. And I'm not sure if any wine developers will be able to testing using J if I report it in the current format. regards,

Feb. 27, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by Dan Kegel

On Wed, Feb 27, 2008 at 8:48 AM, bill lam <cbill.lam(a)gmail.com> wrote: > The app is a package called 'platimg' of J language. > > I had reported this and I believed that it is the negative stride that caused > the problem. Where did you report it? I can't find a bug report. Would you like to file a Wine bug, or should I? > NB. load and decode a jpeg file into 2D integer matrix with each integer > NB. for one pixel element. > readimg1 'picture.jpg' > > where definition of readimg1 is as follows > > readimg1=: 3 : 0 > GdiplusStartup (TOK=.,_1);GdiplusStartupInput;0 > GdipCreateBitmapFromFile y;BMP=.,_1 > z=. bmpARGB {.BMP > GdiplusShutdown {.TOK > z > ) > > bmpARGB=: 3 : 0 > DATA=. i.4%~#BitmapData > GdipBitmapLockBits y;0;ImageLockModeRead;PixelFormat32bppARGB;DATA > 'w h s f p r'=. DATA > z=. (h,w)$memr p,0,(w*h),JINT > GdipBitmapUnLockBits y;DATA > GdipDisposeImage y > z > ) > > Here GdipBitmapLockBits has 2 issues, > > 1. GdipBitmapLockBits accept a null for rect (the second argument) to stands for > the entire region. I can workaround this by calling GdipGetImageWidth and > GdipGetImageHeight to construct the rect. However > > 2. the data returned GdipBitmapLockBits does not point a valid bitmap data, so > the when trying memory read in the following > z=. (h,w)$memr p,0,(w*h),JINT > J gives raise a domain error. (but no crash, so that no crash log) > > Scripts of J can be difficult to understand, but since this example calls > gdiplus api so that you can follow it without much difficulty and write an > equivalent c program to test it. > > current version of J can be downloaded here. > http://www.jsoftware.com/beta.htm > after installation, run package manager that comes with J to install the platimg > addon. Cool, thanks. I also see it's documented here: http://olegykj.sourceforge.net/scripts/platimg.htm - Dan

Feb. 27, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

Dan Kegel wrote: > What app is this, and what is it about Wine's gdiplus that > makes you need to override it? Does the app crash, > or does it just look bad? If it crashes, what's the crash log? > The app is a package called 'platimg' of J language. I had reported this and I believed that it is the negative stride that caused the problem. NB. load and decode a jpeg file into 2D integer matrix with each integer NB. for one pixel element. readimg1 'picture.jpg' where definition of readimg1 is as follows readimg1=: 3 : 0 GdiplusStartup (TOK=.,_1);GdiplusStartupInput;0 GdipCreateBitmapFromFile y;BMP=.,_1 z=. bmpARGB {.BMP GdiplusShutdown {.TOK z ) bmpARGB=: 3 : 0 DATA=. i.4%~#BitmapData GdipBitmapLockBits y;0;ImageLockModeRead;PixelFormat32bppARGB;DATA 'w h s f p r'=. DATA z=. (h,w)$memr p,0,(w*h),JINT GdipBitmapUnLockBits y;DATA GdipDisposeImage y z ) Here GdipBitmapLockBits has 2 issues, 1. GdipBitmapLockBits accept a null for rect (the second argument) to stands for the entire region. I can workaround this by calling GdipGetImageWidth and GdipGetImageHeight to construct the rect. However 2. the data returned GdipBitmapLockBits does not point a valid bitmap data, so the when trying memory read in the following z=. (h,w)$memr p,0,(w*h),JINT J gives raise a domain error. (but no crash, so that no crash log) Scripts of J can be difficult to understand, but since this example calls gdiplus api so that you can follow it without much difficulty and write an equivalent c program to test it. current version of J can be downloaded here. http://www.jsoftware.com/beta.htm after installation, run package manager that comes with J to install the platimg addon. regards,

Feb. 27, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by Dan Kegel

On Wed, Feb 27, 2008 at 7:00 AM, bill lam <cbill.lam(a)gmail.com> wrote: > In current wine version *.55, the built-in version of comctl32 does work for my > app so that I do not need the native comctl32 anymore. Now only odbc and gdiplus > need to be overrided. What app is this, and what is it about Wine's gdiplus that makes you need to override it? Does the app crash, or does it just look bad? If it crashes, what's the crash log?

Feb. 27, 2008

Re: Bug for icons in toolbar (and how to deal with this in bugzilla)

by Juan Lang

Hi Paul, > This is about 'autoruns' from SysInternals (Microsoft) > > The icons on the first row of buttons look fine. All other rows however show the > icons below the position they should actually be. > > I've looked at our bugzilla and found two bugs that look the same: > > http://bugs.winehq.org/show_bug.cgi?id=6948 > http://bugs.winehq.org/show_bug.cgi?id=8813 > > Both are for different applications. > > Should I open a new one for 'autoruns' or use one of the existing ones? Open a new bug. If all three bugs can be shown to be caused by the same defect, they can be closed together. Since they're in different apps, the bugs should be different. --Juan

Feb. 27, 2008

Bug for icons in toolbar (and how to deal with this in bugzilla)

by Paul Vriens

Hi, This is about 'autoruns' from SysInternals (Microsoft) The icons on the first row of buttons look fine. All other rows however show the icons below the position they should actually be. I've looked at our bugzilla and found two bugs that look the same: http://bugs.winehq.org/show_bug.cgi?id=6948 http://bugs.winehq.org/show_bug.cgi?id=8813 Both are for different applications. Should I open a new one for 'autoruns' or use one of the existing ones? -- Cheers, Paul.

Feb. 27, 2008

Re: New winetricks 20080226: adds dotnet11 verb

by bill lam

Dan Kegel wrote: > Which apps? > What version of comctl32 and gdiplus do they require? I check version of gdiplus from pp viewer 2003 (winetricks) and that from win-xp, they are the same version. I must had use my old version from win-me that caused problem. Sorry for the noise. In current wine version *.55, the built-in version of comctl32 does work for my app so that I do not need the native comctl32 anymore. Now only odbc and gdiplus need to be overrided. Thank you to all wine developers. regards,

Feb. 27, 2008