Re: Keeping people from trying iTunes in Wine?

[Luke Benstead]

On 9 September 2010 15:53, Dan Kegel  wrote:

> Scott wrote:
> > This would be relatively simple to implement, and would even
> > be doable with a shell script outside of Wine.  Just md5sum
> > the .exe, compare it with a blacklist, pop the warning if so,
> > and if not pass it to the normal Wine process.
>
> You'd probably want to sha1sum only the first megabyte
> or so, since getting the checksum of a gigabyte
> executable would really slow things down.
>
> And you might want to do it only for files that
> are doubleclicked on, i.e. in the desktop integration,
> rather than messing with the real wine.
> - Dan
>
>
> I brought up a long time ago the idea of having something like this that
checked the current rating in the appdb. So exe files are associated with
the appdb entry and double-clicking would say something like: "This Windows
application is rated as Bronze and may not run correctly" or something.

Luke.

Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

[Luke Benstead]

On 20 July 2010 04:37, Dan Kegel  wrote:

> Quoth Linus:
>
> "Ask the Wine people what strange open-function-from-hell they are
> interested in."
>
> Full message follows.  Discussion archived at e.g.
> http://marc.info/?l=linux-kernel&m=127955270231189&w=2
>
>
That link didn't work for me, it's on the LKML archive here:
http://lkml.org/lkml/2010/7/19/103

Luke.

Re: Please remove / block user from bugzilla

[Luke Benstead]

> How do frequent wine committers, and especially Alexandre, feel about
> > these two issues?
> I'd say Alexandre's opinion is pretty clear, as always:
> http://www.winehq.org/pipermail/wine-devel/2010-February/081744.html.
>
>
That's doesn't settle this at all, Alexandre is almost certainly referring
to the bug number in the patch itself there, rather than the subject line.

Luke.

Re: Please remove / block user from bugzilla

[Luke Benstead]

> > - Misha; I told him tests were ok to submit during a code freeze; this is
> true,
> > given that Alexandre accepted tests as last as last Friday.  I should
> have
> > told him that tests which add stubs probably aren't ok, but he learned
> > that as soon as he submitted.
> > http://www.winehq.org/pipermail/wine-devel/2010-June/084632.html
> > so that seems fine.
> >
> From the look of things Misha will be ok, but I imagine he would have
> been anyway.
>
> But there are also cases like e.g.
> http://bugs.winehq.org/show_bug.cgi?id=21233#c8 where you completely
> miss the real issues in the patch, and instead recommend referring to
> a bug number in the commit log,
>

Probably not my place to wade in here, but that's not true, he didn't
mention the commit log:

"Be sure to mention in the post that it fixes

http://bugs.winehq.org/show_bug.cgi?id=21233";



I'm pretty sure he meant in the email when he emails wine-patches rather
than in the commit log.

I've got to say Henri, I think you are being a little unfair here. Yes,
possibly Dan has given flawed advice in the past, but it's nothing that a
private email or chat on IRC wouldn't have solved.

Launching into a tirade against him publically isn't helping anything, all
these instances are Dan trying to help out, quite obviously not to be
"insidious" or to harm the project.

Luke.

Re: ddraw: Move complex surface destruction into its own function

[Luke Benstead]

Ok I wasn't sure as it's pretty trivial. I'll resend along with the others
after 1.2.

On Jun 28, 2010 8:36 PM, "Henri Verbeet"  wrote:

On 28 June 2010 20:03, Luke Benstead  wrote: > Needed to
properly fix ddraw surfac...
That's of course not appropriate during code freeze.

Re: Documentation?

[Luke Benstead]

On 14 March 2010 12:08, Paul Vriens  wrote:
> On 03/14/2010 11:58 AM, Paul Vriens wrote:
>>
>> On 03/14/2010 11:45 AM, Luke Benstead wrote:
>>>
>>> On 14 March 2010 10:03, Roderick Colenbrander
>>> wrote:
>>>>
>>>> On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchie
>>>> wrote:
>>>>>
>>>>> On 03/12/2010 11:01 AM, André Hentschel wrote:
>>>>>>
>>>>>> Hi Folks,
>>>>>> As we are getting somehow closer to Wine 1.2 i wonder how important
>>>>>> updates on the Documentation are.
>>>>>> Further i am confused about sending patches, should they just
>>>>>> change the
>>>>>> git-repo "docs" or the pages on the website or both?
>>>>>>
>>>>>
>>>>> The website pages are supposed to be automatically generated from
>>>>> the docs
>>>>> every release. So patch the docs themselves.
>>>>>
>>>>> Not sure if this process still works though.
>>>>>
>>>>> Thanks,
>>>>> Scott Ritchie
>>>>>
>>>>
>>>> I thought the plans were to attempt to move all documentation (in an
>>>> updated form) to the Wiki. We would then need some mechanism to create
>>>> documentation out of the wiki. Myself I rather update the wiki when I
>>>> encounter an issue than that I update the old docs.
>>>>
>>>> Roderick
>>>>
>>>>
>>>>
>>>
>>> While on the subject of documentation... would it be a good idea to
>>> begin documenting functions with something like Doxygen or similar?
>>> I'm just wondering if we could be building our own, much more
>>> accurate, MSDN. Is there a reason that Wine isn't documented in this
>>> way?
>>
>> We do have (the autogenerated) http://source.winehq.org/WineAPI/
>>
>> I know there is (was) an issue with the winapi tool so I can't tell if
>> the API documentation on that page is accurate.
>>
>
> I think the page I mentioned is fine.
>
> It's http://www.winehq.org/winapi_stats that didn't have an update in a
> while due to winapi issues.
>
> --
> Cheers,
>
> Paul.
>


Oh, I had actually seen that auto-generated documentation once before
then lost it - still there are many functions without documentation.

Would documentation-only patches be accepted? For example, I can use
my lunch break at work to document functions but it's not long enough
to do any serious hacking. I only ask because I can't remember seeing
documentation only patches on wine-patches :)

Luke.

Re: Documentation?

[Luke Benstead]

On 14 March 2010 10:03, Roderick Colenbrander  wrote:
> On Sat, Mar 13, 2010 at 11:40 PM, Scott Ritchie  wrote:
>> On 03/12/2010 11:01 AM, André Hentschel wrote:
>>>
>>> Hi Folks,
>>> As we are getting somehow closer to Wine 1.2 i wonder how important
>>> updates on the Documentation are.
>>> Further i am confused about sending patches, should they just change the
>>> git-repo "docs" or the pages on the website or both?
>>>
>>
>> The website pages are supposed to be automatically generated from the docs
>> every release.  So patch the docs themselves.
>>
>> Not sure if this process still works though.
>>
>> Thanks,
>> Scott Ritchie
>>
>
> I thought the plans were to attempt to move all documentation (in an
> updated form) to the Wiki. We would then need some mechanism to create
> documentation out of the wiki. Myself I rather update the wiki when I
> encounter an issue than that I update the old docs.
>
> Roderick
>
>
>

While on the subject of documentation... would it be a good idea to
begin documenting functions with something like Doxygen or similar?
I'm just wondering if we could be building our own, much more
accurate, MSDN. Is there a reason that Wine isn't documented in this
way?

Luke.

Re: switching to redmine?

[Luke Benstead]

2009/11/19 Dan Kegel :
> http://yokozar.org/blog/archives/171
> is a nice writeup (thanks Scott) of wineconf.
>
> It all sounds good except for that switching to redmine part...
> The current wiki and bugzilla are working reasonably well,
> doesn't seem worth the disruption to switch.
> I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist
> thingies.  It's really hard to do all those jobs well.
> Sourceforge was the first, and it was really rough.
> Google Code is kind of ok, but it doesn't support git yet,
> and its svn has performance issues (for the moment).
> Launchpad is also kind of ok, and kind of supports git...
> Yet Another WBSM Thingy that I've never
> heard of seems unlikely to be as robust as
> the above systems.
> - Dan
>
>
>

You might well be pleasantly surprised. We've been using Redmine where
I work for about 6-8 months and I'm really impressed with it, I'd
definitely say it was better than Google Code, Trac and SF. The
Redmine website is actually a Redmine tracker (
http://www.redmine.org/projects/redmine ) so you can get a fair idea
how it works.

I don't think it's set in stone that we're switching to Redmine, I
think Scott's just setting it up as an experiment to get feedback.

Luke.

Re: cppcheck sept 18 redux

[Luke Benstead]

2009/9/22 Ben Klein :
> 2009/9/23 Luke Benstead :
>> If it IS the case that this doesn't cause a crash and is perfectly
>> valid, can someone explain to me how/why this works? Or point me (no
>> pun intended) to the bit in the C spec that explains it? Coz the way I
>> read it, it has to dereference dmW, otherwise how would the compiler
>> find the address of the array? ... so confused :)
>
> I believe it's because the array (as a pointer) is at the same
> location as start of the struct (as a pointer). Compiler then applies
> pointer arithmetic without dereferencing.
>

Ah, I see.. but in that case, how is an array different to using a
pointer, like in Vitaliy's example? Surely that's the same thing
essentially?

Luke.

Re: cppcheck sept 18 redux

[Luke Benstead]

2009/9/22 Ben Klein :
> 2009/9/22 Vitaliy Margolen :
>> Mike Kaplinskiy wrote:
>>> It actually does not dereference anything. Try passing null into the
>>> function - it will work just fine. This is a special case because the
>>> array isn't dynamically allocated but is part of the struct, which
>>> means that dmW->dmFormName == (dmW+__offset of dmFormName) and not
>>> *(dmW+__offset of dmFormName). You can try writing a test program
>>> yourself - it will run just fine.
>> It does dereference the pointer. Here is your simple test. Compile it and
>> run it. See what happens.
>>
>> #include 
>>
>> typedef struct _s_test
>> {
>>    void *pointer;
>
> No. Array, not pointer. E.g.:
>    int array[1];
>
>> }  s_test;
>
>
>

If it IS the case that this doesn't cause a crash and is perfectly
valid, can someone explain to me how/why this works? Or point me (no
pun intended) to the bit in the C spec that explains it? Coz the way I
read it, it has to dereference dmW, otherwise how would the compiler
find the address of the array? ... so confused :)

Luke.

Re: ddraw: Separate reference counting for IDirectDraw7 and IDDS4 from IDDS3, IDDS2 and IDDS (try 2)

[Luke Benstead]

2009/8/22 Stefan Dösinger :
> I think it is better to separate the vtables first - ie, give
> IDirectDrawSurface4,  IDirectDrawSurface2 and IDirectDrawSurface their own
> vtable
>
> Also the last iteration of Michael Karcher's patches missed out some
> getters, like IDirect3DDevice*::GetRenderTarget. There may be other
> functions that need to be adjusted to AddRef/Release version specific
> refcounts.
>
>
>
>

Here are my likely broken patches that separate the surface thunks for
refcounting, from months ago. I think the first 4 are OK, but I named
the last one "broken" so I guess that one isn't ;)

Still it's a starting point.

Luke.


thunk_patches3.tar.gz
Description: GNU Zip compressed data

Re: old patch enabling visible icons in some applications

[Luke Benstead]

2009/8/20 Philipp A. :
> what do you mean with “clean it up”? i don’t see anything not-clean about
> it.
> and why is it nonfunctional in your opinion?
> and for testing: that’s what svn-versions are for, aren’t they?
>
> 2009/8/20 James McKenzie 
>>
>> Philipp A. wrote:
>> >>> Well bug 8555 (http://bugs.winehq.org/show_bug.cgi?id=8555) is
>> >>> affected by that FIXME, so that can be a starting bug.
>> >>>
>> >
>> > Well, i think, they don't like working apps.
>> > What on earth can i do to make somebody stop by and put the damn patch
>> > into the svn?
>> >
>> Clean it up and make it functional including tests, if needed.
>>
>> James McKenzie
>
>
>
>
>

Phillip, firstly, please bottom-post on the mailing list.

If the patch was not accepted there would have been a reason. Perhaps
there was an obvious error in the code, perhaps the approach was
wrong, perhaps it won't work in all cases. It also is possible that it
doesn't match the behaviour of Windows, or if it does, it needs to be
proved with a conformance test. Conformance tests are essential to
prove that a.) The fix works, b.) It matches the behaviour on Windows
and c.) a code change won't cause a regression in the future (because
the test would flag that up).

Just because it appears to give the correct result doesn't mean the
patch isn't flawed in some other way, you can always hack a solution
that would work in some cases but it won't be the right approach.

So, if you want this patch to be accepted, then someone needs to take
it up, they need to consult Alexandre Julliard in #winehackers to find
out why he rejected it in the first place, then they need to fix any
issues he has spotted and likely write a conformance test to prove the
patch is correct. You've said you don't want to get involved in
working on the patch itself, so you can find/make a bug report, link
to this patch and explain in the report that the patch seems to fix it
for you.

Luke.

Re: kernel32/nls/winerr: Add Russian translation [try 3]

[Luke Benstead]

2009/8/10 Paul Vriens :
> Luke Benstead wrote:
>>
>> 2009/8/10 Dmitry Timoshkov :
>>>
>>> "Austin English"  wrote:
>>>
>>>> If you don't mind one, I'd appreciate it.
>>>> +MessageId=0
>>>> +SymbolicName=ERROR_SUCCESS
>>>> +Language=RUS
>>>> +Операция успешно завершена.
>>>
>>> winerr_enu.mc: Success
>>>
>>> c:\xp_prompt> net helpmsg 0
>>> The operation completed successfully.
>>>
>>>> +MessageId=2
>>>> +SymbolicName=ERROR_FILE_NOT_FOUND
>>>> +Language=RUS
>>>> +Не удаётся найти указанный файл.
>>>
>>> winerr_enu.mc: File not found
>>>
>>> c:\xp_prompt> net helpmsg 2
>>> The system cannot find the file specified.
>>>
>>>> +MessageId=3
>>>> +SymbolicName=ERROR_PATH_NOT_FOUND
>>>> +Language=RUS
>>>> +Системе не удаётся найти указанный путь.
>>>
>>> winerr_enu.mc: Path not found
>>>
>>> c:\xp_prompt> net helpmsg 3
>>> The system cannot find the path specified.
>>>
>>>> +MessageId=4
>>>> +SymbolicName=ERROR_TOO_MANY_OPEN_FILES
>>>> +Language=RUS
>>>> +Системе не удается открыть файл. Слишком много открытых файлов.
>>>
>>> winerr_enu.mc: Too many open files
>>>
>>> c:\xp_prompt> net helpmsg 4
>>> The system cannot open the file.
>>>
>>> etc., etc.
>>>
>>> --
>>> Dmitry.
>>>
>>>
>>>
>>
>> Vladimir, to clarify, the strings must be direct translations from the
>> English version. They should not be more verbose re-phrasings which is
>> what you have submitted.
>>
>> Luke.
>>
>>
>
> Not sure direct translation of English is a must. It's nice if they are in
> line of course, but the most important thing (like with other documentation
> in our source) is that it must be your own wording and not a verbatim copy
> of Windows documentation/resources.
>
> --
> Cheers,
>
> Paul.
>

Yeah, sorry I meant to say "close" translations - not all languages
would have direct translations..

Luke.

Re: kernel32/nls/winerr: Add Russian translation [try 3]

[Luke Benstead]

2009/8/10 Dmitry Timoshkov :
> "Austin English"  wrote:
>
>> If you don't mind one, I'd appreciate it.
>
>> +MessageId=0
>> +SymbolicName=ERROR_SUCCESS
>> +Language=RUS
>> +Операция успешно завершена.
>
> winerr_enu.mc: Success
>
> c:\xp_prompt> net helpmsg 0
> The operation completed successfully.
>
>> +MessageId=2
>> +SymbolicName=ERROR_FILE_NOT_FOUND
>> +Language=RUS
>> +Не удаётся найти указанный файл.
>
> winerr_enu.mc: File not found
>
> c:\xp_prompt> net helpmsg 2
> The system cannot find the file specified.
>
>> +MessageId=3
>> +SymbolicName=ERROR_PATH_NOT_FOUND
>> +Language=RUS
>> +Системе не удаётся найти указанный путь.
>
> winerr_enu.mc: Path not found
>
> c:\xp_prompt> net helpmsg 3
> The system cannot find the path specified.
>
>> +MessageId=4
>> +SymbolicName=ERROR_TOO_MANY_OPEN_FILES
>> +Language=RUS
>> +Системе не удается открыть файл. Слишком много открытых файлов.
>
> winerr_enu.mc: Too many open files
>
> c:\xp_prompt> net helpmsg 4
> The system cannot open the file.
>
> etc., etc.
>
> --
> Dmitry.
>
>
>

Vladimir, to clarify, the strings must be direct translations from the
English version. They should not be more verbose re-phrasings which is
what you have submitted.

Luke.

Status of XI2 mouse stuff?

[Luke Benstead]

Hi all,

I remember seeing an email that someone had implemented DX mouse input
using the new XInput2 extensions. What's the status of that? Is it in
Wine already?

Cheers,

Luke.

Re: Doing better than barely keeping up with bug reports - Bug Day this Monday (July 20)

[Luke Benstead]

2009/7/17 Rosanne DiMesio :
> On Fri, 17 Jul 2009 14:57:21 +
> Dan Kegel  wrote:
>
>> > DELETED     BugDay  12:33   Informations    DmitryTimoshkov #01 Not 
>> > useful, eveone works on bugs or features at its own preference, at its own 
>> > time
>>
>> Dmitry's being overly negative, I think, and it's just plain rude to
>> delete wiki pages like that.  Let's put it back.
>>
>> That said, it might be wise to post proposals for events
>> and let them percolate for a couple days before
>> announcing them.  (In this case, seeing a few
>> enthusiastic replies might have made Dmitry
>> think twice before doing what he did.)
>> - Dan
>>
>>
>
> I suppose I qualify as one of those "non developer volunteers" being targeted 
> for this, and my reaction is the same as Dmitry's. I've been doing exactly 
> what the instructions on the wiki page ask for, off and on at my own 
> convenience, for about a year, so for me this is at best a non-event. That 
> said, if other people want to do it, I certainly have no objections.
>

The whole "Hug Day" thing works pretty well for Ubuntu, and getting
people to do this kind of spring clean together gives a kind of burst
of energy. Like I said, I've already grabbed 2 people who use Wine but
have never reported bugs before and I think I've just got a 3rd (my
girlfriend :) ). They all seem keen to help out as a one off. Even if
they each just check to see if a single bug is still around on current
Wine at least it's something. I think it's a good idea.

> The one suggestion I would make after reading the wiki page is that I really 
> don't think it's a good idea to invite ordinary users to ask for bugzilla 
> permissions after triaging just a couple of bugs.
>
> --
> Rosanne DiMesio 
>
>
>

I don't think that Scott meant how it reads... I think he probably
means "if you start to do this regularly, feel free to ask for
bugzilla permissions."

Luke.

Re: Doing better than barely keeping up with bug reports - Bug Day this Monday (July 20)

[Luke Benstead]

2009/7/17 Dan Kegel :
>> DELETED       BugDay  12:33   Informations    DmitryTimoshkov #01 Not 
>> useful, eveone works on bugs or features at its own preference, at its own 
>> time
>
> Dmitry's being overly negative, I think, and it's just plain rude to
> delete wiki pages like that.  Let's put it back.
>
> That said, it might be wise to post proposals for events
> and let them percolate for a couple days before
> announcing them.  (In this case, seeing a few
> enthusiastic replies might have made Dmitry
> think twice before doing what he did.)
> - Dan
>
>
>

Done.

Luke.

Re: Doing better than barely keeping up with bug reports - Bug Day this Monday (July 20)

[Luke Benstead]

2009/7/17 Scott Ritchie :
> So, briefly:
>
> Over the past few months, users have added an average of between 12 and
> 14 bugs every day.
>
> Since June 1st:
> - 412 total bugs filed
> - 87 bugs resolved invalid
> - 227 bugs resolved fixed
> - 133 bugs confirmed but not resolved (status new)
> - 292 bugs created but unconfirmed
>
> Doing some subtraction that means we have 292 new untriaged bugs, but we
> triaged or fixed (412-292-87-227-133) = 327 old bugs.
>
> So, we're swimming above water, which is good.  But at this rate it'll
> be years before we triage every bug.  So, let's do something :)
>
>
> Bug Jam this Monday!
>
> One idea that has been tried in the past is to hold regular bug days.
> We've had a lot of success with them in Ubuntu as a way of organizing
> non developer volunteers, especially when we focus the event on a
> particular package.  Today's bug day, for instance, tackled over a 100
> Synaptic bugs: https://wiki.ubuntu.com/UbuntuBugDay/20090716
>
> I'd like to attempt this in Wine.  We tried it once in the past, but no
> one's organizing it now.  Even if it's just me and 2 people testing a
> handful of bugs in our favorite apps, it'll still sink a good number of
> bugs and help drain the swamp.
>
> I'm picking Monday for bug day for a few reasons - it's both after a new
> release and after the weekend, so users will have already had time to
> play their games and see if they're still affected.  If there's any sort
> of success, hopefully this will become a regular event.
>
>
> So, if you're into bug triage, please come and join me in #winehackers
> this Monday.  The purpose of triaging bugs is to ultimately get them
> fixed, so if you're a developer and would rather work on patches then by
> all means do that instead.
>
> I've created a wiki page for the event here: http://wiki.winehq.org/BugDay
> When we're done I'll poke bugzilla for some stats and we can see how
> much of a success the event was.
>
> Thanks,
> Scott Ritchie
>
>
>

I'm up for this. I've already dragged in two other Wine users to help
out as well. So you already have 3 people ;)

Luke.

Re: Windows 2D GDI benchmark tools?

[Luke Benstead]

2009/7/7 Luke Benstead :
> -- Forwarded message --
> From: Luke Benstead 
> Date: 2009/7/7
> Subject: Re: Windows 2D GDI benchmark tools?
> To: Roderick Colenbrander 
>
>
> 2009/7/7 Roderick Colenbrander :
>> Hi,
>>
>> I'm working on rewriting Wine its blitting code using XRender. This
>> has several advantages e.g. no need for depth conversion, no need for
>> manual stretching/mirroring, it saves a lot of back-and-forth copying
>> between X and further various operations will be accelerated by the
>> GPU using XRender. (For a big part it might eliminate the need for a
>> DIB engine!)
>>
>> Right now I'm looking for some 2D GDI benchmark tools which test
>> blitting performance and other 2D operations and which work on Wine. I
>> have tried Sisoft Sandra and PassMark but those don't work on Wine.
>> Does anyone know any other 2D benchmark tools? It would help me a lot
>> to isolate slow parts and optimize my code even further.
>>
>> Thanks,
>> Roderick
>>
>>
>>
>
> (To everyone this time - why am I incapable of hitting "Reply to all" ? )
>
> Maybe this? http://crystalmark.info/software/CrystalMark/index-e.html
>
> ( I haven't tried it, just Googled for benchmarking tools -
> particularly see this screenshot:
> http://crystalmark.info/software/CrystalMark/images/CrystalMark2004R2_Result.png
> there is a GDI mark)
>
> Luke.
>

OK, just tried it. Not only does it work under Wine, but it works
pretty damn well - although the GDI test hurts your eyes :)

Luke.

Fwd: Windows 2D GDI benchmark tools?

[Luke Benstead]

-- Forwarded message --
From: Luke Benstead 
Date: 2009/7/7
Subject: Re: Windows 2D GDI benchmark tools?
To: Roderick Colenbrander 


2009/7/7 Roderick Colenbrander :
> Hi,
>
> I'm working on rewriting Wine its blitting code using XRender. This
> has several advantages e.g. no need for depth conversion, no need for
> manual stretching/mirroring, it saves a lot of back-and-forth copying
> between X and further various operations will be accelerated by the
> GPU using XRender. (For a big part it might eliminate the need for a
> DIB engine!)
>
> Right now I'm looking for some 2D GDI benchmark tools which test
> blitting performance and other 2D operations and which work on Wine. I
> have tried Sisoft Sandra and PassMark but those don't work on Wine.
> Does anyone know any other 2D benchmark tools? It would help me a lot
> to isolate slow parts and optimize my code even further.
>
> Thanks,
> Roderick
>
>
>

(To everyone this time - why am I incapable of hitting "Reply to all" ? )

Maybe this? http://crystalmark.info/software/CrystalMark/index-e.html

( I haven't tried it, just Googled for benchmarking tools -
particularly see this screenshot:
http://crystalmark.info/software/CrystalMark/images/CrystalMark2004R2_Result.png
there is a GDI mark)

Luke.

Re: Removing active maintainers

[Luke Benstead]

2009/6/26 Erich Hoover :
> 2009/6/26 Ken Sharp 
>>
>>
>> Alexander Nicolaysen Sørnes wrote:
>>
>>> It's important to note that the script would also have warned maintainers
>>> that there are queued items for the apps they maintain.
>>>
>>
>> Yup, but queued data is also listed down the left of the page, and an
>> email is sent to the maintainer for every test result, bug link, screenshot
>> and comment added to the app (as well as monitor and other stuff, but that's
>> another issue...)
>>
>>> We can make it so only the first 25 threads are shown by default, then
>>> have a 'show all comments' link. This should make it easier for users,
>>> maintainers and admins alike.
>>> Is 25 a good limit? Please post your suggestions.
>>
>> It doesn't really matter how many comments are shown, most of them are
>> useless, and if clicking on "Show all" shows hundreds or thousands of
>> comments, the user is still none-the-wiser.
>>
>> ...
>
> I have found that many of the "useless" comments show up as good Google
> searches when I'm looking up errors.  This kind of behavior has been
> incredibly useful in the past for figuring out what to do with a bug I've
> encountered.  Unfortunately, lately it's been much harder for me to use this
> approach because after I use the link in Google the comments are gone.  This
> behavior wouldn't be a "big" deal except that AppDB only shows the top
> comments in the Google cache (and Google will eventually remove these
> pages), so there's no way to look at the responses for deleted comments
> (note: if we changed AppDB to feed Google all of the comments that would be
> really nice).
>
> Anyway, I would definitely appreciate a 25 threads/page system - the current
> "infinite comments" system is rather unweildly to navigate.  Personally, I
> would prefer that rather than delete these comments that comments get marked
> as "outdated".  If outdated comments weere pushed to the end of the list,
> and clearly marked that they are outdated, then they could still be useful
> for historical purposes without interfering with the usability of the site.
>
> Erich Hoover
> ehoo...@mines.edu
>
>
I personally think a Slashdot style system (like mentioned earlier) is
perfect for this. If users rated posts up and down, and there is a
customizable threshold above which the comments are visible. Then the
most relevant and useful posts would always be the ones people could
see, outdated/irrelevant posts would drop below the threshold and only
the subject would be visible. You could even use simple AJAX to grab
the comments that were below the threshold when they are requested,
which would save on bandwidth/page load for pages with a large number
of comments.

Luke.

Re: DIB engine

[Luke Benstead]

2009/5/29 Austin English :
> On Fri, May 29, 2009 at 10:50 AM, chris ahrendt  wrote:
>> Right Austin,
>> I have... thats why I asked the question why not sit down and say
>> here is what we want from the DIB engine here is the Spec do this ..
>> I have seen the here is what I don't like. But nothing showing what
>> exactly is needed. This would be the first step in resolving this
>> circular argument / discussion which is what I am trying to
>> facilitate =D. Until that is done all we can do is have this same
>> circular argument / discussion =D
>
> As was said in the other thread, just designing it alone would take a
> few months work. AJ is really busy with other things, and a few months
> work is both a lot of money and a lot of wasted productivity. No one
> is stepping up to sponsor the work, so it's a bit hard for him to take
> that on.
>
> --
> -Austin
>
>
>

Heh, I wonder if someone should approach Autodesk and say, "Give us
sponsorship and we'll get Autocad running on Linux" they surely have
deep pockets :)

 Luke.

P.S. Must learn to reply to all, sorry Austin

Re: Add tests for DirectDraw surface reference counting

[Luke Benstead]

2009/5/15 Stefan Dösinger :
> Am Freitag, 15. Mai 2009 13:52:23 schrieb Luke Benstead:
>> Reference counts are wrong in Wine which causes some games to fail.
>> I'm working patches to make these tests pass so we can remove the
>> todo_wine's.
>>
>> Luke.
>
> The patch adds trailing whitespeaces in a few lines. Please remove them.
> Otherwise the code looks good to me.
>

Oops, same patch without the trailing whitespace.

Luke.
From b0bfef71be54d66471ce53751c568c67258dfdd3 Mon Sep 17 00:00:00 2001
From: Luke Benstead 
Date: Fri, 15 May 2009 13:33:21 +0100
Subject: Add a test for DirectDraw surface reference counting

---
 dlls/ddraw/tests/dsurface.c |  114 +++
 1 files changed, 114 insertions(+), 0 deletions(-)

diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index a0f69b1..43979fe 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
@@ -26,6 +26,7 @@
 #include 
 #include "wine/test.h"
 #include "ddraw.h"
+#include "d3d.h"
 #include "unknwn.h"
 
 static LPDIRECTDRAW lpDD = NULL;
@@ -966,6 +967,118 @@ static void GetDDInterface_7(void)
 IDirectDrawSurface7_Release(dsurface7);
 }
 
+static unsigned long getRefcount(IUnknown *iface)
+{
+IUnknown_AddRef(iface);
+return IUnknown_Release(iface);
+}
+
+static void IFaceRefCount(void)
+{
+LPDIRECTDRAWSURFACE surf;
+DDSURFACEDESC surface;
+HRESULT ret;
+IDirectDrawSurface2 *surf2;
+IDirectDrawSurface2 *surf2a;
+IDirectDrawSurface4 *surf4;
+IDirectDrawSurface7 *surf7a;
+IDirectDrawSurface7 *surf7b;
+IDirect3DTexture* tex;
+IDirect3DTexture2* tex2;
+IDirectDrawGammaControl* gamma;
+unsigned long ref;
+
+/* Create a surface */
+ZeroMemory(&surface, sizeof(surface));
+surface.dwSize = sizeof(surface);
+surface.dwFlags = DDSD_CAPS;
+surface.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE;
+ret = IDirectDraw_CreateSurface(lpDD, &surface, &surf, NULL);
+
+if (ret != DD_OK) 
+{
+ok(FALSE, "Could not create surface, skipping test\n");
+return;
+}
+
+ref = getRefcount((IUnknown *) surf);
+ok(ref == 1, "Refcount is %ld, expected 1\n", ref); /* Check the ref count 
is one */
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawSurface2, (void 
**) &surf2);
+ref = getRefcount((IUnknown *) surf);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n", ref); /* Check the 
ref count is one */
+ref = getRefcount((IUnknown *) surf2);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n", ref); /* This 
should also be one */
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawSurface2, (void 
**) &surf2a);
+ref = getRefcount((IUnknown *) surf2);
+todo_wine ok(ref == 2, "Refcount is %ld, expected 2\n", ref);   /* Surf2's 
refcount should be 2 now, but surf should be 1 */
+ref = getRefcount((IUnknown *) surf);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n", ref);
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawSurface4, (void 
**) &surf4);
+ref = getRefcount((IUnknown *) surf4);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n", ref);
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawSurface7, (void 
**) &surf7a);
+ref = getRefcount((IUnknown *) surf7a);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n", ref);
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawSurface7, (void 
**) &surf7b);
+ref = getRefcount((IUnknown *) surf7b);
+todo_wine ok(ref == 2, "Refcount is %ld, expected 2\n", ref);
+
+/* IDirect3DTexture interface (unlike the others) alters the original 
IDirectDrawSurface ref count */
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirect3DTexture, (void **) 
&tex);
+ref = getRefcount((IUnknown *) tex);
+todo_wine ok(ref == 2, "Refcount is %ld, expected 2\n", ref);
+ref = getRefcount((IUnknown *) surf);
+todo_wine ok(ref == 2, "Refcount is %ld, expected 2\n", ref);
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirect3DTexture2, (void **) 
&tex2);
+ref = getRefcount((IUnknown *) tex);
+todo_wine ok(ref == 3, "Refcount is %ld, expected 3\n", ref);
+ref = getRefcount((IUnknown *) tex2);
+todo_wine ok(ref == 3, "Refcount is %ld, expected 3\n", ref);
+ref = getRefcount((IUnknown *) surf);
+todo_wine ok(ref == 3, "Refcount is %ld, expected 3\n", ref);
+
+IDirectDrawSurface_QueryInterface(surf, &IID_IDirectDrawGammaControl, 
(void **) &gamma);
+ref = getRefcount((IUnknown *) gamma);
+todo_wine ok(ref == 1, "Refcount is %ld, expected 1\n&qu

Re: Dib Engine: some update

[Luke Benstead]

2009/5/1 Massimo Del Fedele :
> Luke Benstead ha scritto:
>>
>> 2009/5/1 Scott Ritchie :
>>>
>>> Massimo Del Fedele wrote:
>>>>
>>>> I put on bug's 421 page an update of my dib engine.
>>>> It implements AlphaBlend, StretchBlt and has many color fixes.
>>>> If you want to try it, just follow instructions on above page.
>>>>
>>>> Ciao
>>>>
>>>> Max
>>>>
>>> Keep at it, it's very exciting :)
>>>
>>> Thanks,
>>> Scott Ritchie
>>>
>>>
>>>
>>
>> Yeah, nice work Max! You are doing an amazing job, I just wish that we
>> knew how to get it into vanilla Wine! My bro really needs this to move
>> his (and several work) machines to Ubuntu, but unfortunately I'm 100
>> miles away and he wouldn't have a clue how to compile and patch Wine.
>> I might have a stab at packaging a custom version :)
>>
>> Luke.
>>
>>
> Thank you all for your messages, I'm glad it's useful for somebody :-)
> I was thinking too on packaging a custom version with the patches on
> my tree btw, I have a couple more which weren't applied because
> "ugly", one allows printing on formats different than printer's
> default one (a need for most autocad users...).
> I'm not too good on debian packaging, but if you have some script
> that can do it we could find a place to host them.
>
> Ciao
>
> Max
>
>
>
>
>

I have a place we could host the packages, but it would take me some
time to learn how to package Wine... I've only ever done small
libraries.

Scott, are you the Ubuntu maintainer? If so, do you have some script
for building the packages?

Luke.

Re: Dib Engine: some update

[Luke Benstead]

2009/5/1 Scott Ritchie :
> Massimo Del Fedele wrote:
>>
>> I put on bug's 421 page an update of my dib engine.
>> It implements AlphaBlend, StretchBlt and has many color fixes.
>> If you want to try it, just follow instructions on above page.
>>
>> Ciao
>>
>> Max
>>
>
> Keep at it, it's very exciting :)
>
> Thanks,
> Scott Ritchie
>
>
>

Yeah, nice work Max! You are doing an amazing job, I just wish that we
knew how to get it into vanilla Wine! My bro really needs this to move
his (and several work) machines to Ubuntu, but unfortunately I'm 100
miles away and he wouldn't have a clue how to compile and patch Wine.
I might have a stab at packaging a custom version :)

Luke.

Re: The DIB engine... does anyone know how to get it into Wine?

[Luke Benstead]

2009/4/29 Chris Howe :
> 2009/4/29 Roderick Colenbrander :
>> On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead  wrote:
>>> It would be nice to see what Alexandre's opinion of the options
>>> discussed in this thread is, as he's ultimately the one who will
>>> decide.
>> [Huw] would document how the DIB engine should be implemented and how it
>> should interact with other parts of Wine.
>
> Honestly, I think getting some agreed-upon documentation up would
> be the most helpful thing.
>
> --
> Chris
>
>
>

I agree.

Luke.

Re: The DIB engine... does anyone know how to get it into Wine?

[Luke Benstead]

It would be nice to see what Alexandre's opinion of the options
discussed in this thread is, as he's ultimately the one who will
decide.

>From an observer's point of view, I'd say that moving the current DIB
code out of wineX11 first before replacing it with Max's DIB code
sounds like the cleanest idea, because then if any bugs are introduced
it will be directly from the migration of the code, not the logic of
the DIB stuff itself. But obviously, from reading the discussion, it's
not as clean cut as just moving the code.

Luke.

Re: The DIB engine... does anyone know how to get it into Wine?

[Luke Benstead]

2009/4/28 Chris Howe :
> I think it's time that a definitive framework for it was agreed upon,
> because as people have said, this isn't the first time that someone
> has tried to implement the DIB engine. It's been on the todo list of
> improvements to Wine for as long as I can remember, but it seems
> as if every time someone tries to make good on that, that development
> gets so far but is then turned down on the grounds that the
> architecture isn't right. That's a lot of hours of wasted work.
>
> But then you'd expect that: it's a big project, and it's hampered by
> the fact that the current system has evolved to sort-of-work in a way
> that avoiding regressions is difficult if not impossible in the short term.
> It's logical that without some agreed upon roadmap, without some
> architectural pre-planning, any one person's attempt is going to come
> up short.
>
> --
> Chris
>
>
>

Might I suggest that, as Huw, Jesse and Max have the most experience
with what needs to be done, perhaps one or more of them could update
this page: http://wiki.winehq.org/DIBEngine with what actually needs
to change in GDI32 to allow for an incremental implementation of the
DIB engine and also perhaps update the page with as much info about
the current architecture, faults with the previous attempts etc. as
possible. If there is more information out there about the problem,
perhaps more people can contribute to coming up with a solution.

Luke.

The DIB engine... does anyone know how to get it into Wine?

[Luke Benstead]

Hi all,

I've been watching the DIB engine work that has been going on in bug
421. It looks like Max has made massive progress getting Autocad
working by the sound of it, almost perfectly and also improvements in
Starcraft have been reported. However, he accepts (and Alexandre has
confirmed) that neither of the two approaches he has tried is the
right one and he believes (as do others) that any correct approach
requires massive changes to GDI32, which if I read it right, no one
seems to know how to do incrementally.

Autocad is one of those apps, like Photoshop, which people need to be
able to use and won't switch away from Windows without it. In fact,
Autocad more so than Photoshop because there is no (almost) feature
equivalent alternative available (like the GIMP for Photoshop). So
it's frustrating to know that someone has it working, but vanilla Wine
isn't going to see it working in the near future.

My question is this: does anyone know how to incrementally implement
the necessary changes? Is it even possible? If it's not possible, is
it work considering branching Wine to implement it correctly, for
merging back into trunk at a later stage once it's been thoroughly
tested? I'm wondering if Wine's development process just doesn't allow
for a big change like this, and perhaps it's the development model
that is the reason bug 421 is so long standing?

Any thoughts, I just want to spur some discussion on this because it
seems that everyone that attempts a DIB engine hits a wall :)

Luke.

Re: [2/3] ntdll: don't treat DOS paths starting with / as Unix paths

[Luke Benstead]

2009/4/8 Oleh R. Nykyforchyn :
> On Wed, 8 Apr 2009 09:46:26 -0600
> Erich Hoover  wrote:
>
>> On Wed, Apr 8, 2009 at 9:07 AM, Luke Benstead  wrote:
>>
>> > ...
>> >
>> > This is probably a really dumb question... but why does wine support
>> > UNIX paths? What is the circumstance where a Windows application will
>> > be trying to access a native file or directory? The only example I can
>> > think of is that an app has specifically been written to be used in
>> > Wine, in which case, shouldn't native UNIX paths be disabled by
>> > default, and perhaps turned on with an environment variable?
>> >
>> > Luke.
>> >
>> >
>> >
>> I personally enjoy the ability to use UNIX paths both in calling
>> applications with command-line arguments and in file dialogs (even if it is
>> necessary to use the wrong slash in dialogs).  I imagine that there are a
>> lot of people that appreciate the ability to use this functionality, since
>> you can use the "familiar paths" you do not need to be familiar with the
>> windows drive mapping.
>>
>> Erich Hoover
>
> I also use wine in somewhat weird way. E.g. I use WinEdt editor under wine to
> edit TeX files, and it can launch Linux executables like latex, xdvi, dvips 
> and so on.
> WinEdt takes native Unix paths when it opens files and then passes them to 
> Linux
> executables. I cannot rely on WinEdt the task to convert Win paths to Unix 
> ones.
> Thus, if this feature is dropped, I will not be able to use such mixed Win-Lin
> environments. I believe that Wine should preserve it present behaviour as 
> default
> and turn on some special treatment of Unix paths (with prefixes etc) on 
> demand,
> possibly on per-application basis.
>
> Oleh Nykyforchyn
>
>
>

I disagree. Wine should treat paths *by default* like they are Windows
paths. UNIX paths should be identified in the way that Alexandre
suggested, with a prefix. That's the best way to make sure that all
Windows programs will work as they should, and still allow for UNIX
paths. Don't worry, I don't think anyone is suggesting removing UNIX
paths completely :)

Luke.

Re: [2/3] ntdll: don't treat DOS paths starting with / as Unix paths

[Luke Benstead]

2009/4/8 Alexandre Julliard :
> Luke Benstead  writes:
>
>> This is probably a really dumb question... but why does wine support
>> UNIX paths? What is the circumstance where a Windows application will
>> be trying to access a native file or directory? The only example I can
>> think of is that an app has specifically been written to be used in
>> Wine, in which case, shouldn't native UNIX paths be disabled by
>> default, and perhaps turned on with an environment variable?
>
> It can be used anywhere an app uses a user-specified path without
> mangling it too much; admittedly that doesn't happen very often, apps
> like to mangle paths. There are also places where Wine itself depends on
> it, to support things like "wine ~/foo.exe" or to allow Unix paths in
> some registry entries.
>
> These are all things that could probably be reimplemented in a more
> reliable fashion, for instance by using \\?\unix instead of relying on
> the path detection heuristic. Once this is done properly everywhere,
> then maybe the hackish way could be removed.
>
> --
> Alexandre Julliard
> julli...@winehq.org
>

That sounds like a far better way of doing it. Perhaps though, if that
method was implemented, passing a program path directly into wine
(wine ~/foo.exe) would be a special case (without a \\?\ prefix). From
a users point of view that's what I'd expect, as you haven't yet
started the application (and entered windows land :) ).

Luke.

Re: [2/3] ntdll: don't treat DOS paths starting with / as Unix paths

[Luke Benstead]

2009/4/8 Peter Rosin :
> Hi!
>
> [I just subscribed, I hope I got the forged in-reply-to header right]
>
> Ben Klein wrote:
>> > This is what I meant about magic translation. It *shouldn't* work, but
>> > I'm aware that it does. DOS/Windows uses backslash as the delimiter
>> > when reporting and storing paths. Is the behaviour of magic
>> > translation from foreslash to backslash documented (by Microsoft)
>> > anywhere?
>
> From: http://msdn.microsoft.com/en-us/library/aa365247.aspx
>
> + MSDN Library
>  + Win32 and COM Development
>    + System Services
>      + File Services
>        + File Systems
>          + File Management
>            + About File Management
>              + Creating, Deleting, and Maintaining Files
>                * File Names, Paths, and Namespaces
>
> "Note  File I/O functions in the Windows API convert "/" to "\" as
>  part of converting the name to an NT-style name, except when using
>  the "\\?\" prefix as detailed in the following sections."
>
> So, the Win32 API supports /
>
>
>
>
> BTW, people using the identity mount technique with MinGW (*) are
> not unlikely to have a /bin/sh on the current drive. Hmmm, but that's
> actually /bin/sh.exe so maybe they are safe? And I guess building
> mingw-gcc on Windows isn't "real work" (that's the main reason for
> the identiy mount, IIUC). Anyway, that's just another stab at the
> python test suite.
>
> Building stuff using MSYS/MinGW (or Cygwin) inside wine which
> requires an identity mount is surely just for fun. Anything MSYS
> or Cygwin inside Wine is for fun. The identity mount technique
> clearly does not work with Wine.
>
> Cheers,
> Peter
>
> (*) Google: mingw "identity mount"
>
>
>

This is probably a really dumb question... but why does wine support
UNIX paths? What is the circumstance where a Windows application will
be trying to access a native file or directory? The only example I can
think of is that an app has specifically been written to be used in
Wine, in which case, shouldn't native UNIX paths be disabled by
default, and perhaps turned on with an environment variable?

Luke.

Process elevation

[Luke Benstead]

Hi all,

I was going to post this to #winehackers but it became too long so
I'll post here instead :)

When trying to run IE8 under Wine, you are greeted with the following error:

err:ntdll:NtQueryInformationToken Unhandled Token Information class 18!

In the TOKEN_INFORMATION_CLASS enum, 18 refers to TokenElevationType.
The error occurs in NtQueryInformationToken which *should* set the
value of a TOKEN_ELEVATION_TYPE (
http://msdn.microsoft.com/en-us/library/bb530718(VS.85).aspx )
instance. This basically returns whether or not a user is elevated, or
can be elevated.

I was going to have a go at fixing it, but I'm not sure what is the
best value to set. Should Wine class a user as an admin and all
processes run elevated? If so, then some applications may refuse to
run as admin, and definitely the same is true that if the user isn't
elevated, so programs will not run.

I don't really know much about this elevation stuff (aside what I've
read in the last half an hour) but I can't seem to work out what value
NtQueryInformationToken should return out of:

TokenElevationTypeDefault  - User is a normal user and can't elevate
TokenElevationTypeFull - User can and is elevated
TokenElevationTypeLimited  - User can elevate, but isn't currently elevated

Should perhaps the elevation level be set by an environment variable,
or registry setting?

Luke.

Re: An idea for the appdb

[Luke Benstead]

2009/2/11 Matt 'Murph' Finnicum :
> On Wed, Feb 11, 2009 at 2:33 PM,   wrote:
>>
>>
>> On Wed, 11 Feb 2009 13:03:21 -0700 (GMT-07:00), James Mckenzie
>>  wrote:

Automatic submission of test data could be a very handy tool.

>>> This would be great, but as previously discussed, who would maintain this
>>> information
>>> and verify it is correct and proper?  Although some features would be
>>> 'neet to have'
>>> it is best to leave them on the drawing board for now and work on the
>>> various bugs
>>> that require workarounds.  This is because of two limited resources:
>>> People and Time.
>>> If you have the skills to implement this feature, go ahead and try on a
>>> limited database
>>> on your home system.  You would quickly see that we have about 10,000
>>> applications
>>> in the AppDB and there are many versions of Wine.
>>
>> Ten thousand records in a database is not very significant. My day job is
>> DBA, so I might have the skills to tackle something like this (at least in
>> part).
>>
>>> This gives you some
>>> starting point
>>> of the size of this task.  Supporting a few applications would lead to
>> the
>>> 'why isn't
>>> my wiz-bang application there' and a great deal of discussion, wasting
>>> more resources.
>>>
>>> Of course, if you could produce something that would emulate the "Report
>>> to "
>>> functionality that is in popular use, that would help keep the AppDB and
>>> Bugzilla
>>> up to date as long as a search capability were added to sweep these
>>> systems for
>>> pre-existing entries related to the current problem.
>>>
>>
>> This was what I was thinking. Microsoft does this in Windows, and they are
>> the reference implementation of the Wine API. If collecting this data helps
>> M$ debug Windows, then I would think it would certainly help Wine too.
>>
>>> Just my opinion, but this project is not worth attempting at this point.
>>>
>>
>> If that is the consensus, then I won't bother looking into this further.
>> However, it seems like there is currently a movement to rework AppDB
>> anyway, so why not consider this idea now, so it could be factored into
>> those plans?
>>
>> -Alex
>>
>>
>>
>>
>
> Why not just write a external utility (perhaps with a bit of support
> from AppDB for mapping exe's to applications) so that a GUI user could
> just right click->AppDB and have their browser fire up? That'd be
> neat, much less complex, and completely non-invasive.
> --Murph
>
>
>

We'd still need some way to map the exe to the app in the appdb, which
brings us back to my checksum idea. Is there any chance that the appdb
could allow for application checksums to be stored alongside version
entries? Even if nothing is done with the information in the near
future, it could prove useful.

Luke.

Re: An idea for the appdb

[Luke Benstead]

2009/2/11 Ben Klein :
> 2009/2/11 Luke Benstead :
>> Hi all,
>>
>> I was thinking earlier it would be quite nice if when I double clicked
>> a Windows app in GNOME it would display a nice dialog saying something
>> like "This Windows application may not run correctly as it is
>> currently rated Silver. Please report any bugs to the Wine project.
>> Continue | Cancel". Obviously this kind of functionality is not a job
>> for Wine, but for the distro. Still, it got me thinking how this kind
>> of functionality might be achieved.
>
> There's been quite a bit of discussion along these lines recently.
> Unfortunately, AppDB simply isn't reliable enough for this type of
> dependence. With any luck, that will change when the recently
> discussed redesign of test data submissions is set up, but it'd still
> take a long time for sensible data to become reasonably usable.
>
>> My idea is that the appdb should allow for people to associate a list
>> of checksums with an application version. For example, WoW might have
>> the checksum for the setup program and the game's executable,
>> associated with the appdb entry. The other extension to the appdb
>> would be to allow a way to programmatically retrieve information on an
>> application's rating etc. by going to a certain address (e.g.
>> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...)
>> which would return the info in XML or some other format.
>
> You've clearly put quite some thought into this, which is highly
> commendable. However, I would personally be against such a move, as it
> would put a lot of extra load on AppDB (in terms of network
> bandwidth). I'm also not too keen about something that retrieves data
> from the net every time you run an app. It's too easy for people to
> mistake it for spyware.

Hmm.. I see your point. However would it really use that much
bandwidth? I mean, any sane implementation of the functionality I
described would only display the dialog the first time that
application was used. Retrieving a tiny xml file is surely less
bandwidth than browsing the appdb for the application (granted it will
happen more often than people browsing the site but I still don't
think it's masses of bandwidth). I can also see what you mean about
spyware, but other apps retrieve stuff from the web if there is a
connection (CDDB, and album covers are two examples).

> Another problem with a system like this is that ratings change
> depending not only on application version (which you've addressed) but
> also on Wine version. Platinum apps could become Garbage for one
> version (and yes, it has happened). Since AppDB test results tend to
> be few and far between on version numbers, it's not really useful for
> an automated "how well will this work?" system. It would have to
> calculate some sort of "best fit" (which will certainly be completely
> wrong on occasion), or just ignore the missing data.
>
> And finally, just like with the other suggestions for using the AppDB
> data elsewhere, this system does not take patches into account. Some
> apps require patches that completely break others (the Worms
> Armageddon ddraw hack and CoD hack come to mind here). Unfortunately,
> there's no sensible way to account for patched Wine in this sort of
> automated system.
>
> It is not a bad idea to give the user some sort of feedback on how
> well they should expect their app to run, but unfortunately it's
> virtually impossible to account for every possibility (patches and
> broken wineprefixes being the biggest problems).
>

You're right, it's a shame the data can't be more frequent and
reliable, I just thought it would be nice to be able to probe the
appdb for this information easily. :)

Luke.

An idea for the appdb

[Luke Benstead]

Hi all,

I was thinking earlier it would be quite nice if when I double clicked
a Windows app in GNOME it would display a nice dialog saying something
like "This Windows application may not run correctly as it is
currently rated Silver. Please report any bugs to the Wine project.
Continue | Cancel". Obviously this kind of functionality is not a job
for Wine, but for the distro. Still, it got me thinking how this kind
of functionality might be achieved.

My idea is that the appdb should allow for people to associate a list
of checksums with an application version. For example, WoW might have
the checksum for the setup program and the game's executable,
associated with the appdb entry. The other extension to the appdb
would be to allow a way to programmatically retrieve information on an
application's rating etc. by going to a certain address (e.g.
http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...)
which would return the info in XML or some other format.

So what do you guys think? Perhaps some of this functionality exists
and I don't know about it :)

Luke.

Re: DIB Engine - Patchset separated by original author

[Luke Benstead]

2009/2/6 L. Rahyen :
> On 2009-02-06 (Friday) 12:40:51 Massimo Del Fedele wrote:
>> I've been out for job for a while, but I don't see many comments about
>> the patch. I guess I'll stop developing the engine for now.
>> It makes few sense to code for something that will probably never be
>> accepted.
>
>Did you try to talk about your implementation of DIB engine with 
> Alexandre (on
> IRC or e-mail privately)? If not you should try.
>BTW, if you get almost zero comments this isn't necessary bad thing - 
> this
> usually means that nobody has anything bad to say about your implementation 
> and
> this is good thing. However, if Alexandre see something wrong in your
> implementation you need to talk to him personally about this to understand
> what's wrong and how you can improve it.
>Personally I think you are doing important and useful job because many 
> programs
> can benefit from DIB engine including AutoCAD.
>
>
>

I agree, you should stop by #winehackers and chat to Alexandre.
Perhaps Huw, and Jesse could also join in a discussion about the best
way forward.

Luke.

Re: wine honor roll slashdotted

[Luke Benstead]

2009/2/3 James Mckenzie :
> Dan Kegel  wrote:
>>Sent: Feb 3, 2009 6:48 AM
>>To: Wine Devel 
>>Subject: wine honor roll slashdotted
>>
>>http://tech.slashdot.org/article.pl?sid=09/02/03/0112249
>>
>>One comment mentions the grade inflation on the appdb,
>>i.e. platinum apps that have not been thoroughly tested
>>or don't really qualify as platinum...
>>
> Dan:
>
> Sadly, I agree with the grade inflation.  We need a grading interface that 
> will generate whether or not an application is 
> Plat/Gold/Silver/Bronze/Garbage based upon user input.  This usually stops 
> the inflation.
>
> James McKenzie
>
>
>

Perhaps, the grading should be separate from the test result
submissions? I know a few times I've run a program under Wine and then
only later looked up the entry on the appdb, by that stage I might not
even be on the same PC, or have the time to submit a full test result,
but I'd have a pretty good idea how I would rate it. It would be good
if logged in users could just quickly say "Yes, I would give this gold
status" then the final grade could be the average of the votes.

Luke.