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

Re: AppDB new design: Top 10s still look ugly

by André Hentschel

Ricardo Filipe schrieb: > 2009/2/15 André Hentschel <nerv(a)dawncrow.de <mailto:nerv(a)dawncrow.de>> > > Ricardo Filipe schrieb: > > hi andré, > > alex didn't apply your patch. he just fixed the .css to give it the > > same style as it had before. > > > > 2009/2/15 André Hentschel <nerv(a)dawncrow.de > <mailto:nerv(a)dawncrow.de> <mailto:nerv(a)dawncrow.de > <mailto:nerv(a)dawncrow.de>>> > > > > Hello, > > Bug #16466 is declared as fixed. but it isnt. my patch should do > > something else. > > I wanted let each top 10 in its own color(platin, gold or > bronce) and > > not to have the platin-look for all. > > anything went wrong while using my patch. maybe the other patch > > went in, > > too? > > It should be this style: > http://www.funplugged.bplaced.net/appdb/ > > > > > > > Hi Ricardo, > but its not the same as before, look at my attachment in bug > #16466, do > you see something else then me? > > > it's not bug #16466 for sure :P > i don't really remember how it was before, and i'm not too fond of > having gold and silver apps with the white too, but it serves it's > function fine... > you'd better talk to alex on that to be sure what's the objective. sorry, it was #16442

Feb. 15, 2009

Re: AppDB new design: Top 10s still look ugly

by André Hentschel

Ricardo Filipe schrieb: > hi andré, > alex didn't apply your patch. he just fixed the .css to give it the > same style as it had before. > > 2009/2/15 André Hentschel <nerv(a)dawncrow.de <mailto:nerv(a)dawncrow.de>> > > Hello, > Bug #16466 is declared as fixed. but it isnt. my patch should do > something else. > I wanted let each top 10 in its own color(platin, gold or bronce) and > not to have the platin-look for all. > anything went wrong while using my patch. maybe the other patch > went in, > too? > It should be this style: http://www.funplugged.bplaced.net/appdb/ > > > Hi Ricardo, but its not the same as before, look at my attachment in bug #16466, do you see something else then me?

Feb. 15, 2009

Re: [patch but not quite ready] NamedPipes messagemode

by Luke Kenneth Casson Leighton

On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton <luke.leighton(a)googlemail.com> wrote: > http://bugs.winehq.org/show_bug.cgi?id=17195 > > with only one significant bug - some memory corruption - the semantics > are now correct in the namedpipe messagemode patch. found it. as suspected, utilising the same critical section fd_cache_section as in ntdll/file/server.c this issue went away. it wasn't memory corruption at all, it was the use of the wineserver socket to send filedescriptors using ioctls: server_get_named_pipe_fd() was picking up a filedescriptor that was intended for server_get_unix_fd() and vice-versa. so - fixed! working! ... sort-of :) the one remaining "fly in the ointment", which i'm going to ignore, is demonstrated by threadread and threadwrite tests: running unix out of socketpair file handles. 20 writes by 5 threads are queued up by e.g. threadwrite, resulting in a whopping two _hundred_ filedescriptors being handed out. reading this: http://msdn.microsoft.com/en-us/library/aa365150.aspx describes how use of a NamedPipe should block on write: "The write operation will block until the data is read from the pipe so that the additional buffer quota can be released. Therefore, if your specified buffer size is too small, the system will grow the buffer as needed, but the downside is that the operation will block. If the operation is overlapped, a system thread is blocked; otherwise, the application thread is blocked." ignoring the bollocks about "buffer sizes", and "buffer quotas", which give an indication of how microsoft internally implements NamedPipes, it's clear then that blocking the application is perfectly acceptable. exactly how this is to be achieved is yet to be determined, but as i keep mentioning, it's highly likely that a per-file-handle mutex is required. quick tests: 1) test1, shortread, send2recv2: pass. 2) reducing BUF_SIZE in the tests code to 128 works, threadread and threadwrite: success 3) removing the interim use of ncacn_ip_tcp in SVCCTL and returning to ncacn_np: success. 4) going back to running a simple python2.7.exe "multiprocessing" tests, which use message-mode named pipes, the whole damn _point_ of this exercise: success 5) running MSYS: fail. bugger. a veery cursory look at the output, it looks like it's a non-message-mode pipe. arg. no surprise there, then. *sigh*. will let you know how i get on. l.

Feb. 15, 2009

Re: [patch but not quite ready] NamedPipes messagemode

by Luke Kenneth Casson Leighton

On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton <luke.leighton(a)googlemail.com> wrote: > http://bugs.winehq.org/show_bug.cgi?id=17195 > > with only one significant bug - some memory corruption - the semantics > are now correct in the namedpipe messagemode patch. found it. as suspected, utilising the same critical section fd_cache_section as in ntdll/file/server.c this issue went away. it wasn't memory corruption at all, it was the use of the wineserver socket to send filedescriptors using ioctls: server_get_named_pipe_fd() was picking up a filedescriptor that was intended for server_get_unix_fd() and vice-versa. so - fixed! done! working! ... sort-of :) the one remaining "fly in the ointment", which i'm going to ignore, is demonstrated by threadread and threadwrite tests: running unix out of socketpair file handles. 20 writes by 5 threads are queued up by e.g. threadwrite, resulting in a whopping two _hundred_ filedescriptors being handed out. reading this: http://msdn.microsoft.com/en-us/library/aa365150.aspx describes how use of a NamedPipe should block on write: "The write operation will block until the data is read from the pipe so that the additional buffer quota can be released. Therefore, if your specified buffer size is too small, the system will grow the buffer as needed, but the downside is that the operation will block. If the operation is overlapped, a system thread is blocked; otherwise, the application thread is blocked." ignoring the bollocks about "buffer sizes", and "buffer quotas", which give an indication of how microsoft internally implements NamedPipes, it's clear then that blocking the application is perfectly acceptable. exactly how this is to be achieved is yet to be determined, but as i keep mentioning, it's highly likely that a per-file-handle mutex is required. quick tests: 1) test1, shortread, send2recv2: pass. 2) reducing BUF_SIZE in the tests code to 128 works, threadread and threadwrite: success 3) removing the interim use of ncacn_ip_tcp in SVCCTL and returning to ncacn_np: success. 4) going back to running a simple python2.7.exe "multiprocessing" tests, which use message-mode named pipes, the whole damn _point_ of this exercise: success 5) running MSYS: fail. bugger. a veery cursory look at the output, it looks like it's a non-message-mode pipe. arg. no surprise there, then. *sigh*. will let you know how i get on. l.

Feb. 15, 2009

Re: AppDB new design: Top 10s still look ugly

by Ricardo Filipe

hi andré, alex didn't apply your patch. he just fixed the .css to give it the same style as it had before. 2009/2/15 André Hentschel <nerv(a)dawncrow.de> > Hello, > Bug #16466 is declared as fixed. but it isnt. my patch should do > something else. > I wanted let each top 10 in its own color(platin, gold or bronce) and > not to have the platin-look for all. > anything went wrong while using my patch. maybe the other patch went in, > too? > It should be this style: http://www.funplugged.bplaced.net/appdb/ > > >

Feb. 15, 2009

AppDB new design: Top 10s still look ugly

by André Hentschel

Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/

Feb. 15, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

Detlef, On Sun, Feb 15, 2009 at 12:50 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > Just use this infos: > hdll = LoadLibraryA("libwine.dll"); > wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); > wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); > wine_dlclose = GetProcAdress(hdll, "wine_dlclose"); The LoadLibraryA call does not work for me. Tried with many names (wine,libwine, etc) and wine is according to strace always trying to open /usr/lib/wine/{lib}libwine.dll.so which is not obviously present. M.

Feb. 15, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Detlef Riekenberg

On So, 2009-02-15 at 01:02 +0100, Martin Hinner wrote: > > - It's already present in Wine: > > libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym > > please read: libs/wine/loader.c > > I saw it, but I don't understand how is it exported to the "Win32 > world", i.e. how do I import these using GetProcAddress() Win32 API ? As I already mentioned: > > libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym Just use this infos: hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose"); Keep attention on the calling convention. > find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not > reveal anything except winegate.dll :-). A "*.spec" is used as input for winebuild to build a "*.def". Keep it as simple as possible and use only grep: "grep -r dlopen <wine-source>/libs/" You find the exported functions in "libs/wine/wine.def" -- By by ... Detlef

Feb. 15, 2009

Re: Updated cebit presentation. Looking for ideas...

by Ricardo Filipe

> > > > A before/after of Safari with corefonts might also be good, to show an > > example of what winetricks can fix. > > Heh. Safari without corefonts hangs. Hard to capture that in a screenshot > :-) > > > you can do that with steam :P

Feb. 15, 2009

Re: mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called

by Alistair Leslie-Hughes

Ignore this, the subject is wrong. "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:4997DB01.1000602(a)hotmail.com... > Hi, > > Changelog: > mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called. > > Best Regards > Alistair Leslie-Hughes > > > > -------------------------------------------------------------------------------- > From 14267df8f532c7acc7cc184c3c1e020639ca8702 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Fri, 6 Feb 2009 20:03:47 +1100 > Subject: [PATCH] Corrected tests > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/urlmon/tests/url.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/urlmon/tests/url.c b/dlls/urlmon/tests/url.c > index c062cf8..e5895c4 100644 > --- a/dlls/urlmon/tests/url.c > +++ b/dlls/urlmon/tests/url.c > @@ -313,7 +313,7 @@ static DWORD WINAPI thread_proc(PVOID arg) > CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); > CHECK_CALLED(CreateInstance); > CHECK_CALLED(PutProperty_MIMETYPEPROP); > - CLEAR_CALLED(PutProperty_CLASSIDPROP); > + CHECK_CALLED(PutProperty_CLASSIDPROP); > CHECK_CALLED(Load); > CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); > CHECK_CALLED(OnObjectAvailable); > @@ -612,7 +612,7 @@ static HRESULT WINAPI Protocol_Start(IInternetProtocol > *iface, LPCWSTR szUrl, > CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); > CHECK_CALLED(CreateInstance); > CHECK_CALLED(PutProperty_MIMETYPEPROP); > - CLEAR_CALLED(PutProperty_CLASSIDPROP); > + CHECK_CALLED(PutProperty_CLASSIDPROP); > CHECK_CALLED(Load); > CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); > CHECK_CALLED(OnObjectAvailable); > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

Feb. 15, 2009