August 2004 - Wine-Devel - list.winehq.org

Re: wineserver epoll

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > > > >>After much talk, the patch seems ready for commit. Since there are many >>systems with slightly older glibc that have the header but do not have >>the implementation in glibc, or that have a stub implementation that is >>guaranteed to fail, we are calling the kernel functions directly. This >>also allows compiling on older systems than the code actually ships to. >> >>Accordingly, the autoconf checks for epoll_create in glibc were dropped. >> >> > >That's wrong; if the libc function exists you should use it, direct >system calls should only be used as a fallback. > But what to do if the library functions exist during compilation, and do not during runtime? Merely linking with them will cause wineserver not to load, claiming that it requires "GLIBC version 3.2.3". Some wine uses (crossover office being one of them) require you to compile once and run almost everywhere, which run counter to this behavior. > And when using system >calls you must not depend on the libc header, you have to define the >structures yourself. > > Just yank the definitions from the header? I can do that, the license is compatible. However, I think it's pointless. Most systems will have that header, and for those who don't, we will have a fallback. What's wrong with using the header if it's there? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 30, 2004

WineHQ - Hosted by PayPal

by Tero Tamminen

Hi! Sorry if this is wrong list or something, but I saw this bug (if this is feature, not a bug, ignore this mail) in front page of WineHQ. Also with quick search with Google I didn't find this reported before. On the right side, there is "Hosted by" and empty link to codeweavers (<a href="http://www.codeweavers.com/"></a>). After that there is PayPal link. Because <a href="http://www.codeweavers.com/"></a> is empty, it seems that this site is hosted by PayPal (which should come after codeweavers, I think). This could be said more clearly I think, but if you go to the front page, you'll notice it. Anyway, have a nice day and so on... -- Tero Tamminen

Aug. 30, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Mike Hearn

On Mon, 30 Aug 2004 08:56:38 +0000, Jacek Caban wrote: > It's not a bug. It's a difference between Wine's and native Windows > implementation. By definition an application that works fine on Windows should work fine on Wine. If they don't, it's a bug. > When you run the attached test with the builtin version, you'll get: > ref = 2 > ref = 3 > ITypeLib has a reference to the linked list of ITypeInfo. Functions > GetTypeInfo and > GetTypeInfoOfGuid search this list, call ITypeInfo::AddRef and returns > the reference > to ITypeInfo. ITypeInfo is destroyed when ITypeLib is destroyed (it > means that each > other ITypeInfos are destroyed too). Running this test with native > Windows dll, results are: > ref = 1 > ref = 2 Sounds like a bug to me. Refcounting differences can cause crashes and memory leaks. > I don't thik it Wine's bug. Applications don't depend on this stuff and > Wine's ref handling is correct. I'd be very surprised if there were no apps that depended on it, actually. Given the number of crashes we've seen caused by refcount problems in this part of the code, I'd say there definitely are.

Aug. 30, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Jacek Caban

Filip Navara wrote: > Jacek Caban wrote: > [snip] > >> I don't thik it Wine's bug. Applications don't depend on this stuff >> and Wine's ref handling is correct. > > > > Of course that applications depend on this stuff. This is common code: > LoadTypeLib("stdole.tlb", &ptlibStdOle); > ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown)); > ptlibStdOle->GetTypeInfoOfGuid(IID_IDispatch, &ptinfoIDispatch)); > ptlibStdOle->Release(); > Now with Wine the last Release will cause the typelib object to be > destroyed and resulting that any later typeinfo references to typelib > are invalid pointers. > I know that. My patch: http://www.winehq.org/hypermail/wine-patches/2004/08/0167.html fixes this problem (patch is applied).

Aug. 30, 2004

ScrollBars and Wine

by Diego 'Flameeyes' Pettenò

Hi, Last tuesday I reported some problems with Ultima OnLine AutoPatch ( http://article.gmane.org/gmane.comp.emulators.wine.user/7046 ), with the last CVS and now I found some more information about the problem. Seems like this NULL Pointer (because I think it's this the problem, seeing the 0x00000000) is dereferenced everytime a scrollbar changes position or size (at least while it's painted). I had a similar problem trying to use Inside UO (program to find out data inside the UO files, wrote in Delphi) and everytime I moved a scrollbar I got an NULL Pointer Exception (but in that case it was handled by the Delphi's Exception Handler, so the program didn't closed). Similar problems have Dependency Walker and also native Regedit. Every time I have this: Backtrace: =>1 0x00000000 (0x00001396) 2 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) as backtrace. With the CVS of two weeks ago at least Dependency Walker run fine without problems at all. -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

Aug. 30, 2004

Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Michael Buesch

Quoting Ove Kaaven <ovek(a)arcticnet.no>: > Well, my theory is that in this situation, with the great new > interactivity-boosting Linux scheduler, the wineserver is considered > very interactive, and gets scheduled a lot more than the high-priority > threads, just so it can satisfy the wait requests of the low-priority > thread. So what about introducing a new "scheduler flag" like the processor affinity flag. Some process may set itself to FLAG_NONITERACTIVE and the scheduler will never boost its priority. This can be allowed for non-root processes, too, as it doesn't increase the priority. -- Regards Michael Buesch [ http://www.tuxsoft.de.vu ]

Aug. 30, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Saulius Krasuckas

On Sun, 29 Aug 2004, Juan Lang wrote: > > 1, whether is better to duplicate code > > SHGetFolderPathW() or to try finding it by an > > ordinal its value (the case for the older versions > > of SHELL32.DLL) as it was stated by Juergen? > > What are you trying to accomplish? For example, it > seems reasonable to assert that you must use the > builtin shell32 and shfolder.dll in combination, or > not at all, as Alexandre once suggested. Maybe it really sounds reasonable for those who know that there are only two functions exported by shlfolder.dll. Yesterday I wasn't aware of this and I was annoyed when Wine failed to run with "shfolder=n" set. > Or, in order for Wine's shfolder.dll to succeed on > older (native) versions of shell32.dll, it seems > reasonable to have it call SHGetSpecialFolderPath* > from SHGetFolderPath*, as MS' version does. I am sure shfolder.dll from win98se installation calls GetProcAddress() to get the address of SHGetFolderPathW @ shell32.dll. Moreover, my shell32.dll doesn't export SHGetSpecialFolderPath* by a name, also. Versions of the dlls I have are: shfolder: 6.00.2600.000 shell32: 4.72.3812.600 What versions do you mention, Juan? > In other words, why do you need the combination of > native shell32 and builtin shfolder.dll? I would like to optimize Wine setup, where the optimization criterion is achieving as small amount of native dll code used as it can be possible (without loosing some required functionality). And combination of native shell32+shdocvw+shlwapi dlls are needed for mIRC and TotalCommander to function more properly. On Sun, 29 Aug 2004, Filip Navara wrote: > >1, whether is better to duplicate code SHGetFolderPathW() or to try > >finding it by an ordinal its value (the case for the older versions of > >SHELL32.DLL) as it was stated by Juergen? > > ShFolder is redistributable. I believe the best solution would be to > move the code from Shell32 to ShFolder and then making the Shell32 > exports forwarders to ShFolder. =) Now there are 4 possible solutions to get mixing work: 1, try linking to SHGetFolderW @ shell32 dynamically - search it by a name or an ordinal value. Kind of smart autodetection (suggested by Juergen). 2, to copy the SHGetFolder* code from shell32.dll (Alexandre). 3, to move the SHGetFolder* code from shell32.dll (Filip). 4, try linking to SHGetSpecialFolderPath* @ shell32 dynamically (Juan). IMHO the 3rd and the 4th solutions would fail when using native shell32.dll from win98se. Or maybe only the 4th case will do so. Where I am wrong? What direction to go? Feel free to explain it.

Aug. 30, 2004

Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by kernel＠kolivas.org

Quoting Michael Buesch <mbuesch(a)freenet.de>: > Quoting Ove Kaaven <ovek(a)arcticnet.no>: > > Well, my theory is that in this situation, with the great new > > interactivity-boosting Linux scheduler, the wineserver is considered > > very interactive, and gets scheduled a lot more than the high-priority > > threads, just so it can satisfy the wait requests of the low-priority > > thread. > > So what about introducing a new "scheduler flag" like the > processor affinity flag. Some process may set itself to > FLAG_NONITERACTIVE and the scheduler will never boost its > priority. This can be allowed for non-root processes, too, > as it doesn't increase the priority. "nice" does exactly what is required. If one thread is a nice level >10 higher than another thread it will never preempt it in mainline 2.6. We definitely don't want to go modifying the scheduler to suit one application. Cheers, Con

Aug. 30, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Ove Kaaven

man, 30.08.2004 kl. 02.50 skrev michael(a)cherryblossom.homelinux.com: > As I recall, most apps fall under two catagories (basically): a) those > who don't bother with priority (they use the default one, mostly toward > lesser end users and general audiences) and b) those who allow the user > to change this via a menu or command line option (advanced apps only or > advanced feature only). and c) those who rely on priorities and set some threads to high priority without asking the user (mainly games) > > Only root can do this under Linux. > > Maybe I sound naive, but would it be possible to get the highest > priority supported by the user (root or otherwise) without going to > root; getting as close to real-time as possible? It's not. Linux only allows non-root processes to reduce its priority, not increase it, even for non-real-time priorities. Windows, however, allows it for non-real-time priorities. > > > > and how wine treats that scheduling (which I also don't). > > > > I don't see how that's relevant. Wine doesn't schedule threads, the > > Linux kernel does. > > He didn't say wine scheduled the threads. He said how wine *treats* > that scheduling. Which makes sense. You have to figure out how to sync > all the threads in an app, and then compare how to sync the different > apps to emulate the scheduling -- if you don't, then you end up with > desynced threads, garbling video, audio, keyboard handling, processing, > etctera. You're talking about synchronization mechanisms, not about scheduling. But now that you've mentioned it, I've been wondering for a while if Windows-model threading could be simulated by the wineserver by having it SIGSTOP-suspend low-priority threads when any high-priority threads are running, then SIGCONT-resume them whenever the high-priority threads gets into blocking waits? Should be doable in wineserver, but would it be a good idea?

Aug. 30, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Jacek Caban

Mike Hearn wrote: >Sounds like a bug to me. Refcounting differences can cause crashes and >memory leaks. > > > I'm sure there are no memory leaks. >>I don't thik it Wine's bug. Applications don't depend on this stuff and >>Wine's ref handling is correct. >> >> > >I'd be very surprised if there were no apps that depended on it, actually. >Given the number of crashes we've seen caused by refcount problems in >this part of the code, I'd say there definitely are. > > Application that depend on this will look like: pITypeInfo = ITypeLib_GetTypeLib(.....) (some stuff) //here application doesn't release ITypeLib if(ITypeInfo_Release(pTypeInfo) == 0) { /* something funny */ } Applications shouldn't do that. If we want to be full compatibile, ITypeInfo has to be created while application asks about ITypeInfo for the first time. It's not a big problem to do so but I don't think it's really important. Another solution would be to destroy ITypeinfo when ref == -1 and make initial value 0. It will keep the present handling of ITypeInfo in ITypeLib and, for application, it will look like Windows ref handling, but I don't know if it is acceptable. I also think that the way Wine does it is better - it just works faster and needes less memory. Jacek

Aug. 30, 2004