September 2003 - Wine-Devel

text edit box not painting text ( on form startup )
by Doug Herbert March 9, 2005

March 9, 2005

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Wine history draft
by Brian Vincent (C) Jan. 27, 2004

Jan. 27, 2004

I put together the following: http://users.theshell.com/~vinn/wine-history.html There's two major additions I'd like to see and I don't think I'm capable of doing them: 1) Wine history from 1994 - 1999 with a specific emphasis on changes to the architecture, design decisions that got discarded, developers who've come and gone. 2) Specific quotes from over the years. I sort of put some examples of that in the document above. Humorous quotes would be especially nice. If no one has any suggestions then I'll likely just remove the existing ones and add the information to the relevant paragraphs. I'm also thinking of adding a paragraph on the tools and programs developed for Wine. Comments / suggestions / criticisms? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

4 3

Configuration parameters
by Dimitrie O. Paun Nov. 22, 2003

Nov. 22, 2003

Hi folks, I've finally managed to do the table I've promised for so long. My appologies for the delay. This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon. Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well. -- Dimi.

7 20

Wine lecture slides
by Shachar Shemesh Nov. 4, 2003

Nov. 4, 2003

Hi all, I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

9 16

Window refresh problem with GroupBox and Tabs
by George Marshall Oct. 21, 2003

Oct. 21, 2003

Hi I've already submitted this bug to the wine bugzilla but I'm posting it here as well 'cause... oh well you know. Pls. look at the end of the message for .gifs Bug 1689 follows: I've got an application which purpose is to just reproduce the wine bug I'm gonna explain below. There is, basically, a window, a tab control with four tabs, some GroupBoxes and a few editboxes. (Please, see the attached .gif to get an idea). Here we go with the interesting part... If you run the application you'll realize that some editboxes are not drawn at all and some other not correctly drawn (Expecially if you go through the tabs...) Now if you minimize and then raise this window or drag part of it out of the screen and then back in, everything in it is correctly "painted". The pic tabwin_ok.gif shows the application correctly drawn, while in tabwin_bad.gif you'll see the application in its bad behavior (Like described above). Another interesting thing to note is that if you go through the tabs backward( from the last one to the first one ) the window contents is correctly drawn, not if you go from the first tab to the last one. This is always reproducible. This bug is 100% reproducible with Wine 20030813, 20030709, 20030618 (the versions I could work with...) I'm actually trying to fix this by myself (an ugly workaround will do the job as well) but any help to get me to the right direction will be appriciated. You're more than welcome to ask for any debug or strace log. Thanks. http://bugs.winehq.org/attachment.cgi?id=359&action=view http://bugs.winehq.org/attachment.cgi?id=360&action=view

2 2

uxtheme.dll
by Kevin Oct. 3, 2003

Oct. 3, 2003

I started work porting a windows app using winelib, and hit an issue relating to the fact that there is currently no implementation of uxtheme.dll (and more importantly, no headers, of which would be enough to compile the app as it dynamically loads all the uxtheme dlls as needed, and falls back gracefully) Because of this, I've been thinking about beginning an implementation of uxtheme.dll. I am curious if someone has already taken up this task, or if anyone any opinions on this topic. Thanks Kevin

13 16

Re: Misc bugs found by using valgrind
by Shachar Shemesh Oct. 2, 2003

Oct. 2, 2003

Michael Günnewig wrote: >Changelog: > Fixed use of uninitialized memory and wrong buffersize (found by valgrind). > > > Michael > > > >------------------------------------------------------------------------ > >--- dlls/avifil32/api.c.SAV 2003-09-20 16:14:45.000000000 +0200 >+++ dlls/avifil32/api.c 2003-09-20 14:46:10.000000000 +0200 >@@ -1009,7 +1009,7 @@ > szFilter[0] = 0; > szFilter[1] = 0; > >- wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter); >+ wszFilter = (LPWSTR)GlobalAllocPtr(GHND, cbFilter * sizeof(WCHAR)); > if (wszFilter == NULL) > return AVIERR_MEMORY; > > What are we doing to prevent integer overflow on these allocations? Shouldn't we, perhaps, use some wrapper that checks that "cbFilter*sizeof(WCHAR)" is not greater than "MAXINT"? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

3 3

Re: Updated winetests.exe
by Ferenc Wagner Oct. 1, 2003

Oct. 1, 2003

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On September 27, 2003 07:42 pm, Jakob Eriksson wrote: > >> Do you want a second file generated apart from the mail >> sent to wine-tests-report? (If yes, where should this >> file be sent?) > > I'm not sure I like this idea. Correlating the two files > is potentially problematic, the best thing is if we bundle > this information somehow into the report itself. This way > the results can be interpreted context-free, which is a > good thing. I did not like this idea either, but decided to go with it in the end. First, to generate summaries I have to correlate files anyway, which *is* problematic already, and having a master file could only make it simpler and also make the cause more obvious if some inconsistency is found. Second, we want to include build failure reports, which can be lengthy (eg. compiler logs), and do not seem to belong to the test results. For an example, see how the dsound test build failure is noted on the page. The summary line could also easily be customized. > Maybe we can simply add a flag to the tests so that the > first thing they do when we run them is to output all this > information How is it better than recording the info at the build stage? Since it has nothing to do with the running environment, that would also feel more natural to me. Sure, all the info could be included in the reports, but I see no point in bloating them with too much static info for little (if any) benefit. One more thing, I really do not have the faintest idea about how to integrate this into the WineHQ page. There may be reasons there, too, like eg. the need to notify the system about a new build, which could be done by uploading the information skeleton... Feel free to persuade me, I am not attached. Feri.

4 7

Re: winealsa: improve sound quality for IDsDriverImpl
by Jerry Jenkins Oct. 1, 2003

Oct. 1, 2003

> > If the behavior is subject to change, there is no way you can test > that at configure time. This needs to be a run time check. > You're right. So I put some code in configure.ac, try to compile & run it when configure is executed. If everything is OK, a macro will be defined in config.h.

3 6

Re: PATCH: stop crashes in desktop mode
by Alexandre Julliard Sept. 30, 2003

Sept. 30, 2003

Alex Pasadyn <ajp(a)mail.utexas.edu> writes: > This patch just puts in a simple check that traps this condition so > Wine doesn't crash. I don't know enough about what that code is > supposed to be doing to fix it properly. (This is certainly better > enough on my system though as it longer crashes!) If someone wants to > describe what "should" happen there I can look into really fixing it. The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process. -- Alexandre Julliard julliard(a)winehq.com

7 14

"Start menu" (continued ...)
by Robert van Herk Sept. 30, 2003

Sept. 30, 2003

Hi all... As I understand, right now there are various "standards" on how to write menus for Linux, that are incompatible. That would mean that writing a "grand unified ;-)" start menu client as I discussed before is currently impossible. What could be made already though, is a Wine deamon that talks to shell32.dll internally and input/outputs with pipes to some linux client, in order to serve the start menu items. This would link the Windows start menu to Linux, in a tidy way. So the idea is that the Windows program's output could be piped to some Linux client that actually creates the menu dynamically, so it stays in continuous synchronization with your Start menu directory. The Linux client cannot be made unified yet, but I suppose I could at least write a client for KDE. It wouldn't be to messy to add other clients later for other desktop enviroments, since the deamon does not have to change in order to do so. That is, only the neccesairy thingies change. From looking at the help files I suppose KPanelAppMenu could do the trick. Would such a system be appreciated by the you people? Or do you think I should wait untill a better standarization is available? Or do you think creating a Windows deamon and a Linux client is too much overkill for such a feature? Also, if this feature would be handy, does anyone have expirience with the KPanelAppMenu? I can't get the thingy to work yet... Grtz, Robert

2 1

Re: Script to compile Wine programs on Windows
by Dimitrie O. Paun Sept. 30, 2003

Sept. 30, 2003

> I don't think that's a real problem, these files don't change > often. It certainly doesn't justify adding a complicated > infrastructure to deal with it. Indeed, I said, and I let it go. But thinking a little more about it, I don't see how you solve the problem with the manual stuff. As I understand it, the problem we need to solve is as follows: -- store rule in Make.rules.in -- handle multiple .rc files per Makefile -- rebuild .res file automatically if .rc or .bmp change Now, in my proposal we have: In Make.rules .rc.extract: bin2res $< && touch $@ %.res: %.rc %.extract $(WRC) -o $@ $< In make depend: bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.extract rsrc.res: bitmap1.bmp bitmap2.bmp bitmap3.bmp rsrc.extract: rsrc.rc The only complication here is the .extract file which allows us to split the dependencies from the rules. The complicated stuff are the dependencies, but you need those anyway. A simple marker file is a small price to pay for the convenience... If you think we can keep it simpler, can you please tell me a bit more of what you have in mind? How are we going to use that $(RCBINARIES) if we have more than one .rc file per Makefile? -- Dimi.

4 7

Re: PATCH: server/trace.c cleanup (RETRY)
by Alexandre Julliard Sept. 30, 2003

Sept. 30, 2003

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > [ 2nd attempt. I really don't see any viable alternative to these > casts; keeping the status quo certainly seems bad. ] That code is generated, there's no point in fixing it. You need to change tools/make_requests. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: shlwapi 405/406
by Robert Shearman Sept. 30, 2003

Sept. 30, 2003

Hi, Just a few comments on an otherwise good patch: > -static BOOL URL_JustLocation(LPCWSTR str) > +static BOOL WINAPI URL_JustLocation(LPCWSTR str) ... > -static LPCWSTR URL_ScanID(LPCWSTR start, LPDWORD size, > WINE_URL_SCAN_TYPE type) > +static LPCWSTR WINAPI URL_ScanID(LPCWSTR start, LPDWORD size, > WINE_URL_SCAN_TYPE type) Is there any reason for changing the calling convention of these two functions? > +/**************************************************************** > ********* > + * MLBuildResURLA [SHLWAPI.406] > + * > + * See MLBuildResURLA. > + */ > +HRESULT WINAPI MLBuildResURLW(LPCWSTR lpszLibName, HMODULE hMod, > DWORD dwFlags, > + LPCWSTR lpszRes, LPWSTR lpszDest, > DWORD dwDestLen) > +{ > + static const WCHAR szRes[] = { 'r','e','s',':','/','/','\0' }; > +#define szResLen (sizeof(szRes)/sizeof(WCHAR) - sizeof(WCHAR)) Should this not be #define szResLen (sizeof(szRes)/sizeof(WCHAR) - 1) ? > + HRESULT hRet = E_FAIL; > + > + TRACE("(%s,%p,0x%08lx,%s,%p,%ld)\n", debugstr_w(lpszLibName), > hMod, dwFlags, > + debugstr_w(lpszRes), lpszDest, dwDestLen); > + > + if (!lpszLibName || !hMod || hMod == INVALID_HANDLE_VALUE || > !lpszRes || > + !lpszDest || (dwFlags && dwFlags != 2)) > + return E_INVALIDARG; > + > + if (dwDestLen >= szResLen + 1) > + { > + dwDestLen -= (szResLen + 1); > + memcpy(lpszDest, szRes, sizeof(lpszDest)); > + > + hMod = MLLoadLibraryW(lpszLibName, hMod, dwFlags); > + > + if (hMod) > + { > + WCHAR szBuff[MAX_PATH]; > + > + if (GetModuleFileNameW(hMod, szBuff, sizeof(szBuff)/sizeof(WCHAR))) > + { > + DWORD dwPathLen = strlenW(szBuff) + 1; > + > + if (dwDestLen >= dwPathLen) > + { > + DWORD dwResLen; > + > + dwDestLen -= dwPathLen; > + memcpy(lpszDest + szResLen, szBuff, dwPathLen * sizeof(WCHAR)); > + > + dwResLen = strlenW(lpszRes) + 1; > + if (dwDestLen >= dwResLen + 1) > + { > + lpszDest[szResLen + dwPathLen + dwResLen] = '/'; > + memcpy(lpszDest + szResLen + dwPathLen, lpszRes, > dwResLen * sizeof(WCHAR)); > + hRet = S_OK; > + } > + } > + } > + MLFreeLibrary(hMod); > + } > + } > + return hRet; > +} Rob

4 8

Re: Start menu (especially for Alexandre Julliard)
by Mike McCormack Sept. 30, 2003

Sept. 30, 2003

Robert van Herk wrote: > Mike McCormack wrote: > >> Ideally, you'd want to write a Gnome VFS module that calls shell32.dll >> and queries the shell name space to generate the start menu the same >> way Windows does. You need to use some RPC mechanism to do that, as >> you can't link wine dlls directly into your gnome vfs module. > > > Oof, that sounds hard to do ;-). > > Does this mean that this module would rather be a "Windows" program (or > Wine program if you like), than a Linux programme? Because I guess that > with a Win32 program it would be easier to access shell32.dll. Although > that would not blend so well into your Linux environment I guess... > > Or maybe it is possible to write a thin Windows deamon that kinda serves > the icons and links to a Linux program? Maybe they can talk though > std/in std/out so that they could be piped together? > > Any ideas on that? What I'm talking about would be, like you say, a Windows daemon that servers the icons and pathes. The client and server would communicate with each other via a pipe or something like that. The client(s) would be a gnome vfs library, the KDE equivilent, or perhaps even plugins for other desktops. To make it easier, i guess you could just make the windows daemon enumerate the .lnk files in Windows/Start Menu first, then once you have that working, make it query the shell instead. The appropriate code from Gnome to look at is in the gnome cvs: :pserver:anonymous(a)anoncvs.gnome.org:/cvs/gnome the module names are: gnome-vfs gnome-vfs-extras gnome-panel I was looking at xml-rpc for the protocol to use on the pipe, but that might be a bit of an overkill, and it could be easier to write the protocol yourself. http://www.xmlrpc.com/directory/1568/implementations If you are going to use xml-rpc, make sure to choose an implementation that is LGPL compatible. Mike

2 1

RE: Wineconf 2004, otherwise known as...
by Steven Edwards Sept. 30, 2003

Sept. 30, 2003

Hey Jer, I will try to be there. I can't speak for the rest of the ReactOS developers but I think we may have one or two that would like to come. I have always wanted to see the Russian Winter so I guess St. Paul in January is good practice. Thanks Steven > -----Original Message----- > From: wine-devel-admin(a)winehq.org > [mailto:wine-devel-admin(a)winehq.org]On > Behalf Of Jeremy White > Sent: Friday, September 26, 2003 5:41 PM > To: wine-devel(a)winehq.com > Subject: Wineconf 2004, otherwise known as... > > > ...making good on my threat. > > We are making plans to host Wineconf 2004, > in St. Paul, MN, during January 2004. > > This is the last chance for someone in Europe to volunteer > to organize it in their neck of the woods... > > Otherwise, we plan to provide: > * A meeting space for 2 days > * Arrangements for moderately price hotel rooms > * Advice on transportation, which should be straightforward > * A meal or two, and drinks for at least one evening > * We'll have all CodeWeavers Wine hackers in town for the event > * Free buttons for the St. Paul Winter Carnival: > http://www.winter-carnival.com/ > <grin> > > What we will expect you to provide: > * Your airfare (sorry, no IPO money for us) > * Your hotel room > * A laptop with wireless > * Long underwear and Parkas > > What I don't know yet: > * We may need to charge some sort of modest fee, > depending on how the budget and our bank account > look. We're willing to shoulder some costs, > but we may need extra help. We'll also plan on > using the Wine party fund to help cover some costs. > * Exact dates; my thinking is to do it in conjunction > with a weekend (e.g. Fri/Sat or Sun/Mon), but > I want to see what meeting space cost/availability > looks like before I pick. Right now, Fri Jan 16th/ > Sat Jan 17th are looking good (note that LinuxWorld NY > is the following week for those that might be able > to get their employer to sponsor the trip Stateside). > > > Thoughts? Comments? > > If you think you would come, please email me privately; > I'd like to get a rough count to help with planning. > > Cheers, > > Jeremy __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

5 5

Wineconf 2004, otherwise known as...
by Jeremy White Sept. 30, 2003

Sept. 30, 2003

...making good on my threat. We are making plans to host Wineconf 2004, in St. Paul, MN, during January 2004. This is the last chance for someone in Europe to volunteer to organize it in their neck of the woods... Otherwise, we plan to provide: * A meeting space for 2 days * Arrangements for moderately price hotel rooms * Advice on transportation, which should be straightforward * A meal or two, and drinks for at least one evening * We'll have all CodeWeavers Wine hackers in town for the event * Free buttons for the St. Paul Winter Carnival: http://www.winter-carnival.com/ <grin> What we will expect you to provide: * Your airfare (sorry, no IPO money for us) * Your hotel room * A laptop with wireless * Long underwear and Parkas What I don't know yet: * We may need to charge some sort of modest fee, depending on how the budget and our bank account look. We're willing to shoulder some costs, but we may need extra help. We'll also plan on using the Wine party fund to help cover some costs. * Exact dates; my thinking is to do it in conjunction with a weekend (e.g. Fri/Sat or Sun/Mon), but I want to see what meeting space cost/availability looks like before I pick. Right now, Fri Jan 16th/ Sat Jan 17th are looking good (note that LinuxWorld NY is the following week for those that might be able to get their employer to sponsor the trip Stateside). Thoughts? Comments? If you think you would come, please email me privately; I'd like to get a rough count to help with planning. Cheers, Jeremy

9 12

[ANN] Conformance testing campaign
by Ferenc Wagner Sept. 30, 2003

Sept. 30, 2003

Greetings! Hereby I ask people who have access to real Windows machines to help me gather information about the behaviour of cross- compiled conformance tests on the different platforms. Please go to http://afavant.elte.hu/~wferi/wine for details. If you can build the tests in the Wine tree by MSVC, then packaging the compiled binaries would also mean a valuable addition. You will also find a packaging script on the page. Thanks for your time, Feri.

9 39

wine & ccache
by Dimitrie O. Paun Sept. 30, 2003

Sept. 30, 2003

Hi folks, Just wanted to let people know that ccache works rather well with wine. On my lowly 600MHz Pentium box, it takes about 1h to compile, after a make clean. Second time through it takes about 1/4h to do the same thing, 75% faster! (As an added bonus, CPU utilization dropped from 86% to 60%) A nice thing would be to also be able to generate a top Makefile that knows all about the project, and we no longer do the recursive descent. It takes my box almost 20 seconds to do a 'make -s' after a full build. Not sure how doable this is, but I'm sure that things would be way faster if everything would be in one big Makefile. Probably I'm just going to end up buying a faster box before this gets implemented though :) How long does it take to do a 'time make -s' after a full build on one of the beefier boxes? -- Dimi.

6 8

Start menu (especially for Alexandre Julliard)
by Robert van Herk Sept. 30, 2003

Sept. 30, 2003

OK people, As I understand (from the explanation by Russell Howe (thanx:-))), there is a script called wineshelllink that is supposed to install the created start menu items in your KDE menu. First of all: this script does not seem to do anything on my installation (Slackware 9). Are there known problems with this script? Second: from looking at the script it seems that this menu is not synchronized with the actual contents of your start menu, which would seem more fancy to me. Because Windows users will be aquainted with the fact that the Start menu directory actually contains the contents of the start menu. What I would propose is a system in which the contents of the wine menu would be in continuous synchronization with your start menu. That would mean: * Less error prone coding (no need for extra scripts etc) * More forward functionality (moving in the folder will actually result in moving in the menu as well) * Better support for applications (links that are not written through api calls will actually show up as well) * Ability to copy links between Windows installation and Wine installation Wouldn't you agree such a system would be better? Grtz, Robert

2 1

Trouble installing MS SQLserver 2000 Client Tools
by Craig Davison Sept. 30, 2003

Sept. 30, 2003

Hi, I've been trying to install the SQLserver Client Tools with Wine 20030911 (on Redhat 9). The setup process fails near the beginning because it cannot install MDAC ("Setup is installing Microsoft Data Access Components (MDAC) ..."). It exits with a dialog that says "Installation of the Microsoft Data Access Components package failed. (-1)". The following console messages are displayed: fixme:process:CreateProcessA (F:\standard\x86\other\sqlredis.exe,...): CREATE_SEPARATE_WOW_VDM ignored fixme:win32:PE_CreateModule Security directory ignored fixme:process:CreateProcessA (E:\IXP001.TMP\setupre.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:string:MultiByteToWideChar MB_USEGLYPHCHARS not supported fixme:string:MultiByteToWideChar MB_USEGLYPHCHARS not supported fixme:string:MultiByteToWideChar MB_USEGLYPHCHARS not supported fixme:string:MultiByteToWideChar MB_USEGLYPHCHARS not supported I can't install MDAC standalone (MDAC_TYP.EXE from microsoft's website) either, but I don't think that matters because SQLserver setup will always try to install MDAC. Note that I have IE 5.5SP2 installed, and I think DCOM98 (I can't tell if that failed or succeeded) according to instructions in the WineHQ appdb. Wine is emulating "win98". Any hints? Thanks

2 1

Re: [dx82] Recode all the lights support
by MichaelGuennewig＠gmx.de Sept. 30, 2003

Sept. 30, 2003

Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > Changelog > > MaxActiveLights means number of concurrent lights, but any number can > be set up. Change support for lights into a linked list and only set > up an equivalent gl light when the light is enabled. > > Jason > > PS If this causes any regressions please let me know. I have tested it > as far as possible and havent seen anything wrong with it. When trying to playing "The Elder Scrolls III: Tribunal" version 1.4.1313 german I get now the following fixme's: fixme:d3d:IDirect3DDevice8Impl_LightEnable Light enabled requested but light not defined, so defining one! Now the cone's of the lights are visible on surfaces near a source. Looks better now, but the known issues (body texture missing, crash after a while) still persists. Michael

1 0

Question about WineX licences
by Jonathan Wilson Sept. 30, 2003

Sept. 30, 2003

From what I understand, if you download the WineX source tree, you get code under LGPL, code under X11 and code under APL (which is basicly a licence chosen to make sure that others cant just grab those bits and use them) Does anyone know which bits are under APL? I know the directx bits are but what else is TransGaming holding back?

5 8

Re: winealsa: improve sound quality for IDsDriverImpl
by Alexandre Julliard Sept. 30, 2003

Sept. 30, 2003

Jerry Jenkins <Jerry_J_Jenkins(a)hotmail.com> writes: > Based on this thought, I need a function to retrieve the buffer. Then > I found that snd_pcm_mmap_begin is the right one. But no documents > said that it is responsible for return the driver's buffer. Well, I > can verify that, and the result is really delightful for the time > being. In the long run I prefer the configure time check. I can check > that at runtime in DSDB_MMAPCopy and print some messages if the > behavior of snd_pcm_mmap_begin changes, but I can't prevent others > from accessing the buffer before DSDB_MMAPCopy check it. If the behavior is subject to change, there is no way you can test that at configure time. This needs to be a run time check. -- Alexandre Julliard julliard(a)winehq.com

1 0

Fix for bug 640 - moving thin frames leaves mess
by Pavel Roskin Sept. 30, 2003

Sept. 30, 2003

Hello! I've made a patch for http://bugs.winehq.org/show_bug.cgi?id=640 I'm sending it here because I don't 100% sure it's ready for wine-patches. But the patch fixes an important problem and I don't want it to be unnoticed. On certain versions of XFree86 (4.2.1 + Raveon 7000/VE), focus rectangles are painted in white. Also, windows with thin frames (including all popup windows) create mess when dragged, except in when managed mode. It appears that GXxor value used in graphics/x11drv/graphics.c is misinterpreted - instead of xoring the background with the pen color, the pen color is painted as is. Another xoring doesn't hide the rectangle, thus creating mess of white dotted rectangles. The radical fix would be to avoid GXxor completely, but I'm leaving it to gurus and I'm not sure if it's needed. Fortunately, there is a correct and justifiable fix on the higher level. The focus rectangle (e.g. the rectangle around active buttons) should be painted using the system text color. Xoring this color with background is wrong. Even on systems where it works, it changes the color from black to dark gray (light gray xor white), although not too much to notice it. DrawFocusRect() has been changed to use R2_COPYPEN mode. On the other hand, draw_moving_frame() should use xor, so using DrawFocusRect() is wrong there, once the later is fixed. PatBlt() with PATINVERT works just fine with buggy XFree86 and it's already used for thick frames. The patch uses a checkered brush to imitate the dotted line. The result is very close to what I see on Windows 2000 - dotted line of one pixel wide using inverted color. In fact, the frame seems to be redrawn faster and smoother than without the patch on the system without the bug. -- Regards, Pavel Roskin

5 14