wine-devel September 2008

wine-devel@winehq.org

116 participants
274 discussions

Debugging applications running on wine
by Kevin K 09 Sep '08

09 Sep '08

Is winedbg the only method of debugging applications being developed for Windows on Wine? For instance, assume a program developed with Visual Studio in C or C++, and I needed to debug it on Linux? Thanks, Kevin

1 0

Re: Patchwatcher security improvements
by Ambroz Bizjak 09 Sep '08

09 Sep '08

> Also, it's possible some of your changes won't be needed > after the refactoring... I plan to run wine-slave as a different > user anyway... That doesn't solve much; although in may look clean, it is not secure. The user should have a limited amount of resources to work with. Your way, for example, it can write the whole master Wine tree. With my patches, the master tree is read-only for the user, and it only has its own copy to work with which is never used again. I plan to further improve things. In particular, killing stall processes is not implemented securely now. As I have already mentioned, additional access control is needed to produce a fully solid system. For example, disk access should be limited (think about world-writable folders and stuff like ~/.bashrc), and memory usage should be limited as well (could patchwatcher get killed when the patch starts consuming memory?). Considering the refactoring, I see you are just some moving stuff into its own file; I can easily adjust my code.

1 0

re: Patchwatcher security improvements
by Ambroz Bizjak 08 Sep '08

08 Sep '08

> Interesting. One of my goals is to support Solaris and BSD; > have you tried your stuff there? Not yet, but that stuff is pretty generic, so it shouldn't be hard to get it to work. > I'm surprised you had to give up on the chroot... > I was planning on trying to run just wine-slave.sh in > a chroot jail, since it's the only part that would > actually try to run any part of the wine build system. Creating the chroot itself is really hard and has to be done for each platform separately. The basic system and also all development tools and Wine dependencies have to be copied properly. And there are the tests with their own bunch of requirements. In the end you would end up with a chroot that is not much different from the base system itself. And it doesn't really bring many security benefits. Many potentially insecure interfaces have to be exposed anyway (/proc, X server with OpenGL, sound hardware). If a clean and dedicated system is used and permissions are properly configured, running stuff on the base system shouldn't really be a problem. Furthermore, using some advanced access control system (like SELinux) would probably be easier to configure and more efficient.

1 0

re: [1/5] secur32: Require gnutls for schannel
by Dan Kegel 08 Sep '08

08 Sep '08

> If its easier with gnutls, please use it. +1 I also agree that nss is likely to replace openssl as the toolkit of choice. But if depending on gnutls is the easiest path to a working schannel, that's the right thing to do. We can always change later if a compelling reason arises. - Dan

1 0

Re: user32.dll: Add stub for LockWorkStation
by Rob Shearman 08 Sep '08

08 Sep '08

2008/9/8 Paul Chitescu <paulc(a)voip.null.ro>: > /*********************************************************************** >+ * LockWorkStation (USER32.@) >+ */ >+BOOL WINAPI LockWorkStation() This is the right place to put it be the above should be "LockWorkStation(void)" not "LockWorkStation()". -- Rob Shearman

1 0

Re: wininet: InternetQueryOption return size when buffer too small
by James Hawkins 08 Sep '08

08 Sep '08

On Mon, Sep 8, 2008 at 5:01 PM, Rotem Zach <rotemz(a)gmail.com> wrote: > > + > + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_SERVER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Got wrong length %d instead of %d\n",sizeof(ULONG)); > + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_SERVER Wrong Error %d Expecting %d\n"); > + > + internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Got wrong length %d instead of %d\n",sizeof(ULONG)); > + internetQWCheckErr(ERROR_INSUFFICIENT_BUFFER,(WCHAR*)"Open: INTERNET_OPTION_MAX_CONNS_PER_1_0_SERVER Wrong Error %d Expecting %d\n"); > + All of these lines are way too long. Please stick close to an 80-col line limit. -- James Hawkins

1 0

winhttp test failures
by James Hawkins 08 Sep '08

08 Sep '08

Hi Hans, Tests you added to the file dlls/winhttp/tests/notification.c are causing several test failures across all platforms. Can you please have a look at this? Thanks, James Hawkins

1 0

Re: [1/5] secur32: Require gnutls for schannel
by Marcus Meissner 08 Sep '08

08 Sep '08

On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote: > > From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001 > From: Henri Verbeet <hverbeet(a)gmail.com> > Date: Mon, 8 Sep 2008 22:39:11 +0200 > Subject: secur32: Require gnutls for schannel > +AC_ARG_WITH(gnutls, AS_HELP_STRING([--without-gnutls],[do not use GnuTLS (schannel support)])) Hmm, I really do not think gnutls will have a long feature, NSS seems to be the future choice of crypto frameworks :/ Ciao, Marcus

3 4

Re: wined3d: Add support for updating part of a compressed surface.
by Henri Verbeet 08 Sep '08

08 Sep '08

2008/9/5 Christof Sigel <christof.sigel(a)intenode.on.net>: > + /* since DXT compressed formats are specified in 4x4 pixel blocks devide pitch by 4 */ > + int srcPitch=srcLockedRect.Pitch>>2; > + int destPitch=destLockedRect.Pitch>>2; That will break with DXT1 surfaces. All the DXT formats are specified in 4x4 blocks, but for DXT1 a 4x4 block is 8 bytes, while for the other DXT formats a block is 16 bytes. This also has implications for how you should handle copying row by row, since each row is 4 pixels high. Strictly speaking you should also verify that the pitch exactly corresponds to the surface width before using the "single memcpy" path, since theory the surface layout in memory could look like this: |<----width--->| |<-----------pitch------------>| xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |--------------|xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | surface |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxx |--------------|xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx In other words, for a DXT1 surface with height h, width w and pitch p, you should copy h/4 rows of w*2 bytes, where each row starts at pBits+p*row. For DXT2/3/4/5 you'd copy w*4 bytes for each row. A test for this code would be appreciated.

2 2

Peb->BeingDebugged and a debugger messing up
by Markus Hitter 08 Sep '08

08 Sep '08

Hello all, after wrestling severals days with Wine's debugging capabilities I think I need some advice. First, regardless wether my app (Catia) is launched with wine or winedbg, Peb->BeingDebugged is always False. To the best of my efforts I can't find the code snippet which sets this variable or does some sort of probing for the correct value. Oddly enough, the app breaks into the debugger after creation of a new process, anyways. As the app uses a launcher, I have the chance to set BeingDebugged explicitely to True. Some time later, after the app created a few threads, it's back to False. Are there applications out there setting this flag to what they think is best? Any other possible reasons for going BeingDebugged back to False while running in winedbg? None of the functions Wine provides and handles this variable appears to be called by the application. Third thing is, Wine's attempt to auto-launch the debugger messes up. Not only if BeingDebugged is reported wrongly, it obviously runs in conflicts if launched due to a exception stack overflow. Is it really wise to launch it by triggering an interrupt in DbgBreakPoint()? Short of better suggestions, I'd try to make debugger launching independent from Peb->BeingDebugged (server/kernel should know better), try to get rid of the interrupt in DbgBreakPoint() and/or make debugger autolaunching optional (at compile time). What do you think? Thanks, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
28
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 September 2008