Re: Threading experts?
[EMAIL PROTECTED] wrote: I had to use with-nptl to build winex pn Mandrake 9.1, the binarys did't work without that option. This wasn't necessarry on wine, but winex won't run without it. WineX is a different in this regard. We don't differentiate between NPTL and LinuxThreads - and the option is --enable-pthreads and not --with-nptl. Dmitry wrote: I may be wrong, but according to the information posted to one of our support forums, support for NPTL was backported from 2.5 kernels by RedHat, and nobody else has support for NPTL in 2.4 kernel series. You are correct from my understanding. Wine does a binary patch for errno stuff which is supposedly sufficient to not require using pthreads until NPTL comes into the fold. So, you shouldn't compile --with-nptl on Mandrake. Ciao, Peter **
Re: Debuging Wine
As pointed out by Lionel this is a list for wine development; not WineX devel or support. I suggest followups to [EMAIL PROTECTED] and remove wine-devel. Jarmo wrote: Hi, I am trackin a weard bug and I would need a help a little. I am trying to run Orbiter in winex. Orbiter runs without problems in windows. It seems that Orbiter.exe is using a call that does not exist in wine. How can I find out the name of that call ? access to call 0x406cd420 Main_Direct3DDevice_SetTexture works fine just before this call. Code causing the crash: 0x004513c0 movl%eax,0x4c(%esp) 0x004513c4 call*0x84(%eax)this will lead 0xdead001e A quick grep of the code turns up: 0xdead001E, /* ComputeSphereVisibility */ This would be your missing function. I suggest you start by trying a stub implementation - and post that to winex-devel under the X11 license for inclusion into CVS. Relocation entries: 0x406cd010 is address of Main_Direct3DDevice_DrawIndexedPrimitiveVB 0x406cd3a0 is address of Main_Direct3DDevice_GetTexture 0x406f0910 (DDRAW.DLL): 406cd2f0 406ccae0 406ccc70 406cce60 0x406f0920 (DDRAW.DLL): 406cd010 *! dead001e !* 406cd3a0 406cd420 0x406f0930 (DDRAW.DLL): 406cd530406cd5f0 406cd700 406cd760 Relocation entries: 0003d91c R_386_32 Main_Direct3DDevice_DrawPrimitiveVB 0003d920 R_386_32 Main_Direct3DDevice_DrawIndexedPrimitiveVB 0003d924 ? ? ? ? 0003d928 R_386_32 Main_Direct3DDevice_GetTexture 0003d92c R_386_32 Main_Direct3DDevice_SetTexture Regards, Jarmo -- Peter Hunnisett TransGaming Technologies Bus: 416.979.9900 x327 Fax: 416.978.6052 [EMAIL PROTECTED] http://www.transgaming.com *Let the games begin*
suspended threads acquiring synchronization objects
Howdy, we've discovered that windows seems to not allow suspended threads to acquire synchronization objects, which make really really good sense, while wine does. I've attached a simple test case, the code for the test case and a ReWind licensed patch for the problem. Would people have a look at the patch and let me know if it's the best way to fix it, or if I've missed anything? Thanks, Peter [EMAIL PROTECTED]
Re: CVS Compile error.
Also worth a note that this would be WineX cvs not Wine cvs. Perhaps [EMAIL PROTECTED] would be a better location (and in fact you can check the archives I belive on this one). Ciao, Peter Vincent Béron wrote: Patrik Båt a écrit: Hello people out there! Im trying to compile the cvs source of WINE and gets error: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fno-keep-static-consts -D__int8=char -D__int16=short -D__int32=int -D__int64=long long -fPIC -D__WINE__ -fshort-wchar -D_REENTRANT -I/usr/X11R6/include -o dpnet_main.o dpnet_main.c cc1: Invalid option `-fshort-wchar' make[2]: *** [dpnet_main.o] Error 1 make[2]: Leaving directory `/root/winecvs/wine/dlls/dpnet' make[1]: *** [dpnet/libdpnet.so] Error 2 make[1]: Leaving directory `/root/winecvs/wine/dlls' make: *** [dlls] Error 2 Is it anyone ho have a clue? I updated the CVS source today, 2003-02-05 (-MM-DD). ./configure dosen't complaine... My system is: Linux 2.4.20, Debian 3.0 unstable. Seeing that there are 15 packages returned for a search for gcc in unstable, could you tell us which version of gcc you use? It seems your gcc doesn't like -fshort-wchar. I'm not sure since when it is in gcc, or how ./configure reacts if it's absent. Vincent
Re: Wine kernel acceleration module?
Tom Wickline wrote: Gavriel State wrote: Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) May I ask for a list of Apps ? Well the paper that we posted with the donation announcement (http://www.transgaming.com/papers/shmserver.html) provides a certain list. We were of course concerned with games that we knew had this problem (American McGee's Alice and Quake3). As for a complete list I don't think that we have one but it has been tried, without any observed issues, on several other games that reside in my blurry hazy memory. Guess that doesn't help much. The paper does also mention some of the toy applications in the program directory that were used. Perhaps people could post their success and failure stories? Ciao, Peter Tom Take care -Gav
Prototype implementation of a shared memory winserver
Hi, in the quest for speed parity in multimedia applications TransGaming has investigated a few options in dealing with the nasty overhead of the present wineserver implementation. I have just recently posted a prototype patch for a shared memory wineserver, to the ReWind project, (http://sourceforge.net/mailarchive/forum.php?thread_id=1413925forum_id=8836) which, in a small benchmarking suite, has shown some remarkable performance gains. The concept for the shm wineserver came about during discussions at the OLS in 2002 and remained a concept until a little while ago we had enough time to create a working prototype. TransGaming is donating this code to the ReWind project in the hopes that it will encourage other Wine developers to continue to share code under the more open BSD/X11 style license and to help overcome the remaining issues with this approach. Rather than make a really long technical email, we decided that a bit of a paper would be more appropriate (it also has links to the patches). The paper can be found at http://www.transgaming.com/papers/shmserver.html Regards, Peter Hunnisett [EMAIL PROTECTED]
Re: Windows LNK file format
On Wed, 27 Mar 2002 07:44:38 -0600, Aric Stewart said: I would say write a winelib app using the IShellLink and IPersistantFile interfaces. Basically do it the same way as you would under windows. However i seem to remember that you need to call COM functions differently for winelib apps than windows apps. Can someone else confirm that for me? -aric Shouldn't need to do anything particularly special. Just make sure you're using a resonable enough compiler and compile the Winelib application with the -DICOM_USE_COM_INTERFACE_ATTRIBUTE . Have a look at wine/include/wine/obj_base.h at the top comments for a little more information. Otherwise, yes, you will need to do things a little differently. Ciao, Peter Lonnie Cumberland wrote: Hello All, I am working with wine and want to develop a simple application that will read the Win85/98/2000 LNK files that are used to hold the application data for the desktop icons and url. does anyone have any information on these files, or has anyone done any work with some code to read/write these files? Cheers, Lonnie -- Lonnie Cumberland OutStep Technologies Incorporated EMAIL: [EMAIL PROTECTED] : [EMAIL PROTECTED] The Basis Express Virtual Office Data Backup and Recovery Services URL: http://www.basis-express.com The Virtual Office without boundaries!!!
Re: Fix spec definition for dplayx ordinal variable
On 21 Feb 2002 13:01:55 -0800, Alexandre Julliard said: Peter Hunnisett [EMAIL PROTECTED] writes: gdwDPlaySPRefCount is an exported ordinal variable might as well declare it as such. Note that this creates a copy of the variable, so you can no longer reference it from the C code. I'm not sure this is what you meant to do. Ooops. No. That's not what I had intended; they should be one and the same. I assume that I should be able to do a GetProcAddress on it then in order to be able to use the variable value internally? Or will that not work? -- Alexandre Julliard [EMAIL PROTECTED] Thanks, Peter
Re: C++ Winelib problems
On 22 Jan 2002 15:23:34 -0800, Alexandre Julliard said: Peter Hunnisett [EMAIL PROTECTED] writes: I've attached a patch which removes the recursive dep search from MODULE_DllProcessAttach and moves MODULE_DllProcessAttach from LoadLibraryExA into MODULE_LoadLibraryExA. Does this seem like a reasonable approach to take? Any problems with the patch? I think the current order is correct, and it needs to be done this way because of circular dependencies. The problem is that you need to delay calling constructors until the DLL entry point is called. This probably requires some compiler/linker magic. Ok. This is about the best voodo I can chant up at this point in time. I'm not terribly fond of it but I didn't have a chicken, or chicken substitute, around to sacrifice for extra coding power. It's not tested with unicode stuff and on any platforms other than x86, but it appears to have the semblance of a solution. The basic concept is that you must link the 32 bit spec file last among the spec files, but before any object files. We short circuit the normal way to build the ELF init section by starting a new function __wine_dllname_deferred_init which should end up containing any special init section code from the object files and the standard ELF initialization stuff. We then bind in an entry point for the builtin dll which invokes the deferred initialization code and then run the actual initialization entry point if there is one. It requires a little bit of grease since ntdll can't be called until the ctor stuff is invoked so it gets special permission to be built the old way but of course, wine wants to call it early on in life. Other than that, basically everything is limited to making winebuild produce even more stuff. How does this seem? On the right track? Suggestions for improvement? Am I missing anything with the assembler? -- Alexandre Julliard [EMAIL PROTECTED] Ciao, Peter lump_ctor_and_entry_point.diff Description: application/unknown
cleaning up pthreads implementation - ABI problem
Howdy,
I was just looking at cleaning up the pthreads
implementation but I don't think that it's possible to
have our pthreads implementation without providing
binary compatibility with the pthread implementation
we're hijacking. The reason is that the mutex and
rwlock objects are supposed to be opaque to the
programmer but in fact they are not opaque to the
compiler.
According to the standard, one doesn't have to call
pthread_{mutex,rwlock}_init before using a
{mutex,rwlock} as would be required with a totally
opaque type. The standard allows for static
initialization of the mutex and rwlock using
PTHREAD_{MUTEX,RWLOCK}_INITIALIZER if you don't want
any special attributes.
libc does just this with its rwlock for gettext's
global data. If you look at the ream of
FIXME:pthread_rwlock_{rd,un}lock that sometimes come
out starting wine you'll see that there's no call to
pthread_rwlock_init. Of course, this stuff is safe
because there's generally no writers wanting the
pthread_rwlock_wrlock.
So our current pthreads mutex implementation works
in Linux by the skin of its teeth, becuase the first
field in the mutex is reserved and initialized to 0
(in both the static and pthread_mutex_init cases),
provided the version of LinuxThreads is new enough and
a pointer is the same size as an int. Now I assume
that this would mean it fails curiously for things
that don't use LinuxThreads. This would also seem to
mean, since we need binary compatibility, that things
could even fail if someone upgrades their libc :(
BTW, our check is presently basically only on
__GLIBC__. Flavour me ignorant, and lazy, but I would
assume that this not a Linux only symbol. So in fact
the wine pthreads implementation might be already used
incorrectly.
Reader/Writer locks can be made to work the same
way, as the mutex, since there are several fields
which are initialized to NULL and we can then
HeapAlloc our own structure off that field. We can
then come up with weird and wonderful exceptions for
the wonky cases that are sure to exist in some
implementation of pthreads.
Can anyone see a nice way out of this that I'm
remaining ignorant to? I can't even think of a runtime
way of detecting if our implementation is going to
work. All in all I'm not too enthusiatic about the
potential maintenance nightmare that this may provide
but it would seem the only way is to have different
mutex and rwlock structures depending on the pthreads
implementation we're hijacking.
Some code if people are more interested in details:
From glibc 2.2.4
/* Mutexes (not abstract because of
PTHREAD_MUTEX_INITIALIZER). */
/* (The layout is unnatural to maintain binary
compatibility
with earlier releases of LinuxThreads.) */
typedef struct
{
int __m_reserved; /* Reserved for
future use */
int __m_count; /* Depth of
recursive locking */
_pthread_descr __m_owner; /* Owner thread (if
recursive or errcheck) */
int __m_kind; /* Mutex kind: fast,
recursive or errcheck */
struct _pthread_fastlock __m_lock; /* Underlying
fast lock */
} pthread_mutex_t;
#define PTHREAD_MUTEX_INITIALIZER \
{0, 0, 0, PTHREAD_MUTEX_TIMED_NP,
__LOCK_INITIALIZER}
What WINE uses (scheduler/pthread.c):
/* assume that pthread_mutex_t has room for at least
one pointer,
* and hope that the users of pthread_mutex_t
considers it opaque
* (never checks what's in it) */
typedef struct {
CRITICAL_SECTION *critsect;
} *wine_mutex;
rwlocks on the other hand are not so lucky as there's
no unused bits:
From glibc-2.2.4
/* Read-write locks. */
typedef struct _pthread_rwlock_t
{
struct _pthread_fastlock __rw_lock; /* Lock to
guarantee mutual exclusion */
int __rw_readers; /* Number of
readers */
_pthread_descr __rw_writer; /* Identity of
writer, or NULL if none */
_pthread_descr __rw_read_waiting; /* Threads
waiting for reading */
_pthread_descr __rw_write_waiting; /* Threads
waiting for writing */
int __rw_kind; /* Reader/Writer
preference selection */
int __rw_pshared; /* Shared
between processes or not */
} pthread_rwlock_t;
# define PTHREAD_RWLOCK_INITIALIZER \
{ __LOCK_INITIALIZER, 0, NULL, NULL, NULL,
\
PTHREAD_RWLOCK_DEFAULT_NP, PTHREAD_PROCESS_PRIVATE
}
Ciao,
Peter
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
wv{sn,ns}printf[AW]
Hi, it appears that we have a bit of a hack in the wine code. Presently we export wvsnprintf[AW] from user32. - These two functions do not appear to be in the real user32.dll and the comments in the code seem to back it up. - Windows does have wvnsprintf[AW] (note the transposed sn) exported from shlwapi.dll So my questions are: 1) Was the user32 a bit of a hack because those routines just weren't noticed or was it because of something from before shlwapi? 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause user32 to have to import shlwapi (because wsprintfA and friends use it in their implementation) and I don't know if that's legal because user32 seems to only import gdi32 and kernel32. If not, what's the solution? Reimplement everything in user32 to not use wvnsprintf and move the implementation over or just keep the existing situation and rename wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? Thanks, Peter [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Are these the ordinal names?
Howdy, I have a couple of questions about the following error messages err:win32:fixup_imports No implementation for SHLWAPI.dll.281(wvnsprintfA) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.282(wvnsprintfW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for SHLWAPI.dll.240(StrRetToStrW) imported from C:\windows\system\shdocvw.dll, setting to 0xdeadbeef 1) Do these messages mean that 281 is named wvnsprintfA and so on? If so, why does the SHLWAPI.240 name not seem to jive with the existing implementation? 2) Why would I be getting the error for SHLWAPI.dll.240(StrRetToStrW) given the fact that the shlwapi.spec file contains the following line and there does seem to be an implementation in ordinal.c? 240 stdcall @(long long long long) SHLWAPI_240 Ciao, Peter Hunnisett [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: HANDLE and NULL
During my test I was greeted by thousands of warnings. But except for one fix in gdiobj.c and another in registry.c it compiled and I could even run the whole Wine regression test suite: sol.exe :-) Doesn't surprise me too much. I suppose that it's also important to actually get the wine core converted over since I believe you made most of the programs directory use STRICT anyways. But this means turning a blind eye on thousands of warnings. Sending a single patch fixing all the warnings is out of the question, it would be way too big. But doing it file by file means introducing warnings until we make the global switch in windef. Would it be better to compile some subsystems with STRICT on and others with STRICT off? I was thinking about doing something like this. Just work a system at a time, as you pointed out, and as long as it doesn't break the basic ia32 user (does the sparc version of WineLib work - seem to remember Ulrich mentioning that there were still a few things which needed to be fixed in the tree) I suspect we don't have a problem during the transition. You could even just stick a #define STRICT at the top of the includes in a .c file as a temporary measure although a -DSTRICT in the makefile would be a little nicer. At some point we just switch everything over to use STRICT or pull out that #ifdef STRICT if it doesn't need to be there. I think so long as an effort is made to fix the real problems first rather than the printfs first this should be a reasonable approach. Remember how long it took the debug interface to switch over :) I'm willing to help slog through the mechanical stuff if you need a hand. Just mail me. I might even grudging convert over to using CVS now that the company has changed their internal firewall to be a little more reasonable ;) -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm Ciao, Peter Hunnisett [EMAIL PROTECTED]
re:X11DRV_LineTo optimization ?
Forget what I said. I looked at the post again. They're not constants so no constant folding type of stuff would happen. Duh :( However, the other portion of my babble actually holds. How often is it going to speed things up? Is it worth the extra code? embarrassing brain fart deleted Ciao, Peter Hunnisett [EMAIL PROTECTED]
LPCOLESTR definition
Howdy, I'm wondering if anyone knows the reason why in WINE we have LPCOLESTR defined as an LPCWSTR vs an LPCSTR in windows? Just a typo or is there something more sinister? Ciao, Peter Hunnisett [EMAIL PROTECTED]
cvs commit patch listing
Hi, just noticed that there's a, what I would consider, oversight for the generated listing that's sent out; it doesn't provide a diff of new files. For example: ChangeSet ID: 970017527636480060871691 CVSROOT:/opt/cvs-commit Module name:wine Changes by: julliard@wine2. 00/09/26 21:18:48 Modified files: include: Makefile.in mouse.h Added files: include: zmouse.h Log message: Jeremy White Created zmouse.h, moved wheel code from mouse.h into it. Patch: http://cvs.winehq.com/patch.py?root=/opt/cvs-commitlogs=/opt/cvs-commit/CVSROOT/winecommitlogid=970017527636480060871691 Revision ChangesPath 1.11 +2 -1 wine/include/Makefile.in 1.11 +0 -31 wine/include/mouse.h While the link does provide diffs for the modified files, it doesn't provide anything for the added one. I wouldn't mind seeing something like that added. I suppose that the same should be done for deleted files but wouldn't be needed for moved files (if it's possible to differentiate). What do people think? Is this possible to do with CVS (I don't use CVS so I don't know)? Ciao, Peter Hunnisett [EMAIL PROTECTED]
VxD and kernel module
a snip Supporting VxD loading will definitely NEVER happen. Supporting NT ring 0 driver loading will probably also never happen, although it might be possible at some time if someone ever really wanted to work on it, and that is doubtful. Just a question. With the wine server running as a linux kernel module would we be able to support native VxDs? I'll be honest that I don't understand the transition between rings but I'm guessing that it must involve a trap of some descript which could then be passed off to the kernel module to run in a more priviledged mode. Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: TSX* question
snip Yes, if you only consider systems using a recent glibc and a thread-safe Xlib. True. But, I guess, we can assume that for Linux-based system, right? Probably, yes. There are people who run libc5 still. My personal computer has it still, but I haven't used it in a bit as it's 4000 miles away. You were proposing just to make the check for glibc anyways, so that'll do. snip Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Wine windows always on top?
Are you using the --managed option? This should make the window known to the window manager. If you are, then I'm at an immediate loss. From the man pages: --managed Create each top-level window as a properly managed X window instead of creating our own "sticky" win dow. I have exactly the same problem ... Matthias (SuSE 6.4) At 11:36 03.08.00 -0400, you wrote: When I run Windoze apps under Wine, I cannot get X apps (xterm and such) on top of any wine window. Wine windows are always sitting on top of everything else. Is that the intended behavior? It seems to me that some (fairly long) time ago it didn't behave this way. I'm running Motif WM (apparently the original one, not LessTif clone), RedHat Linux 6.1 snip P.S. Not to sound too snarky, but it doesn't excactly seem to be a developer question. Perhaps the question would have been better suited to the newsgroup. Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: PATCH: edit control 1
On the second hand, consider misc/debugstr.c broken. dbg_vprintf() uses only 500 byte as buffer and horrible fails with 15k of unwrapped string data. Sounds like it should be using something like vsnprintf internally. If no one has any objections to changing the use of vsprintf to vsnprintf I'll do something up and submit it. Ciao, Marcus Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Failed CD-ROM ID
In message "Re: Failed CD-ROM ID", you write: Yup. That's another dsound race problem. I think that I docuemented it at the top of the dsound_main.c. I did put a correct Enter/Leave crit section check around some of the AddRef/Release functions, but I think that was only for the stubs that I added. Doesn't a critical section slows the thing down considerably since it envolves server communication? The interlocked functions should be fine here. It would appear that the implementation of the Interlocked is faster since it must be using the native processor atomic operations and, as you pointed out, doesn't do any server communication. Thinking about it, I guess there is no reason for a crit Enter/Leave since everything is reference counted, provided we never muck around with the ref count anywhere except these functions (which is the case except for creation). juergen --- [EMAIL PROTECTED] ... from sunny Berlin Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Failed CD-ROM ID
In message "Re: Failed CD-ROM ID", you write: snip Also in 20005xx there was a bug that after 10 or 15 minutes of play the game would lock up and the same 1 second of sound would loop forever, so I think there is a bug in the sound code) I just put 20005xx back on my system so I'll give a full -debugmsg +dsound +relay in a day or two. If that doesn't show anything too useful, perhaps you could reinsert the trace lines in the AddRef and Release functions. Perhaps I screwed up the reference counting in an attempt to clean it up. Of course the resulting file will be massive, but it may show something. I know that there is at least one race condition remaining which can lead to sound disappearing but you should get a WARN out around when that happens. -- Frank J. Ramsay [EMAIL PROTECTED] Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Failed CD-ROM ID
In message "Re: Failed CD-ROM ID", "" [EMAIL PROTECTED] writes: If that doesn't show anything too useful, perhaps you could reinsert the trace lines in the AddRef and Release functions. Just as a idea: if the AddRef is used by different threads it might be useful to use: InterLockedIncrement((This-ref)) instead of This-ref++. Same applies to Release too. juergen snip Yup. That's another dsound race problem. I think that I docuemented it at the top of the dsound_main.c. I did put a correct Enter/Leave crit section check around some of the AddRef/Release functions, but I think that was only for the stubs that I added. I know that we have this problem in just about all of the builtin DirectX stuff. I've had it on my list of things to fix for dplay for some time now. Too much stuff to do, not enough to do it. Does someone want to pick up the ball and go for a run? Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: WWN article: DLL overrides
snip I would at least mention somewhere that the settings in these sections may be overridden by the -dll option on the command line I may be ignorant, but it would seem that as of, at least the last release, this doesn't work. You can only use the -dll option to specify things if you don't have a DllOverides section. I haven't looked into it, because I'm basically too lazy. I'd guess DllOverides is evaluated after the command lines. I think that at one time you could command line override the wine.conf file though (memory hazy ask later...;). Rein. -- Rein Klazes [EMAIL PROTECTED] Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: ddraw problem?
In message "Re: ddraw problem?",
"Lionel Ulmer" [EMAIL PROTECTED] writes:
snip
fixme:ddraw:Xlib_IDirectDraw2Impl_QueryInterface (0x4040cba4):interface for IID
{6aae1ec1-662a-11d0-889d-00aa00bbb76a} _NOT_ found!
As far as I can tell from the log, the application is crashing in it's
own code (the Wine code seems fine in this case).
snip
So maybe the application does not expect a DDraw implementation not to
support D3D2 and crash for this...
My guess is that it's expecting the 3d2 interface because of some other ddraw
component being available. That's to say, buggy application code.
To test that theory, you could modify the Xlib_IDirectDraw2Impl_QueryInterface
code to return 0xDEADABBA or something like that and see if the crash promptly
happens on that address (since it crashes on NULL which is what the object
should be set to on failure from that routine).
Anyway, this is only a supposition
--
Lionel Ulmer - [EMAIL PROTECTED]
Ciao,
Peter Hunnisett
[EMAIL PROTECTED]
re:RFC: Wine 1.0
). Perhaps start that with version 2.0 when we might be a little more stablized ;) Thoughts? Comments? Jeremy Ciao, Peter Hunnisett [EMAIL PROTECTED]
re:Stack Overflows
I've been noticing a lot of exceptions, of type 0xC0FD (STACK_OVERFLOW), while using WINELib. snip Can anyone tell me if there is a known problem here that as been fixed? I'll take a guess that this might be a solution. http://www.integrita.com/cgi-local/lwgate.pl/WINE-CVS/archives/2000-05/Patcher/article-18.html Is there someting I can do to prevent this from happening? Thanks, Gilroy Billard mailto:[EMAIL PROTECTED] Software Developer Trakonic, inc. Free Demo at: http://www.trakonic.com Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: fw:winemine patch
In message "Re: fw:winemine patch", you write: snip my machine (PII 350). BTW, it's best if you send your patches to [EMAIL PROTECTED] because that way people (like you and me) who can't get at the CVS can still apply them. Yes well, I don't like my mailbox filling up with patch submissions so I don't subscribe to the patch list. I realize it's not optimal. I find that the bandwidth with the CVS commits is actually better. Besides we've seen, if I'm recalling correctly, that patches submitted to the list aren't necessarily applied as is and there are some submissions which don't make it to the patch list. Alexandre does use his discression and CVS seems to be the only offical way of doing things between releases. This does slightly impact some people who don't use CVS mais, c'est la vie. Should we change policy and require submissions to only the patch list and remove the requirement of subscription (and change the ANNOUNCE file?) On a side note you can sort of grab the latest files from a few links off the web that show the present CVS tree, provided you know what's been applied and rejected. It's a manual effort and not perfect though... Joshua _ NetZero - Defenders of the Free World Click here for FREE Internet Access and Email http://www.netzero.net/download/index.html Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Fwd: Memory leak in WineMine
Well if the leak appears to be comming from the CreateCompatilbeDC, my changes will have reduced the impact since we were doing some pretty massive creation/deletion for DrawMine. I didn't even look for a leak, though. The code does have that pattern in several places. Which is causing it, or are they all. What about the fact that SelectObject can return the old handle? Could that be your leak - handle to a resource? In message "Re: Fwd: Memory leak in WineMine", "Joshua Thielen" [EMAIL PROTECTED] writes: After checking out the memory leak, I think I've narrowed it down to this code snippet: ---in main.c--- hMemDC = CreateCompatibleDC( hdc ); SelectObject (hMemDC, p_board-hMinesBMP); BitBlt( hdc, (col - 1) * MINE_WIDTH + p_board-mines_rect.left, (row - 1) * MINE_HEIGHT + p_board-mines_rect.top, MINE_WIDTH, MINE_HEIGHT, hMemDC, 0, offset * MINE_HEIGHT, SRCCOPY); DeleteDC( hMemDC ); -- Am I doing anything incorrect here? After commenting out various parts, I believe the leak occurs in CreateCompatibleDC or DeleteDC, but I could not find any bugs in these functions. Actually, I did notice that origDC never gets unlocked in CreateCompatibleDC, is this a bug? Unlocking this does not stop the memory leak in winemine, however. Joshua Thielen _ NetZero - Defenders of the Free World Click here for FREE Internet Access and Email http://www.netzero.net/download/index.html Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: Is there a Wine dumpbin?
Looks like LCC to my untrained eye - check winehq for links to it. I think that the elf version might have been a port by Uwe. Last I checked the windows version worked under wine as well. PEDUMP - Win32/COFF .EXE/.OBJ file dumper - 1993 Matt Pietrek, 1995-1997 Jacob Navia Working version Sep 28 1998 21:07:43 Syntax: PEDUMP [switches] filename -ainclude everything in dump -hinclude dump of sections -linclude line number information -rel show base relocations -eshow resources -xeXtract section: for instance /x.data -ddump code view format debug info -sshow symbol table Uwe Bonnes perpetrated a program called pedisassem that lists imports and everything else about the same time. I have the source for that; I think I ftpmailed it from his site, but I have lost track of that too. Ciao, Peter Hunnisett [EMAIL PROTECTED]
compile failure in server/context_i386.c
Hi, I just compiled the last two releases and I'm getting a compile failure in server/context_i386.c relating to the use of PTRACE_PEEKUSER and PTRACE_POKEUSER for ptrace calls. Looking in my system (libc5) I have PTRACE_PEEKUSR and PTRACE_POKEUSR (note the lack of E in USR). This seems to be what's in my linux 2.0.14 source. Is something corrupted in my system, or am I about the only weirdo still running libc5? I just "fixed" it by guessing that it was a typo. Could someone confirm or deny? If so I'll submit a patch since it doesn't seem to be high priority... Ciao, Peter Hunnisett [EMAIL PROTECTED]
