wine-devel

wine-devel@winehq.org

84463 discussions

Re: Interesting Magic # exception understood by the MS debugger...
by Alexandre Julliard 03 Apr '01

03 Apr '01

"James Hatheway" <james(a)macadamian.com> writes: > For now, I put the little hack I attached to this mail in my tree to > save my sanity. My question to the list is, (A) is there a way to name > threads in Linux/Unix (I don't think so, but of course I could be wrong) No, and we don't need that. > and (B) should we support MS's hack somehow in the official tree? Yes, in the Wine debugger, which should store the name and simply continue execution, just like the MSVC debugger does. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells 03 Apr '01

03 Apr '01

Okay, I've thought about how to make the wine kernel module easier to use for Wine, and I've started adding another API to it - one that interprets Wine server messages. When I designed the module initially, I decided to make it possible to add as many API's as I liked, so in theory it's not too difficult. I'm currently performing a major rearrangement of the files that comprise the module: * Splitting the current win32 API bits out of the same files that contain the actual object class implementations. * Putting the core and the API's in separate subdirectories. * Abstracting name support, so that the internal API takes an "object name" which the user API is responsible for extracting from userspace and converting from WCS/MBS as necessary. * Fixing introduced bugs. This does not mean that I'm getting rid of the Win32 API I've already got! It will just be optional. Calling the new API will be by means of either: union generic_request msg; syscall(__NR_win32,WINESERVER_WINE_SERVER_MESSAGE,&msg); Or: union generic_request msg; int fd = open("/proc/wineserver"); struct WineserverIoctl wioc = { WINESERVER_WINE_SERVER_MESSAGE, &msg }; ioctl(fd,WINESERVER_IOCTL,&wioc); David

1 0

Interesting Magic # exception understood by the MS debugger...
by James Hatheway 02 Apr '01

02 Apr '01

Hi guys, I encountered something interesting while debugging a newer build of my application. I noticed that all of a sudden I was receiving approximately 10 new exceptions in the debugger on startup that I wasn't receiving before. After digging a little, I found out that the app coders were making use of a 'hidden' feature of MS VC that allowed you to name your threads (thus allowing for easier debugging). To do this, you call RaiseException with the code of 0x406D1388. (Search on deja.com or google.com for "0x406D1388" for details.) The windows debugger seems to be on the lookout for this code. Of course, what it does in wine is just breaking into the debugger many times and getting on my nerves. :-) For now, I put the little hack I attached to this mail in my tree to save my sanity. My question to the list is, (A) is there a way to name threads in Linux/Unix (I don't think so, but of course I could be wrong) and (B) should we support MS's hack somehow in the official tree? -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

1 0

Re: RegSetValueEx problem?
by davep 02 Apr '01

02 Apr '01

On Sun, 01 Apr 2001, you wrote: > At 01:59 PM 31/03/2001 +0100, you wrote: > > <snip> > >Compiling and running Winemine under Windows 95 this problem doesn't occur. > >Win95 truncates the value at the first null. > > Under NT4 SP6, if I write (for example) '47' + 0 + 13 bytes of garbage, I get > exactly that when querying with the same buffer length (16). > If I use a longer buffer, one binary 0 is appended. > If I use a shorter buffer, nothing is copied and the function does not succeed > (ERROR_MORE_DATA). > > Of course under Regedit the garbage is not displayed; regedit displays only '47' > in this case. Ah, I didn't know Regedit was not giving the true value. That complicates matters even more. It seems I'll have to do some experiments. -- Dave Pickles

1 0

Re: event flags using pipes
by Alexandre Julliard 01 Apr '01

01 Apr '01

Mike McCormack <mike_mccormack(a)looksmart.com.au> writes: > Why? By changing the client side implementation of SetEvent and > ResetEvent the use file descriptors and implementing a client side > unix fd/handle cache, it should be possible to eliminate server calls > for these operations and improve the performance of wineserver. I don't see how you can get the right semantics this way, but maybe I missed something. How will you be able to wake a single thread for auto-reset events, but all of them for manual events? How are you going to implement PulseEvent? How can you do WaitForMultipleObjects for an auto-reset event without a race? -- Alexandre Julliard julliard(a)winehq.com

1 0

event flags using pipes
by Mike McCormack 01 Apr '01

01 Apr '01

Hi, i've written an implementation of windows event flags using pipes. (The modifications are confined to server/event.c for the moment.) Why? By changing the client side implementation of SetEvent and ResetEvent the use file descriptors and implementing a client side unix fd/handle cache, it should be possible to eliminate server calls for these operations and improve the performance of wineserver. Anyway, any comments are welcome. Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

RegSetValueEx problem?
by davep 31 Mar '01

31 Mar '01

I've been trying to track down why WineMine does not save my best scores ;-( On exit, WineMine saves the current user settings to the registry with code like this: char data[16]; wsprintf( data, "%d", p_board->pos.x ); RegSetValueEx( hkey, "Xpos", 0, REG_SZ, (LPBYTE) data, sizeof( data )); The problem here is that the 'count' parameter passed to RegSetValueEx is not the string length but the size of the entire buffer. Wine dutifully writes into the registry the entire buffer including the trailing garbage, and also adds a null to the end if there isn't one there. When WineMine tries to read the value back it is now 17 characters long and too big to fit in the 16-byte buffer. Compiling and running Winemine under Windows 95 this problem doesn't occur. Win95 truncates the value at the first null. So RegSetValueEx needs fixing. However there are already comments in there about the differences between 95 and NT in the handling of REG_SZ values, and I don't have an NT system to carry out checks. Can someone with experience propose a solution? -- Dave Pickles

1 0

Sendmessage fix..
by crazney 31 Mar '01

31 Mar '01

Hey, im writing cause i presently use Andreas Mohr's sendmessage fix (titled TEB fix, because it stop the TEB errors).. basically, what the patch does, is clean up after a killed SendMessage if it didnt clean itsself up.. (well something like that, iirc).. anyway, i run the LHL howto page, and this patch is very useful to running Half-Life and several other games/programs.. so itd be nice to have it in CVS.. which it isnt presently.. when Andreas Mohr first wrote the patch, he told me that alexandre denied it, and neither him, ove or myself can work out why.. so yer, i'd just like to know a) why was it refused.. and b) can you put it in now, or write something which does just this now.. thanks in advance ps, can you please email me about this, because im not subscribed to this list. cheers David -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Hammerton aka crazney Victoria, Australia http://crazney.net/ HOWTO maintainer and Linux Half-Life http://lhl.linuxgames.com/ email: http://crazney.net/contact.html -> Note: this email address expires after one week.

1 0

Re: [PATCH] HOOK_CallHook
by David Elliott 30 Mar '01

30 Mar '01

Francois Jacques wrote: > Group, This patch comes from investigation of a bug that was observed in > RedHat 7.0 and not observed in RedHat 6.1. After a debugging session that > involved Stephane and I, we found out that it was a compiler issue (which > I feared from the start, but wasn't considering it seriously... > arghhh). The RedHat 6.1 installation has gcc version 2.91.66 and the > RedHat 7.0 installation has gcc version 2.96-20000731 (RedHat Linux 7.0) > with latest updates from RedHat. What's happening : 1) HOOK_CallHook is > being called (notice wParam and lParam arguments)2) Local variables > wParamOrig and lParamOrig are set to wParam and lParam values3) Mapping > function is called (MapFunc) with the *addresses* of wParam and lParam so > those get changed before we call the hook4) After MapFunc is called, > wParamOrig and lParamOrig values also changed to the new values of wParam > and lParam (!) Explanation : Down to the assembly level code, the compiler > doesn't create wParamOrig and lParamOrig on the stack. Instead, it > directly use wParam and lParam. Fix : add volatile to wParamOrig and > lParamOrig to prevent optimizations on those variables (aka. force their > presence on the stack) This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. -Dave

6 9

Re: [PATCH] HOOK_CallHook
by François Jacques 30 Mar '01

30 Mar '01

>OK, I must have misunderstood you then. Sorry ... It's ok :) >I've managed to reduce the problem to a simple testcase, which is >appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... > >Culprit *appears* to be the global common subexpression elimination, >although this is not quite definite. I haven't tracked the problem >down yet. Are you thinking of doing more investigation on that? >However, when switching off GCSE (-fno-gcse), correct code is produced. >I'm not sure I'd like to do a complete Wine build without GCSE though; >this might significantly reduce code quality ... Oh the runtime behavior should not change that much but it's still non-negligeable. I like the "disable-gcse-if-you-probe-that-gcc-version" approach. >I'll write a configure check to switch off gcse, using the testcase >below. We should probably contact RedHat (I think Jacub Jelinek >handles 2.96 bugs ...) to confirm that GCSE is really at fault. If you want to post it with the test program, go ahead :) I never posted to gcc bug list so I'm not sure how much attention would be given to the bug. I think the mailing list should be cc'ed on the postings so everybody can follow up how it turns out. Ciao! Francois

1 0

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