Re: Disabling File attachments on Wiki
"Vitaliy Margolen" wrote: Please disable file attachments on Wiki. There are no way to verify their validity and for the past week it's been a constant source of spam. IMHO file attachment does not belong on text only Wiki. If anyone needs to attach a patch a two - they can link it to the one in ML archives or even bugzilla. Vitaliy. Anyone? Also how about blocking this IP: 213.155.0.32 ? It would be also helpful to to get all wiki user account list (check it time from time for suspicious names) and have an ability to delete accounts of known spammers for Wiki admins. Is it possible? -- Dmitry.
Re: Taking a break from Wine
On Wed, Mar 11, 2009 at 6:33 PM, Dan Kegel wrote: > Every now and then, my wrists force me to take > a break from Wine development. This time it's > also a matter of focus; I would like to spend more > time with my family while also focussing more > on my day job. One of the three had to go, > for a while at least. Hope you have a good break! > I will still try to update winetricks once a month, > but it might be good if other folks volunteered > to help out there; drop me a line if you're interested. I've got commit access on winezeug already, so I can do that. > Likewise, it would be good if someone else took > on running patchwatcher. (Shame, I have these nice > boxes here, just waiting to run it, and no time to > do it.) I'd be happy to answer questions from anyone > who wants to give it a shot. I'm working on this, but exams have delayed it. I've only got one machine though, but hopefully it can do the job...once I get time to tinker on it. -- -Austin
Re: Taking a break from Wine
Dan Kegel wrote: > Every now and then, my wrists force me to take > a break from Wine development. This time it's > also a matter of focus; I would like to spend more > time with my family while also focussing more > on my day job. One of the three had to go, > for a while at least. > Thank you Dan, you will be missed for every moment you're gone. > I will still try to update winetricks once a month, > but it might be good if other folks volunteered > to help out there; drop me a line if you're interested. > I was just about to package this properly - please let me know who takes over as the contact person. > Likewise, it would be good if someone else took > on running patchwatcher. (Shame, I have these nice > boxes here, just waiting to run it, and no time to > do it.) I'd be happy to answer questions from anyone > who wants to give it a shot. > > I may also still give talks about Wine here and there, > if a good venue presents itself. > I'm also more than willing to give talks at whatever venue, in case you need a sub or a break. Thanks, Scott Ritchie
Re: Wine on Windows - wiki notes
2009/3/11 Steven Edwards : > On Wed, Mar 11, 2009 at 5:53 PM, David Gerard wrote: >> I thought Cygwin had long had sendmsg/recvmsg: > According to Microsofts documentation (thanks Thunderbird) > Vista/Windows Server 2008 and the Subsystem for Unix applications is > supposed to support this so we might actually have a chance at seeing > Wine run on Windows soon. I have a regression test for passing file > descriptors with sendmsg/recvmsg I am working on that should be ready > in a few more days and will post it. I'll test with Cygwin and SFU > under Windows XP. Hopefully someone with Vista and Windows Server 2003 > or 2007 can test for us. SUA for Windows 7 should be available around RC time: http://blogs.msdn.com/sfu/archive/2009/01/23/nfs-and-sua-in-windows-7.aspx (I've been experimenting with the Windows 7 beta. I'll have to hold off on more of that until I have a spare machine with the ridiculous quantities of memory it wants to run without great pain. Stupidly fat. Pretty, though.) Vista/Win7 is where Wine on Windows would actually be useful to users, of course - given Wine targets XP already. - d.
Re: Wiki challenge question on user account creation
2009/3/12 David Gerard : > Again, you appear to be reading things I didn't write at all, > even while quoting what I did. Your communications are > confusing, please make them less so. I apologise, I was getting you confused with King InuYasha. Serves me right for emailing while tired :D
Re: Taking a break from Wine
On Wed, Mar 11, 2009 at 4:50 PM, Ben Klein wrote: > What is involved in the maintenance of winetricks? I might be > available to do that :) Mostly just running its test suite every once in a while and updating the script when some URL or checksum changes, as well as watching the bug tracker and merging patches from other folks.
Re: Taking a break from Wine
2009/3/12 Dan Kegel : > Every now and then, my wrists force me to take > a break from Wine development. This time it's > also a matter of focus; I would like to spend more > time with my family while also focussing more > on my day job. One of the three had to go, > for a while at least. Even though you've done some great work for the Wine project, you're still a volunteer and you can only give the time that's available. I hope you have a great time with your family and that work isn't too stressful on you :P What is involved in the maintenance of winetricks? I might be available to do that :)
Re: Wiki challenge question on user account creation
2009/3/11 Ben Klein : > 2009/3/12 David Gerard : >> Reasons for picking Moin are typically: >> Reasons for picking MediaWiki are typically: > Moin is sounding better to me so far. Less overhead is good. > Generally, people pick a Wiki that Just Works (TM). Unfortunately, > they pretty much all do, so there's no absolute "this is better". The > existence of so many different Wiki systems is testament to that. Well, yeah. Has anyone given a good reason to move from Moin? I can read the wiki and write stuff in it OK. >> I did a move at work from Moin to MediaWiki, on the intranet wiki ten >> of us use all day every day. Our reason was that our Moin wiki was >> just somehow not as usable as we wanted from a wiki, so we gave >> MediaWiki a go and it was good enough to bother moving engines. Also, >> the Moin wiki was full of outdated rubbish, so this was a handy excuse >> to start over. > "somehow not as usable" isn't a strong argument either. Specifically > what issues do you have with Moin, and are they present on > wiki.winehq.org? None. You appear to be reading something that I didn't write. >>> Number of new users is not necessarily proportional to number of new >>> spammers. Do we actually have a problem with spam on the Wiki? >> If there is, I'll hereby put my hand up to help. > You were implying that there IS a problem with spammers. I see a > request elsewhere on wine-devel to have an IP blocked, so that's one > spammer out of how many new users? Er, I didn't state that wiki.winehq.org has a problem with spammers - I asked if there was, *in the text you actually quoted*. Again, you appear to be reading things I didn't write at all, even while quoting what I did. Your communications are confusing, please make them less so. - d.
Taking a break from Wine
Every now and then, my wrists force me to take a break from Wine development. This time it's also a matter of focus; I would like to spend more time with my family while also focussing more on my day job. One of the three had to go, for a while at least. I will still try to update winetricks once a month, but it might be good if other folks volunteered to help out there; drop me a line if you're interested. Likewise, it would be good if someone else took on running patchwatcher. (Shame, I have these nice boxes here, just waiting to run it, and no time to do it.) I'd be happy to answer questions from anyone who wants to give it a shot. I may also still give talks about Wine here and there, if a good venue presents itself. Ta for now! - Dan
Re: Wiki challenge question on user account creation
2009/3/12 David Gerard : > 2009/3/11 Ben Klein : > >> Does what we have now work? Yes. Is there any reason why we should >> consider moving from Moin to some other Wiki system? Your turn to >> answer. > > At work, I use a ridiculous range of wiki engines. I've used Moin and > MediaWiki most heavily. > > Reasons for picking Moin are typically: > > * it'll do > * it's not PHP > * it doesn't use a database. > > Reasons for picking MediaWiki are typically: > > * it'll do > * people know how to use Wikipedia. Moin is sounding better to me so far. Less overhead is good. Generally, people pick a Wiki that Just Works (TM). Unfortunately, they pretty much all do, so there's no absolute "this is better". The existence of so many different Wiki systems is testament to that. > I did a move at work from Moin to MediaWiki, on the intranet wiki ten > of us use all day every day. Our reason was that our Moin wiki was > just somehow not as usable as we wanted from a wiki, so we gave > MediaWiki a go and it was good enough to bother moving engines. Also, > the Moin wiki was full of outdated rubbish, so this was a handy excuse > to start over. "somehow not as usable" isn't a strong argument either. Specifically what issues do you have with Moin, and are they present on wiki.winehq.org? >> Number of new users is not necessarily proportional to number of new >> spammers. Do we actually have a problem with spam on the Wiki? > > If there is, I'll hereby put my hand up to help. You were implying that there IS a problem with spammers. I see a request elsewhere on wine-devel to have an IP blocked, so that's one spammer out of how many new users?
Re: Wine on Windows - wiki notes
2009/1/1 Steven Edwards : > Honestly though I think this is the wrong approach. If you want to > emulate an older windows environment you should look at something like > VMware's Thinapp. The Wine on Windows method is going to involve > either emulating Win32 on Cygwin on Win32 or Win32 on POSIX on NTOS. I > think its too many layers of abstraction and redirection. I don't know > the internals of the Thinapp design, (if Ge van Geldorp is lurking he > can explain more), but I believe it uses Side by Side assemblies to > link on older versions of Windows dlls or Windows replacement dlls to > trick the applications in to thinking they are on older Windows. You > could take the existing Wine for Mingw32 dlls and a good bit of other > Wine code and try to start a project doing something like this without > the overhead of the wineserver and posix emulation. > > A FOSS Thinapp clone sounds like a reall fun project actually... I see two advantages of Wine over VMware technology here. 1) Wine is free, VMware Thinapp is trial/commercial license 2) VMware is a virtual machine, even for Thinapp. You need a copy of a complete operating system to run apps inside it. The argument could be made that a virtual machine (e.g. VirtualBox OSE, QEMU or KVM/QEMU) is a better solution to getting Windows programs to run than using Wine (in particular VirtualBox which supports hardware accelerated OpenGL and, using wined3d in the development version, DirectX). So why has there been any development on Wine at all over the past 16 years or so? Because Wine is *not* a complete operating system, and because Wine is distributed under free (beer and speech forms) licenses. I also see two problems with the idea of creating a Wine-based thinapp clone. 1) Effort. You're talking about a redesign of Wine that involves removing POSIX and wineserver dependence. This is not a trivial thing in any way, shape or form. Wine is designed from the start to provide a Win32 compatibility layer and environment on Unix and Unix-like systems. You would also have to remove all X11 dependence. (I'm not sure how Wine on Windows works right now, is there a DirectX pass-through or does it use an X server?) 2) Wine already allows you to change what Windows version is reported to applications on a per-app basis. I'm unsure what component is used for this, but I suspect it's built somewhere into wineserver. Someone correct me if I'm wrong :)
Re: Wine on Windows - wiki notes
On Wed, Mar 11, 2009 at 5:53 PM, David Gerard wrote: > I thought Cygwin had long had sendmsg/recvmsg: > > http://www.cygwin.com/ml/cygwin-patches/2002-q1/msg00111.html > > What do you mean here? It has an implementation but not one that supports doing a recvmsg with a file descriptor so I understand. It seems Interix/Services for Unix and Subsystem for Unix applications have the same problem. According to Microsofts documentation (thanks Thunderbird) Vista/Windows Server 2008 and the Subsystem for Unix applications is supposed to support this so we might actually have a chance at seeing Wine run on Windows soon. I have a regression test for passing file descriptors with sendmsg/recvmsg I am working on that should be ready in a few more days and will post it. I'll test with Cygwin and SFU under Windows XP. Hopefully someone with Vista and Windows Server 2003 or 2007 can test for us. -- 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: Wine on Windows - wiki notes
[reviving oldish thread] 2008/12/31 Steven Edwards : > I've poked at it off and on over the years Its been my experience > building on Cygwin was actually less trouble. Cygwin and SFU/Internix > both require the same basic lowlevel magic. Proper signal handling, > getting the thread management right and sendmsg/recvmsg support. I > think someone on the cygwin side was working on the sendmsg/recvmsg > part so maybe that could be ported over to SFU. I thought Cygwin had long had sendmsg/recvmsg: http://www.cygwin.com/ml/cygwin-patches/2002-q1/msg00111.html What do you mean here? - d.
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
>From 165aeb4aa1350b6d26be268ca7e4136058484069 Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 22:09:47 +0300
Subject: [ntdll] Move search for assemblyIdentity element
Function for manifest parsing tried search for assemblyIdentity element
only if it placed in begin of a manifest. Now it will be more accurate
and wait for it in entire one
---
dlls/ntdll/actctx.c | 60 --
1 files changed, 29 insertions(+), 31 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index f864033..9ca8f35 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -1390,37 +1390,6 @@ static BOOL parse_assembly_elem(xmlbuf_t* xmlbuf, struct actctx_loader* acl,
assembly->no_inherit)
return FALSE;
-if (xmlstr_cmp(&elem, assemblyIdentityW))
-{
-if (!parse_assembly_identity_elem(xmlbuf, acl->actctx, &assembly->id)) return FALSE;
-ret = next_xml_elem(xmlbuf, &elem);
-
-if (expected_ai)
-{
-/* FIXME: more tests */
-if (assembly->type == ASSEMBLY_MANIFEST &&
-memcmp(&assembly->id.version, &expected_ai->version, sizeof(assembly->id.version)))
-{
-FIXME("wrong version for assembly manifest: %u.%u.%u.%u / %u.%u.%u.%u\n",
- expected_ai->version.major, expected_ai->version.minor,
- expected_ai->version.build, expected_ai->version.revision,
- assembly->id.version.major, assembly->id.version.minor,
- assembly->id.version.build, assembly->id.version.revision);
-return FALSE;
-}
-else if (assembly->type == ASSEMBLY_SHARED_MANIFEST &&
-(assembly->id.version.major != expected_ai->version.major ||
- assembly->id.version.minor != expected_ai->version.minor ||
- assembly->id.version.build < expected_ai->version.build ||
- (assembly->id.version.build == expected_ai->version.build &&
- assembly->id.version.revision < expected_ai->version.revision)))
-{
-FIXME("wrong version for shared assembly manifest\n");
-return FALSE;
-}
-}
-}
-
while (ret)
{
if (xmlstr_cmp_end(&elem, assemblyW))
@@ -1452,6 +1421,35 @@ static BOOL parse_assembly_elem(xmlbuf_t* xmlbuf, struct actctx_loader* acl,
{
ret = parse_clr_surrogate_elem(xmlbuf, assembly);
}
+ else if (xmlstr_cmp(&elem, assemblyIdentityW))
+ {
+ if (!parse_assembly_identity_elem(xmlbuf, acl->actctx, &assembly->id)) return FALSE;
+
+ if (expected_ai)
+ {
+ /* FIXME: more tests */
+ if (assembly->type == ASSEMBLY_MANIFEST &&
+ memcmp(&assembly->id.version, &expected_ai->version, sizeof(assembly->id.version)))
+ {
+ FIXME("wrong version for assembly manifest: %u.%u.%u.%u / %u.%u.%u.%u\n",
+ expected_ai->version.major, expected_ai->version.minor,
+ expected_ai->version.build, expected_ai->version.revision,
+ assembly->id.version.major, assembly->id.version.minor,
+ assembly->id.version.build, assembly->id.version.revision);
+ ret = FALSE;
+ }
+ else if (assembly->type == ASSEMBLY_SHARED_MANIFEST &&
+ (assembly->id.version.major != expected_ai->version.major ||
+ assembly->id.version.minor != expected_ai->version.minor ||
+ assembly->id.version.build < expected_ai->version.build ||
+ (assembly->id.version.build == expected_ai->version.build &&
+ assembly->id.version.revision < expected_ai->version.revision)))
+ {
+ FIXME("wrong version for shared assembly manifest\n");
+ ret = FALSE;
+ }
+ }
+ }
else
{
WARN("unknown element %s\n", debugstr_xmlstr(&elem));
--
1.6.2
Re: [ntdll] lookup_assembly function should returns STATUS_SUCCESS
STATUS_SUCCESS is 0x0, see http://source.winehq.org/source/include/ntstatus.h#L30
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
>From c59dbc8de90398c03e7cc44124a5902b1b2d8fc7 Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 22:27:09 +0300
Subject: [ntdll] lookup_assembly function should returns STATUS_SUCCESS
Expected result of function is STATUS_SUCCESS if no errors occurred,
but it returned zero in this case
---
dlls/ntdll/actctx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index 9ca8f35..1eb8ef7 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -1942,7 +1942,7 @@ static NTSTATUS lookup_assembly(struct actctx_loader* acl,
static const WCHAR dotDllW[] = {'.','d','l','l',0};
unsigned int i;
WCHAR *buffer, *p, *directory;
-NTSTATUS status;
+NTSTATUS status = STATUS_SUCCESS;
UNICODE_STRING nameW;
HANDLE file;
--
1.6.2
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
>From a7af98e6d2d185614d92c02c817ac74382c1b35c Mon Sep 17 00:00:00 2001 From: Roman Mindalev Date: Wed, 11 Mar 2009 21:32:42 +0300 Subject: [ntdll] Free memory for type field of an asembly_identity Memory for this field was allocated and never freed --- dlls/ntdll/actctx.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c index 25c590a..f864033 100644 --- a/dlls/ntdll/actctx.c +++ b/dlls/ntdll/actctx.c @@ -338,6 +338,7 @@ static void free_assembly_identity(struct assembly_identity *ai) RtlFreeHeap( GetProcessHeap(), 0, ai->arch ); RtlFreeHeap( GetProcessHeap(), 0, ai->public_key ); RtlFreeHeap( GetProcessHeap(), 0, ai->language ); +RtlFreeHeap( GetProcessHeap(), 0, ai->type ); } static struct entity* add_entity(struct entity_array *array, DWORD kind) -- 1.6.2
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
>From 4f895878f85988c292454662ae07ba3e72d7e7ba Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 21:25:52 +0300
Subject: [ntdll] Care about arch and name fields in assembly_identity structure
On parsing of a manifest is possible access to zero address and crash.
It's happens because arch and name manifest attributes can
be not specified and pointers in assembly_identity structure can be
uninitialized. This patch adds check for these fields
---
dlls/ntdll/actctx.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index 79d475f..25c590a 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -496,17 +496,19 @@ static WCHAR *build_assembly_dir(struct assembly_identity* ai)
static const WCHAR noneW[] = {'n','o','n','e',0};
static const WCHAR mskeyW[] = {'d','e','a','d','b','e','e','f',0};
+const WCHAR *arch = ai->arch ? ai->arch : noneW;
const WCHAR *key = ai->public_key ? ai->public_key : noneW;
const WCHAR *lang = ai->language ? ai->language : noneW;
-SIZE_T size = (strlenW(ai->arch) + 1 + strlenW(ai->name) + 1 + strlenW(key) + 24 + 1 +
- strlenW(lang) + 1) * sizeof(WCHAR) + sizeof(mskeyW);
+const WCHAR *name = ai->name ? ai->name : noneW;
+SIZE_T size = (strlenW(arch) + 1 + strlenW(name) + 1 + strlenW(key) + 24 + 1 +
+ strlenW(lang) + 1) * sizeof(WCHAR) + sizeof(mskeyW);
WCHAR *ret;
if (!(ret = RtlAllocateHeap( GetProcessHeap(), 0, size ))) return NULL;
-strcpyW( ret, ai->arch );
+strcpyW( ret, arch );
strcatW( ret, undW );
-strcatW( ret, ai->name );
+strcatW( ret, name );
strcatW( ret, undW );
strcatW( ret, key );
strcatW( ret, undW );
--
1.6.2
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
Austin English wrote: On Wed, Mar 11, 2009 at 2:40 PM, Roman Mindalev wrote: Jacek Caban wrote: Hi Roman, On parsing of manifest in PE module is possible access to zero address and crash. It's happens because not all manifest attributes can be specified and pointers in assembly_identity structure can be uninitialized. This patch adds function for setting empty strings in structure elements when they not initialized. Your patch looks like a workaround. You should fix the code to cope with NULL pointers correctly instead of allocating useless empty strings. Also initialize_assembly_identity doesn't make sense. ai is initialized a few lines later by memset call. Thanks for your notices! I'm rewrote patch, append some changes and split to small parts. Please send only one patch per e-mail. Ok
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
On Wed, Mar 11, 2009 at 2:40 PM, Roman Mindalev wrote: > Jacek Caban wrote: >> >> Hi Roman, >> >>> On parsing of manifest in PE module is possible access to zero address >>> and crash. It's happens because not all manifest attributes can be >>> specified and pointers in assembly_identity structure can be >>> uninitialized. This patch adds function for setting empty strings in >>> structure elements when they not initialized. >> >> >> Your patch looks like a workaround. You should fix the code to cope with >> NULL pointers correctly instead of allocating useless empty strings. >> Also initialize_assembly_identity doesn't make sense. ai is initialized a >> few lines later by memset call. > > Thanks for your notices! > I'm rewrote patch, append some changes and split to small parts. > > > > Please send only one patch per e-mail. -- -Austin
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
Jacek Caban wrote:
Hi Roman,
On parsing of manifest in PE module is possible access to zero address
and crash. It's happens because not all manifest attributes can be
specified and pointers in assembly_identity structure can be
uninitialized. This patch adds function for setting empty strings in
structure elements when they not initialized.
Your patch looks like a workaround. You should fix the code to cope with
NULL pointers correctly instead of allocating useless empty strings.
Also initialize_assembly_identity doesn't make sense. ai is initialized
a few lines later by memset call.
Thanks for your notices!
I'm rewrote patch, append some changes and split to small parts.
>From 4f895878f85988c292454662ae07ba3e72d7e7ba Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 21:25:52 +0300
Subject: [ntdll] Care about arch and name fields in assembly_identity structure
On parsing of a manifest is possible access to zero address and crash.
It's happens because arch and name manifest attributes can
be not specified and pointers in assembly_identity structure can be
uninitialized. This patch adds check for these fields
---
dlls/ntdll/actctx.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index 79d475f..25c590a 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -496,17 +496,19 @@ static WCHAR *build_assembly_dir(struct assembly_identity* ai)
static const WCHAR noneW[] = {'n','o','n','e',0};
static const WCHAR mskeyW[] = {'d','e','a','d','b','e','e','f',0};
+const WCHAR *arch = ai->arch ? ai->arch : noneW;
const WCHAR *key = ai->public_key ? ai->public_key : noneW;
const WCHAR *lang = ai->language ? ai->language : noneW;
-SIZE_T size = (strlenW(ai->arch) + 1 + strlenW(ai->name) + 1 + strlenW(key) + 24 + 1 +
- strlenW(lang) + 1) * sizeof(WCHAR) + sizeof(mskeyW);
+const WCHAR *name = ai->name ? ai->name : noneW;
+SIZE_T size = (strlenW(arch) + 1 + strlenW(name) + 1 + strlenW(key) + 24 + 1 +
+ strlenW(lang) + 1) * sizeof(WCHAR) + sizeof(mskeyW);
WCHAR *ret;
if (!(ret = RtlAllocateHeap( GetProcessHeap(), 0, size ))) return NULL;
-strcpyW( ret, ai->arch );
+strcpyW( ret, arch );
strcatW( ret, undW );
-strcatW( ret, ai->name );
+strcatW( ret, name );
strcatW( ret, undW );
strcatW( ret, key );
strcatW( ret, undW );
--
1.6.2
>From a7af98e6d2d185614d92c02c817ac74382c1b35c Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 21:32:42 +0300
Subject: [ntdll] Free memory for type field of an asembly_identity
Memory for this field was allocated and never freed
---
dlls/ntdll/actctx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index 25c590a..f864033 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -338,6 +338,7 @@ static void free_assembly_identity(struct assembly_identity *ai)
RtlFreeHeap( GetProcessHeap(), 0, ai->arch );
RtlFreeHeap( GetProcessHeap(), 0, ai->public_key );
RtlFreeHeap( GetProcessHeap(), 0, ai->language );
+RtlFreeHeap( GetProcessHeap(), 0, ai->type );
}
static struct entity* add_entity(struct entity_array *array, DWORD kind)
--
1.6.2
>From 165aeb4aa1350b6d26be268ca7e4136058484069 Mon Sep 17 00:00:00 2001
From: Roman Mindalev
Date: Wed, 11 Mar 2009 22:09:47 +0300
Subject: [ntdll] Move search for assemblyIdentity element
Function for manifest parsing tried search for assemblyIdentity element
only if it placed in begin of a manifest. Now it will be more accurate
and wait for it in entire one
---
dlls/ntdll/actctx.c | 60 --
1 files changed, 29 insertions(+), 31 deletions(-)
diff --git a/dlls/ntdll/actctx.c b/dlls/ntdll/actctx.c
index f864033..9ca8f35 100644
--- a/dlls/ntdll/actctx.c
+++ b/dlls/ntdll/actctx.c
@@ -1390,37 +1390,6 @@ static BOOL parse_assembly_elem(xmlbuf_t* xmlbuf, struct actctx_loader* acl,
assembly->no_inherit)
return FALSE;
-if (xmlstr_cmp(&elem, assemblyIdentityW))
-{
-if (!parse_assembly_identity_elem(xmlbuf, acl->actctx, &assembly->id)) return FALSE;
-ret = next_xml_elem(xmlbuf, &elem);
-
-if (expected_ai)
-{
-/* FIXME: more tests */
-if (assembly->type == ASSEMBLY_MANIFEST &&
-memcmp(&assembly->id.version, &expected_ai->version, sizeof(assembly->id.version)))
-{
-FIXME("wrong version for assembly manifest: %u.%u.%u.%u / %u.%u.%u.%u\n",
- expected_ai->version.major, expected_ai->version.minor,
- expected_ai->version.build, expected_ai->version.revision,
- assembly->id.version.major, assembly->id.version.minor,
- assembly->id.version.build, assembly->id.version.revision);
-
Re: shlwapi: Correct AssocCreate and tests (try 2)
Hi Alistair, Alistair Leslie-Hughes wrote: Hi, Added check for IUnknown, thanks Jacek. It would be better to return correct error on QueryInterface failure. Otherwise you're duplicating the code. Jacek
Re: [ntdll] Care about empty fields of assembly_identity structure in actctx.c
Hi Roman, On parsing of manifest in PE module is possible access to zero address and crash. It's happens because not all manifest attributes can be specified and pointers in assembly_identity structure can be uninitialized. This patch adds function for setting empty strings in structure elements when they not initialized. Your patch looks like a workaround. You should fix the code to cope with NULL pointers correctly instead of allocating useless empty strings. Also initialize_assembly_identity doesn't make sense. ai is initialized a few lines later by memset call. Jacek
Re: [PATCH] 0001-Fixed-tests-in-dlls-ws2_32-tests-sock.c-for-simple_s.patch
Hi Andrew,
diff --git a/dlls/dbghelp/type.c b/dlls/dbghelp/type.c
index 947eb49..4e426e2 100644
--- a/dlls/dbghelp/type.c
+++ b/dlls/dbghelp/type.c
It seems rather unlikely that dbghelp is causing failures in the
winsock tests. Perhaps dbghelp is getting invoked due to a crash?
Besides,
-sym_info->TypeIndex = (DWORD)type;
+sym_info->TypeIndex = (DWORD_PTR)type;
This doesn't appear correct. sym_info is a SYMBOL_INFO *, and
SYMBOL_INFO.TypeIndex is declared as ULONG. The fix is likely to
require storing an index into a table rather than a pointer in
TypeIndex, since type (a struct symt **) won't fit in a ULONG.
-tifp->ChildId[i] = (DWORD)*pt;
+tifp->ChildId[i] = (DWORD_PTR)*pt;
Same here.
-WS(u_long) S_addr;
+ULONG S_addr;
(snip)
-#define FIONBIO_IOW('f', 126, u_long)
+#define FIONBIO_IOW('f', 126, ULONG)
These casts are fishy. Why are ULONG and u_long (WS_u_long) different
sizes? If they are, the includes are broken somehow, as there's
simply no need for S_addr to be anything but 32 bits.
--Juan
Re: LookupAccountSidW returns "unexpected" username
2009/3/10 Andreas Rosenberg : > While I did some experimenting with the proposals from Vitaliy Margolen > to get an accepted patch for GetUserProfileDirectoryW, I found this > behavior: > > OpenProcessToken(hProcess,TOKEN_QUERY,&hToken); > ... > GetTokenInformation( hToken, TokenUser, ptiUser, cbti, &cbti ) > ... > LookupAccountSidW( NULL, ptiUser->User.Sid, lpUserName, lpchSize,lpDomain, > &cbDomain, &snu ); > > In Windows XP SP3 the LookupAccountSidW fills lpUserName with the > name of the current user (same as GetUserName) > > Running this code in Wine results in the username: 'INTERACTIVE'. See server/token.c:security_unix_uid_to_sid. This should return a SID with a pattern that LookupAccountSidW can recognise and then extract the uid and look it up and return the UNIX user name. > Seems like the LookupAccountSidW does something not compatible with > Windows. Im thinking about writing a test code, but simply checking > if the above code returns the same as GetUserNameW seems not > correct, if test code should run under a different account as the actual > login user. > > Is this a requirement for running the wine tests? -- Rob Shearman
Re: qmgr test failures
On Tue, Mar 10, 2009 at 6:59 PM, Rob Shearman wrote: > 2009/3/9 Austin English : >> Howdy Rob, >> >> Looks like one of your recent qmgr patches added failure to qmgr: >> http://test.winehq.org/data/1b9a6fb4e9f5a76f1ca352bef121689df02d9289/#group_Wine >> >> file.c:121: Test failed: GetRemoteName failed: 800706c6 >> file.c:124: Tests skipped: Unable to get remote name of test_file. >> file.c:138: Test failed: GetLocalName failed: 800706c6 >> file.c:141: Tests skipped: Unable to get local name of test_file. >> file: 6 tests executed (0 marked as todo, 2 failures), 2 skipped. >> >> qmgr: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. >> qmgr.c:217: Test failed: Adding a job in another process failed >> qmgr: 11 tests executed (0 marked as todo, 1 failure), 0 skipped. >> >> Could you take a look? > > I can't reproduce it, so someone who can needs to give me a > +seh,+tid,+ole,+qmgr log of it happening. > > -- > Rob Shearman > Seems to have cleared up, I can't get it to happen in tree, and it's not showing up on http://test.winehq.org. Maybe a race condition? -- -Austin
Fwd: Disabling File attachments on Wiki
to list as well -- Forwarded message -- From: David Gerard Date: 2009/3/11 Subject: Re: Disabling File attachments on Wiki To: Dimi Paun 2009/3/11 Dimi Paun : > On Wed, 2009-03-11 at 08:02 -0600, Vitaliy Margolen wrote: >> Anyone? Also how about blocking this IP: 213.155.0.32 ? > Not sure how we can block that IP easily. If it has to do > with iptables, forget it. You add a line to moin_config.py : http://moinmo.in/AntiSpamFeatures#Black_Lists_--_detecting_spam_by_source MoinMoin doesn't have the sophisticated anti-vandal capabilities of MediaWiki, but it's far from helpless. - d.
Re: Disabling File attachments on Wiki
On Wed, 2009-03-11 at 08:02 -0600, Vitaliy Margolen wrote: > Anyone? Also how about blocking this IP: 213.155.0.32 ? Not sure how we can block that IP easily. If it has to do with iptables, forget it. -- Dimi Paun Lattica, Inc.
Re: [3/6] wined3d: The adapters array should be owned by IWineD3DImpl.
2009/3/11 Allan Tong :
> On Wed, Mar 11, 2009 at 5:18 AM, Henri Verbeet
> wrote:
>
>> @@ -4051,10 +4097,11 @@ static void WINE_GLAPI diffuse_d3dcolor(const void
>> *data)
>> static void WINE_GLAPI specular_d3dcolor(const void *data)
>> {
>> DWORD specularColor = *((const DWORD *)data);
>> + GLbyte d[] = {D3DCOLOR_B_R(specularColor),
>> + D3DCOLOR_B_G(specularColor),
>> + D3DCOLOR_B_B(specularColor)};
>>
>> - GL_EXTCALL(glSecondaryColor3ubEXT)(D3DCOLOR_B_R(specularColor),
>> - D3DCOLOR_B_G(specularColor),
>> - D3DCOLOR_B_B(specularColor));
>> + specular_func_3ubv(d);
>> }
>>
>> static void WINE_GLAPI warn_no_specular_func(const void *data)
>> @@ -4110,6 +4157,7 @@ static void fillGLAttribFuncs(const WineD3D_GL_Info
>> *gl_info)
>> }
>> specular_funcs[WINED3DDECLTYPE_FLOAT4] = invalid_func;
>> if(GL_SUPPORT(EXT_SECONDARY_COLOR)) {
>> + specular_func_3ubv =
>> (glAttribFunc)GL_EXTCALL(glSecondaryColor3ubvEXT);
>> specular_funcs[WINED3DDECLTYPE_D3DCOLOR] = specular_d3dcolor;
>> } else {
>> specular_funcs[WINED3DDECLTYPE_D3DCOLOR] =
>> warn_no_specular_func;
>
> This looks like an unrelated change.
>
Yes, but unfortunately it isn't. GL_EXTCALL() depends on
GLINFO_LOCATION, which was defined as "(Adapters[0].gl_info)". That
obviously doesn't work anymore now that Adapters isn't global anymore.
Having specular_func_3ubv as global isn't particularly pretty or safe
of course, but it's not much worse than eg. the specular_funcs array
in that regard.
>> @@ -4182,7 +4231,7 @@ BOOL InitAdapters(void) {
>> /* No need to hold any lock. The calling library makes sure only one
>> thread calls
>> * wined3d simultaneously
>> */
>> - if(numAdapters > 0) return Adapters[0].opengl;
>> + if (This->adapter_count) return This->adapters[0].opengl;
>>
>> TRACE("Initializing adapters\n");
>
> Is this check still necessary? InitAdapters should only be called
> once per IWineD3DImpl object.
>
Yeah, this is redundant now. I'll send a patch to remove it.
Re: Wiki challenge question on user account creation
2009/3/11 Ben Klein : > Does what we have now work? Yes. Is there any reason why we should > consider moving from Moin to some other Wiki system? Your turn to > answer. At work, I use a ridiculous range of wiki engines. I've used Moin and MediaWiki most heavily. Reasons for picking Moin are typically: * it'll do * it's not PHP * it doesn't use a database. Reasons for picking MediaWiki are typically: * it'll do * people know how to use Wikipedia. I did a move at work from Moin to MediaWiki, on the intranet wiki ten of us use all day every day. Our reason was that our Moin wiki was just somehow not as usable as we wanted from a wiki, so we gave MediaWiki a go and it was good enough to bother moving engines. Also, the Moin wiki was full of outdated rubbish, so this was a handy excuse to start over. It's not clear that any of those reasons apply here. Moving wiki engines is a *pain in the backside* and it's not something you do unless you have to. > Number of new users is not necessarily proportional to number of new > spammers. Do we actually have a problem with spam on the Wiki? If there is, I'll hereby put my hand up to help. - d.
Re: Disabling File attachments on Wiki
Vitaliy Margolen wrote: > Please disable file attachments on Wiki. There are no way to verify their > validity and for the past week it's been a constant source of spam. > > IMHO file attachment does not belong on text only Wiki. If anyone needs to > attach a patch a two - they can link it to the one in ML archives or even > bugzilla. > > Vitaliy. Anyone? Also how about blocking this IP: 213.155.0.32 ? Vitaliy
Re: [3/6] wined3d: The adapters array should be owned by IWineD3DImpl.
On Wed, Mar 11, 2009 at 5:18 AM, Henri Verbeet wrote:
> @@ -4051,10 +4097,11 @@ static void WINE_GLAPI diffuse_d3dcolor(const void
> *data)
> static void WINE_GLAPI specular_d3dcolor(const void *data)
> {
> DWORD specularColor = *((const DWORD *)data);
> + GLbyte d[] = {D3DCOLOR_B_R(specularColor),
> + D3DCOLOR_B_G(specularColor),
> + D3DCOLOR_B_B(specularColor)};
>
> - GL_EXTCALL(glSecondaryColor3ubEXT)(D3DCOLOR_B_R(specularColor),
> - D3DCOLOR_B_G(specularColor),
> - D3DCOLOR_B_B(specularColor));
> + specular_func_3ubv(d);
> }
>
> static void WINE_GLAPI warn_no_specular_func(const void *data)
> @@ -4110,6 +4157,7 @@ static void fillGLAttribFuncs(const WineD3D_GL_Info
> *gl_info)
> }
> specular_funcs[WINED3DDECLTYPE_FLOAT4] = invalid_func;
> if(GL_SUPPORT(EXT_SECONDARY_COLOR)) {
> + specular_func_3ubv =
> (glAttribFunc)GL_EXTCALL(glSecondaryColor3ubvEXT);
> specular_funcs[WINED3DDECLTYPE_D3DCOLOR] = specular_d3dcolor;
> } else {
> specular_funcs[WINED3DDECLTYPE_D3DCOLOR] = warn_no_specular_func;
This looks like an unrelated change.
> @@ -4182,7 +4231,7 @@ BOOL InitAdapters(void) {
> /* No need to hold any lock. The calling library makes sure only one
> thread calls
> * wined3d simultaneously
> */
> - if(numAdapters > 0) return Adapters[0].opengl;
> + if (This->adapter_count) return This->adapters[0].opengl;
>
> TRACE("Initializing adapters\n");
Is this check still necessary? InitAdapters should only be called
once per IWineD3DImpl object.
- Allan
Re: Wiki challenge question on user account creation
2009/3/11 King InuYasha : > On Tue, Mar 10, 2009 at 9:17 PM, Ben Klein wrote: >> >> 2009/3/11 King InuYasha : >> > Why are we using Moin anyways? I know Fedora used to use Moin and they >> > moved >> > off of it for their wiki, and I honestly think that perhaps WineHQ needs >> > to >> > as well. >> >> If you're going to argue for a complete replacement of the Wiki >> system, you'll have to provide better support than "Fedora dumped >> Moin". > > I didn't want to provide reasons to dump it unless I know why we ARE using > it so I can provide better counterarguments. Just showing up with arguments > for another wiki based system without knowing why Moin is chosen does not > paint me in worse light than I already am ;) > It makes me seem belligerent. Does what we have now work? Yes. Is there any reason why we should consider moving from Moin to some other Wiki system? Your turn to answer. 2009/3/11 King InuYasha : > On Wed, Mar 11, 2009 at 3:46 AM, David Gerard wrote: >> 2009/3/5 King InuYasha : >> > A wiki shouldn't have users creating accounts every day, that is a bad >> > indicator. >> >> It is difficult to understand the thinking behind such a statement >> unless you are literally aiming to close a project to outside >> participation. > > Sorry, I should have completed my thought. If you can justify users creating > accounts every day and adding real content to the wiki, then that is fine. > But in most cases, when wikis have lots of users creating accounts every > day, generally some serious spamming is going on or is about to go on. Now, > WineHQ is a high-activity site, so there is some justification for having > lots of users, but take care to use basic precautions when having users > created. My two favorite methods of ensuring users are actually real ones > are email confirm and CAPTCHA, usually a combination of the two. If you > still see similarly high levels of user creation and real content is being > added, then its ok. However, if you use an old version of any web content > software, then the benefits may be negated by the fact that it is possible > that the wiki engine had already been compromised. Number of new users is not necessarily proportional to number of new spammers. Do we actually have a problem with spam on the Wiki?
Re: [ddraw/tests 1/2] Fix a few test failures on W2K (VMware?)
Paul Vriens wrote: Hi, As acknowledged by Stefan, there is no point in testing colors if something isn't drawn. I'm not sure if this is W2K specific or W2K in combination with VMware. Changelog Fix a few test failures on W2K (VMware?) Please ignore this series of 2. I'm first going to check the remark the Henri made about a possible missing EndScene. -- Cheers, Paul.
Re: [ddraw/tests 2/2] Mark some more tests are broken() on W2K
2009/3/11 Stefan Dösinger : > Am Mittwoch, 11. März 2009 12:07:27 schrieb Paul Vriens: >> + ok(hr == D3D_OK || >> + broken(hr == D3DERR_SCENE_IN_SCENE), /* W2K */ >> + "IDirect3DDevice7_BeginScene failed with %08x\n", hr); > I don't like that one. I think I wrote those tests on Win2K partially, so I'd > blame it on Vmware. Its ok to skip checking the colors to reduce follow-up > tests, but I dislike accepting random errors because Vmware returns them. If > you find a real Windows hardware driver that returns this error its ok to > accept D3DERR_SCENE_IN_SCENE as a return value > Isn't that the point of marking it broken() though? I'm pretty sure the failures are specific to vmware rather than w2k. D3DERR_SCENE_IN_SCENE suggests there was a previous BeginScene() without a matching EndScene() though, so you'll want to make sure this isn't caused by eg. a skip() in an earlier test.
Re: [ddraw/tests 2/2] Mark some more tests are broken() on W2K
Stefan Dösinger wrote: Am Mittwoch, 11. März 2009 12:07:27 schrieb Paul Vriens: +ok(hr == D3D_OK || + broken(hr == D3DERR_SCENE_IN_SCENE), /* W2K */ + "IDirect3DDevice7_BeginScene failed with %08x\n", hr); I don't like that one. I think I wrote those tests on Win2K partially, so I'd blame it on Vmware. Its ok to skip checking the colors to reduce follow-up tests, but I dislike accepting random errors because Vmware returns them. If you find a real Windows hardware driver that returns this error its ok to accept D3DERR_SCENE_IN_SCENE as a return value So what do you propose? Making it broken(FAILED(hr)) ? -- Cheers, Paul.
Re: [ddraw/tests 2/2] Mark some more tests are broken() on W2K
Am Mittwoch, 11. März 2009 12:07:27 schrieb Paul Vriens: > + ok(hr == D3D_OK || > + broken(hr == D3DERR_SCENE_IN_SCENE), /* W2K */ > + "IDirect3DDevice7_BeginScene failed with %08x\n", hr); I don't like that one. I think I wrote those tests on Win2K partially, so I'd blame it on Vmware. Its ok to skip checking the colors to reduce follow-up tests, but I dislike accepting random errors because Vmware returns them. If you find a real Windows hardware driver that returns this error its ok to accept D3DERR_SCENE_IN_SCENE as a return value
Re: Wiki challenge question on user account creation
On Wed, Mar 11, 2009 at 3:46 AM, David Gerard wrote: > 2009/3/5 King InuYasha : > > > A wiki shouldn't have users creating accounts every day, that is a bad > > indicator. > > > It is difficult to understand the thinking behind such a statement > unless you are literally aiming to close a project to outside > participation. > > > - d. > > > Sorry, I should have completed my thought. If you can justify users creating accounts every day and adding real content to the wiki, then that is fine. But in most cases, when wikis have lots of users creating accounts every day, generally some serious spamming is going on or is about to go on. Now, WineHQ is a high-activity site, so there is some justification for having lots of users, but take care to use basic precautions when having users created. My two favorite methods of ensuring users are actually real ones are email confirm and CAPTCHA, usually a combination of the two. If you still see similarly high levels of user creation and real content is being added, then its ok. However, if you use an old version of any web content software, then the benefits may be negated by the fact that it is possible that the wiki engine had already been compromised.
Re: ddraw/visual tests
Am Mittwoch, 11. März 2009 11:03:59 schrieb Paul Vriens: > Hi Stefan, > > As you wrote most of the tests: > > I'm looking into some of the ddraw:visual failures (windows 2000 and I > guess only VMware). > > Several tests draw quads but only if _BeginScene succeeded. Is it useful at > all to check the colors afterwards if the quads are not drawn in the first > place? > > I don't want to mark all those failures as broken() if failing _BeginScene > could just do with a win_skip() for the test of a particular test. There's no point in checking if beginscene fails, since nothing is drawn. Unless it doesn't make the code too ugly you can add a win_skip if you want
Re: Wiki challenge question on user account creation
I didn't recommend MediaWiki. If anything, MediaWiki would put us in a _worse_ situation than before. On Wed, Mar 11, 2009 at 3:48 AM, David Gerard wrote: > 2009/3/11 King InuYasha : > > > Why are we using Moin anyways? I know Fedora used to use Moin and they > moved > > off of it for their wiki, and I honestly think that perhaps WineHQ needs > to > > as well. > > > As someone who's done the Moin->MediaWiki thing, I heartily > disrecommend it if avoidable: > > http://www.mediawiki.org/wiki/MoinMoin > > > - d. > > >
ddraw/visual tests
Hi Stefan, As you wrote most of the tests: I'm looking into some of the ddraw:visual failures (windows 2000 and I guess only VMware). Several tests draw quads but only if _BeginScene succeeded. Is it useful at all to check the colors afterwards if the quads are not drawn in the first place? I don't want to mark all those failures as broken() if failing _BeginScene could just do with a win_skip() for the test of a particular test. -- Cheers, Paul.
Re: Wiki challenge question on user account creation
2009/3/11 King InuYasha : > Why are we using Moin anyways? I know Fedora used to use Moin and they moved > off of it for their wiki, and I honestly think that perhaps WineHQ needs to > as well. As someone who's done the Moin->MediaWiki thing, I heartily disrecommend it if avoidable: http://www.mediawiki.org/wiki/MoinMoin - d.
Re: Wiki challenge question on user account creation
2009/3/5 King InuYasha : > A wiki shouldn't have users creating accounts every day, that is a bad > indicator. It is difficult to understand the thinking behind such a statement unless you are literally aiming to close a project to outside participation. - d.
Re: Wiki challenge question on user account creation
On Wed, Mar 11, 2009 at 3:38 AM, King InuYasha wrote: > On Tue, Mar 10, 2009 at 9:17 PM, Ben Klein wrote: > >> 2009/3/11 King InuYasha : >> > Why are we using Moin anyways? I know Fedora used to use Moin and they >> moved >> > off of it for their wiki, and I honestly think that perhaps WineHQ needs >> to >> > as well. >> >> If you're going to argue for a complete replacement of the Wiki >> system, you'll have to provide better support than "Fedora dumped >> Moin". >> > > I didn't want to provide reasons to dump it unless I know why we ARE using > it so I can provide better counterarguments. Just showing up with arguments > for another wiki based system without knowing why Moin is chosen does not > paint me in worse light than I already am ;) > > It makes me seem belligerent. > Oops, I meant does paint me in a worse light than I already am...
Re: Wiki challenge question on user account creation
On Tue, Mar 10, 2009 at 9:17 PM, Ben Klein wrote: > 2009/3/11 King InuYasha : > > Why are we using Moin anyways? I know Fedora used to use Moin and they > moved > > off of it for their wiki, and I honestly think that perhaps WineHQ needs > to > > as well. > > If you're going to argue for a complete replacement of the Wiki > system, you'll have to provide better support than "Fedora dumped > Moin". > I didn't want to provide reasons to dump it unless I know why we ARE using it so I can provide better counterarguments. Just showing up with arguments for another wiki based system without knowing why Moin is chosen does not paint me in worse light than I already am ;) It makes me seem belligerent.
Re: Fwd: [Wine] Re: The pros and cons of a wiki AppDB
You cannot compare AppDB to Wikipedia nor anything like that. You cannot compare wiki vandals to spambots either. That's outside the point, anyway. The real problem here is this, a wiki fits a need where most content can be added and changed by anyone and everyone. This is not the AppDB's goal. You are setting sail for administration-hell. Nevermind having one volunteer, you would put more workload on current maintainers, and it would certainly not attract many more. There's been discussions on ways to improve the AppDB recently, I'm sure you followed them. Things are working out, there are just a few points to fix; how it can be confusing for users submitting test data, and how it can be confusing for users reading test data. There is no actual problem with the data itself most of the time. I liked the proposal for getting some kind of Application Wizard that would automatically give the app a rating, etc. I'd also like, as a user but also as a maintainer of external resources, to have a nice organized page for tips/hacks/patches/what-not in order to get an app to work. Here is a common example. I play WoW and just installed Ubuntu to ditch my Windows install. I want to get WoW working. My first reaction is to google or ask around and I'll get linked to wine. This is the first page I will see: http://appdb.winehq.org/objectManager.php?sClass=application&iId=1922 That's confusing, I have multiple versions of the game, but for WoW I should only have something like "WoW without any expansion", "WoW: The Burning Crusade" (1st expansion) and "WoW: Wrath of the Lich King". Additionally, the most recent version is in the middle of the others; I might not read, click the first link and get way-outdated data from wine 0.9.39. Solution: Have an obvious "Recent version(s)" link, and a more obscure "Old/Archived test data" if need be archiving it. I then land on this page if I get it right: http://appdb.winehq.org/objectManager.php?sClass=version&iId=14154 Woah this is just huge. No way I'm reading it all. I have dozens and dozens of workarounds - am I gonna have to use them all or something? I want to get everything right on the get-go but this is very discouraging. If you know how it works it's actually pretty neat, but this is kind of unreadable. A few solutions: Have a bunch of section. Maybe something tabbed or something, when I look at a page for the first time I don't want to see something extremely long. Moving the comments out of the page, but with a very obvious link would be nice. What I'm thinking is some kind of tab UI between the breadcrumb and the top of the test data. Test Data || Known bugs (8) || Workarounds || Comments What I'm doing here is just splitting the page in 4. Everything should fit within 1 or 2 screens, much more readable suddenly. "Known bugs" could probably have a maintainer-written note on anything that doesn't belong on bugzilla (such as bugs happening on Windows only) and voila. See, no need for a Wiki. Jerome L. On Mon, Mar 9, 2009 at 4:47 AM, David Gerard wrote: > 2009/3/9 Ben Klein : >> 2009/3/9 David Gerard : >>> 2009/3/8 James Mckenzie : > If we move to an open Wiki, be prepared to be very busy. I've seen spambots get past most, if not all, of the verification systems and bomb away. > >>> I come from years of fighting vandals on Wikipedia. I know a thing or >>> two about the field ... > >> AppDB is not an encyclopaedia. > > > And, of course, I didn't say it was, so your point is very unclear > indeed. I would have thought the above was fairly obviously answering > the question of wiki spam control, and noting that I know a thing or > two about the area; in this case, the relevant point is that Wikipedia > is a wiki rather than that it is an encyclopedia. > > If you're going to pick random unrelated tangents out of what I write, > it won't really enhance communication. > > > - d. > > > -- Adys
