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

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