wine-devel December 2010

wine-devel@winehq.org

83 participants
219 discussions

Full path to wine executable in generated .desktop files
by Ilya Basin 18 Dec '10

18 Dec '10

When you install a program, some desktop files are put here: ~/.local/share/applications/wine/ ~/Desktop/ [Desktop Entry] Name=Microsoft Office Access 2003 Exec=env WINEPREFIX="/home/leniviy/.wine" wine ... I have 2 wine instances: official in /usr and patched in /opt/wine-csshack . Because of that I would like to have "/opt/wine-csshack/bin/wine", not just "wine" in the generated .desktop files. What can go wrong if we do so?

1 0

Removal of dcom98 from winetricks?
by Scott Ritchie 18 Dec '10

18 Dec '10

I remember discussing this at wineconf as something we should do, but it seems there's at least one situation I've found where it still helps: http://bugs.winehq.org/show_bug.cgi?id=8780 Is it possible this is a hidden issue bleeding into other apps as well? Thanks, Scott Ritchie

1 0

socks & wine, patching wininet to use winsock
by Gabriele Greco 18 Dec '10

18 Dec '10

I'm trying to make programs that need a socks proxy to work on wine. They work with freecaps or similar winsock patches as long as they don't use wininet or other indirect winsocks APIs to make their stuff, if they use wininet those patches could not work since wininet bypasses winsocks and use linux sockets directly. In the head of the wininet.dll sources there is this comment: /* FIXME!!!!!! * This should use winsock - To use winsock the functions will have to change a bit * as they are designed for unix sockets. * SSL stuff should use crypt32.dll */ I tried to change netconnection.c to use winsock functions WSAConnect, WSASend & WSARecv since WS_send, WS_recv and WS_connect are not exposed by ws2_32 instead of direct linux socket functions (connect/send/recv), but I had no way to check the problems with unix sockets vs inet sockets cause the library crashes wine before hitting anything related with my CODE patches. It crashes simply because I've added in Makefile.in ws2_32 module IMPORTS, doing so what I've observed is that standard linux sockets calls are "wrapped" and points now to NULL (because ws2_32 is not loaded?). In this specific case "getaddrinfo" is NULL and HTTP_ResolveName crashes when calling it. Anyone can suggest me the correct approach to implement this? I have to load manually ws2_32 in the wininet initialization? -- Bye, Gabry

2 1

Re: widl: Added support for registering alternative progids.
by Huw Davies 17 Dec '10

17 Dec '10

On Fri, Dec 17, 2010 at 04:14:24PM +0100, Jacek Caban wrote: > diff --git a/tools/widl/parser.y b/tools/widl/parser.y > index c924a66..28cb1da 100644 > --- a/tools/widl/parser.y > +++ b/tools/widl/parser.y > @@ -190,7 +190,7 @@ static statement_list_t *append_statement(statement_list_t *list, statement_t *s > -%token tAGGREGATABLE tALLOCATE tANNOTATION tAPPOBJECT tASYNC tASYNCUUID > +%token tAGGREGATABLE tALLOCATE tANNOTATION tAPPOBJECT tASYNC tASYNCUUID tALTPROGID Hi Jacek, This breaks alphabetical order in this line. Cheers, Huw.

1 0

Re: [PATCH 5/7] mshtml: Added IHTMLScriptElement::get_scr implementation.
by Marvin 17 Dec '10

17 Dec '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=7657 Your paranoid android. === W7PRO (32 bit dom) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: [PATCH 1/5] server: Handle more inotify mask values
by Alexandre Julliard 16 Dec '10

16 Dec '10

Piotr Caban <piotr(a)codeweavers.com> writes: > -static int inode_check_dir( struct inode *parent, const char *name ) > -{ > - char *path; > - unsigned int filter; > - struct inode *inode; > - struct stat st; > - int wd = -1, r = -1; > - > - path = inode_get_path( parent, strlen(name) ); > - if (!path) > - return r; > - > - strcat( path, name ); > - > - r = stat( path, &st ); > - if (r < 0) goto end; > - > - if (!S_ISDIR(st.st_mode)) > - { > - r = 0; > - goto end; > - } > - > - r = 1; > - > - filter = filter_from_inode( parent, 1 ); > - if (!filter) > - goto end; > - > - inode = inode_add( parent, st.st_dev, st.st_ino, name ); > - if (!inode || inode->wd != -1) > - goto end; > - > - wd = inotify_add_dir( path, filter ); > - if (wd != -1) > - inode_set_wd( inode, wd ); > - else > - free_inode( inode ); > - > -end: > - free( path ); > - return r; > -} You can't remove all this, you still need to add a watch for newly created directories. -- Alexandre Julliard julliard(a)winehq.org

1 0

Testbot: User not logged in Problem with WVISTAADM
by André Hentschel 15 Dec '10

15 Dec '10

Hi Greg, there is a noisy problem with the WVISTAADM, which causes much tests to be shown as "Failed" in the patchtracker. should we blacklist the Message returned by WVISTAADM or can you fix the underlying problem? -- Best Regards, André Hentschel

3 4

Thread-safety in winmm?
by Joerg-Cyril.Hoehle＠t-systems.com 15 Dec '10

15 Dec '10

Hi, I'm thankful for any kind of information regarding thread-safety and re-entrancy involving WINMM. I found little on the net. Basically, I'm wondering what kind of guarantees must code in winmm (which includes the MCI) provide w.r.t. multiple application threads using the winmm API. Use cases for the MCI: A) Thread 1: MCI_PLAY, thread 2: MCI_STOP B) Thread 1: MCI_PLAY, 2: MCI_PAUSE, 3: MCI_STOP C) Thread 1: MCI_PLAY, 2: MCI_STOP, 3: WINMM shutdown via ^C D) Any 2 MCI commands from 2 threads, excl. MCI_CLOSE E) Including MCI_CLOSE For instance, the following construct that is used in some Wine MCI drivers is not fully thread safe: WINE_MCI* wmw = (WINE_MCI*)mciGetDriverData(wDevID); /* oops */ if (wmw) { /* oops */ EnterCriticalSection(wmw->cs); The thread may be preempted at oops time, another one may close the device meanwhile; crash follows. Note that the MCI is easier to deal with than the rest of WINMM, because it has no CALLBACK_FUNCTION. Function callbacks create an additional burden via re-entrant code. Often enough, they are invoked within a critical section (e.g. lookup xyzNotifiyClient() in wine*.drv/). However, a CS is not a MUTEX, and callback code will happily enter any critical section already hold within the same thread! One could say that critical sections give a wrong feeling of security. Presumably CS are used over mutexes all over the place because a) they are said to be more efficient b) using mutexes to protect against re-entrant code is no solution either, as dead-locks would occur. The above example shows that it would be tough to make a driver thread-safe without the help of the central WINMM component. So I'm left wondering what are adequate levels of protection that I should design into code while I'm rewriting some of the MCI. - Should I care about robustness against driver shutdown as a consequence of ^C? (a particular case of close while playing) - One may argue that re-entrancy is not an issue for WINMM. Bug #3930, comment #37 explains that function callbacks should be invoked from another thread... - What is the worst that I should expect? (We already know that apps call winmm functions from within callbacks even though MSDN says it may deadlock...) - What should WINMM guarantee? - Will DRV_CLOSE ever be called once only? - Should a closing driver kill player threads or patiently wait? I've been thinking about supporting a graduated scenario similar to: E: robustness against any sequence of commands from a single thread; Bug #22978 shows mciseq does not satisfy that condition. D: asynchronous player + thread-safe stop/reset command; C: ... A: fully thread- and re-entrancy-safe One thing I've learned already is that innocent looking code such as PostThreadMessage() may cause the currently running thread to be preempted, even though it did not yet set all state variables correctly. E.g., the app may process a notification earlier that you'd believe it does! Thanks for any pointers, Jörg Höhle

1 0

Re: ntdll: use off_t instead of long
by Alexandre Julliard 15 Dec '10

15 Dec '10

André Hentschel <nerv(a)dawncrow.de> writes: > This is more correct and prevents a crash on sparc (at least what > Austin and me acutally reached) It's not more correct, it's just moving the problem around... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] cmd: Add CHOICE builtin with DOS6 to XP commandline parameter
by Alexandre Julliard 15 Dec '10

15 Dec '10

Detlef Riekenberg <wine.dev(a)web.de> writes: > + while (!errorlevel) { > + count = 0; > + while (!count){ > + /* FIXME: Add support for option /T */ > + WCMD_ReadFile(GetStdHandle(STD_INPUT_HANDLE), answer, 1, &count, NULL); > + if (!count) { > + WINE_TRACE("no more data from stdin\n"); > + if (have_console) > + SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), oldmode); > + > + HeapFree(GetProcessHeap(), 0, my_command); > + return; > + } > + } > + if (!opt_s) > + answer[0] = toupperW(answer[0]); > + > + ptr = strchrW(opt_c, answer[0]); > + if (ptr) { > + WCMD_output_asis(answer); > + WCMD_output(newline); > + if (have_console) > + SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), oldmode); > + > + errorlevel = (ptr - opt_c) + 1; > + WINE_TRACE("answer: %d\n", errorlevel); > + HeapFree(GetProcessHeap(), 0, my_command); > + return; > + } > + else > + { > + /* key not allowed: play a bell */ > + WINE_TRACE("key not allowed: %s\n", wine_dbgstr_w(answer)); > + WCMD_output_asis(bellW); > + } > + } > + /* This location is never reached */ It doesn't make sense to have a loop condition that never happens. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
22
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2010