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

Re: Cabinet update

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

Re: Janitorial Projects

by Francois Gouget

On Sun, 1 Dec 2002, Dimitrie O. Paun wrote: [...] > This is too complicated. First, it requires Visual C++, which sucks. I think that being able to compile the tests with Visual C++ is very important. There are a lot of professional Windows programmers out there who have Visual C++ and who would be very qualified for writing tests and who may not want to install MinGW on their Windows machine. So it's important to make it as easy as possible for them to write tests in the environment they are most confortable with, i.e. Visual C++. > We should be able to compile the tests with MinGW, as any OSS project > out there. So I would say the TODO for building the tests is as follows: > * 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. > * 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. > * 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). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Dec. 2, 2002

Re: The conformance tests need you!

by Martin Wilck

Am Mon, 2002-12-02 um 19.12 schrieb Francois Gouget: > > Am Sam, 2002-11-30 um 04.02 schrieb Francois Gouget: > > > > > > Come on people, we can do better. > > > Send fixes to wine-patches, and send me emails to so that I update this > > > table. > > > > I'll have a look at the winsock stuff. > > Thanks :-) 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 ? 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. 2, 2002

Re: Winelib - MFC application

by Dimitrie O. Paun

On December 2, 2002 10:57 am, jaymz(a)free.fr wrote: > >What exatcly did you do for this one? > > Comment out the section that defined NONAMELESSTRUCT and NONAMELESSUNION >From the Makefile? > >>- There was a conflict on HKEY type between <afxres.h> and > >> <wine/windef.h> > > > >What did you do? > > > > remove one of them ! Maybe we can find a solution that doesn't require removing anything! :) It works on Windows, how do they do it? > >>- Some little others syntax issues like: __try __expect, asm {}, > >>unsigned short(x), (LPCTSTR)CString > >> > > > >I reckon these are mods to the MFC source, no? > > yes ! I'd be curious to see the patch, if you can make it available, of course... -- Dimi.

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

David Laight <david(a)l8s.co.uk> writes: > Yes, but even then strcpy may not be safe! Another thread could change > the length after you've counted it. Please, this is silly. If another thread is changing the string, all string functions will break, strlcpy is not magically "safer" than strcpy. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

POSE (Palm OS Emulator) on WINE?

by Bodo Wenzel

Hi list. Because Sony doesn't provide a Unix source code branch, I tried to run their Windows based POSE on WINE. At first glance it runs, but only until a command of the context menu is chosen. WINE reports an "unhandled exception" and launches the debugger. My question: does anyone heard about how to make POSE run on WINE? Is anyone interested in making them work together? Both are Open Source... Unfortunately I can't because of my lack of time :-( TIA, Bodo

Dec. 2, 2002

How to fix display errors?

by Ferenc Wagner

Hello, I decided to forward a previous post of mine from the users' newsgroup, since I got no answers there, and consider this a developer question: I'd like to correct some bugs. Having read the Developers' Guide didn't help me much: the relevant topic was empty (the program runs, but shows some errors). Perhaps you can point me in the right direction (I mean: source file in the tree)? Below is the article. See a screenshot at http://afavant.elte.hu/~wferi/wine.png (25K). It exhibits several slight problems. 1. The scrollable list has no border (Suchanfrage window, above the Phrasensuche checkbox). 2. The text input field (with Goethe in it) has no border, too. 3. The "Minimize" button is misplaced: clicking to the right of it invokes its action, the button itself is not clickable. 4. The little toolbar window to the right looks strange, but what is worse, it is sticky: appears on every viewport (It's not managed by fvwm2, like the main window.) The Suchanfrage subwindow is not sticky. While executing the program, I get the following messages: err:toolbar:ToolbarWindowProc unknown msg 0465 wp=0000004c lp=412c1d70 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:statusbar:StatusWindowProc unknown msg 0486 wp=0000 lp=00000000 err:toolbar:ToolbarWindowProc unknown msg 0486 wp=00000000 lp=00000000 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub Is there anything I can do about the above (cosmetic) errors? I use a recent CVS checkout (Wine 20021125), and I know C programming, but have no experience with graphics and Windows. Feri.

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> > And in any case the right approach to writing > > correct and secure code is not to truncate every string in sight to > > some fixed buffer size; it's to make sure you allocate buffers of the > > right size, and then you can use standard strcpy/strcat/sprintf/etc. > > without worrying about lengths. Yes, you can use a small (on stack) buffer for the 'usual' case and only allocate a large one in the unusual ones. (but don't use alloca()...) > I think this statement has to be tightened. I am sure you know exactly what > you mean, Alexandre, and I believe that I and many others do. However I > think we need to mention that one needs to consider that the strings passed > in may be bad, e.g. unterminated. Either one uses that actual measured > lengths of the strings when allocating or one checks the lengths of the > strings against the allocated space. Yes, but even then strcpy may not be safe! Another thread could change the length after you've counted it. > In particular one DOES NOT allocate on > the basis of some wishy-washy documentation statement or a hard-coded > constant that the caller may well have ignored. Absolutely! David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Martin Wilck

Am Mon, 2002-12-02 um 13.57 schrieb 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. 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. 2, 2002

Re: strcat+strcat+strcat == baaad

by Martin Wilck

Am Son, 2002-12-01 um 23.07 schrieb Shachar Shemesh: > When I'm wrong, I'm wrong. > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)sun:~/sources/wine/test$ ./way3 > Operation took 0 seconds 427037 usec First off, the program is wrong in that "way3" doesn't do what it's supposed to (concatenate). Below is a patch for your benchmark with a "WAY4" going a similar path as WAY3, but using strlen() and memcpy(), and a WAY5 that is pretty similar to David's, but better with gcc 3.2. My resume is: Don't try to outwit the C library. Assume that the user has installed a good one, and use library functions. (Btw ever looked at the section about "strcat" in the glibc info pages?) WAY4 below is very fast with a good C library. On i686, it is best for all optimizations except -O1 where gcc inlines self-generated i386-optimized code which is more than a factor of 2 slower than the library routine. It also requires the "-march=i686" option to gcc, otherwise gcc wrongly assumes that i386 optimizations are the best, and uses them always. Of course, if the lengths of the strings are known, you can speed this up a lot by doing without strlen(). WAY2 depends on the "strcat" implementation in the library. It may be slower than the snprintf solution if strcat is badly optimized. (And it's unsafe)! David's WAY3, being not library dependent, is quite good except for -O0. With GCC 3.2 and optimization -O2 and above, it is necessary to reverse the "if" and "else" clauses in str_add(), otherwise performance degrades because gcc assumes the "if" branch is taken more often. (That reversed str_add is called "WAY5" below. These are my results, obtained on a PIII system with RedHat 8.0, using "gcc -Ox -march=i686" as optimization: (I took gcc3.2 -O0 as "reference value" 1.0): GCC 3.2 -O0 -O1 -O2 -O3 WAY1 1.00 0.98 0.97 0.97 WAY2 0.93 0.98 0.92 0.93 WAY3 2.28 0.67 0.95 1.05 WAY4 0.49 1.00 0.46 0.41 WAY5 2.53 0.66 0.66 0.76 GCC 2.96 -O0 -O1 -O2 -O3 WAY1 1.00 0.98 1.02 1.02 WAY2 0.93 0.93 0.93 0.93 WAY3 2.21 0.67 0.69 0.63 WAY4 0.49 1.02 0.48 0.42 WAY5 2.42 0.67 0.69 0.63 Martin --- strorg.c Mon Dec 2 13:29:43 2002 +++ strcpy.c Mon Dec 2 17:35:00 2002 @@ -12,15 +12,38 @@ int c; do { +#if WAY5 + if ( s < lim ) c = *a++; + else { + s = lim - 1; + c = 0; + } +#else if (s >= lim) { s = lim - 1; c = 0; } else c = *a++; +#endif *s++ = c; } while (c); - return s; + return --s; +} + +char* +str1_add(char*s, int *len, const char *a) +{ + + int l = strlen(a); + if ( l >= *len ) + l = *len - 1; + + memcpy ( s, a, l ) ; + *len -= l; + s += l; + *s = 0; + return s; } int main() @@ -32,7 +55,7 @@ gettimeofday(&before, NULL); for( i=0; i<NUM_ITER; ++i ) { -#ifdef WAY1 +#if WAY1 strcpy( buffer, STRING ); strcat( buffer, STRING ); strcat( buffer, STRING ); @@ -46,21 +69,33 @@ #elif WAY2 sprintf( buffer, "%s%s%s%s%s%s%s%s%s%s", STRING, STRING, STRING, STRING, STRING, STRING, STRING, STRING, STRING, STRING ); -#elif WAY3 +#elif ( WAY3 || WAY5 ) char *pointer=buffer; char *const limit=buffer+sizeof(buffer); - buffer[0]='\0'; - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); - pointer=str_add( buffer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); + pointer=str_add( pointer, limit, STRING ); +#elif WAY4 + char *p = buffer; + int len = sizeof(buffer); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); + p = str1_add (p, &len, STRING); #endif } gettimeofday(&after, NULL); @@ -70,13 +105,7 @@ diff_sec=after.tv_sec-before.tv_sec; diff_usec=after.tv_usec-before.tv_usec; - if( diff_usec<0 ) - { - diff_usec+=1000000; - diff_sec--; - } - - printf("Operation took %ld seconds %ld usec\n", diff_sec, diff_usec ); + printf("Operation took %07ld usec\n", diff_sec * 1000000 + diff_usec ); } return 0; -- 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. 2, 2002

Re: valgrind and wine

by Dan Kegel

Aric Stewart wrote: > I have actually worked a little with Julian Steward on this problem > just before 1.1.0 I actually have a build of valgrind here on my laptop > with works with very simple wine applications. I remember there was one > hack i had to do to the valgrind source to disable some of its sanity > checking. > > I could not get valgrind to work with more advanced wine programs > because i kept getting > > trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x402e1a30 > > if you want to work with valgrind i will did up how i turned off the > sanity checking with 1.1.0 and see if you can get it working. Yes, please do document how you got valgrind to start working with Wine! Maybe somebody bright with time on their hands will be able to solve the issue you ran into. Thanks, Dan

Dec. 2, 2002

RE: strcat+strcat+strcat == baaad

by Medland, Bill

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static func), or > in some library that will be linked (statically, I hope). Ideas? We don't need that, there are Windows API functions like lstrcpyn that can be used for that. And in any case the right approach to writing correct and secure code is not to truncate every string in sight to some fixed buffer size; it's to make sure you allocate buffers of the right size, and then you can use standard strcpy/strcat/sprintf/etc. without worrying about lengths. -- Alexandre Julliard julliard(a)winehq.com

Dec. 2, 2002

Re: valgrind and wine

by Aric Stewart

Hello, I have actually worked a little with Julian Steward on this problem just before 1.1.0 I actually have a build of valgrind here on my laptop with works with very simple wine applications. I remember there was one hack i had to do to the valgrind source to disable some of its sanity checking. I could not get valgrind to work with more advanced wine programs because i kept getting trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x402e1a30 if you want to work with valgrind i will did up how i turned off the sanity checking with 1.1.0 and see if you can get it working. -aric Lionel Ulmer wrote: >>==6476== Valgrind detected that your program requires >>==6476== the following unimplemented functionality: >>==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. >>==6476== This may be because the functionality is hard to implement, >>==6476== or because no reasonable program would behave this way, >>==6476== or because nobody has yet needed it. In any case, let me know >>==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. > > > Which version of Valgrind is this ? According to the web page, 1.1.0 should > support this system call : 'Specifically, valgrind can now deal with x86 > segment registers, segment override prefixes and the modify_ldt system > call'. > > But well, for it to really be useful, we would need then also to override in > Valgrind (or in Wine) all the Threading and Heap functions. > > Lionel >

Dec. 2, 2002

Re: Winelib - MFC application

by jaymz＠free.fr

Dimitrie O. Paun wrote: >>The packing pragmas looks handled by gcc-3.2.1, so we may remove all >>modifications made by winemaker >> >> >Maybe winemaker should be patched to not add them based on a >switch (maybe determine default value based on compiler). >BTW, do you _have_ to remove them, or it doesn't matter? > It was just warning issues >>I had to force winnt.h to use nameless struct and unions >> >> >What exatcly did you do for this one? > Comment out the section that defined NONAMELESSTRUCT and NONAMELESSUNION >>- I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h >> >> >Sounds like a patch would be in order, no? > >>- I linked _alloca() to alloca() function >> >> >Where? Again, maybe you should submit this one. > >>- There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> >> >> >What did you do? > > remove one of them ! >>- Some little others syntax issues like: __try __expect, asm {}, >>unsigned short(x), (LPCTSTR)CString >> >> >I reckon these are mods to the MFC source, no? > yes !

Dec. 2, 2002

Re: Wine/FF7 midi help request

by Jeff Smith

>From: Robotech_Master <robotech(a)eyrie.org> > >On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a >discussion about midi in WINE in which FF7 was mentioned): > > > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > > modification to wine at all, and the OSS emulation of ALSA makes the > > thing transparent to WINE. > >Can you, or someone, please let me know how to set up wine to use >this? I'm running Debian Linux; these are the versions of timidity >and wine that I have: > >ii timidity 2.11.2-1.3 Software-only MIDI sequencer. >ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) This is something I would not mind knowing myself. It's not too high a priority for me though as I have SoundFonts working on my SBLive now. >For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a >Soundblaster live card. > >On the FF7 config program, it gives me the choices > > Wine OSS midi out (#0) - disabled > EMU10K1 midi 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 >Under "midi data" it gives me the choises > > General midi > Soundfont midi (Creative AWE32/AWE64) > Yamaha XG midi I would imagine this should stay on General midi unless you are *sure* it needs to be on another selection. >No matter what I try, in whatever combination, I get "Error opening >device" and the wine console says > >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel >(0x403ab930,0001003c,3):stub > >Can someone help me out--or point me at somewhere else I can find >help? Try running it like this ... wine -debugmsg +winmm,+midi,+msacm program_name.exe ... and send the output. -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Dimitrie O. Paun

On December 2, 2002 03:04 am, Greg Turner wrote: > cvs is the "right way" although I forget how it's done. I've used tkcvs > for this sort of thing. it's a horrible anachronistic kinda gui but it > has a really useful graphical view of each file's history in there that > can be a huge help when tracking down a particular change. A picture > is worth 1000 keystrokes sometimes... BTW, anyone willing to take wincvs for a spin. Is a very nice CVS frontend, for those of use addicted to clicking about, and a perfect target for Wine! http://www.wincvs.org -- Dimi.

Dec. 2, 2002

Winelib - MFC application

by jaymz＠free.fr

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

Dec. 2, 2002

Re: Screenshots v0.1

by Dimitrie O. Paun

On December 1, 2002 02:41 pm, Brian Vincent wrote: > I've gotten a lot of great screenshots over the past few weeks. I've > put together a preview you can find here: > > http://www.theshell.com/~vinn/ss/preview.html Very nice! I'll add the link to the TODO entry. > Be warned, the format isn't the best, the thumbnails aren't even close > to optimized, I only looked at it in one browser, and it might even steal > your lunch money. They look great man, what do you want to optimize them for? :) > Okay, if you've read this far maybe you're expecting something to > prompt discussion. One of the things you'll notice is there's a > lot of screenshots on there there almost certainly don't run out > of the box. In some instances the folks above listed exactly what > they had to do to make it run. Personally, I don't think it matters. > We already have the apps DB and the proposed "Gold/Silver/.." apps > list, I really don't think we need more than a link to one of those. Indeed. I would say as long as the app runs decently (with whatever tricks) it's OK. But if the app runs enough just to produce the shot... it's not fair, kinda like false advertisement. -- Dimi.

Dec. 2, 2002

Re: Winelib - MFC application

by Dimitrie O. Paun

On December 2, 2002 10:04 am, Ronald MALLET wrote: Cool! Shouldn't some of these be submitted as patches? > First for compiling the MFC: > --------------------------------------- > - I had to uncomment PSH_WIZARD97 in /wine/prsht.h > - The packing pragmas looks handled by gcc-3.2.1, so we may remove all > modifications made by winemaker Maybe winemaker should be patched to not add them based on a switch (maybe determine default value based on compiler). BTW, do you _have_ to remove them, or it doesn't matter? > - I had to force winnt.h to use nameless struct and unions What exatcly did you do for this one? > - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h Sounds like a patch would be in order, no? > - I linked _alloca() to alloca() function Where? Again, maybe you should submit this one. > - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> What did you do? > - Some little others syntax issues like: __try __expect, asm {}, > unsigned short(x), (LPCTSTR)CString I reckon these are mods to the MFC source, no? -- Dimi.

Dec. 2, 2002

Winelib - MFC application

by Ronald MALLET

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Paul Millar

On Mon, 2 Dec 2002, Greg Turner wrote: > cvs is the "right way" although I forget how it's done. 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 ---- Paul Millar

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> optimizations: -O2 strcpy/cat sprintf snprintf str_add stpcpy > 2.926220 1.427674 1.408928 3.405458 0.892890 1000 > 2.622081 1.308464 1.292384 3.062085 0.867009 900 > 2.363464 1.169335 1.152487 2.727685 0.740690 800 These do not look right, in particular the first column is too fast. For instance my system gives (NUM_ITER=1000): 0.174988 0.042060 0.042097 0.057267 1000 0.155118 0.038678 0.038592 0.051500 900 0.138036 0.034586 0.034597 0.045832 800 ... 0.005573 0.006449 0.006452 0.002103 30 0.003858 0.005962 0.005964 0.001536 20 0.002163 0.005783 0.005802 0.000967 10 It is as if the code from your program is executing far slower than anything from libc! David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

RE: strcat+strcat+strcat == baaad

by Patrik Stridvall

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I > can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static > func), or in > some library that will be linked (statically, I hope). Ideas? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

Dec. 2, 2002

Re: Screenshots v0.1

by Mike Hearn

Good stuff Brian, I saw the new preview page earlier. Even I was impressed by what Wine can do and I've been using it for a while now so that has to be a good start. I dunno, maybe you could have a "see more screenshots" link which just links to a directory with symlinks to the rest of the screenshots that weren't included, no matter what the size etc: I know some people who just *cannot* get enough screenshots sometimes. On Sun, 2002-12-01 at 19:41, Brian Vincent wrote: > I've gotten a lot of great screenshots over the past few weeks. I've > put together a preview you can find here: > > http://www.theshell.com/~vinn/ss/preview.html > > Be warned, the format isn't the best, the thumbnails aren't even close > to optimized, I only looked at it in one browser, and it might even steal > your lunch money. > > Random notes: > > - there's lots of great shots not on the thumbnails page - most likely > there's a reason, not 800x600, didn't scale well, or I simply overlooked it > > - you can find all of the screenshots at: > http://www.theshell.com/~vinn/ss > > - the images predominantly are PNG, though there are quite a few JPEGs. > No GIF. > > - Special thanks to: > Thomas Wickline > Carlos Lozano > David Buchmann > Guido Grazioli > Ender > Juliasz Gonera > Michael Krasucki > Mike Hearn > Rick Romero > Robert Shade > Rory King > Tony Lambregts > tavis > > Okay, if you've read this far maybe you're expecting something to > prompt discussion. One of the things you'll notice is there's a > lot of screenshots on there there almost certainly don't run out > of the box. In some instances the folks above listed exactly what > they had to do to make it run. Personally, I don't think it matters. > We already have the apps DB and the proposed "Gold/Silver/.." apps > list, I really don't think we need more than a link to one of those. > > Also, a few weeks ago there was a lot of discussion of a new WineHQ > site. Any progress on that front? > > -Brian Vincent -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

David Laight wrote: >Inlining them would (probably) be bad news. They are not >a completely trivial size (ie smaller than the call sequence) >and they are more likely to be resident in the Icache if they >are functions. > Yes, but they are much more likely to fit into the function scope optimization if they are inlined. >They are useful though, and do what the programmer wanted >(unlike strncpy whose only point is that it doesn't overrun >the target buffer). > >However in this case they aren't quite right! > > len = strlcpy(buf, s0, buflen); > len += strlcpy(buf + len, s1, buflen - len) > len += strlcpy(buf + len, s2, buflen - len) > ahem. The code should be: strlcpy(buf, s0, buflen); strlcat(buf, s1, buflen); strlcat(buf, s2, buflen); If you are going to be sliding the buffer with each call, then you can just as well use your functions. >is slightly more complex than using my str_add(). > >The source for the functions can be grabbed from netbsd or freebsd. > > David > > >

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static func), or in > some library that will be linked (statically, I hope). Ideas? Inlining them would (probably) be bad news. They are not a completely trivial size (ie smaller than the call sequence) and they are more likely to be resident in the Icache if they are functions. They are useful though, and do what the programmer wanted (unlike strncpy whose only point is that it doesn't overrun the target buffer). However in this case they aren't quite right! len = strlcpy(buf, s0, buflen); len += strlcpy(buf + len, s1, buflen - len) len += strlcpy(buf + len, s2, buflen - len) is slightly more complex than using my str_add(). The source for the functions can be grabbed from netbsd or freebsd. David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> With higher O values, the difference becomes bigger, but I'm not sure > then that some of the operations are not optimized out of the process, > which makes the entire benchmark useless. I don't think they would be, and it is easy enough to check (objdump -d way1). Benchmarking is meaningless if you don't use the optimisation level then will be used in real life. Also the compiler is really designed to be used with -O, the code generatd without it is only 'half cooked'. > Do we go for David's suggestion, that is more efficient, but is also > more cubersome and requires two extra vars to implement right? The extra variables are likely to be well optimised by the compiler. strlcpy/cat will be even slower than the strcpy/cat versions. way1: 900 ms way1a: 1321 (strlcpy/cat) way2: 721 ms way3: 322 ms way3a: 223 ms (without bound check) David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

David Laight wrote: >>probably that >>you were underestimating the time required to parse the format string, >>which is probably greater than anything else. Everything else is simple >>searching and copying whereas the parsing is probably at least a >>quadratic-order function. >> >> > >No it will be linear (on the length of the format string). >But just rather more expensive than you probably expect. > That's the reason that I thought it will be faster. However, since the test program copied 40 bytes 10 times, which is a rather extreme case, and still was not faster, we can only conclude that sprinf is not practical for almost all standard cases. >There is a lot of red tape lurking. > > David > > This, however, does not answer the usability issue. Obviously, we won't put in patches that convert to anything else just because someone didn't like it (yes, I agree with Alexander on this point). There is, however, the question of buffer overruns. I suggest implementing strlcat and strlcpy, as in OpenBSD. I can write them, but I'm not sure where to place them. They should either be inlined (as in - implemented in an include file as a static func), or in some library that will be linked (statically, I hope). Ideas? For those who don't know strl* functions - they are just like strn* functions, except that the parameters are sane: In strn*: * Resulting string is not always NULL terminated. * In strncat, the terminating null is always written, but is not counted in the size!!! * The size parameter is sometimes the total size of the buffer, and sometimes the size of the unused portion of the buffer. * On strncpy, the entire buffer is written into, even if very little of it is needed (performance) All of the above make for awkward and error prone coding. In order to use strncat properly, you have to keep subtracting the number of characters already copied, and 1 for the terminating nul. As a result of these subtractions, a negative overflow (i.e. - from 0 to maxint) may happen, which in turn causes buffer overruns itself. Unlike it, in the strl* functions: * Resulting string is ALWAYS NULL terminated, whether there was enough room or not. * The buffer is not padded with NULLs beyond the terminating one (performance). * The number is ALWAYS the total buffer size. No arithmetics are necessary. Shachar

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> probably that > you were underestimating the time required to parse the format string, > which is probably greater than anything else. Everything else is simple > searching and copying whereas the parsing is probably at least a > quadratic-order function. No it will be linear (on the length of the format string). But just rather more expensive than you probably expect. There is a lot of red tape lurking. David -- David Laight: david(a)l8s.co.uk

Dec. 2, 2002

Re: Adding support for xxx_test.exe all

by Francois Gouget

On 30 Nov 2002, Alexandre Julliard wrote: [...] > > Do others find this patch acceptable? Useful? > > The drawback I see is that with this change the tests do not start > with a clean process state, which could cause problem for some of > them. Or we need to require that all tests cleanup properly after > them, which may be a bit painful. Tests have to cleanup behind themselves to some extent otherwise it means they cannot be run twice in a row and that would be very bad. But yes, they might leave static variables behind or environment variables or whatnot. That would really not be very clean. The tests don't work well enough on Windows that I know whether that is the case or not. Note that it would be pretty easy to just 'system("xxx_test.exe foo") each individual test which would solve the above issue. It may be that with Patrik's script for running all tests the need for an 'xxx_test.exe all' may be lower. I'll play some more with the tests and maybe I'll submit a patch that adds an 'all' option based on 'system'. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Greg Turner

On Monday 02 December 2002 01:19 am, Dan Kegel wrote: > Dan Kegel wrote: > > I found an unopened copy of msvc++ 4.0 at a garage sale last year > > for $5, couldn't resist. Today I finally tried to install it under > > Wine. > > OK, more details. I switched to testing the simplest > function of msvc's setup program: the exit button. > All I do is click on the exit button. (Easy, right?) > It works fine in Wine-20020804, but fails in Wine-20020904 and later. > > Logs at > http://www.kegel.com/msvc4-setup-wine-20020804.ok.log.bz2 > http://www.kegel.com/msvc4-setup-wine-20020904.bad.log.bz2 > > The interesting part is the 1000 lines after the line containing > 'Button'; it looks like in the later wines, the program gets stuck > in a WaitForSingleObject, maybe. I have to kill Wine to recover. > > Next step appears to be for me to download > ftp://ftp.winehq.com/pub/wine/wine-cvsdirs-20020804.tar.gz > and start fetching the cvs tree as of particular days in > August, and figure out exactly which commit caused the regression. > What cvs command do I use to do that (it's not documented on > winehq.com, I think)? Or is there a better way? > > Thanks, > Dan cvs is the "right way" although I forget how it's done. I've used tkcvs for this sort of thing. it's a horrible anachronistic kinda gui but it has a really useful graphical view of each file's history in there that can be a huge help when tracking down a particular change. A picture is worth 1000 keystrokes sometimes... -- gmt

Dec. 2, 2002

Wine/FF7 midi help request

by Robotech_Master

On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a discussion about midi in WINE in which FF7 was mentioned): > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > modification to wine at all, and the OSS emulation of ALSA makes the > thing transparent to WINE. Can you, or someone, please let me know how to set up wine to use this? I'm running Debian Linux; these are the versions of timidity and wine that I have: ii timidity 2.11.2-1.3 Software-only MIDI sequencer. ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a Soundblaster live card. On the FF7 config program, it gives me the choices Wine OSS midi out (#0) - disabled EMU10K1 midi Under "midi data" it gives me the choises General midi Soundfont midi (Creative AWE32/AWE64) Yamaha XG midi No matter what I try, in whatever combination, I get "Error opening device" and the wine console says fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ab930,0001003c,3):stub Can someone help me out--or point me at somewhere else I can find help? Thanks. -- 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: strcat+strcat+strcat == baaad

by Michal Janusz Miroslaw

On Mon, 2 Dec 2002, Shachar Shemesh wrote: > When I'm wrong, I'm wrong. > > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)sun:~/sources/wine/test$ ./way3 > Operation took 0 seconds 427037 usec > With higher O values, the difference becomes bigger, but I'm not sure > then that some of the operations are not optimized out of the process, > which makes the entire benchmark useless. > > So, what are our conclusions? Do we just implement strlcpy and strlcat > so that everyone has a function that is both efficient AND secure? > > Do we go for David's suggestion, that is more efficient, but is also > more cubersome and requires two extra vars to implement right? Well, I tested this further. Result's attached (test.log). Columns are: WAY1 (strcat), WAY2 (sprintf), WAY2_5(snprintf), WAY3 (str_add), WAY4(stpcpy). WAY4 is something I remembered from old DOS days, but it's nonstandard and probably available only in glibc. Since I used glibc compiled for i686 (pentium2), we probably should not consider entries with '-mcpu=pentium4' in comparision. Test platform: Pentium4 Northwood; linux-2.4.20; glibc-2.2.4 compiled with optimizations for Pentium2. My vote is for sprintf, as it can easily be converted to safer version and is easier to read. My two cents only. :) Michal Miroslaw

Dec. 2, 2002

Re: regression: msvc4.0 install dies sooner now

by Dan Kegel

Dan Kegel wrote: > I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5, > couldn't resist. Today I finally tried to install it under Wine. OK, more details. I switched to testing the simplest function of msvc's setup program: the exit button. All I do is click on the exit button. (Easy, right?) It works fine in Wine-20020804, but fails in Wine-20020904 and later. Logs at http://www.kegel.com/msvc4-setup-wine-20020804.ok.log.bz2 http://www.kegel.com/msvc4-setup-wine-20020904.bad.log.bz2 The interesting part is the 1000 lines after the line containing 'Button'; it looks like in the later wines, the program gets stuck in a WaitForSingleObject, maybe. I have to kill Wine to recover. Next step appears to be for me to download ftp://ftp.winehq.com/pub/wine/wine-cvsdirs-20020804.tar.gz and start fetching the cvs tree as of particular days in August, and figure out exactly which commit caused the regression. What cvs command do I use to do that (it's not documented on winehq.com, I think)? Or is there a better way? Thanks, Dan

Dec. 2, 2002

Re: strcat+strcat+strcat == baaad

by David Fraser

Shachar Shemesh wrote: > Benchmark will follow soon. In the mean time, think about the fact > that, compared to linear copying of the strings in, these are the > overheads (neglecting function call overhead, which is not neglectible > but is fair): > n - number of strings in the final string > m(i) - length of string i (0<i<=n) > sm(i) - sigma of all lengths up to i (0<i<=n) > sm(n) - total length of all strings > with sprintf - parsing the format string*n+sm(n) > with strcpy+strcat - for each strcat we have to find the end of the > string (sm(i-1)), and then write our own string (m(i)). Shachar Shemesh wrote: > When I'm wrong, I'm wrong. > > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 > sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 > sun(a)sun:~/sources/wine/test$ ./way1 > Operation took 0 seconds 450763 usec > sun(a)sun:~/sources/wine/test$ ./way2 > Operation took 0 seconds 598408 usec > sun(a)sun:~/sources/wine/test$ ./way3 > Operation took 0 seconds 427037 usec > Was going to say earlier, but didn't get to it ... the reason is probably that you were underestimating the time required to parse the format string, which is probably greater than anything else. Everything else is simple searching and copying whereas the parsing is probably at least a quadratic-order function. Anyway you've now demonstrated that so this isn't that relevant anymore... David

Dec. 2, 2002

Wine REALLY emulates Windows (was: Texture corruption in Wine)

by David D. Hagood

I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole "Just re-install it, it will fix it" thing down pat! 8^> To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows "mysterious changes" thing down pat! But it works. As Bugs Bunny said, "I don't ask questions, I just have fun." So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it....

Dec. 1, 2002

regression: msvc4.0 install dies sooner now

by Dan Kegel

I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5, couldn't resist. Today I finally tried to install it under Wine. wine-20020605-2 (rh8): installer started; when I clicked on 'Install Visual C++', it put up a 'Installing... please wait' dialog, then failed with a 'Can't read version info from C:\windows\kernel386.drv' message (more or less), then hung. wine-20021125 (from source): installer started; when I clicked on 'Install Visual C++', it hung. Looks like a regression to me. Logs of --debugmsg +relay are up at http://www.kegel.com/msvc4setup-wine20020605.log.bz2 http://www.kegel.com/msvc4setup-wine20021125.log.bz2 The latter file is 28MB uncompressed, 512KB compressed. I'm now building the intermediate releases of wine to see if I can narrow down when the regression occurred. - Dan

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

When I'm wrong, I'm wrong. sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1 sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2 sun(a)sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3 sun(a)sun:~/sources/wine/test$ ./way1 Operation took 0 seconds 450763 usec sun(a)sun:~/sources/wine/test$ ./way2 Operation took 0 seconds 598408 usec sun(a)sun:~/sources/wine/test$ ./way3 Operation took 0 seconds 427037 usec With higher O values, the difference becomes bigger, but I'm not sure then that some of the operations are not optimized out of the process, which makes the entire benchmark useless. So, what are our conclusions? Do we just implement strlcpy and strlcat so that everyone has a function that is both efficient AND secure? Do we go for David's suggestion, that is more efficient, but is also more cubersome and requires two extra vars to implement right? Shachar David Laight wrote: >>I said that due to the wall to wall agreement over the superiority of >>sprintf/snprintf. If there is a consensus, we should stick to it. >> >> > >But the performance of it will suck badly..... > >Something like: > >char * >str_add(char *s, char *lim, const char *a) >{ > int c; > > do { > if (s >= lim) { > s = lim - 1; > c = 0; > } else > c = *a++; > *s++ = c; > } while (c); > > return s; >} > >So you can do: > lim = buf + len; > buf = str_add(buf, lim, "abc"); > buf = str_add(buf, lim, "123"); > ... >might be safer. > > David > > >

Dec. 1, 2002

Re: DIB engine

by David

Hi Hetz, Just a few clarifications. The TransGaming DIBengine doesn't use SDL, and it was written mostly by Jonathan Meunier with help from Gav, Peter and myself. Anyhow, I believe Johan Gill is aware that we have the dibengine, and is in fact probably refering to it (as I have had private correspondence with him) For those who don't follow this list all the time, more information can be found in these two threads: http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html and http://www.winehq.com/hypermail/wine-devel/2002/11/0849.html Cheers David On Mon, 2 Dec 2002 08:17, Hetz Ben Hamo wrote: > Hi, > > Before you re-invent the wheel - David (forgot his family name, sorry > David) from Transgaming (if I'm not mistaken) has started to work on a DIB > engine that uses SDL, so you might want to collaborate with him on his > engine.. > > This reminds me a question: Is there a way that instead of using the DIB > engine, to create an RDP events and show them in an application like > rdesktop? > > Thanks, > Hetz > > On Sunday 01 December 2002 22:52, Johan Gill wrote: > > Hi all, I've just started working on the DIB engine, FYI. > > -- > > Johan Gill, johane(a)lysator.liu.se

Dec. 1, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > > That solves the libc problem however compiling with -flong-int also > > means that it will be impossible to call other libraries, which > > means that it will be a little hard to use Unix specific library > > to have extra functionallity under Unix. > > But those apps will be aware of the issue, and can use explicit types, > just like we're going to do in Wine. Sure, they will not be able to > use the header files directly (actually, they might by having some > compat files that are not compiled with said flag on), but I don't > think it's a big deal anyway. It's workable, A better solution would be to port the source code to the LP64 model. It is entirely possible for to support all of LP32 (Win32 and "Unix32"), LLP64 (Win64) and LP64 ("Unix64") in a sane way. I don't think it is worth the effort to support LLP64 beyond having a "-flong-int" flag to get a working version to show as a prototype that porting is indeed possible. > and Win64 will not > bother us for some time... True. Microsoft doesn't seems that eager pushing Win64 either...

Dec. 1, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > That solves the libc problem however compiling with -flong-int also > means that it will be impossible to call other libraries, which > means that it will be a little hard to use Unix specific library > to have extra functionallity under Unix. But those apps will be aware of the issue, and can use explicit types, just like we're going to do in Wine. Sure, they will not be able to use the header files directly (actually, they might by having some compat files that are not compiled with said flag on), but I don't think it's a big deal anyway. It's workable, and Win64 will not bother us for some time... -- Dimi.

Dec. 1, 2002

Re: DIB engine

by Hetz Ben Hamo

Hi, Before you re-invent the wheel - David (forgot his family name, sorry David) from Transgaming (if I'm not mistaken) has started to work on a DIB engine that uses SDL, so you might want to collaborate with him on his engine.. This reminds me a question: Is there a way that instead of using the DIB engine, to create an RDP events and show them in an application like rdesktop? Thanks, Hetz On Sunday 01 December 2002 22:52, Johan Gill wrote: > Hi all, I've just started working on the DIB engine, FYI. > -- > Johan Gill, johane(a)lysator.liu.se

Dec. 1, 2002

DIB engine

by Johan Gill

Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, johane(a)lysator.liu.se

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by David Laight

> I said that due to the wall to wall agreement over the superiority of > sprintf/snprintf. If there is a consensus, we should stick to it. But the performance of it will suck badly..... Something like: char * str_add(char *s, char *lim, const char *a) { int c; do { if (s >= lim) { s = lim - 1; c = 0; } else c = *a++; *s++ = c; } while (c); return s; } So you can do: lim = buf + len; buf = str_add(buf, lim, "abc"); buf = str_add(buf, lim, "123"); ... might be safer. David -- David Laight: david(a)l8s.co.uk

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > > > >>Well - still snprintf is more efficient. >> >> > >I don't think so, but feel free to provide benchmarks. > > Benchmark will follow soon. In the mean time, think about the fact that, compared to linear copying of the strings in, these are the overheads (neglecting function call overhead, which is not neglectible but is fair): n - number of strings in the final string m(i) - length of string i (0<i<=n) sm(i) - sigma of all lengths up to i (0<i<=n) sm(n) - total length of all strings with sprintf - parsing the format string*n+sm(n) with strcpy+strcat - for each strcat we have to find the end of the string (sm(i-1)), and then write our own string (m(i)). >>But there is also no reason not to welcome these submissions if >>someone already took the time to submit them. >> >> > >There's no objective reason why sprintf is better than strcat in that >case, it's purely a matter of personal taste. > Not if you accept my performance claim. Also, there is the security thingamy. The str* method is a bitch to make secure. You have to keep subtracting the already processed strings from the remaining buffer length, and then you run into the risk of subtracting more than you have, resulting in a negative number=buffer overflow despite your best efforts. There is the question of the null - yes/no. There is a horrible performance hit for strncpy for filling the entire buffer, while not promising null termination. In short, it is one major headache. snprintf, on the other hand, is simple, to the point, and clean. You still have to make sure the buffer is terminated, but that's all. > As such, whoever writes >the code in the first place gets to choose the way it's done. > Agreed, assuming ALLof my previous arguments are rejected. > What if >I apply that patch and someone sends a patch tomorrow changing the >sprintfs back into strcats because he prefers that? Should I apply >it? After all he took the time to submit it too... > > I said that due to the wall to wall agreement over the superiority of sprintf/snprintf. If there is a consensus, we should stick to it. Shachar

Dec. 1, 2002

Re: "not enough space in GDI heap" / forking vstlib programs

by Kjetil S. Matheussen

On Sun, 1 Dec 2002, Uwe Bonnes wrote: > Kjetil> So is there a way around this error. Doing a fork for each new > Kjetil> plug-in perhaps? Is that safe? I want to do that also to avoid > Kjetil> having a plug-in crash the vst-server. > > Did you get this error with a recent wine version? I hadn't had this errors > for some time now. > Yes, Wine-20021031. How about forking a winelib program, is that legal? --

Dec. 1, 2002

Screenshots v0.1

by Brian Vincent

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here: http://www.theshell.com/~vinn/ss/preview.html Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money. Random notes: - there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it - you can find all of the screenshots at: http://www.theshell.com/~vinn/ss - the images predominantly are PNG, though there are quite a few JPEGs. No GIF. - Special thanks to: Thomas Wickline Carlos Lozano David Buchmann Guido Grazioli Ender Juliasz Gonera Michael Krasucki Mike Hearn Rick Romero Robert Shade Rory King Tony Lambregts tavis Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those. Also, a few weeks ago there was a lot of discussion of a new WineHQ site. Any progress on that front? -Brian Vincent

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > Well - still snprintf is more efficient. I don't think so, but feel free to provide benchmarks. > But there is also no reason not to welcome these submissions if > someone already took the time to submit them. There's no objective reason why sprintf is better than strcat in that case, it's purely a matter of personal taste. As such, whoever writes the code in the first place gets to choose the way it's done. What if I apply that patch and someone sends a patch tomorrow changing the sprintfs back into strcats because he prefers that? Should I apply it? After all he took the time to submit it too... -- Alexandre Julliard julliard(a)winehq.com

Dec. 1, 2002

Re: "not enough space in GDI heap" / forking vstlib programs

by Uwe Bonnes

>>>>> "Kjetil" == Kjetil S Matheussen <k.s.matheussen(a)notam02.no> writes: Kjetil> Hello, as I just announced I'm developing a vst-server, that Kjetil> loads and runs windows vst plugins. But after loading and Kjetil> unloading a lot of plugins, I get lots of Kjetil> "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for Kjetil> 24 bytes" errors. Kjetil> I understand that the cause of this error is caused by a memory Kjetil> leak in a windows program. However, in the vst-server, there is Kjetil> no way to control memory leaks in the plug-ins, as those are Kjetil> made by various groups and persons. Kjetil> So is there a way around this error. Doing a fork for each new Kjetil> plug-in perhaps? Is that safe? I want to do that also to avoid Kjetil> having a plug-in crash the vst-server. Did you get this error with a recent wine version? I hadn't had this errors for some time now. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 1, 2002