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

Re: Arts, DSound, and Media Player

by Johan Gill

Jeremy Shaw wrote: >Hello, > >I am trying to get media player to work with the winearts audio >driver. I compiled the latest source from CVS, added >Drivers="winearts.drv" to the config file, and installed media player. > >When I try to play a file (like an mp3), I do not get any audio. If I >watch the elapse time, it will increment normally for a few seconds >and then start playing super fast. Also when it starts playing >super-fast I get the following error a bunch of times: > >fixme:dsound:DSOUND_MixOne problem with underrun detection >(mixlen=17640 < primary_done=49392) > > I get the impression when looking at the source that the dsound HEL simply doesn't support producing sound. /Johan Gill, johane(a)lysator.liu.se

July 3, 2002

Re: [help] GDI text fonts

by Huw D M Davies

On Wed, Jul 03, 2002 at 04:54:18PM +0800, leanne wrote: > Huw D M Davies wrote: > > > > >It's still not clear to me whether you're using XServer rendered fonts > >or client side (Wine) rendered fonts. Could you send me the > >--debugmsg +font,+xrender log ? > > > >Huw. > > > Hello, > > I have checked cvs today and found that it supports to download tt > fonts to printer but the position of the text messes up. > Maybe it's a bug. > > I still find the font of the interface is very ugly, what do you think? > Attached please find the log and screenshot. > Very thanks. > > trace:font:DumpFontList Family: L"AR PL Mingti2L Big5" > trace:font:DumpFontList L"Reguler" > trace:font:DumpFontList Family: L"AR PL KaitiM Big5" > trace:font:DumpFontList L"Regular" There's a problem with Type42 font downloads, a workaround for this to edit generic.ppd and change the line *TTRasterizer: Type42 to *TTRasterizer: None this will tell Wine to send download the font as a Type 1 outline which should work. Do you mean that the roman (English) font is ugly (since I have no idea whether the Chinese characters look ok maybe you let me know how they look)? You only have two fonts installed (see the above fragment from the log), so the english text has to come from one of these fonts. What you may want to do is to install some fonts like Arial, Times New Roman etc. You could either copy these from a Windows installation (or add a line to the [FontDirs] section of config to point at an existing Windows partition font directory), or you can download a selection of the core Windows fonts from Microsoft's website. Huw. -- Huw Davies huw(a)codeweavers.com

July 3, 2002

Re: Fix for [bug 829] DIB_DirectDrawSurface_Blt same src./dest. surface = screen corruption

by Lionel Ulmer

The patch looks fine to me. There is just one comment opn these lines : > + if (SameSurface) > + { > + static BOOL WarnSurface = FALSE; > + if (!WarnSurface) > + { > + FIXME("\tSame source and destination could cause display problems\n"); > + WarnSurface = TRUE; > + } > + } Why did you add this ? If you verified your patch and it's working, why add additionnal debug informations that will only confuse people :-) ? Moreover, I do not know the performance hit between a 'memcpy' and a 'memmove', but well, one could have put the old code in a if (!SameSurface) to have the fastest path available to the most common case. A part from these nitpicks, the patch looks fine and I will test it this evening on FalloutTactics to see if it fixes the screen corruption :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 3, 2002

Re: Still getting this error

by Steven Edwards

Sorry about that... it seems I forgot that under *nix I should be running tools/wineinstall rather then just doing a ./configure && make && make install It seems something is up with the make install, because now everything is working fine. Thanks Steven > Warning: loading builtin gdi32.dll, but native > version > already present. Expect trouble. > Warning: loading builtin user32.dll, but native > version already present. Expect trouble. > wine: Unhandled exception, starting debugger... __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

July 3, 2002

Re: Private Profile Regression Test

by Dmitry Timoshkov

"Joshua Thielen" <joshua_thielen(a)yahoo.com> wrote: > What do you think about cases 10 and 11 in > WritePrivateProfileSection where the section name is > [Strange 2]? If this section name is added twice, > windows does not replace the section as is expected > but instead adds a duplicate [Strange 2] section. I > thought this case was interesting, but I wasn't sure > if it should be tested in wine. I think your approach is completely valid. Wine regression tests should contain as much as possible various wild tests. You know, Windows applications are very unpredictable beasts :-) due to missing or misleading API documentation. > > I also have the following failures under win2k: > > > > Number of bytes read do not match > > FAIL: c:\result.ini does not match compare1.ini > > Number of bytes read do not match > > FAIL: c:\result.ini does not match compare2.ini > > I originally wrote the test in windows, but I'm afraid > something might have changed when I ported it from > windows to wine test code. How do you compile and run > the tests under windows? Using the attached patch. Since I was working on some other tests, I borrowed some code snippets from Wine test suite to not depend on the Wine testing environment and make my tests easily adjustable for Wine. What I miss in the current Wine test framework are: a) tests, expected to fail under some circumstances b) portable use of structured exception handling to test the cases which might or should crash. > If you like, you can comment out the lines with > DeleteFileA("c:\\result.ini") and then comment out > either test_WritePrivateProfileString or > test_WritePrivateProfileSection from the START_TEST > function to see the result.ini that is supposed to > match compare1.ini or compare2.ini, respectively. Yes, I cursory looked at them, but haven't enough time yet to find the source of problem. > After looking at the code again (with rested eyes), I > think that I might be missing some tests that I > intended to put in and I definitely have a few typos. > If you see anything else that needs to be added or > changed, please let me know. Sure, when I'll find some more time. -- Dmitry.

July 3, 2002

Re: MS' hidden API

by Francois Gouget

On Wed, 3 Jul 2002, P. Christeas wrote: > > > Yes, the goal of wine is to eventually run all windows applications > > (except for device drivers). However, for Wine 1.0, the focus will be on > > running a set of widely used applications, such as Microsoft Office, > > Lotus Notes, etc. Currently, many applications will work with a little > > tweaking. > > I do have an objection to that. Linux has many native applications, including > an office suite, a mailer, a perfect browser etc. Ahem, I would disagree with the perfect browser part<g>. But that's besides the point. Apparently, what you want is to see Linux succeed on the desktop. Then Office, Outlook, Money & co are a requirement. The issue is not whether they have perfectly good Linux replacements, but whether people are going to switch if that means giving up the applications they use now. Some people have good reasons not to switch to the Linux apps: for instance some user use Word add-ons for reference management, bibliographies, etc. Until similar specialized add-ons (this specific one or others) are available these people just won't switch. Other people have not so good reasons (that's not what I use), but that's irrelevant. It means they won't switch to Linux just the same (or obstruct any switch in they company). And until people switch to Linux these specialized add-ons, and the tens of thousands of specialty/professional applications you mentioned will not be ported to Linux, thus preventing large numbers of people from switching too. So the best strategy is to add support for the applications that will allow the greater number of people to switch to Linux. And it turns out that if you order applications on this criteria, they will turn out to be pretty much in the order of their popularity in the Windows world. But all the above is irrelevant since the premise "for Wine 1.0, the focus will be on running a set of widely used applications" is incorrect. This is not the focus of the 1.0 release. The focus of the 1.0 release (as far as the Wine project is concerned) is to get Wine to a stable state where we can go a fix bugs without having to reorganize three quarters of the code and to break half the applications and existing Wine/Winelib applications out there. This is why dll separation, window management and stabilization of the server protocol is on the 0.9 list. http://bugs.winehq.com/showdependencytree.cgi?id=35 We will have reached 0.9 when the the above tasks are completed. Then during the 0.9.0 to 1.0 period we will work out any left-over issue in the above items and gradually freeze the code for a 1.0 release. After that we should be able to improve Wine without breaking compatibility so much, and without having too much regression. But there is not official list of applications that 'must work in 1.0'. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

July 3, 2002

Re: MS' hidden API

by P. Christeas

> Yes, the goal of wine is to eventually run all windows applications > (except for device drivers). However, for Wine 1.0, the focus will be on > running a set of widely used applications, such as Microsoft Office, > Lotus Notes, etc. Currently, many applications will work with a little > tweaking. I do have an objection to that. Linux has many native applications, including an office suite, a mailer, a perfect browser etc. Perhaps wine-developers should not focus on porting such apps from the other system. I 've even heard that we should even drop any support to the win apps, in a try to make them obsolete. My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too. However, we couldn't make the rare apps run, until the API is mature, such that the most common ones will run, too. So, don't worry if Outlook or Money doesn't run, worry about Matlab (say..).

July 2, 2002

Re: Small 'let's prevent a crash' fix

by Huw D M Davies

On Tue, Jul 02, 2002 at 11:25:47PM +0200, Lionel Ulmer wrote: > > This does not fix the real problem (ie why does this DC not have a font even > > if the application called a 'SelectObject' on it), but well, it cannot harm > > to be more verbose and to prevent crashes if possible :-) > > OK, found the 'error' : the problem comes from the fact that I am using > client-side fonts (aka XRender) : so the 'font' part of the physDev > structure is always '0'. And that also means that we cannot use as is the > glXUseXFont function. > > So basically, I need to implement it myself using 'GetGlyphOutline' (should > not be that hard to do :-) ). > > Now my question : is 'GetGlyphOutline' always working even when not using > client-side fonts ? If yes, I will completely remove the call to > glXUseXFonts (I know, in that case, fonts displayed by OpenGL will be > different by the one displayed by X, but well, ...) and always use the > manual 'GetGlyphOutline' function. GetGylphOutline won't work if FreeType isn't available or if there are no TrueType fonts installed. At the moment the way to check for this is to look at dc->gdiFont, if this is non-NULL then gdi font rendering will work on this dc. In x11drv we do this test as well as a test for the RENDER extension at the top of X11DRV_SelectFont() and will fall back to X11 fonts if either is not present. Note though that if the dc is an x11drv dc for a non-RENDER enabled server, then dc->gdiFont will be NULL, since X11DRV_SelectFont will have returned TRUE which tells gdi to destroy any gdi font that it may have created. Huw.

July 2, 2002

Still getting this error

by Steven Edwards

With the last release I can build and use wine but with the current CVS I still get the following errors. Warning: loading builtin gdi32.dll, but native version already present. Expect trouble. Warning: loading builtin user32.dll, but native version already present. Expect trouble. wine: Unhandled exception, starting debugger... I am still not able to track down the patch that causes this. I have a clean WINE with no windows on any of my drives in my slackware box. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

July 2, 2002

Re: Small 'let's prevent a crash' fix

by Lionel Ulmer

> This does not fix the real problem (ie why does this DC not have a font even > if the application called a 'SelectObject' on it), but well, it cannot harm > to be more verbose and to prevent crashes if possible :-) OK, found the 'error' : the problem comes from the fact that I am using client-side fonts (aka XRender) : so the 'font' part of the physDev structure is always '0'. And that also means that we cannot use as is the glXUseXFont function. So basically, I need to implement it myself using 'GetGlyphOutline' (should not be that hard to do :-) ). Now my question : is 'GetGlyphOutline' always working even when not using client-side fonts ? If yes, I will completely remove the call to glXUseXFonts (I know, in that case, fonts displayed by OpenGL will be different by the one displayed by X, but well, ...) and always use the manual 'GetGlyphOutline' function. And I will try at the same time to remove all GLX calls from wgl.c and put them in special X11DRV escapes to have a real X11 free wgl.c file (ie for example, creating an OpenGL context would be a special escape for the X11DRV as it's basically something that is in GLX). Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 2, 2002