wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: Remove heap.h
by Dimitrie O. Paun 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 07:57:31AM -0800, Jon Griffiths wrote: > Hi, > > After applying, include/heap.h can be removed from cvs. To be honest, I'm not too happy with this patch, HEAP_strdupWtoA was a good marker for code that needed fixing, this patch just makes those places harder to find. -- Dimi.

2 2

Re: Get rid of DPRINTF in x11drv/opengl.c
by Dimitrie O. Paun 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 12:04:23PM +0100, Diego 'Flameeyes' Pettenò wrote: > I had some spare time, and I wanted to do some mostly non-designing code, so I > took the time to look at wine's janitorial projects, and I took a look at the > DPRINTF -> TRACE conversion. > > The attached patch removes DPRINTFs from x11drv/opengl.c (which is the only > file in x11drv which uses them), and replacing the 6 different following > calls with a single call for bits and buffer counters. This is a good project to work on, but the reason it's not done yet it's because it is not a simple replacement of DPRINTF with TRACE. Doing stuff like: + TRACE(" - size / version : %d / %d\n", ppfd->nSize, ppfd->nVersion); + TRACE(" - dwFlags : "); Will not work correctly in a multitreaded environment, where the lines may get intertwinded on output with statements from other threads. The way to do it is to prepare the output in a memory buffer, and output it at once. This can be done with the wine_dbg_sprintf() function. In cases where you need logic to construct the output (like testing for flags, etc), you can do it by first printing to a local buffer, and then printing the content of the buffer to a debug buffer via wine_dbg_sprintf(). A simple example of this technique can be found in the dlls/kernel/locale.c file, in the debugstr_lang() function. -- Dimi. -- Dimi.

2 1

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation
by Jonathan Gevaryahu 30 Dec '04

30 Dec '04

Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >To: Anish Mistry <mistry.7(a)osu.edu> >Cc: wine-devel(a)winehq.org >Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total > Annihilation > >and if you remove the entire line (if (!is_version_nt()) access = >TIMER_ALL_ACCESS;)? >A+ > > >--__--__-- > That doesn't fix the problem here. Still the same trace response... I haven't run it enough times to see if it will still occasionally work with that line altered or removed... I know it does work (without any changes from the version in CVS) about 5% of the time. Jonathan Gevaryahu lord_nightmare(a)users.sf.net

6 6

Re: Get rid of DPRINTF in wininet
by Dimitrie O. Paun 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 12:33:52PM +0100, Diego 'Flameeyes' Pettenò wrote: > I hope only my usual karma is not here this time or I'll make everybody lost > time ^^ I'm afraid it is <g>. This is a case where the wine_dbg_sprintf() business is in order. -- Dimi.

2 1

Re: Get rid of DPRINTF in opengl32
by Dimitrie O. Paun 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 12:37:12PM +0100, Diego 'Flameeyes' Pettenò wrote: > Hi, > this time is a very small patch, it simply replace DPRINTF with TRACE without > oher changes. Once again, a job for wine_dbg_sprintf(). -- Dimi.

1 0

Re: Get rid of DPRINTF in winedos
by Dimitrie O. Paun 30 Dec '04

30 Dec '04

On Thu, Dec 30, 2004 at 12:22:18PM +0100, Diego 'Flameeyes' Pettenò wrote: > Hi, > The attached patch replaces DPRINTF -> TRACE in winedos dll, joining the near > DPRINTF used to tace dos interrupts. This looks good, but do we still need the explicit 'if (TRACE_ON(relay))'? I think we can use the explicit one from TRACE(), no? -- Dimi.

1 0

NLS/IME functions
by Diego 'Flameeyes' Pettenò 30 Dec '04

30 Dec '04

Hi, I'm still trying to figure out how nls/ime functions are placed in windows systems to fix up the patch I sent some days ago. I haven't had the time to find out if YuGiOh calls GetProcAddress (because isn't mine, it's of a friend of mine which is trying to get it working, so I need him to test), so I'm fooling around checking for a way to fix this up. At least Win98's and Win2k's user32.dll have the functions defined into winnls32.h, also if they are defined as compatibility with winnt3. At the moment on wine these functions are commented out also as stubs so they are completely missing. On Windows I'm not able to find a winnls32.dll which is instead present on wine, and seems to define similar functions (but they are quite all spec-stubs, but three functions which are defined (stubbing), without a STUB trace. How should be this done? Implement stub-functions for every nls/ime function? Or simply ignore them for now? Thanks for the time, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

1 0

build problem on current cvs
by Stefan Leichter 29 Dec '04

29 Dec '04

Hello, i hope you all had nice Christmas. Now back to business :-) trying to build current cvs (~7:45 AM UTC) i get the error: make[1]: Entering directory `/usr/src/wine/wine-build/include' ../tools/widl/widl -I../../wine/include -I. -I../../wine/include -I../include -h -H oaidl.h ../../wine/include/oaidl.idl ../../wine/include/wtypes.idl:1: Oops, segment violation make[1]: *** [oaidl.h] Abgebrochen make[1]: *** Datei »oaidl.h« wird gelöscht make[1]: Leaving directory `/usr/src/wine/wine-build/include' make: *** [include] Fehler 2 My system is still SuSE 9.0. I am doing 'out of tree' builds. Bye Stefan

3 7

Re: clean-up
by Eric Blade 29 Dec '04

29 Dec '04

My apologies for not responding, I had attempted to sign up for the list, and that had failed. Oops! Now, here I am. :) Paul van Schayck said, about the <<br />> .. oops, that was a mistake in my search/replace.. I thought I had fixed all of those occurences that I made. Also, for the !loggedin() || !have_priv(admin) .. i just copied that code from another module, that had used it in that exact same spot.. the file had a comment that said "// check for admin access here" .. :P no, i don't think it should be !loggedin() && !have_priv(admin) .. that wouldn't make sense, if it were &&.. that needs to be an || . Re: Johnathan Ernst: As I said, I had just copied the code from the other places in the admin/* files that used it. Before I changed that, the code simply said: if(!loggedin()) .. which meant anyone logged in could access that admin function. It does make sense that if not logged in you couldn't have admin privs, so I could change all the files to check that instead. So, my next question.. do you have to have admin priv to be a maintainer? Becauses some of the files check for loggedin, havepriv(admin) and maintainer flags. Should admin/adminCommentView.php be protected? I realise it's in the admin category, but it doesn't look like anyone can get into any mischief with that.. could almost be handy for users. --- anyway, i've fixed those issues, merged it to latest CVS, and will be re-sending it off in just a minute. Thanks :) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [AppDB] Small appbrowse cleanup
by Chris Morgan 29 Dec '04

29 Dec '04

Please, no tabs :-P Chris On Wednesday 29 December 2004 7:10 am, Paul van Schayck wrote: > weird

1 0

Re: [QUARTZ] Some stuff to start the graph
by Robert Shearman 29 Dec '04

29 Dec '04

Christian Costa wrote: > Hi, > > Changelog: > Implemented IMediaControl_Run that explores the graph, counts > renderers and starts filters. > Better implementation of IBaseFilter_Run for AVI SPlitter and AVI > Decompressor. > Use the standard memory allocator when an output pin does not provide > any allocator. > Set allocator properties for AVI Decompressor output pin and update > the buffers size at connection time. > > Christian Costa titan.costa(a)wanadoo.fr > >------------------------------------------------------------------------ > >Index: dlls/quartz/avidec.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avidec.c,v >retrieving revision 1.12 >diff -u -r1.12 avidec.c >--- dlls/quartz/avidec.c 27 Dec 2004 17:15:58 -0000 1.12 >+++ dlls/quartz/avidec.c 29 Dec 2004 09:06:24 -0000 >@@ -235,6 +235,9 @@ > pAVIDec->pBihOut->biCompression = 0; > pAVIDec->pBihOut->biSizeImage = pAVIDec->pBihOut->biWidth * pAVIDec->pBihOut->biHeight * pAVIDec->pBihOut->biBitCount / 8; > >+ /* Update buffer size of media samples in output */ >+ ((OutputPin*)pAVIDec->ppPins[1])->allocProps.cbBuffer = pAVIDec->pBihOut->biSizeImage; >+ > pAVIDec->init = 1; > TRACE("Connection accepted\n"); > return S_OK; >@@ -354,7 +357,13 @@ > > if (SUCCEEDED(hr)) > { >- hr = AVIDec_OutputPin_Construct(&piOutput, NULL, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); >+ ALLOCATOR_PROPERTIES props; >+ props.cbAlign = 1; >+ props.cbPrefix = 0; >+ props.cbBuffer = 0; /* Will be updated at connection time */ >+ props.cBuffers = 2; >+ >+ hr = AVIDec_OutputPin_Construct(&piOutput, &props, NULL, AVIDec_Output_QueryAccept, &pAVIDec->csFilter, &pAVIDec->ppPins[1]); > > if (FAILED(hr)) > ERR("Cannot create output pin (%lx)\n", hr); >@@ -502,6 +511,8 @@ > This->state = State_Running; > } > LeaveCriticalSection(&This->csFilter); >+ >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[1]); > > This needs to be inside the critical section. > > return hr; > } >Index: dlls/quartz/avisplit.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/avisplit.c,v >retrieving revision 1.10 >diff -u -r1.10 avisplit.c >--- dlls/quartz/avisplit.c 27 Dec 2004 17:15:58 -0000 1.10 >+++ dlls/quartz/avisplit.c 29 Dec 2004 09:06:26 -0000 >@@ -327,6 +327,7 @@ > { > HRESULT hr = S_OK; > AVISplitter *This = (AVISplitter *)iface; >+ int i; > > TRACE("(%s)\n", wine_dbgstr_longlong(tStart)); > >@@ -337,6 +338,17 @@ > } > LeaveCriticalSection(&This->csFilter); > >+ hr = PullPin_InitProcessing(This->pInputPin); >+ >+ if (SUCCEEDED(hr)) >+ { >+ for (i = 1; i < This->cStreams + 1; i++) >+ { >+ OutputPin_CommitAllocator((OutputPin *)This->ppPins[i]); >+ } >+ hr = PullPin_StartProcessing(This->pInputPin); >+ } >+ > return hr; > } > > And so does this. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); > >+ if (This->state == State_Running) >+ return S_OK; >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ > return S_FALSE; > } > > And this all needs to be protected by a critical section too. > >@@ -1191,7 +1287,9 @@ > OAFilterState *pfs) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); > >- TRACE("(%p/%p)->(%ld, %p): stub !!!\n", This, iface, msTimeout, pfs); >+ TRACE("(%p/%p)->(%ld, %p): semi-stub !!!\n", This, iface, msTimeout, pfs); >+ >+ *pfs = This->state; > > > This probably needs protection too. Rob

2 3

Re: [QUARTZ] Some stuff to start the graph (take 2)
by Robert Shearman 29 Dec '04

29 Dec '04

Christian Costa wrote: > Hi, > > This time with more thread safety. Looking better, but one more change needed. In addition, most of the code in filtergraph.c isn't thread safe. Thread safety is particularly important in DirectShow where threads are heavily used. Debugging random crashes is not fun. ... > /*** IMediaControl methods ***/ > static HRESULT WINAPI Mediacontrol_Run(IMediaControl *iface) { > ICOM_THIS_MULTI(IFilterGraphImpl, IMediaControl_vtbl, iface); >+ int i; >+ IBaseFilter* pfilter; >+ IEnumPins* pEnum; >+ HRESULT hr; >+ IPin* pPin; >+ LONG dummy; >+ PIN_DIRECTION dir; > >- TRACE("(%p/%p)->(): stub !!!\n", This, iface); >+ TRACE("(%p/%p)->()\n", This, iface); >+ >+ if (This->state == State_Running) >+ return S_OK; > > > This should be inside the critical section, being careful, of course, not to return without calling LeaveCriticalSection. >+ EnterCriticalSection(&This->cs); >+ >+ /* Explorer the graph from source filters to renderers, determine renderers number and >+ * run filters from renderers to source filters */ >+ This->nRenderers = 0; > ResetEvent(This->hEventCompletion); > >+ for(i = 0; i < This->nFilters; i++) >+ { >+ BOOL source = TRUE; >+ pfilter = This->ppFiltersInGraph[i]; >+ hr = IBaseFilter_EnumPins(pfilter, &pEnum); >+ if (hr != S_OK) >+ { >+ ERR("Enum pins failed %lx\n", hr); >+ continue; >+ } >+ /* Check if it is a source filter */ >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ IPin_QueryDirection(pPin, &dir); >+ if (dir == PINDIR_INPUT) >+ { >+ source = FALSE; >+ break; >+ } >+ } >+ if (source == TRUE) >+ { >+ TRACE("Found a source filter\n"); >+ IEnumPins_Reset(pEnum); >+ while(IEnumPins_Next(pEnum, 1, &pPin, &dummy) == S_OK) >+ { >+ /* Explore the graph downstream from this pin */ >+ ExploreGraph(This, pPin, 0); >+ } >+ IBaseFilter_Run(pfilter, 0); >+ } >+ IEnumPins_Release(pEnum); >+ } >+ >+ This->state = State_Running; >+ >+ LeaveCriticalSection(&This->cs); >+ > return S_FALSE; > } > > Rob

2 1

Re: UNICOWS: stub implementations
by Stefan Leichter 29 Dec '04

29 Dec '04

Am Dienstag, 28. Dezember 2004 13:16 schrieb Hans Leidekker: > This one removes most remaining spec file stubs from unicows. It depends > on my previous patches to winspool, kernel, user, gdi, rasapi and shell. > > -Hans > > Changelog: > Stub implementations for AddMonitorW, AddPortW, AddPrintProcessorW, > AddPrintProvidorW, AdvancedDocumentPropertiesW, ConfigurePortW, > DeleteMonitorW, DeletePortW, DeletePrinterDriverW,DeletePrintProcessorW, > DeletePrintProvidorW, EnumDateFormatsExW, EnumPortsW, > EnumPrintProcessorDatatypesW, GetAltTabInfoW, GetICMProfileW, GetJobW, > GetLogColorSpaceW, GetPrintProcessorDirectoryW, > RasConnectionNotificationW, RasCreatePhonebookEntryW, RasDeleteSubEntryW, > RasDialW, RasEditPhonebookEntryW, RasGetConnectStatusW, > RasGetEntryDialParamsW RasGetEntryPropertiesW, RasGetErrorStringW, > RasGetProjectionInfoW, RasHangUpW, RasRenameEntryW, RasSetEntryDialParamsW, > RasSetSubEntryPropertiesW, SHGetNewLinkInfoW, SetICMProfileW, > UpdateICMRegKeyW. Hello Hans, you missed to send the implementations of the stubs! Bye Stefan

2 2

Re: Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

I see that the file .wine/user.reg has a line in it that reads "USERPROFILE"="c:\\Windows\\Profiles\\Administrator" but my Windows directory has no Profiles subdirectory in it: mark@gandalf Windows $ ls -al total 40 drwxr-xr-x 9 mark users 4096 Dec 28 10:46 . drwxr-xr-x 4 mark users 4096 Dec 28 10:46 .. -rw-r--r-- 1 mark users 0 Dec 28 10:46 .keep drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Desktop drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Favorites drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Fonts drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Inf drwxr-xr-x 2 mark users 4096 Dec 28 10:46 Recent drwxr-xr-x 3 mark users 4096 Dec 28 10:46 Start Menu drwxr-xr-x 2 mark users 4096 Dec 28 10:46 System -rw-r--r-- 1 mark users 481 Dec 28 10:54 win.ini mark@gandalf Windows $ Possibly this is part of the problem??? Thanks, Mark On Tue, 28 Dec 2004 14:46:58 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > I'm guessing this means WIne is compiled on this machine in a way that > > doesn't output debug information? > > > > If so (please let me know) then I'll have to look up how to compile > > to include this output. > > I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty > chatty, so the default configure options in the RPM spec file must be what > you need. > >

1 0

Re: Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

On Tue, 28 Dec 2004 14:46:58 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 2:39 PM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > I'm guessing this means WIne is compiled on this machine in a way that > > doesn't output debug information? > > > > If so (please let me know) then I'll have to look up how to compile > > to include this output. > > I installed my copy on Fedora Core 2 by building an RPM, and WINE is pretty > chatty, so the default configure options in the RPM spec file must be what > you need. > I'm on Gentoo. It sticks in my mind that there is a configure option that turns this on. It's not on by default. I'm doing this on a relative's Gentoo box right now. On my Gentoo system at home I have debugging turned on so I'll wait until I get there in a couple of days and try again with debugging turned on. My though, having poked around a bit, is that there is a registry entry for each user that says whether the user has admin rights. I think that's not turned on, but I don't know if I turn it on whether it will actually work. This is all guessing. Again, Wine is not bombing out at all. I'm just getting a Windows dialog telling me that I need to be an administrator. - Mark

1 0

Re: Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

Kenneth, There are no messages when I run Wine like this: WINEDEBUG=+all wine setup.exe I'm guessing this means WIne is compiled on this machine in a way that doesn't output debug information? If so (please let me know) then I'll have to look up how to compile to include this output. - Mark On Tue, 28 Dec 2004 14:21:32 -0800, Kenneth Porter <shiva(a)sewingwitch.com> wrote: > --On Tuesday, December 28, 2004 11:12 AM -0800 Mark Knecht > <markknecht(a)gmail.com> wrote: > > > How can I tell Wine to trick an install program into thinking the user > > has administrator rights under Windows XP? I've switched the windows > > type in the config file to winxp but the install program for Autocad > > 2005 tells me to log in again as an administrator. > > My guess is that it's either unable to write to a system directory or it's > looking for a certain group membership. Try tracing the installer and see > if it's doing something like that. > >

2 1

Windows Admionistrator Rights
by Mark Knecht 28 Dec '04

28 Dec '04

Hi - Sorry for cross posting to both winde-devel and wine-users but I need to try and get an answer today on this. I'm at my dad's house and using Wine on his computer. How can I tell Wine to trick an install program into thinking the user has administrator rights under Windows XP? I've switched the windows type in the config file to winxp but the install program for Autocad 2005 tells me to log in again as an administrator. Thanks in advance, Mark

2 1

ptrace + Warcraft 3 issues remain (2.6.10)
by Jesse Allen 28 Dec '04

28 Dec '04

Last I reported on Warcraft 3 with the ptrace changes in 2.6.10-rc3 is that it made some improvement, but still doesn't work. I'll will describe in detail what I know now. Since the changes in 2.6.10-rc3, Linus made a very good clean up of ptrace.c and signal.c in arch/i386/kernel. I don't want to necessarily reverse all these changes because they are good changes (ie easier to understand and hack now). So I hacked the kernel to change what is necessary to make the game run again. I have attached the patch against 2.6.10 to show the required changes. Comments on what I have learned about the 3 ptrace changes (see my original report): #1 ptrace.c In set_singlestep() and clear_singlestep(), the flag TIF_SINGLESTEP is now set and cleared. In the header file in include/asm-i386/thread_info.h, it seems to indicate to me that it is an internal flag to remember to re enable single-stepping for a thread on returning to the program. While speaking to my brother on this, we believe that this change was done correctly. But this change alone will break the game. I have looked in both wine for PTRACE_SINGLESTEP to see what it does and in the kernel for TIF_SINGLESTEP. Since set/clear TIF_SINGLESTEP causes the problem, I really need more information on everything about TIF_SINGLESTEP. #2 signal.c - Not single-stepping into signal handlers unless the tracer requests it Previous to 2.6.9-rc2, my understanding is that a call to setup_frame() would clear the trap flag in preparation for a signal delivery. Roland made a slight tweak to it and an example of it is this: if (regs->eflags & TF_MASK) { if (current->ptrace & PT_PTRACED) { ptrace_notify(SIGTRAP); } else { regs->eflags &= ~TF_MASK; } } Linus later changed it to: /* * Clear TF when entering the signal handler, but * notify any tracer that was single-stepping it. * The tracer may want to single-step inside the * handler too. */ if (regs->eflags & TF_MASK) { regs->eflags &= ~TF_MASK; if (current->ptrace & PT_DTRACE) ptrace_notify(SIGTRAP); } In 2.6.10, this new piece of code actually works with Warcraft III. I no longer have to reverse this change. The result is obvious because it makes it so you don't automatically single step into the handler, which wine doesn't really want. #3 signal.c - Clearing the trap flag if being traced by debugger in setup_sigcontext() For some reason, Warcraft III doesn't work if it is cleared here. I have no idea if this TF clear is really necessary. However, everything I've read on this seems to indicate to me that this change is important, so I need to find out what this causes to the game. I captured a log of the seh debug messages because I think this is may be where to look. I also hacked in to display trace messages in wine's dlls/ntdll/signal_i386.c showing eflags and whether TF is cleared in trap_handler() and raise_trap_exception(). I ran the game under 2.6.10 and the modded 2.6.10, to capture the working version, and the failing version. The results are fairly nonrandom and comparable and you can identify differences. Unfortunately, I cannot upload them at the moment because my connection is slow and the files are large. I'll upload it another time. Jesse

1 0

Re: [OLE #16] Comment out an assert, as we don't yet implement IRemUnknown
by Andreas Mohr 28 Dec '04

28 Dec '04

Hi, On Tue, Dec 28, 2004 at 03:37:17PM +0000, Mike Hearn wrote: > Mike Hearn <mh(a)codeweavers.com> > Comment out an assert, as we don't yet implement IRemUnknown > > --- dlls/ole32/stubmanager.c (revision 9) > +++ dlls/ole32/stubmanager.c (local) > @@ -171,8 +175,10 @@ int stub_manager_unref(struct stub_manag > EnterCriticalSection(&m->lock); > if (!list_empty(&m->ifstubs)) > { > - ERR("PANIC: Stub manager is being destroyed with outstanding interface stubs\n"); > - assert( FALSE ); > + ERR("PANIC: Stub manager %s is being destroyed with outstanding interface stubs\n", wine_dbgstr_longlong(m->oid)); > + > + /* assert( FALSE ); */ > + /* fixme: this will happen sometimes until we do proper lifecycle management via IRemUnknown */ > } > > /* fixme: the lifecycle of table-weak marshals is not $ find|xargs grep FIXME|wc -l 11011 $ find|xargs grep fixme|wc -l 83 Might be good to keep it that way... Andreas Mohr

3 3

[AppDB] Get rid of value fillers in appSubmit.php for a new version
by Paul van Schayck 28 Dec '04

28 Dec '04

Those value fillers are not used. We never send users back to the page when errors are found (maybe we should). Changelog: Remove registered globals from the new-version submit. They are not used.

3 4

wine: could not load kernel32.dll, status c000007b
by Serge S. Spiridonoff 28 Dec '04

28 Dec '04

Hi, I've compiled a Win32 GUI app under Linux using WineLib but it fails to start. Any ideas what's wrong with the program? [test]WINEDEBUG=+loaddll ./dlg1 trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\msvcrt.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\advapi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\gdi32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\user32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\winspool.drv" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comctl32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\iphlpapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\rpcrt4.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\ole32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shell32.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\comdlg32.dll" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "krnl386.exe" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "system.drv" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "GDI.EXE" : builtin trace:loaddll:MODULE_LoadModule16 Loaded module "USER.EXE" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\x11drv.dll" : builtin trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\imm32.dll" : builtin wine: could not load kernel32.dll, status c000007b Thanks in advance, Serge

1 0

Re: MSI: free allocated buffers
by Joris Huizer 28 Dec '04

28 Dec '04

Mike McCormack wrote: > > ChangeLog: > <aric(a)codeweavers.com> > * free allocated buffers > > The other daty I saw a lot of patches changing things like if (buffer) HeapFree(GetProcessHeap(),0,buffer); To HeapFree(GetProcessHeap(),0,buffer); Why are you adding new code with the if() statement in place again? Just curious regards, Joris

3 2

Re: Unicodify System Metrics
by Mike Hearn 28 Dec '04

28 Dec '04

On Tue, 28 Dec 2004 00:26:36 -0500, jchevrier wrote: > --- sysparams.c.orig 2004-12-27 20:09:20.000000000 -0500 > +++ sysparams.c 2004-12-27 21:45:02.674627072 -0500 Hi, The patch looks OK at a first glance but in future please diff from the source root, preferably against CVS. thanks -mike

1 0

[AppDB] naming convention
by Jonathan Ernst 28 Dec '04

28 Dec '04

As discussed with Chris and others on IRC we'd like to use a new variable naming convention in AppDB code. The proposed scheme is the following ("hungarian notation"): handles: $hSomeHandle integer: $iSomeInteger objects: $oSomeObject arrays: $aSomeArray strings: $sSomeString and so on. constants will still be uppercase without prefix. Do someone object this ? Jonathan

2 2

Re: free allocated buffers
by Dmitry Timoshkov 28 Dec '04

28 Dec '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > Index: dlls/msi/action.c > =================================================================== > RCS file: /home/wine/wine/dlls/msi/action.c,v > retrieving revision 1.55 > diff -u -r1.55 action.c > --- dlls/msi/action.c 27 Dec 2004 19:12:35 -0000 1.55 > +++ dlls/msi/action.c 28 Dec 2004 06:47:04 -0000 > @@ -423,6 +423,59 @@ > } > } > > +/* Called when the package is being closed */ > +extern void ACTION_free_package_structures( MSIPACKAGE* package) > +{ > + INT i; The "extern" above should be removed. -- Dmitry.

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