December 2002 - Wine-Devel - list.winehq.org

Re: Reducing the header maze (warning: long, unsuitable for children)

by Joerg Mayer

> Now, here's my question: couldn't we build a script to automatically fix > some of these problems? Imagine this pseudocode as a bash script, > makefile, or something along those lines: > > o gather and create a table of all .c -> .h and .h -> .h dependencies > > o for each file: > o one by one, try removing each reference to a header, and see if the > affected units still compile. If they all do, permanently > remove that reference, but remember it was there Last step: Add everything back for systems that are on a different os (xbsd, x86solaris, reactos) use older/newer glibcs whatever I've forgotten While the idea is good, I think a few people won't be happy with the result - and correctly so. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 3, 2002

Re: Compiling out the debug messages

by Jeff Smith

Bill, Unless I missed the whole point, you gave the answer before asking the question. ./configure should have been ./configure --disable-debug -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Dec. 3, 2002

Re: Reducing the header maze (warning: long, unsuitable for children)

by Alexandre Julliard

Greg Turner <gmturner007(a)ameritech.net> writes: > This should ensure that each header can actually be run through the > compiler all by itself -- that is, that it #include's any headers it > relies on to compile. We don't want that, it's not what Windows does. But yes, the whole obj_*.h stuff is a mess, that's why we should get rid of it all, and use the exact same include names and dependencies as Windows. Anything else is a nightmare to maintain. -- Alexandre Julliard julliard(a)winehq.com

Dec. 3, 2002

Re: Compiling out the debug messages

by Alexandre Julliard

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > I presume that if I look for example in the dlls/user/Makefile at this stage > I should see NO_DEBUG_MSGS and NO_TRACE_MSGS somewhere, but I don't. > > Please can someone explain how this is supposed to work and where I have > probably gone wrong. (e.g. where should I see the NO_DEBUG_MSGS) It should be in include/config.h. -- Alexandre Julliard julliard(a)winehq.com

Dec. 3, 2002

Re: wtypes.idl patch

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > You need to regenerate wtypes.h (and it's best to apply my latest widl > patch first). Should regenerated .h files be part of submitted patches in > the future? For me that's not necessary; maybe for others who would like to review the patch, but I doubt many people are going to review the auto-generated stuff anyway. Just do what's easiest for you. -- Alexandre Julliard julliard(a)winehq.com

Dec. 3, 2002

Reducing the header maze (warning: long, unsuitable for children)

by Greg Turner

I'm working on Ove's comhdr1 & comhdr2 patches. So far, so good, btw -- I have it compiling against yesterday's CVS (recent commits are not folded in yet). I'll submit after I kick the tires a bit and make sure everything seems to be working (otherwise, I'll probably post it here and ask for help). Anyhow, this project has served to remind me just how deep, and how confusing, the maze of wine headers can really be. It's clear to me that lots of header inclusions are just historical remnants, that no longer serve any purpose, and, conversely, that many implicit header dependencies exist that happen to be hidden, and missing (i.e., X.h needs Y.h, but all references to X.h happen to occur after Y.h was already included, so there's no compile failure). A third kind of unnecessary (but arguably correct, in many cases) dependency is created when an include file is pulled in that is already pulled in by some prior include... This negatively affects wine development because (a) it's hard to change things, the headers break too easily, and (b) the make process rebuilds stuff that doesn't need rebuilding when things change (unavoidable, to an extent, of course, but perhaps it's too much right now). Now, here's my question: couldn't we build a script to automatically fix some of these problems? Imagine this pseudocode as a bash script, makefile, or something along those lines: o gather and create a table of all .c -> .h and .h -> .h dependencies o for each file: o one by one, try removing each reference to a header, and see if the affected units still compile. If they all do, permanently remove that reference, but remember it was there at this point we should have approximately the minimum number of header references in the code to compile wine. But some of the header references we eliminated were probably legitimate dependencies, event though we compiled OK, as mentioned above... so now we: o for each header, try to compile a "Hello World" which includes just that header file. If it fails (or even generates warnings): o for each header reference that was eliminated, try putting it back in. If still failing, try different combinations (this could become a really nasty computation with all kinds of permutations possible, but if certain simple tricks don't work, we can just give up). o if we couldn't find any way to fix it, mark the header for human review. This should ensure that each header can actually be run through the compiler all by itself -- that is, that it #include's any headers it relies on to compile. Finally... o A human picks up the pieces and fixes the breakages o The whole heuristic can start over, now, until the results start to look repetitive or trivial... I can think of some reasons this might not work out so well as I might hope, but... what do you guys think? is such a test meaningful? Is there some tool that already automates this type of investigation, or some better way to achieve the same thing? Would it be, in your opinion, too much work for too little benefit? FWIW, I can probably think of more enjoyable tasks to spend my time on... but OTOH I am really tired of waiting for wine to build on my aging pc -- anything that could speed up the build process would probably save me some from some discomfort, and others too. (At least there's no C++ in there; I'm rebuilding my system lately (I killed it over the holidays messing with glibc), and building stuff like KDE, mozilla, sun-java, and openoffice makes wine look pretty darn svelte! g++ 3.2.1 just crawls; the more "object oriented" the source is, the longer it seems to take to compile... :( ) Just "thinking out loud," probably a terrible idea, but let me know what you think, anyways... -- gmt p.s., I was kidding about unsuitable for children... but then, not sure why children should want to read this -- or adults, for that matter :P

Dec. 3, 2002

Compiling out the debug messages

by Medland, Bill

I know I don't know what I am doing, but.. The documentation says that to compile out the trace, warning and fixme messages I should specify --disable-debug when running configure. So I try ./configure make depend make <build an rpm and install it on another machine> <run wine> <stare at the fixme messages, swear etc.> I presume that if I look for example in the dlls/user/Makefile at this stage I should see NO_DEBUG_MSGS and NO_TRACE_MSGS somewhere, but I don't. Please can someone explain how this is supposed to work and where I have probably gone wrong. (e.g. where should I see the NO_DEBUG_MSGS) Bill Medland

Dec. 3, 2002

How to find out if file is loaded?

by Klaus Niederkrueger

Hello, I would like to know the following: I start some program with "wine -debugmsg +file" and I get quite a lot of times trace:file:CreateFileW L"tiles\\TS01.bmp" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x80 trace:file:CreateFileW returning 0x58 trace:file:_lopen ('tiles\TS01.BMP',0000) trace:file:CreateFileW L"tiles\\TS01.BMP" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 trace:file:CreateFileW returning 0x58 trace:file:ReadFile 0x58 0x406d2690 14 0x406d264c (nil) trace:file:ReadFile 0x58 0x406d2668 40 0x406d264c (nil) trace:file:ReadFile 0x58 0x406d26a4 1024 0x406d264c (nil) trace:file:_lclose handle 88 So it seems to me that the file tiles\TS01.BMP is loaded, but when I use "ltrace wine ..." I don't find any output regarding this file. Why is that? Thanks for any answer Klaus

Dec. 3, 2002

Re: Direct3D8 regression/bug

by Sylvain Petreolle

NVidia and its bugged binary shit... I have the same issue. Workaround : use synchronous mode. Note : it crashes even with mplayer.exe !! This proves its not related to last patches. > Perhaps the problem is related to the OpenGL drivers. I'm using > Nvidia's > OpenGL drivers (1.0-3123). > > I hope this helps a bit, > > Roderick Colenbrander > > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 3, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dan Kegel

Alexandre Julliard wrote: > Dan Kegel <dank(a)kegel.com> writes: > > >>Wouldn't it suffice to compile the Wine DLLs as PE? >>Then you wouldn't need to link binaries of different >>types together. > > But then you wouldn't be able to use ELF libraries from Wine DLLs, > which means you would need to recompile all the system libraries as PE > too. Oh. (Hey, that might be an advantage... then you could limit which system libraries wine programs used by just not recompiling them :-) - Dan

Dec. 3, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Wouldn't it suffice to compile the Wine DLLs as PE? > Then you wouldn't need to link binaries of different > types together. But then you wouldn't be able to use ELF libraries from Wine DLLs, which means you would need to recompile all the system libraries as PE too. -- Alexandre Julliard julliard(a)winehq.com

Dec. 3, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dan Kegel

Alexandre Julliard wrote: > Dan Kegel <dank(a)kegel.com> writes: >>Alexandre Julliard wrote: >> >>>Yes, it would be possible to resolve imports directly through the ELF >>>tables and avoid our own separate import mechanism; basically this >>>would be a PE-aware ld.so. It's quite a bit of work though, and >>>portability is an issue. In any case it's for after 1.0 IMO. >> >>Portability to NetBSD shouldn't be an issue, as >>they seem to have already implemented it :-) See >>http://chiharu.haun.org/peace/ > > As far as I can tell, this is only a PE loader, so you need to > cross-compile everything as PE dlls. What we would want for Wine is an > ELF loader that can also load PE and seamlessly link binaries of both > types together. Wouldn't it suffice to compile the Wine DLLs as PE? Then you wouldn't need to link binaries of different types together. - Dan

Dec. 3, 2002

WIN_FindWndPtr

by Dustin Navea

Hey just out of curiosity, now that we are working toward v1.0 (not like we werent before) shouldnt this error be changed over to a fixme? It doesnt seem like all that much needs to be done (aside from marshalling and whatnot). Just wondering if we were planning on fixing it before v1.0, as it would be a big boon to have it still there in v1.0... -Dustin

Dec. 3, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Alexandre Julliard wrote: > > Yes, it would be possible to resolve imports directly through the ELF > > tables and avoid our own separate import mechanism; basically this > > would be a PE-aware ld.so. It's quite a bit of work though, and > > portability is an issue. In any case it's for after 1.0 IMO. > > Portability to NetBSD shouldn't be an issue, as > they seem to have already implemented it :-) See > http://chiharu.haun.org/peace/ As far as I can tell, this is only a PE loader, so you need to cross-compile everything as PE dlls. What we would want for Wine is an ELF loader that can also load PE and seamlessly link binaries of both types together. -- Alexandre Julliard julliard(a)winehq.com

Dec. 3, 2002

Re: Painting message order?

by Paul Millar

On 3 Dec 2002, Mike Hearn wrote: > It sends WM_PAINT, the does the NCPAINT thing which seems to be do do > with window borders, and then some ERASEBKGND messages come from > somewhere. I have a sneaking suspicion that the background gets erased > after it's painted and not before, but that's a total shot in the dark > and the absence of flicker kind of makes my theory look not so strong. Well, speaking in ignorance (I freely admit to it ;) it *could* have something to do with problem 2 of: http://www.winehq.com/hypermail/wine-devel/2002/11/0803.html corruption when dialogue boxes are moved around. I tried it again today (with cvs a few days old) and the problem still exists. ---- Paul Millar

Dec. 3, 2002

Re: HTML Help and IWebBrowser status

by Joerg Mayer

On Tue, Dec 03, 2002 at 04:46:00AM -0600, Ender wrote: > That brings me to my other WIP, de-QT'ing KHTML and turning it into a > working browser implementation for WINE. So far this is actually coming > along quite well, and besides a few points it definatly makes an effective > browser and IE compatability seems to generally be good enough to keep the > majority of IWebBrowser using applications happy. I've since abandoned my > earlier hopes to keep the changes minor (in order to make it easier to > backport fixes from the main KDE cvs), simply because it was making the > code quite messy. > > Hopefully I'll have some beta code ready in a week or two, depending on > how my free time goes. I just told Dirk (one of the people putting quite a lot of time into kde) about your work and he told be the following (translated from German): > > lustiges Projekt: "de-QT'ing KHTML"... > > erzähl ihm mal von kdenox - im prinzip kdelibs dropins mit limitierter > funktionalität für khtml only. [Tell him about kdenox - which is basically a kdelibs replacement with limited functionality for khtml only] > Ausserdem gibt es then Atheos port, der einfach die (wenigen) verwendeten Qt > Klassen durch eigene Implementierung ersetzt und somit einen fast > unmodifizierten khtml tree übernehmen kann. [Then there is the Atheos port, which simply replaces the (few) used Qt classes by its own implemetation and is thus able to use an almost unmodified khtml tree] Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 3, 2002

Re: HTML Help and IWebBrowser status

by Dimitrie O. Paun

On December 3, 2002 05:46 am, Ender wrote: > Currently the HTML Help viewer requires an IWebBrowser interface, and only > really works with an Internet Explorer installation - so I don't believe > it should be commited into WINE proper yet. We don't want applications in > our own CVS that require native dlls :) I think you should submit it like this. IWebBrowser is a standard Win interface that we are going to support, so there's no reason for winhelp to make use of it. The fact that we don't have our own _implementation_ doesn't change a thing. They are perfectly separate issues. And in any event, if HTML Help works with IE, it's better than nothing, as it gives people a chance of working with it, test it out, even submit patches against it. :))) -- Dimi.

Dec. 3, 2002

Painting message order?

by Mike Hearn

Hi all, My beloved SVG plugin broke again :( For some reason it's not repainting properly, in fact, the only way I can force it to repaint when running in wine desktop, internet explorer kiosk mode (ie it fills a window) is by toggling high quality/low quality which controls antialiasing. trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT sent from self wp=00000001 lp=00000000 trace:message:SPY_EnterMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] wp=00000001 lp=00000000 trace:message:SPY_ExitMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] returned 00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT returned 00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND sent from self wp=000008a8 lp=00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND returned 00000001 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT returned 00000000 That's a message trace of the paint cycle (when I make it paint by minimizing the wine window for instance. It sends WM_PAINT, the does the NCPAINT thing which seems to be do do with window borders, and then some ERASEBKGND messages come from somewhere. I have a sneaking suspicion that the background gets erased after it's painted and not before, but that's a total shot in the dark and the absence of flicker kind of makes my theory look not so strong. I did some traces with +gdi as well, but it wasn't very helpful. There were lots of GetObjPtr and locking methods called, but I didn't see any actual obviously drawing related calls. There was 1 warning: GetObjPtr was called at one point with nil. What does this mean? I can't find any documentation about GetObjPtr on google. I'll look at the sources later to see if I can figure out what's wrong. Anyway, my final question is : is there a way to alter the colour with which the background is erased? Even if it screws up rendering elsewhere just for debugging i'd like to see if I can make it display as anything *except* offwhite. If so then it confirms my theory. Or are those messages processed by the plugin itself? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 3, 2002

Re: bug (regression) in ddraw/d3d

by Lionel Ulmer

> It turns out that FF8Config calls IDirect3DImpl_2_EnumDevices (2 times) > but then calls GL_IDirect3DImpl_3_CreateDevice. Could you send me a +ddraw trace of the problem happening ? If this is what I think, the fix will be very easy to do and simplify our code a little bit. Basically, we have one GUID per D3DDevice revision... And according to what you tell, this must be wrong => one just have to change the code to always report only one GUID and after do the dynamic COM cast according to the interface calling the function. I will see what I can do this evening. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 3, 2002

Re: HTML Help and IWebBrowser status

by Mike Hearn

Hi Roderick, This was discussed about a month ago, so see the archives for more info. Basically there was a Gecko vs KHTML debate, with Ender (who is writing the code) eventually settling on KHTML for the following reasons: - Simple - No XPCOM dependancies - Could be more easily hacked to add IE compatability (and was more IE compatible to start with) - Small, good for embedding, relatively fast (gecko embedding is huge) - Would be possible to include in the Wine CVS tree as opposed to Gecko which is probably almost as big as Wine itself. There are obviously some pros for Mozilla as well, but the things that make Moz a good choice for a web browser don't apply so much to a good replacement for the WebBrowser control. thanks -mike On Wed, 2002-12-04 at 12:50, Roderick Colenbrander wrote: > Hi, > > Why not use Mozilla instead of KHTML? There exists an opensource activex > control based on mozilla which is fully compatible with IWebBrowser. The only > difference is that the name is MozillaBrowser. There's even a little tool > that can convert a IWebBrowser app to a MozillaBrowser app by changing the > CLSID. Likely this control can be somehow recompiled using winelib and native > mozilla. > > Check this page: > http://www.iol.ie/~locka/mozilla/mozilla.htm > > Roderick Colenbrander > > On Tuesday 03 December 2002 11:46, Ender wrote: > > Hi all, > > I'm just posting a quick update on my various WINE work for those > > intrested. > > > > I currently have a working HTML Help viewer, which seems to work pretty > > well on everything I've tested so far. It does however need some more work > > to conform to the way the real HTML Help system works in Windows (eg, I > > havn't written an ActiveX control for it yet). > > > > Currently the HTML Help viewer requires an IWebBrowser interface, and only > > really works with an Internet Explorer installation - so I don't believe > > it should be commited into WINE proper yet. We don't want applications in > > our own CVS that require native dlls :) > > > > That brings me to my other WIP, de-QT'ing KHTML and turning it into a > > working browser implementation for WINE. So far this is actually coming > > along quite well, and besides a few points it definatly makes an effective > > browser and IE compatability seems to generally be good enough to keep the > > majority of IWebBrowser using applications happy. I've since abandoned my > > earlier hopes to keep the changes minor (in order to make it easier to > > backport fixes from the main KDE cvs), simply because it was making the > > code quite messy. > > > > Hopefully I'll have some beta code ready in a week or two, depending on > > how my free time goes. > > > > I have a few questions however, mostly I'd like to hear from Alexandre > > on whether he'll consider accepting this into CVS. A working IWebBrowser > > implementation is, in my opinion, a must - and my HTML Help work does > > require it - but there are a few points to consider: > > > > - It is C++. So far, all of WINEs dlls are plain C. Is this really a > > rule, or just a result of the current areas of focus? I can't really > > de-C++ khtml and co, but I'm unsure as to whether it's okay to add a > > requirement for a working C++ compile environment on core dll's. > > > > - It is somewhat big, several megabytes of new code. Hopefully I can chop > > it down after removing a lot of the unneeded KDE and QT code I currently > > have #ifdef'ed and commented out. > > > > Cheers, > > Ender > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 3, 2002

Re: Direct3D8 regression/bug

by Roderick Colenbrander

After some more testing I found the problem. I only don't know how to fix it since I don't have any OpenGL experience yet. It seems that d3d8 only works in 24bit colours and that 16bit is unsupported at the moment. On Wednesday 04 December 2002 18:42, Roderick Colenbrander wrote: > Hi, > > Just to see how well Wine's Direct3D8 support is working, I played with > some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades > used when he started Wine's Direct3D8 implementation) A few weeks ago all > those demo's worked. Perhaps some things where not rendered correctly but > they worked. > > A few days ago I rechecked those demo's but now all d3d8 apps I try crash. > Immedeately winedbg is launched. The app seems to crash in libGL.so.1. > > Here's the error with a backtrace: > > Unhandled exception: page fault on read access to 0x00000008 in 32-bit code > (0x40bf4a06). > In 32-bit mode. > 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax > Wine-dbg>bt > Backtrace: > =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) > > Lionel suggested that his OpenGL patches may have caused this problem. He > had the same crashes on his pc. I reversed his patches but it still had > problems. (perhaps I made some misstakes somewhere ..) > > Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's > OpenGL drivers (1.0-3123). > > I hope this helps a bit, > > Roderick Colenbrander

Dec. 3, 2002

HTML Help and IWebBrowser status

by Ender

Hi all, I'm just posting a quick update on my various WINE work for those intrested. I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet). Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :) That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy. Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes. I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider: - It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's. - It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out. Cheers, Ender

Dec. 3, 2002

Re: Installing Internet Explorer without windows

by Alberto Massari

Hi Boris, At 16.06 27/11/2002 -0600, Boris wrote: >I just tried installing IE 5.5 from setup.exe and it never seems to >install properly without windows being installed or modifying files. It >would be nice to install Internet Explorer without patching anything. I >hope more people work towards that. I tried to do the same, and now IE 5.5 is (almost) working. BTW, I needed to emulate the NT plaftorm, so I first tried specifying Win2k in the config file; unfortunately the installer in this case only installs a bunch of files, skipping the ones it known are already shipped with Win2k (most notably, iexplore.exe is missing :-( ). So I settled for emulating Win NT 4.0. Also, I changed the DllOverrides section of the config file to only have "setupapi" = "builtin" "*" = "native, builtin" This is the list of hacks I had to do, with the possible resolution: - the installer requires Win NT 4.0 SP6a; it turned out that the check on the presence of SP6a (vs SP6) is this key in the HKLM branch of the registry: Software\Microsoft\Windows NT\Current Version\Hotfix\Q246009 "Installed"="1" - the installer assumes the presence of rundll32.exe in c:\windows (now it's part of Wine :-) so this is not an issue anymore) - the installer needs a copy of cabinet.dll from a Windows installation (someone is working on a builtin version, so this will not be an issue) - after the installation has completed, go through the registry and do the rename operations found in the System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations key and run all the commands found in the Software\Microsoft\Windows\CurrentVersion\RunOnce branch (someone is working on a "reboot" feature that will do this automatically, so this will not be an issue) - now you can run IE, but it will crash shortly after having displayed the home page; I fixed this by using a native version of ole32.dll and rpcrt4.dll coming from an NT 4.0 installation. This could be probably avoided by completing the implementations of builtin dlls like urlmon.dll, but it's too early to say that... Even with the 2 dlls in place, pictures are not displayed.... Hope this helps, Alberto

Dec. 3, 2002

Direct3D8 regression/bug

by Roderick Colenbrander

Hi, Just to see how well Wine's Direct3D8 support is working, I played with some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades used when he started Wine's Direct3D8 implementation) A few weeks ago all those demo's worked. Perhaps some things where not rendered correctly but they worked. A few days ago I rechecked those demo's but now all d3d8 apps I try crash. Immedeately winedbg is launched. The app seems to crash in libGL.so.1. Here's the error with a backtrace: Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x40bf4a06). In 32-bit mode. 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) Lionel suggested that his OpenGL patches may have caused this problem. He had the same crashes on his pc. I reversed his patches but it still had problems. (perhaps I made some misstakes somewhere ..) Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's OpenGL drivers (1.0-3123). I hope this helps a bit, Roderick Colenbrander

Dec. 3, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> With gcc 3.2? That compiler optimizes the jmp away in an if statement, > apparently assuming that the "if" clause is executed much more often. > The "else" clause, OTOH, jmp's to the end of the subroutine and jumps > back afterwards. Thus if the compiler guesses wrongly, the CPU'll have > to do two more jmp's per loop, with possible instruction cache miss. > Hard for me to believe that'll be a speed improvement on any CPU. If the > compiler guesses right, 1 jmp will be saved per loop. Actually 2.95.3 which doesn't seem to want to generate a loop with only one taken branch. Something must make the conditional forward jump be faster than the unconditional one. And yes, I couldn't believe it either :-) David -- David Laight: david(a)l8s.co.uk

Dec. 3, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dan Kegel

Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> I am not sure but I suspect the compiler generates indirect accesses for >> these. I'm not sure what gcc does for variables exported from another >> library. It seems like it has to be doing something similar. So if we >> could get access to that indirection we may be able to make things work. > > Yes, it would be possible to resolve imports directly through the ELF > tables and avoid our own separate import mechanism; basically this > would be a PE-aware ld.so. It's quite a bit of work though, and > portability is an issue. In any case it's for after 1.0 IMO. Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/ http://groups.google.com/groups?selm=20020516061929.5DA943C110%40gabi-n.hau… et seq. http://www.freebsd.org/cgi/man.cgi?query=compat_pecoff&manpath=NetBSD+1.6 - Dan

Dec. 3, 2002

Re: strcat+strcat+strcat == baaad

by Martin Wilck

Am Mon, 2002-12-02 um 20.15 schrieb David Laight: > Actually I don't have glibc - I'm running netbsd not linux. > Netbsd might benefit from faster strxxx routines. Can't you use an optimized glibc on NetBSD? > OTOH the times are very dependant on the cpu model! > My slotA athlon 700 executes my str_add() faster the > way I coded it - I tried the other order and it sucked. With gcc 3.2? That compiler optimizes the jmp away in an if statement, apparently assuming that the "if" clause is executed much more often. The "else" clause, OTOH, jmp's to the end of the subroutine and jumps back afterwards. Thus if the compiler guesses wrongly, the CPU'll have to do two more jmp's per loop, with possible instruction cache miss. Hard for me to believe that'll be a speed improvement on any CPU. If the compiler guesses right, 1 jmp will be saved per loop. > Of course you can use the same tricks as glibc does to speed > up your own variant of the copy routine. I am not talking what you or I could or couldn't do. I am just saying Wine should rely on glibc for these things, and not try to outwit those who're doing these things all the time. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Dec. 3, 2002

Re: bug (regression) in ddraw/d3d

by J. Hoffmann

On Tuesday 03 December 2002 04:09, Lionel Ulmer wrote: > > Im still trying to find the bug (and then a fix :-), but it would help > > me a lot, if someone could tell me where the > > GL_IDirect3DImpl_3_CreateDevice gets called from. > > Well, the real question is to wonder why the application requests to create > a Direct3DDevice2 and not a D3DDevice3 as it should... It turns out that FF8Config calls IDirect3DImpl_2_EnumDevices (2 times) but then calls GL_IDirect3DImpl_3_CreateDevice. Now, I don't know yet why it calls the D3D2 for Enum and D3D3 for CreateDevice, but it explains why it didn't crash in the cvs version from 11/24/02: the patch which introduced the crash contains: - XCAST(EnumDevices) Thunk_IDirect3DImpl_2_EnumDevices, + XCAST(EnumDevices) GL_IDirect3DImpl_2_EnumDevices, if I change "GL_" back to "Thunk_" in the current cvs so that the IDirect3DImpl gets casted to the Direct3D3 interface, then the program no longer crashes. (But that does not say much, since it only tests for features and doesn't really use D3D) -- Jens

Dec. 2, 2002

Re: Wine 0.9 TODO v0.6

by Dimitrie O. Paun

On December 2, 2002 03:12 pm, Z_God wrote: > First, would it be an idea to say at least *insert any number* of Windows > apps should be working perfectly with Wine before it is called 0.9? > For example, we at least want to have 200 known perfectly working apps. This is the Gold list we are talking about. So yeah, we are doing that, but we are considering 30-40 apps, not 200. > And why not start at version 0.6 or something and calling Wine beta > software instead of alpha when these TODOs are done? Long historical reasons. Been discussed many times. -- Dimi.

Dec. 2, 2002

Re: HTML Help and IWebBrowser status

by Roderick Colenbrander

Hi, Why not use Mozilla instead of KHTML? There exists an opensource activex control based on mozilla which is fully compatible with IWebBrowser. The only difference is that the name is MozillaBrowser. There's even a little tool that can convert a IWebBrowser app to a MozillaBrowser app by changing the CLSID. Likely this control can be somehow recompiled using winelib and native mozilla. Check this page: http://www.iol.ie/~locka/mozilla/mozilla.htm Roderick Colenbrander On Tuesday 03 December 2002 11:46, Ender wrote: > Hi all, > I'm just posting a quick update on my various WINE work for those > intrested. > > I currently have a working HTML Help viewer, which seems to work pretty > well on everything I've tested so far. It does however need some more work > to conform to the way the real HTML Help system works in Windows (eg, I > havn't written an ActiveX control for it yet). > > Currently the HTML Help viewer requires an IWebBrowser interface, and only > really works with an Internet Explorer installation - so I don't believe > it should be commited into WINE proper yet. We don't want applications in > our own CVS that require native dlls :) > > That brings me to my other WIP, de-QT'ing KHTML and turning it into a > working browser implementation for WINE. So far this is actually coming > along quite well, and besides a few points it definatly makes an effective > browser and IE compatability seems to generally be good enough to keep the > majority of IWebBrowser using applications happy. I've since abandoned my > earlier hopes to keep the changes minor (in order to make it easier to > backport fixes from the main KDE cvs), simply because it was making the > code quite messy. > > Hopefully I'll have some beta code ready in a week or two, depending on > how my free time goes. > > I have a few questions however, mostly I'd like to hear from Alexandre > on whether he'll consider accepting this into CVS. A working IWebBrowser > implementation is, in my opinion, a must - and my HTML Help work does > require it - but there are a few points to consider: > > - It is C++. So far, all of WINEs dlls are plain C. Is this really a > rule, or just a result of the current areas of focus? I can't really > de-C++ khtml and co, but I'm unsure as to whether it's okay to add a > requirement for a working C++ compile environment on core dll's. > > - It is somewhat big, several megabytes of new code. Hopefully I can chop > it down after removing a lot of the unneeded KDE and QT code I currently > have #ifdef'ed and commented out. > > Cheers, > Ender

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Dan Kegel

Paul Millar wrote: > For the record, Gerard's writeup on how to do CVS regression hunting is > available here: > > http://cvs.winehq.com/cvsweb/wine/documentation/cvs-regression.sgml Thanks! I guess http://www.winehq.org/download/ should link to http://www.winehq.org/Docs/wine-devel/cvs-regression.shtml at the end of the section "Getting Wine from CVS", maybe? - Dan

Dec. 2, 2002

Re: bug (regression) in ddraw/d3d

by Lionel Ulmer

> Im still trying to find the bug (and then a fix :-), but it would help > me a lot, if someone could tell me where the GL_IDirect3DImpl_3_CreateDevice > gets called from. Well, the real question is to wonder why the application requests to create a Direct3DDevice2 and not a D3DDevice3 as it should... For that, look at any enumeration function called before this and check that it returns the right interface. Because, well, the application cannot just invent this GUID, it needs to get it from somewhere. Check also your registry (so that maybe if there was a bug once, you maybe 'polluted' your registry with an old and wrong GIUD that now makes the application crash). Anyway, not really able to debug right now (I am 'roaming' and on Win2K right now as I have no net access on Linux). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Michal Janusz Miroslaw

On Mon, 2 Dec 2002, Francois Gouget wrote: > Other observations: > * my naive strcpy/strcat implementation seems more efficient than the > one in the glibc! That's pretty weird. If you have glibc from binary package compiled with optimizations for other processor that you have, it is possible. > * cpycat is much more efficient in this type of scenario. That's not > very surprising of course. Why does the C library have such braindead > functions as strcpy and strcat? Since we are talking about catenating strings only (no %d and family), then I would suggest combining speed of cpycat (in glibc there's stpcpy) and ease of use of sprintf and use something like that: #include <stdarg.h> char *strpcpymore(char *buf, ...) { const char *p; va_list ap; va_start(ap, buf); while ((p = va_arg(ap, const char *))) buf = stpcpy(buf, p); va_end(ap); return buf; } Then we could write: strpcpymore(buffer, "path", "/", "file", ".", "ext", NULL); And make everybody happy. Michal Miroslaw

Dec. 2, 2002

bug (regression) in ddraw/d3d

by J. Hoffmann

Hi, I wanted to play around with the improvements to ddraw/d3d, and tried to run Final Fantasy 8 which worked before in software rendering mode with the native direct music dlls. Unfortunately FF8Config (and FF8 itself) crashes now with the recent changes. The patch which introduces the regression is: http://www.winehq.com/hypermail/wine-cvs/2002/11/0231.html (cvs version just before the patch works, applying the patch results in a pagefault.) The problem appears to be that GL_IDirect3DImpl_3_CreateDevice gets called with an rclsid = IID_D3DDEVICE2_OpenGL instead of IID_D3DDEVICE3_OpenGL, so that an D3DDevice2 gets created for the Direct3D3 interface (which results in a pagefault later, when the device is used.) See traces below. Im still trying to find the bug (and then a fix :-), but it would help me a lot, if someone could tell me where the GL_IDirect3DImpl_3_CreateDevice gets called from. (I see that it is an entry in the vtable but haven't found the function there it gets gets called yet..) regards, Jens Hoffmann ** trace for the old version: (cvs 11/24/02 16:14:09 CST) ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4568)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x40852 3cc) trace:ddraw:direct3d_create creating implementation at 0x403a5380. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a5384. trace:ddraw:Main_DirectDraw_AddRef (0x403a4568)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a5380/0x403a5384)->({31416d44-86ae-11d2-822d-a8d53187cafc},0x403a4e28,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4e28, d3d = 0x403a5380 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x80a0260) trace:ddraw:d3ddevice_create setting current context err:ddraw:set_context This function should not be called in the current state of the code... trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a5770. trace:ddraw:create_device_helper returning OpenGL D3DDevice3 (nil) trace:ddraw:Thunk_IDirect3DDeviceImpl_3_EnumTextureFormats (0x403a5774)->(0x405393,0x42e014) thunking to IDirect3DDevice7 interface. ... ** trace for cvs head: ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4540)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x408523cc) trace:ddraw:direct3d_create creating implementation at 0x403a54b0. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a54b4. trace:ddraw:Main_DirectDraw_AddRef (0x403a4540)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a54b0/0x403a54b4)->({31416d44-86ae-11d2-822d-a8d53187cafb},0x403a4f18,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4f18, d3d = 0x403a54b0 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x809f818) trace:ddraw:d3ddevice_create setting current context trace:ddraw:set_context glxMakeCurrent 0x80690c0, 62914563, 0x809f818 trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a55e8. trace:ddraw:create_device_helper returning OpenGL D3DDevice2 0x403a55f0 trace:ddraw:Thunk_IDirect3DDeviceImpl_2_NextViewport (0x403a55f0)->(0x405393,0x42cb40,00000000) thunking ...

Dec. 2, 2002

Re: Programs to test D3D

by Christian Costa

J C wrote: > Hi all, > > I've been following the recent work on D3D and decided I would give a > couple of > benchmarks/demos I had around a go. Pleasantly I found that they > actually start up > now and display some stuff on screen! Before the recent patches they > would fail > completely when starting the actual D3D stuff. I'm not sure if you're > aware of these programs or not but I figured I would pass on the URLs > to you as they might be of help. > > This first is a demo called Bleam: > http://www.bluespoon.com/banjoh/ > This page has a binary of the demo and source code as well. > Try the following patch (an awful hack layered upon the latest D3D patches) and run Bleam, you will be interested..... ;-) Christian PS: I will do something soon to handle texturing in a cleaner way Index: mesa.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/mesa.c,v retrieving revision 1.9 diff -u -r1.9 mesa.c --- mesa.c 21 Nov 2002 21:04:16 -0000 1.9 +++ mesa.c 2 Dec 2002 21:50:40 -0000 @@ -55,6 +55,8 @@ } else { IDirect3DTextureGLImpl *gl_tex = (IDirect3DTextureGLImpl *) tex; + IDirect3DTexture2_Load((LPDIRECT3DTEXTURE2)tex,(LPDIRECT3DTEXTURE2)tex); + glEnable(GL_TEXTURE_2D); /* Default parameters */ glBindTexture(GL_TEXTURE_2D, gl_tex->tex_name); @@ -144,6 +146,9 @@ case D3DRENDERSTATE_SRCBLEND: /* 19 */ switch ((D3DBLEND) dwRenderState) { + case D3DBLEND_ONE: + rs->src = GL_ONE; + break; case D3DBLEND_SRCALPHA: rs->src = GL_SRC_ALPHA; break; @@ -155,6 +160,9 @@ case D3DRENDERSTATE_DESTBLEND: /* 20 */ switch ((D3DBLEND) dwRenderState) { + case D3DBLEND_ONE: + rs->dst = GL_ONE; + break; case D3DBLEND_INVSRCALPHA: rs->dst = GL_ONE_MINUS_SRC_ALPHA; break;

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> Other observations: > * my naive strcpy/strcat implementation seems more efficient than the > one in the glibc! That's pretty weird. Probably because the glibc routines are heavily optimised for long strings. I did a load of experiments with different versions of memcpy, the instruction setup cost of 'rep movsl' is such that it is faster not to use it for copies of (IIRC) 180 bytes on my athlon. The 'rep movsb' used to copy the trailing bytes is definitely wasteful. > * cpycat is much more efficient in this type of scenario. That's not > very surprising of course. Why does the C library have such braindead > functions as strcpy and strcat? Probably goes back into the annals of Unix history. My guess is that the return value wasn't defined, but happened to be the destination buffer address on one of the first implementations. Some code used the fact and no one dared change it.... Probably similar to asking why the priority of | and == are backwards. (K/R didn't want to change any code when they invented ||.) David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

W->A calling and 32->16 calling

by Rolf Kalbermatter

While going through the shell32 sources I found several issues with respect of this and at least one of them I couldn't find in the Janitorial list. ExtractIconW calls ExtractIconA which is mentioned but ExtractIconA calls InternalExtractIcon16 which is a 16 bit undocumented but exported function. I guess this should also go into the 32->16bit list somehow. I have worked on some fix for this but have to admit that this seems a little bit tricky. InternalExtractIcon16 also tries to open the file name with LoadLibrary16 so if it is a 16bit DLL the requested icons will still be extracted. PrivateExtractIcon and friends which are similar but also can handle negative icon indices which indicates that it should be treated as icon identifier, do as far as I can see not deal with 16bit libraries (they ultimatively call ICO_ExtractIconExW. This of course poses the question if the 32bit function ExtractIcon is supposed to return icons for 16bit libraries and if so, ExtractIconEx may actually also be required to do so. Below is a first attempt for a patch which does most probably not try to load resources from 16bit libraries yet. Also how about going with InternalExtractIcon16? Any comments to this? Rolf Kalbermatter Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.108 diff -u -r1.108 shell32_main.c --- dlls/shell32/shell32_main.c 21 Nov 2002 23:56:42 -0000 1.108 +++ dlls/shell32/shell32_main.c 2 Dec 2002 20:43:23 -0000 @@ -544,19 +544,18 @@ * FIXME * if the filename is not a file return 1 */ -HICON WINAPI ExtractIconA( HINSTANCE hInstance, LPCSTR lpszExeFileName, - UINT nIconIndex ) -{ HGLOBAL16 handle = InternalExtractIcon16(HINSTANCE_16(hInstance),lpszExeFileName,nIconIndex, 1); - TRACE("\n"); - if( handle ) - { - HICON16* ptr = (HICON16*)GlobalLock16(handle); - HICON16 hIcon = *ptr; - - GlobalFree16(handle); - return HICON_32(hIcon); - } - return 0; +HICON WINAPI ExtractIconA(HINSTANCE hInstance, LPCSTR lpszFile, UINT nIconIndex) +{ + HICON ret; + INT len = MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, NULL, 0); + LPWSTR lpwstrFile = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + + TRACE("%p %s %d\n", hInstance, lpszFile, nIconIndex); + + MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, lpwstrFile, len); + ExtractIconW(hInstance, lpwstrFile, nIconIndex); + HeapFree(GetProcessHeap(), 0, lpwstrFile); + return ret; } /************************************************************************* @@ -564,18 +563,21 @@ * * FIXME: if the filename is not a file return 1 */ -HICON WINAPI ExtractIconW( HINSTANCE hInstance, LPCWSTR lpszExeFileName, - UINT nIconIndex ) -{ LPSTR exefn; - HICON ret; - TRACE("\n"); +HICON WINAPI ExtractIconW(HINSTANCE hInstance, LPCWSTR lpszFile, UINT nIconIndex) +{ + HICON hIcon = NULL; + + TRACE("(%p %s %d\n", hInstance, debugstr_w(lpszFile), nIconIndex); - exefn = HEAP_strdupWtoA(GetProcessHeap(),0,lpszExeFileName); - ret = ExtractIconA(hInstance,exefn,nIconIndex); + if (nIconIndex == -1) + return (HICON) PrivateExtractIconsW(lpszFile, -1, 0, 0, NULL, 0, 0, 0); - HeapFree(GetProcessHeap(),0,exefn); - return ret; + ExtractIconExW (lpszFile, nIconIndex, &hIcon, NULL, 1); + if (hIcon) + return hIcon; + return (HICON)1; } + typedef struct { LPCSTR szApp;

Dec. 2, 2002

Re: Janitorial Projects

by Francois Gouget

On Mon, 2 Dec 2002, Dimitrie O. Paun wrote: [...] > > > * arrange such that we can generate _one_ executable for all tests > > > > I think this is not necessary. All we need is a batch file to invoke all > > the tests and Patrik has already supplied that part. > > It's not necessary, but it would be nice. A bunch of tests with a batch > file have to be packaged in a .zip, downloaded, unzipped, figure out what > to run, etc. If we could instead provide _one_ executable, testing on > Windows would be a simple click on a webpage, and I guess a lot of people > can, and are willing to do that. > > Again, I take myself as an example: I simply loath to have to figure out > where to unzip something, pollute my dirs, etc. You should be able to unzip the tests anywhere. Sure that means you will have a lot of choice and may have to make hard decisions<g>. Besides, I'm not sure one can compile all the tests in just one executable or that it would be wise. There would be quite a high risk of naming conflicts between the tests, and that executable would have to link with tons of libraries for instance. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.

Dec. 2, 2002

Re: Wine 0.9 TODO v0.6

by Z_God

First, would it be an idea to say at least *insert any number* of Windows apps should be working perfectly with Wine before it is called 0.9? For example, we at least want to have 200 known perfectly working apps. And why not start at version 0.6 or something and calling Wine beta software instead of alpha when these TODOs are done? Then it would be possible to work towards a great 1.0 release. Just look at Mozilla, they post-poned their 1.0 release more than a year to become really great. Keep up the great work!! Z_God Op maandag 2 december 2002 19:40, schreef Dimitrie O. Paun: > Hi folks, > > Version 0.6 of the TODO for Wine 0.9 is available at: > http://www.dssd.ca/wine/Wine-0.9-TODO-0.6.html > As always, you can find the work-in-progress one here: > http://www.dssd.ca/wine/Wine-0.9-TODO.html > > As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment > -- A5: New FAQ is done, waiting to be promoted to WineHQ > -- D2: Alexandre got rid of the rsrc directive in .spec files > -- E4: Lionel made OpenGL detection dynamic > -- E9: New TODO item for fixing header location as discussed on > wine-devel > > Enjoy!

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Francois Gouget

Attached the source of my benchmark program in case anyone wants to have a look at it. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

Dec. 2, 2002

Re: Wine 0.9 TODO v0.6

by Dimitrie O. Paun

On December 2, 2002 02:21 pm, Hetz Ben-Hamo wrote: > I looked at the screenshots. Looks very impressive but very problematic.. > > Why problematic? simple: > > most of those applications requires many tweaks to run. Yes, this is why we're going to have the Gold page, listing apps that you can get going without any tricks. It's going to contain screenshots as well, it's going to be self contained. This page is a little different, there no point in putting the same constraints on it as the Gold page. That being said, I fully agree with you. So I think that we should: * NOT include apps that crash or don't work reasonable well Just starting up enough to take a shot is not good enough * NOT include apps that can not be tweaked into working with a reasonable enough of effort. Apps that _require_ cxoffice or WineX have no place on this page * DO include a warning saying that the apps featured on this page may require teaks to get working. Each shot should have a link to the appropriate entry on the appdb that has up to date instructions on how to get the app working * TRIM the list rather than have lots and lots of apps that may not work right, or have installation problems, etc. -- Dimi.

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Morten Welinder

Unless we're talking an inner and very intensive loop, all this is a bit silly. However, assuming that it does make sense, sprintf variants are not part of the answer. They're interpreted and var-arg type, both of which are little good for efficiency. More like something along these lines: char *tmpdst = dst; strcpy (tmpdst, src1); tmpdst += strlen (src1); strcpy (tmpdst, src2); tmpdst += strlen (src2); strcpy (tmpdst, src3); tmpdst += strlen (src3); ... strcpy (tmpdst, srcN); tmpdst += strlen (srcN); ... This works even better when the strlen calls have known results. Of course, nothing keeps the compiler from noticing a certain pattern of sprintf calls can producing an equaivalent of the above, but right now gcc will not do that if I recall correctly. Morten

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Francois Gouget

On 30 Nov 2002, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > > > I don't like pieces of code that go: > > > > strcpy(foo, bar1); > > strcat(foo, bar2); > > strcat(foo, bar3); > > strcat(foo, bar4); > > strcat(foo, bar5); > > strcat(foo, bar6); > > > > It's really inefficient: the cost increases quadratically with the size > > of the resulting string. > > Well, no, the cost is linear. It would only be quadratic if the number > of strcat calls depended on the length of the string. True. > > It's more efficient to do: > > > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); > > I seriously doubt that sprintf would be faster that a couple of > strcats. And I don't think we need to worry about this kind of > micro-optimizations right now... Which is why I'm not going through the source looking for them. It's just that sometimes I find one and cringe when I think at the inefficiency of reading the first string 3 or more times and having even more stuff to read with each strcat. This seems like a popular subject and everyone goes with their benchmark. So I had to do one too<g>. I took what I think is a quite common case where one does concatenates three strings, typically a path with a filename: sprintf(buf,"%s/%s",path,filename); The goal of my benchmark (attached) is to determine for what path length an sprintf becomes as efficient as an strcpy+2*strcat combination. I implemented the above operation using: * sprintf * strcpy+strcat * my own naive strcpy+strcat, just to see how much difference it makes compared to the optimized glibc implementation * a cpycat implementation which is how strcpy and strcat should have been implemented in the first place. cpycat returns a pointer to the trailing '\0' which means you can chain calls to cpycat. The test have been run on Debian (so assume the glibc may not be optimized much), on an Athlon processor and compiled with a simple '-O2 -fPIC', i.e. with the same options as Wine. The cutoff point turns out to be for a path length of about 220 characters: $ ./sprintf 100 len=100 sprintf: elapsed=45791 strcat: elapsed=27811 mystrcat: elapsed=27830 cpycat: elapsed=13205 $ ./sprintf 220 len=220 sprintf: elapsed=54540 strcat: elapsed=55507 mystrcat: elapsed=53610 cpycat: elapsed=21876 $ ./sprintf 300 len=300 sprintf: elapsed=63352 strcat: elapsed=76068 mystrcat: elapsed=73931 cpycat: elapsed=30482 So yes, most of the time sprintf is probably not more efficient than strcpy+strcat. Just for fun I added a 5 string case ( add '.'+extension) and the cutoff goes down to 120 characters which is still quite long. That being said I still prefer the sprintf approach because it has a much better worst case behavior. Other observations: * my naive strcpy/strcat implementation seems more efficient than the one in the glibc! That's pretty weird. * cpycat is much more efficient in this type of scenario. That's not very surprising of course. Why does the C library have such braindead functions as strcpy and strcat? Oh, and I'll side with Alexandre to say that in most cases, a better alternative to using snprintf/strncpy/strncat is to carefully mesure the length of your arguments, compute the exact length of the concatenated string (or at least an upper bound, e.g. in the case of widechar to multi-byte conversions) and allocate a buffer of the required size. Do anything else you will end up with truncated data in your buffer which means your function probably did not perform up to spec. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Dec. 2, 2002

Re: Janitorial Projects

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > All that's needed now is the packaging of the batch file plus the test > executables. Then we may start on the automation aspects but it may not > be very easy unless we can cross-compile the tests, i.e. generate > Windows executables from Linux (which I believe should be possible). Not only possible, it's already implemented: apt-get install mingw32 ./configure make crosstest -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

Re: Wine 0.9 TODO v0.6

by Hetz Ben-Hamo

> As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment I looked at the screenshots. Looks very impressive but very problematic.. Why problematic? simple: most of those applications requires many tweaks to run. Example: try to install Office 2k on the latest wineHQ. You'll have lots of problems installing it, and even if you install, you'll need to do "reboot" - which is not available unless you have CrossOver office. Same goes to many applications which have screenshots there.... So think what will happend if users will download wine-snapshot and won't be able to install the apps that appears in the screenshots? lots of anger, flames, false bug reports, you name it ;) Thanks, Hetz

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> > It is as if the code from your program is executing far > > slower than anything from libc! > > That is very well possible if he has the right libc. Take a look at the > optimizations in the string functions in glibc, and you'll have an idea > why. Unless you are a assembler programming Guru for a certain > architecture, you'll have a hard time beating them. I'm a fairly good assembler programmer.... Actually I don't have glibc - I'm running netbsd not linux. Netbsd might benefit from faster strxxx routines. OTOH the times are very dependant on the cpu model! My slotA athlon 700 executes my str_add() faster the way I coded it - I tried the other order and it sucked. Similarly escaping with: lim[-1] = 0; return lim; didn't help. Of course you can use the same tricks as glibc does to speed up your own variant of the copy routine. David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: Wine/FF7 midi help request

by Robotech_Master

Jeff Smith (whydoubt(a)hotmail.com) wrote in message <F206LIby98FfDrVKxJ700013bd1(a)hotmail.com>: > This looks like what I would get from the OSS driver - emu10k1. > The module name for the ALSA driver is snd-emu10k1. The choices > I would expect from ALSA's OSS emulation would be something like: > Emu10k1 > MIDI 0-0 > Emu10k1 Port 0 > Emu10k1 Port 1 > Emu10k1 Port 2 > Emu10k1 Port 3 Note--I forgot to mention, but I have Emu10K1 sound & midi support compiled into my kernel, not as modules. (I'm running 2.4.20.) > Try running it like this ... > wine -debugmsg +winmm,+midi,+msacm program_name.exe > ... and send the output. I tried this with the FF7config program, and it produced 26K of output; I've put the complete dump at http://www.eyrie.org/~robotech/winemidi.txt Here's the last few dozen lines, from when I was clicking the "test midi" button and it was telling me it couldn't access the device: trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x4068262c p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:midiStreamClose (0x8001)! trace:winmm:midiStreamStop (0x8001)! trace:winmm:midiStreamRestart (0x8001)! trace:winmm:MMSYSTEM_MidiStream_Player Ready to go 2 trace:winmm:MMSYSTEM_MidiStream_MessageHandler STOP trace:winmm:midiOutReset (0x8001) trace:winmm:MMDRV_Message (MidiOut 0 9 0x406828c4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406828c4 p1=0x00000000 p2=0x00000000 trace:midi:OSS_modMessage (0000, 0009, 406828C4, 00000000, 00000000); trace:midi:modReset (0000); trace:winmm:MMDRV_Message => 68 trace:winmm:MMSYSTEM_MidiStream_Player End of thread trace:winmm:DllMain 0x406a0000 0x3 (nil) trace:msacm:DllMain 0x41120000 0x3 (nil) trace:winmm:midiOutClose (0x8001) trace:winmm:MMDRV_Message (MidiOut 0 4 0x406828c4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x406828c4 p1=0x00000000 p2=0x00000000 trace:midi:OSS_modMessage (0000, 0004, 406828C4, 00000000, 00000000); trace:midi:modClose (0000); warn:midi:modClose device not opened ! trace:winmm:MMDRV_Message => 1 trace:winmm:MIDI_OutOpen (0x471180, 0, 00000000, 00000000, 00000000); trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (MidiOut 0 3 0x406827a8 0x403ad4dc 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=3 usr=0x406827a8 p1=0x403ad4dc p2=0x00000000 trace:midi:OSS_modMessage (0000, 0003, 406827A8, 403AD4DC, 00000000); trace:midi:modOpen (0000, 0x403ad4dc, 00000000); warn:midi:modOpen device disabled ! trace:winmm:MMDRV_Message => 68 trace:winmm:MIDI_OutOpen => 68 hMidi=(nil) trace:winmm:waveOutGetDevCapsA (0 0x406828f0 52)! trace:winmm:MMDRV_Message (WaveOut 0 4 0x00000000 0x406828f0 0x00000034 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x00000000 p1=0x406828f0 p2=0x00000034 trace:winmm:MMDRV_Message => 0 trace:winmm:waveOutMessage ((nil), 2058, 1080567472, 0) trace:winmm:MMDRV_PhysicalFeatures (0x403a4e54, 080a, 406826b0, 00000000) trace:winmm:MMDRV_Message (WaveOut 0 2058 0x00000000 0x406826b0 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=2058 usr=0x00000000 p1=0x406826b0 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open (0x403ad9f4, 0, Out, 0x403ad9e0, 40F55F74, 403AD758, 00030080, 32); trace:winmm:WAVE_Open wFormatTag=1, nChannels=2, nSamplesPerSec=22050, nAvgBytesPerSec=44100, nBlockAlign=2, wBitsPerSample=8, cbSize=0 trace:winmm:WAVE_Open cb=40f55f74 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (WaveOut 0 5 0x406825e4 0x40682614 0x00030080 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=5 usr=0x406825e4 p1=0x40682614 p2=0x00030080 trace:winmm:MMDRV_Message => 0 trace:winmm:WAVE_Open => 0 hWave=0x8000 trace:winmm:waveOutSetVolume (0000, ffffffff); trace:winmm:MMDRV_Message (WaveOut 0 17 0x00000000 0xffffffff 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=17 usr=0x00000000 p1=0xffffffff p2=0x00000000 trace:winmm:MMDRV_Message => 0 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ad758,00010043,3):stub trace:winmm:MIDI_OutOpen (0x471180, 0, 00000000, 00000000, 00000000); trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (MidiOut 0 3 0x406828d4 0x403ad504 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=3 usr=0x406828d4 p1=0x403ad504 p2=0x00000000 trace:midi:OSS_modMessage (0000, 0003, 406828D4, 403AD504, 00000000); trace:midi:modOpen (0000, 0x403ad504, 00000000); warn:midi:modOpen device disabled ! trace:winmm:MMDRV_Message => 68 trace:winmm:MIDI_OutOpen => 68 hMidi=(nil) trace:winmm:MIDI_StreamOpen (0x471184, 0x471194, 1, 0x004064d0, 0x00010043, 0x00030000)! fixme:winmm:MIDI_StreamOpen *lpuDeviceID=0 trace:winmm:MMDRV_Open Setting mmdIndex to 0 trace:winmm:MMDRV_Message (MidiOut 0 3 0x406828c4 0x403ac504 0x00030000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=3 usr=0x406828c4 p1=0x403ac504 p2=0x00030000 trace:midi:OSS_modMessage (0000, 0003, 406828C4, 403AC504, 00030000); trace:midi:modOpen (0000, 0x403ac504, 00030000); warn:midi:modOpen device disabled ! trace:winmm:MMDRV_Message => 68 trace:msacm:DllMain 0x41120000 0x2 (nil) trace:winmm:DllMain 0x406a0000 0x2 (nil) trace:winmm:MMSYSTEM_MidiStream_Player (0x403ad4e8)! trace:winmm:MMSYSTEM_MidiStream_Player Ready to go 1 trace:winmm:MIDI_StreamOpen => (0/0) hMidi=0x8001 ret=68 lpMidiStrm=0x403ad4e8 trace:winmm:waveOutClose (0x8000) trace:winmm:MMDRV_Message (WaveOut 0 6 0x4068262c 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=6 usr=0x4068262c p1=0x00000000 p2=0x00000000 trace:winmm:MMDRV_Message => 0 trace:winmm:midiStreamClose (0x8001)! trace:winmm:midiStreamStop (0x8001)! trace:winmm:midiStreamRestart (0x8001)! trace:winmm:MMSYSTEM_MidiStream_Player Ready to go 2 trace:winmm:MMSYSTEM_MidiStream_MessageHandler STOP trace:winmm:midiOutReset (0x8001) trace:winmm:MMDRV_Message (MidiOut 0 9 0x406828c4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=9 usr=0x406828c4 p1=0x00000000 p2=0x00000000 trace:midi:OSS_modMessage (0000, 0009, 406828C4, 00000000, 00000000); trace:midi:modReset (0000); trace:winmm:MMDRV_Message => 68 trace:winmm:MMSYSTEM_MidiStream_Player End of thread trace:winmm:DllMain 0x406a0000 0x3 (nil) trace:msacm:DllMain 0x41120000 0x3 (nil) trace:winmm:midiOutClose (0x8001) trace:winmm:MMDRV_Message (MidiOut 0 4 0x406828c4 0x00000000 0x00000000 Y)! trace:winmm:MMDRV_Message Calling message(dev=0 msg=4 usr=0x406828c4 p1=0x00000000 p2=0x00000000 trace:midi:OSS_modMessage (0000, 0004, 406828C4, 00000000, 00000000); trace:midi:modClose (0000); warn:midi:modClose device not opened ! trace:winmm:MMDRV_Message => 1 -- Chris Meadows aka | Co-moderator, rec.toys.transformers.moderated Robotech_Master | Homepage: <URL:http://www.eyrie.org/~robotech/> robotech(a)eyrie.org | And now I've started a weblog: | http://robotech_master.livejournal.com

Dec. 2, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 2, 2002 01:54 pm, Francois Gouget wrote: > On Sun, 1 Dec 2002, Dimitrie O. Paun wrote: > > * make sure we can compile them with MinGW > > That said I agree that the tests should also be compilable with MinGW > because OSS projects should strive to be self-sufficient. I've never argued _not_ supporting Visual C++. All I am saying is that it's (more) important to have a build system based on MinGW. And this not only based on self-sufficiency -- there are many people out there that don't have MSVC++. Like myself for example :), and I have to admit, I don't plan on installing it anytime soon... So yeah, the msvcmaker is great, but we need a mingwmaker as well :))) > > * arrange such that we can generate _one_ executable for all tests > > I think this is not necessary. All we need is a batch file to invoke all > the tests and Patrik has already supplied that part. It's not necessary, but it would be nice. A bunch of tests with a batch file have to be packaged in a .zip, downloaded, unzipped, figure out what to run, etc. If we could instead provide _one_ executable, testing on Windows would be a simple click on a webpage, and I guess a lot of people can, and are willing to do that. Again, I take myself as an example: I simply loath to have to figure out where to unzip something, pollute my dirs, etc. I just wouldn't do it. You may say I'm lazy, and I'd agree with you, but that's how I operate. On the other hand, if it would be a simple click thingy, I would find it fun to do it from time to time, just for shits and giggles. > > * create script that builds them say, every few (3-5) days, tests > > if the executable changed (by comparing MD5 sums) from the last > > build, and if so, put it up for download on a site, and email > > the test volunteers a notification (containing the URL) that > > the tests have changed, and they should retest. The URL should > > be fixed (e.g. http://www.corp.com/wine/wine-tests.exe) so the > > tester can bookmark it, write scripts against it, etc. > > All that's needed now is the packaging of the batch file plus the test > executables. Then we may start on the automation aspects but it may not > be very easy unless we can cross-compile the tests, i.e. generate > Windows executables from Linux (which I believe should be possible). Why is that? If we can get the MinGW stuff working, I'm sure will find someone on the list willing to compile them from time to time... -- Dimi.

Dec. 2, 2002

Re: The conformance tests need you!

by Francois Gouget

On 2 Dec 2002, Martin Wilck wrote: [...] > I am currently having trouble with running stuff natively on Windows. > Can anybody run the winsock test with verbose output (trace enabled) on > Windows NT and send me the result ? Here goes: sock.c:686: **** STARTING TEST 0 **** sock.c:327:simple_server (b2) starting sock.c:386:simple_client (dd): starting sock.c:336:simple_server (b2) ready sock.c:389:simple_client (dd): server ready sock.c:341:simple_server (b2): waiting for client sock.c:386:simple_client (28): starting sock.c:389:simple_client (28): server ready sock.c:401:simple_client (dd) connected sock.c:341:simple_server (b2): waiting for client sock.c:422:simple_client (dd) exiting sock.c:401:simple_client (28) connected sock.c:369:simple_server (b2) exiting sock.c:422:simple_client (28) exiting sock.c:607: Test failed: some threads have not completed sock.c:688: **** TEST 0 COMPLETE **** sock.c:686: **** STARTING TEST 1 **** sock.c:327:simple_server (a5) starting sock.c:336:simple_server (a5) ready sock.c:341:simple_server (a5): waiting for client sock.c:440:event_client (ce): starting sock.c:440:event_client (cc): starting sock.c:442:event_client (ce): server ready sock.c:451: Test failed: event_client (ce): connect error: 10022 sock.c:442:event_client (cc): server ready sock.c:451: Test failed: event_client (cc): connect error: 10022 sock.c:607: Test failed: some threads have not completed sock.c:613:terminating thread 000000a5 sock.c:613:terminating thread 000000ce sock.c:613:terminating thread 000000cc sock.c:688: **** TEST 1 COMPLETE **** There is no further output. The process does not terminate and has 1 remaining thread at this point. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Dec. 2, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I am not sure but I suspect the compiler generates indirect accesses for > these. I'm not sure what gcc does for variables exported from another > library. It seems like it has to be doing something similar. So if we > could get access to that indirection we may be able to make things work. Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002