Re: attrib.exe[2/4] add usage function
On Sun, Aug 16, 2009 at 2:12 PM, EA Durbin wrote:
>
>
>
> Windows Live™: Keep your life in sync. Check it out.
>
>
>
Hi EA
I posted these comments on bugzilla before I also saw that you
submitted the patchset:
in patch 2, you should just use one call to printf or just puts, one call per
line is not necessary, just do as such:
printf("foo\n"
"bar\n"
"baz\n");
Why does the usage function return 1? I see that you propagate it as
the return value on
incorrect usage, attrib.exe still returns 0 on Windows if you give an invalid
option:
C:\Users\jeffz>attrib +J foo
Invalid switch - +J
C:\Users\jeffz>echo %ERRORLEVEL%
0
-Jeff
Re: about video memory detection in wine
2009/8/15 Stefan Dösinger : > I'll send the patches on monday with a few minor improvements. > I think the spec should be fixed/extended first.
Re: Appinstall testing guide up on the wiki
On Sat, Aug 15, 2009 at 11:58 AM, Austin English wrote: > James asked me to put up a guide for testing applications with > Appinstall. The guide looks great. Will there be any service to facilitate sharing of scripts between users? Matt
Re: Appinstall testing guide up on the wiki
Hi Austin, On Sat, Aug 15, 2009 at 2:58 PM, Austin English wrote: > It handles the process of automatically downloading, running, > verifying and testing various applications under Wine, against > previously verified Windows behavior. It can test for regressions of > popular applications/features, as well as making sure bugs aren't > subtly fixed. The wrapper script handles fresh WINEPREFIX's, > winetricks dependencies, timeouts of runaway/hung tests, and parsing > of the output logs. I've just given this a cursory look but I like it. I think what we need to do to insure that its used and that scripts are kept up to date is encourage wine appdb submission of scripts for applications that are listed as gold/platinum. My thinking is that if we get good scripts in appdb then the app maintainer wont have to carry all the work of regression testing it at each release. If someone finds a regression they can use the script to save time as they rollback and test prior winehq releases and work with that app advocate to track down the issue. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: When do regressions become high priority for developers?
My personal priority are similar to Vincent's. If I cause a regression, I try to fix it *) If its an easy fix, useful hints in the bug report etc, and my time permits *) Or if the fix is important to the one who pays my electricity bills(CodeWeavers) *) If the regression is a real regression because the patch had a flaw, and not because it happened to uncover existing other bugs(for example, I do NOT consider Bug 18401 a regression) *) If the regression happens in an area of code that is generally shaky and needs more attention to fix. In that case just trying to patch out the regression will cause new regressions - directly working on the big fix as time permits is usually better. There are surely some exceptions to this etc and I guess I left some easier regressions I caused untouched because I simply lost track of them. Every now and then they get randomly fixed or someone else picks them up.
Re: When do regressions become high priority for developers?
I can't speak for the rest of developers, but for me bugs become a priority if: * They are regressions caused by a patch that I wrote. * They are in an area that I know well (gdiplus, windowscodecs, explorer/appbar.c). * CodeWeavers, my employer, decides that they should. There are only a few areas of the code that I know well. I can and often do work in other areas, but my progress is slower there. Given that volunteer developers (including CodeWeavers) decide on their priorities in their own ways, it's quite possible (even likely) that there are bugs that should be important to the Wine project but are not important to any individual developer. -- Vincent Povirk
Re: about video memory detection in wine
Am Saturday 15 August 2009 09:25:27 schrieb Sun, Sunny: > It doesn't matter that the total memory is not documented, as long as it > can tell you the true value. The concern is that lack of spec documentation makes it harder to maintain the code. Like the GL_ATI_texture_compression_3dc code, which is essentially based on guessing. However, for ATI_meminfo we have your info in the mailing list archives, and if the extension is eventually updated its ok I guess. I'll send the patches on monday with a few minor improvements.
RE: When do regressions become high priority for developers?
>That's a tough question. Note that Photoshop CS3 >installer has been busted for months Yep, the same problem busts the CS4 installer as well, so both CS3 and CS4 has gone from working(with tricks, practically flawless in CS4s case) to non-installable. >From what I have understood, this is not really a regression, but rather a >redesign which have caused the application to fail to install. I would not weigh Perrys problem against mine(not that I think CSx are low-profile apps), but rather say that regressions seems to be more ok when the cause is a redesign, and not when it is a common bug. I would not agree with that, though. This project is, for good reason, very cautious about accepting patches of bugs and should also be so with new functionality. Now I am not aware of the reasons for the redesign, they might be valid, but I would still think that we could learn from this in some way. If not a policy, but maybe some kind of way to tell the community of things like this happening? Yes, the development versions are development versions in the projects view, however, the community treats them as real releases. Come to think of it, the project does it as well. Bug reports regarding the release version are somewhat frowned upon. Isn't that a sign that major releases are a bit too far apart? //Nicklas PS. This is especially annoying since I've just had a positive conversation with Adobe about helping out with providing a download location for atmlib.dll so that Dan and Austin could include it into winetricks, removing the last really unsafe step of the installation. I just hope they don't watch the appdb. But then I am a developer, so I hardly notice frustration anymore. :-) DS.
Appinstall testing guide up on the wiki
Howdy all, James asked me to put up a guide for testing applications with Appinstall. It's on the wiki (which seems to be down at the moment) at http:/wiki.winehq.org/Appinstall_Testing. I had a couple people read over it to make sure I didn't miss anything obvious (or omit stuff that seems obvious to me). If you've got a few minutes and want to write a test for your favorite downloadable application, give it a try. AutoHotKey is pretty simple to pick up, and basic tests (e.g., making sure app launches and doesn't crash) is pretty simple to write. Send me your tests and I'll add them to the test suite. If anything in the guide is unclear, please let me know and I'll update it. If everything looks good, I'll e-mail wine-users, so users can test their favorite apps. For those who haven't followed, Appinstall is my Summer of Code project to automate application testing using AutoHotKey + a wrapper shell script. It handles the process of automatically downloading, running, verifying and testing various applications under Wine, against previously verified Windows behavior. It can test for regressions of popular applications/features, as well as making sure bugs aren't subtly fixed. The wrapper script handles fresh WINEPREFIX's, winetricks dependencies, timeouts of runaway/hung tests, and parsing of the output logs. Source is at http://winezeug.googlecode.com/svn/trunk/appinstall/ -- -Austin
re: When do regressions become high priority for developers?
Matt Perry wrote: > When do regressions become high priority for developers? > [SecureCRT broke with wine-0.9.54, > http://bugs.winehq.org/show_bug.cgi?id=13583 ] > 14 months seems to be more than reasonable to repair a regression. That's a tough question.Note that Photoshop CS3 installer has been busted for months, and is in a similar limbo. (We even know how to fix it, but nobody has time at the moment.) Often people will fix regressions that pop up after their changes. In this case, the developer is no longer around. Also, this regression might be a 'we exposed a hole in wine' rather than a plain old bug, so the fix might mean writing a bunch of new code. In this case, the previous version of the app works under Wine, so perhaps that makes a fix less urgent. Sometimes it helps to attract the attention of the app's developer. I'll ping them and see what they say, maybe they can tell us where we're going wrong. Occasionally one of the true hotshots (like AF) will take an interest and diagnose the cause. That makes it a lot easier to fix, the cost to fix the bug becomes much less uncertain, and if some company needs the app to work, a paid fix becomes more affordable at that point. But even with that, sometimes it's ages before the bug bubbles up to the top of anyone's priorities. I wish I had a better answer for you! - Dan
Re: New Wine Gecko 1.0.0 RC
André Hentschel wrote: Just tried to copy in some german dictionaries from my firefox but it didnt work. Then i deleted both the copied in german and the standard english ones and the spellchecker was disabled. That looks much better when writing nonenglish. I've sent a patch that disables spellchecker in all languages. Jacek
When do regressions become high priority for developers?
When do regressions become high priority for developers? I ask because I opened bug 13583 over 14 months ago, provided all the information requested, as did other people, and nothing has happened. The program worked with Wine 0.9.53 but has been broken since then. I have continued to test the program on newer versions of Wine occasionally, but the bug persists. In fact, I am starting to see more regressions in recent Wine builds that prevent me from getting to the point in the program where I can test the regression reported in the bug report. 14 months seems to be more than reasonable to repair a regression. I'm worried about having to forever maintain a separate installation of Wine just to use this program. I'll be happy to test further if someone is going to work on this bug but right now my efforts seem to be for naught. Should I bother to continue to give this bug any attention or just abandon it and focus my efforts elsewhere? Matt
Re: d3d10: Add annotation skipping.
On Sat, Aug 15, 2009 at 07:37:12PM +0200, Henri Verbeet wrote: > 2009/8/15 Rico Sch?ller : > > +static inline void parse_annotation(const char **ptr, unsigned int count) ^^ And there is no reason to inline something this size David -- David Laight: da...@l8s.co.uk
Re: d3d10: Add annotation skipping.
2009/8/15 Rico Schüller :
> +static inline void parse_annotation(const char **ptr, unsigned int count)
> +{
> +unsigned int i;
> +DWORD d[3];
> +
> +if(count == 0) return;
> +
> +FIXME("Skipping %#x annotation(s):\n", count);
> +for (i = 0; i < count; ++i)
> +{
> +read_dword(ptr, &d[0]);
> +read_dword(ptr, &d[1]);
> +read_dword(ptr, &d[2]);
> +FIXME("\t0x%08x 0x%08x 0x%08x\n", d[0], d[1], d[2]);
> +}
> +}
Please try to stick to the general structure of the other parsing
functions. I.e., something like this:
static void parse_fx10_annotation(const char **ptr)
{
skip_dword_unknown(ptr, 3);
}
and
{
unsigned int i;
...
read_dword(ptr, &p->annotation_count);
for (i = 0; i < p->annotation_count; ++i)
{
parse_fx10_annotation(ptr);
}
...
}
Re: Writing Conformance Tests
2009/8/15 Mike : > Being new to wine, I was thinking about starting to learn the system by > writing conformance tests. > > Most of us do NOT have access to machines of every flavor of Windows. Is > there a standard method to deal with differences across platforms? > > I realize that often, this won't be an issue, but was wondering what (if any) > the practice is for write across platforms without access to these platforms. Write the tests and check them against Wine and at least one version of Windows (more if you have access to them). Once the tests are in, you can then check the results on the http://test.winehq.org/data/ page. If you don't have access to the failing version/configuration, you can post the patch to wine-devel and ask for testing on XYZ version of Windows. HTH, - Reece
AF_Irda.h header file
Hi,
Wine was missing the AF_Irda.h header file so I decided to write one.
Unfortunately someone else had the same idea and the result was commited 3
days ago... :)
Nonetheless, I attached my version, it contains all definitons of the
Windows SDK 7 header though is not WS_tified.
Thomas
/*
* Copyright (C) the Wine project
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
#ifndef __AFIRDA__
#define __AFIRDA__
#ifndef _WINSOCKAPI_
typedef unsigned char u_char;
typedef unsigned short u_short;
typedef unsigned intu_int;
typedef unsigned long u_long;
#endif
#define WINDOWS_AF_IRDA 26
#define WINDOWS_PF_IRDAWINDOWS_AF_IRDA
#define WCE_AF_IRDA 22
#define WCE_PF_IRDAWCE_AF_IRDA
#ifndef AF_IRDA
#define AF_IRDAWINDOWS_AF_IRDA
#endif
#define IRDA_PROTO_SOCK_STREAM 1
#define PF_IRDAAF_IRDA
#define SOL_IRLMP 0x00FF
#define IRLMP_ENUMDEVICES 0x0010
#define IRLMP_IAS_SET 0x0011
#define IRLMP_IAS_QUERY 0x0012
#define IRLMP_SEND_PDU_LEN 0x0013
#define IRLMP_EXCLUSIVE_MODE0x0014
#define IRLMP_IRLPT_MODE0x0015
#define IRLMP_9WIRE_MODE0x0016
#define IRLMP_TINYTP_MODE 0x0017
#define IRLMP_PARAMETERS0x0018
#define IRLMP_DISCOVERY_MODE0x0019
#define IRLMP_SHARP_MODE0x0020
#define IAS_ATTRIB_NO_CLASS 0x0010
#define IAS_ATTRIB_NO_ATTRIB0x
#define IAS_ATTRIB_INT 0x0001
#define IAS_ATTRIB_OCTETSEQ 0x0002
#define IAS_ATTRIB_STR 0x0003
#define IAS_MAX_CLASSNAME 64
#define IAS_MAX_ATTRIBNAME 256
#define IAS_MAX_USER_STRING256
#define IAS_MAX_OCTET_STRING 1024
enum
{
LM_HB1_PnP = 1,
LM_HB1_PDA_Palmtop = 2,
LM_HB1_Computer = 4,
LM_HB1_Printer = 8,
LM_HB1_Modem = 16,
LM_HB1_Fax = 32,
LM_HB1_LANAccess = 64,
LM_HB_Extension = 128,
LM_HB2_Telephony = 1,
LM_HB2_FileServer= 2
};
#define LmCharSetASCII 0
#define LmCharSetISO_8859_1 1
#define LmCharSetISO_8859_2 2
#define LmCharSetISO_8859_3 3
#define LmCharSetISO_8859_4 4
#define LmCharSetISO_8859_5 5
#define LmCharSetISO_8859_6 6
#define LmCharSetISO_8859_7 7
#define LmCharSetISO_8859_8 8
#define LmCharSetISO_8859_9 9
#define LmCharSetUNICODE 255
typedef u_longLM_BAUD_RATE;
#define LM_BAUD_1200 1200
#define LM_BAUD_2400 2400
#define LM_BAUD_9600 9600
#define LM_BAUD_1920019200
#define LM_BAUD_3840038400
#define LM_BAUD_5760057600
#define LM_BAUD_115200 115200
#define LM_BAUD_576K576000
#define LM_BAUD_1152K 1152000
#define LM_BAUD_4M 400
#define LM_BAUD_16M 1600
typedef struct
{
u_long nTXDataBytes;
u_long nRXDataBytes;
LM_BAUD_RATEnBaudRate;
u_long thresholdTime;
u_long discTime;
u_short nMSLinkTurn;
u_char nTXPackets;
u_char nRXPackets;
}
LM_IRPARMS, *PLM_IRPARMS;
typedef struct _SOCKADDR_IRDA
{
u_short irdaAddressFamily;
u_char irdaDeviceID[4];
charirdaServiceName[25];
}
SOCKADDR_IRDA, *PSOCKADDR_IRDA, FAR *LPSOCKADDR_IRDA;
typedef struct _WINDOWS_IRDA_DEVICE_INFO
{
u_char irdaDeviceID[4];
charirdaDeviceName[22];
u_char irdaDeviceHints1;
u_char irdaDeviceHints2;
u_char irdaCharSet;
}
WINDOWS_IRDA_DEVICE_INFO, *PWINDOWS_IRDA_DEVICE_INFO, FAR *LPWINDOWS_IRDA_DEVICE_INFO;
typedef struct _WCE_IRDA_DEVICE_INFO
{
u_char irdaDeviceID[4];
charirdaDeviceName[22];
u_char Reserved[2];
}
WCE_IRDA_DEVICE_INFO, *PWCE_IRDA_DEVICE_INFO;
typedef WIND
Writing Conformance Tests
Being new to wine, I was thinking about starting to learn the system by writing conformance tests. Most of us do NOT have access to machines of every flavor of Windows. Is there a standard method to deal with differences across platforms? I realize that often, this won't be an issue, but was wondering what (if any) the practice is for write across platforms without access to these platforms. Thanks, Mikey
Re: [8/21] comctl32: Add basic structure for IImageList interface
Hi Detler, > Disassembling Windows Code is not allowed for Wine. > You should have know that and you should know the result. I'd just like to explain what it was exactly that I did, to possibly clear up any confusion. After submitting a set of patches, and receiving the comment that HIMAGELIST/IImageList should be the same, I was wondering about maintaining internal compatibility with the "old" structure, since it looked to me as if the existing HIMAGELIST structure had been specifically ordered to be compatible with Windows (see the commit at http://tinyurl.com/mfwl54 for instance - I presumed there was a reason behind this involving application compatibility). I then wrote a very simple little test program which took the existing Wine structural definition of HIMAGELIST, and then cast that onto the Windows structure, and performed a couple of tests to compare various values (eg, the "magic" value), to see if they were compatible. This was the extent of my "debugging" of the code, and I did not then make use of any of the seemingly-nonsensical values the program returned. The code in the header file in the patch (http://tinyurl.com/l4ffln) is the only part that was "affected" by this, and I simply moved the two structure members I had previous defined in another structure to the HIMAGELIST structure. I made no effort to further investigate or make compatible the structure with the native Windows structure. Additionally, at no time did I actively "disassemble" any Windows code, or do anything more than compare the first few values in the structure with this test program. I have since been made aware that even this is possibly unacceptable, and I understand that I may have made a mistake in doing so. Possibly I screwed up a bit, I accept that. I would just like to reiterate however that it was a very crude form of "debugging", as detailed above, and that no changes to the code were ultimately made as a result of it. No other code I have ever written has involved similar practices, and I would personally argue that this piece of code itself is for the largest part unaffected. I appreciate your comments, and hopefully this message will help explain things. It was obviously never my intention to put the project into jeopardy by replicating MS code directly (and, of course, this is something I have not done anyway). Cheers, -- Owen Rudge http://www.owenrudge.net/
Re: [8/21] comctl32: Add basic structure for IImageList interface
On Mi, 2009-08-12 at 23:31 +0100, Owen Rudge wrote: > > You can't do that. HIMAGELIST should be the same thing as IImageList. > > Hmm. Looking at the HIMAGELIST/IImageList internals in a debugger on > Windows, the layout appears to be ... :-( Disassembling Windows Code is not allowed for Wine. You should have know that and you should know the result. -- By by ... Detlef
New winetricks 20090815: new verbs directplay, openwatcom, dotnet30
Another fortnight, another winetricks. Main changes are Solaris portability improvements, more verbs support silent install, and three new verbs: directplay will be handy for those couple dozen networked games that use that API. dotnet30 probably isn't ready for prime time, but it's there for testing. openwatcom is handy for those of us working on the win16 test suite. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes since 20090716: r634 | daniel.r.kegel | 2009-08-15 02:22:33 -0700 (Sat, 15 Aug 2009) | 12 lines Improve error dialog to use kde or gnome's dialog program as appropriate (important since Sun doesn't ship xmessage!) and check ownership of .winetrickscache Thanks to Matt Lewandowsky for this patch. Also fix cabextract and unzip tests to show an error dialog in gui case and fix dogui() to not explode if WINETRICKS_TMP doesn't exist yet r633 | austinenglish | 2009-08-14 09:22:45 -0700 (Fri, 14 Aug 2009) | 1 line add OpenWatcom verb r632 | austinenglish | 2009-08-14 09:20:32 -0700 (Fri, 14 Aug 2009) | 1 line ie6 can install silently too r631 | daniel.r.kegel | 2009-08-14 07:07:15 -0700 (Fri, 14 Aug 2009) | 11 lines Use die for showing the "you don't own" error, so gui users can see it Check WINEPREFIX rather than HOME if appropriate (based on a patch by Matt Lewandowsky) r629 | daniel.r.kegel | 2009-08-13 00:01:49 -0700 (Thu, 13 Aug 2009) | 4 lines Don't use test -O, as it's not present on older systems. Based on a patch by Matt Lewandowsky r628 | daniel.r.kegel | 2009-08-12 22:58:10 -0700 (Wed, 12 Aug 2009) | 4 lines Patch from Matt Lewandowsky to work on systems with classic tar instead of gnu tar (i.e. old solaris). r622 | austinenglish | 2009-08-10 19:06:28 -0700 (Mon, 10 Aug 2009) | 2 lines add directplay for Windows 98 (from Directx9) (Patch by Hugh Perkins) r619 | daniel.r.kegel | 2009-08-08 15:34:47 -0700 (Sat, 08 Aug 2009) | 4 lines Different workaround for Samyak problems (see Focht's dotnet20 appdb entry). Patch from Austin, lightly tweaked. r618 | daniel.r.kegel | 2009-08-08 15:25:26 -0700 (Sat, 08 Aug 2009) | 2 lines Update to handle new gecko. (Patch from Austin, with a few tweaks by me.) r615 | daniel.r.kegel | 2009-08-08 07:10:41 -0700 (Sat, 08 Aug 2009) | 3 lines added dotnet30. (Install finishes with current wine; haven't tried running any apps yet.) r613 | austinenglish | 2009-08-07 15:08:12 -0700 (Fri, 07 Aug 2009) | 2 lines make more installers silent, if possible. Adjust winetrickstest to match r605 | austinenglish | 2009-08-01 10:55:56 -0700 (Sat, 01 Aug 2009) | 2 lines update sha1sums/broken urls
Wine icon refresh
On Sa, 2009-08-08 at 20:42 +0100, Joel Holdsworth wrote: > If you want, I can draw a Tango-style icon for it, as part of my work in > progress wine icon refresh: http://www.airwebreathe.org.uk/wine-icon/ They look nice, but I have some comments: idb_std_large.bmp and idb_std_small.bmp: The print preview icon looks like a printer and has a lens in on size. The printing icon looks like a printer and has a lens in on size The search icon looks like the print preview icon on Windows You should use seperate icons and properly use the lens. For printing, use a printer icon (Windows also use a printer icon here) For the print preview, use something different. (Windows is using a full paper sheet with a lens) You can test your icons with: wine wordpad programs: The Wine glass do not have a consistent size. I prefer using the smaller Wine glass, but then the small icons (16/22) are hard to merge. winetest: The icons for all other programs have the Wine glass on the other side. -- By by ... Detlef
RE: about video memory detection in wine
Hi Here I just want to tell you that if a user uses an old driver that we don't support querying total memory will lead to vidmem = 0, that is unexpected, so we should have a check. It doesn't matter that the total memory is not documented, as long as it can tell you the true value. And for the old card that doesn't support ATI_meminfo can still go the fall back path. I think the biggest benefit from using this extension is that you don't have to update the vidmem list for newly realeased ATI cards, and you can get the correct amount of video memory for the same render string but with different video memory (eg: HD4870 may have 1GB memory or only 512MB memory) Regards Sunny -Original Message- From: Stefan Dösinger [mailto:stefandoesin...@gmx.at] Sent: Saturday, August 15, 2009 12:31 AM To: Sun, Sunny Cc: Roderick Colenbrander; wine-devel@winehq.org Subject: Re: about video memory detection in wine Am Friday 14 August 2009 18:01:07 schrieb Sun, Sunny: > +if(gl_info->vidmem < 64 * 1024 * 1024) > +gl_info->vidmem = 64 * 1024 * 1024; I guess the idea is that no ATI card that was ever supported on fglrx has less than 64 mb of memory? My old radeon 9000, which isn't supported by fglrx since years now has 64 MB. Does this hold true for radeon 8500 cards too? I think I'll use the guessed amount of vidmem in this case instead of hardcoding 64 MB. Using the undocumented value and the check for older drivers which don't support it is a bit hacky, but its a well-isolated hack and avoids a lot of problems, so it should be ok.
