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

Fixing NTQueryVirtualMemory once and for all (Was: Borland C++ 5.5 fails on Link, any ideas?)

by Troy Rollo

On Mon, 1 Mar 2004 00:53, Jakob Eriksson wrote: > Somebody made a patch to support this in the past, but it was not > the proper way to do it. > It's got something to do with address space not being setup the same way > as on Windows as far as I can recall. Part of the problem is that there doesn't appear to be a "right" way to do it. I think one of the "hacks" just prevented NtQueryVirtualMemory from indicating there was a block of memory crossing the 0x80000000 boundary. Under Windows, it's only on the "Enterprise Edition" operating systems that such a result could be returned from NtQueryVirtualMemory, so this is perhaps not as incorrect as might otherwise be thought. On non EE NT systems, the user address space ends at 0x7fffffff. On Windows 95 series systems, there is a bunch of memory already allocated at 0x7fffffff and down, thus preventing there from ever being a single block of memory (allocated or unallocated) crossing this boundary. On the other hand, there's another problem with NtQueryVirtualMemory - it won't report memory that has been used by native executables and libraries, so that, for example, although the "wine-*" executables (and lots of .so files) take up memory, NtQueryVirtualMemory will not report this (unless this has changed recently). It is not out of the question that an application might use NtQueryVirtualMemory to look for a suitable block to allocate and then explicitly request that block, but find that they've actually hit the location where the WINE code is, so that the request fails. Now on Linux it would be possible to fix NtQueryVirtualMemory to report all allocations by grovelling at /proc/{pid}/maps, but this may not be possible on other systems, or where it is possible will require some other mechanism. So there's really two issues: 1. How should we deal with the 0x80000000 boundary anomaly? 2. Should we attempt to deal with the fact that NtQueryVirtualMemory doesn't report memory used by native executables and libraries?

Feb. 29, 2004

Re: Cross compiling Wine with MinGW

by Francois Gouget

On Wed, 25 Feb 2004, Hans Leidekker wrote: [...] > Same goes for the networking related dlls > (ws2_32, icmp and iphlpapi, vnb.vxd, wininet, wsock32). Shouldn't wininet build on ws2_32 and thus compile? I think it should be investigated... > msvcrt is close to building because what I saw was mostly header > clashes, which could be fixed with proper guards I think. Yes. msvcrt should compile too. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Feb. 29, 2004

Re: Borland C++ 5.5 fails on Link, any ideas?

by Michael Pyne

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29 February 2004 05:48 am, you wrote: > Try attaching to the process using winedbg: > > $ winedbg > .... > to get the backtraces of the different threads (there may only be one). > > See if any are stuck inside the heap code. If so try running with +heap > and remember to redirect to a file, as the resultant output will be large. Well, after fixing Gentoo's winedbg wrapper, I got the backtraces you requested (actually, the whole session, in case it helps). I couldn't tell if it was the heap code, all of the functions seem to be related to threading. I eventually ran --debugmsg +all, but still didn't see any heap-related output. :-/ I attached backtraces of both sessions of winedbg in case that's where +heap made a difference. I will try the patch that others suggested and report back on it's effect. Regards, - Michael Pyne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAQikxqjQYp5Omm0oRApsxAJ9dfQE2LwifCA54glwq8K9dBaoREgCgrT8C YOS1e/dfwnsHnzkb/kUOrh4= =iu3h -----END PGP SIGNATURE-----

Feb. 29, 2004

winxp version info

by Ivan Leo Murray-Smith

To avoid problems like this one that recently appeared in the newsgroup > Wine emulates XP which is good, > however upon attempting installation it springs up a message requiring > that i have my pc install SP1 it may be a good idea to set the winxp emulation to return the values of winxp sp1. Ivan.

Feb. 29, 2004

Re: [QUARTZ] Add implementation for IFilterMapper interface

by Christian Costa

Robert Shearman wrote: >Christian Costa wrote: > > >>>Ok. I had assumed devenum was complete, but obviously not. Does >>> >>> >>it spit out >> >> >>>any fixme's? >>> >>> >>> >>> >>No, it doesn't. >> >>In fact, Devenum enumerates entries in: >>1) HROOT\CLSID\{"clsid of categories"]\Instance >>2) HCURRENTUSER\Software\Microsoft\ActiveMovie\devenum >> >>For Direct Show filters, Devenum retreives filters registered with >>IFilterMapper and recreates entries in ....\devenum >>so when enumerating filters we get the IFilterMapper2 filters followed >>by IFilterMapper ones. >>I think this is the same for ICM and ACM filters. >> >>The current code only do 1 or 2 but not both at the same time. >> >> > >That makes a lot of sense. If I get some time I will implement this. > > > > Fine. :-) BTW, Windows seems to only update the devenum entries, if any, of the category eumerated. I don't think this is significant or not though... Bye, Christian

Feb. 29, 2004

Re: [QUARTZ] Add implementation for IFilterMapper interface

by Boaz Harrosh

Christian Costa wrote: > Fine. :-) > BTW, Windows seems to only update the devenum entries, if any, of the > category eumerated. > I don't think this is significant or not though... > > devenum entries are Just a cache that quartz is keeping. It is different between DirectShow versions. I have never figured out how/when it decides to refresh the cache but he does a good Job. So I suspect it is only an in-session cache that is refreshed every App load (first use). The main REG, that is standard, and that gets written by DllRegisterServer is the HKEY_CLASS_ROOT one.

Feb. 29, 2004

Re: Borland C++ 5.5 fails on Link, any ideas?

by Ove Kaaven

søn, 29.02.2004 kl. 03.35 skrev Michael Pyne: > I was wondering if there is a way I can help figure out what the problem is so > that we can get this bug fixed. You could always start with http://www.winehq.org/hypermail/wine-devel/2002/07/0102.html

Feb. 29, 2004

Re: Borland C++ 5.5 fails on Link, any ideas?

by Jakob Eriksson

On Sat, Feb 28, 2004 at 09:35:52PM -0500, Michael Pyne wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I've been trying to use the free Borland C++ 5.5 command-line tools to compile > some Windows applications for my school assignments. To be specific, I am in > a graphics class where every turnin has to be Windows. :-( > > Anyways, Borland C++ runs fine until it tries to link the program in question, > at which point ilink32.exe just sits there and eats CPU cycles. I've tried Somebody made a patch to support this in the past, but it was not the proper way to do it. It's got something to do with address space not being setup the same way as on Windows as far as I can recall. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

Feb. 29, 2004

RE: [QUARTZ] Add implementation for IFilterMapper interface

by Robert Shearman

Christian Costa wrote: > > >Ok. I had assumed devenum was complete, but obviously not. Does > it spit out > >any fixme's? > > > > > No, it doesn't. > > In fact, Devenum enumerates entries in: > 1) HROOT\CLSID\{"clsid of categories"]\Instance > 2) HCURRENTUSER\Software\Microsoft\ActiveMovie\devenum > > For Direct Show filters, Devenum retreives filters registered with > IFilterMapper and recreates entries in ....\devenum > so when enumerating filters we get the IFilterMapper2 filters followed > by IFilterMapper ones. > I think this is the same for ICM and ACM filters. > > The current code only do 1 or 2 but not both at the same time. That makes a lot of sense. If I get some time I will implement this. Thanks for the new patch, it looks good. Rob

Feb. 29, 2004

Re: Borland C++ 5.5 fails on Link, any ideas?

by Mike Hearn

On Sat, 28 Feb 2004 21:35:52 -0500, Michael Pyne wrote: > Anyways, Borland C++ runs fine until it tries to link the program in question, > at which point ilink32.exe just sits there and eats CPU cycles. I've tried > letting it run in case it was simply slower than normal due to the Wine > layer, but that doesn't seem to be case (I've let it sit for minutes at a > time). Hmm, I've used Delphi under Wine to compile apps just fine, but I guess the linkers share no code. Try attaching to the process using winedbg: $ winedbg > walk process .... > attach 0xf > walk thread > bt 0x9 > bt 0xwhatever to get the backtraces of the different threads (there may only be one). See if any are stuck inside the heap code. If so try running with +heap and remember to redirect to a file, as the resultant output will be large. > OS: Gentoo w/ Linux 2.6.3 (Wine was not compiled using NPTL, but OpenGL > support is in) NPTL is detected at runtime now. thanks -mike

Feb. 29, 2004