August 2007 - Wine-Devel - list.winehq.org

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 30, 2007

Aug. 30, 2007

On Thursday August 30 2007 07:03, you wrote: > Hello, > > I have corrected a patch. Now font in the menu and a font in winecfg > coincides. Your patch still doesn't work correctly. With 120 DPI setting font size in winecfg and notepad menu is different (menu' font is bigger; no so big as before but still bigger). As I have said, in Windows font size is the same in whole system if I change DPI setting and this is (correct) behavior of current WINE too. Please note that your patch behaves even worse at higher DPI resolutions. For example if I set: "LogPixels"=dword:00000096 ...In system.reg then menu font is of ridiculosly big size. In winecfg I have normal font size suitable for my display resolution. In fact, dword:00000096 setting this is what I use in both WINE and Windows (in Windows I can just use "Custom..." menu; in WINE winecfg isn't yet sophisticated enough). In short: if DPI setting changes then font size should change in linear fashion at the same rate for all fonts. Also please explain what exactly you are trying to fix with your patch (what application)? Are you sure that Windows behaves in the same way as you proposing? Test case probably would be nice thing. Sorry, but purpose of your patch is unclear to me. In your changelog field you tell that "This patch does a font for the menu, statusbar and messages dependent from logpixels" but as far as I know WINE already have correct behavior and respects the LogPixels value (it already sets correct size in menu, status bar and other GUI elements). This is why I'm asking you for an real-world example (with real-world application) of what you are trying to fix. P.S. Don't forget to reply to wine-devel so others can see the discussion.

3 4

Re: dsound: Disable thread calls and increase refcount in dllmain
by Dmitry Timoshkov Aug. 30, 2007

Aug. 30, 2007

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Seems native directsound keeps itself loaded by calling LoadLibrary when > attaching. A simple testcase I wrote confirms that at least for xp, by > not crashing. After seeing this, I decided to write my own test, and can confirm now that this patch looks correct: after a successful LoadLibrary("dsound.dll") FreeLibrary needs to be called 2 times before it starts to return FALSE. Just for fun I tested other dlls as well (GetModuleHandle returns 0 for all of them before the LoadLibrary call): user32 requires 4 FreeLibrary calls after LoadLibrary, dinput - 1, mfc42 - 1, advapi32 - 1, comctl32 - 1. I'm attaching the program I used for testing. > + GetModuleFileNameW(hInstDLL, modname, sizeof(modname)/sizeof(*modname)); > + LoadLibraryW(modname); Probably simple LoadLibrary("dsound.dll") should be enough. -- Dmitry.

3 2

Re: winex11.drv: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (2nd try, fixes bug #9262)
by Alexandre Julliard Aug. 30, 2007

Aug. 30, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > I'm not sure if I understood how it's supposed to look like. Is > something like this good? It adds an 'if' in the inner loop, but it's > an 'if' that is easy to predict and this version makes less memory > reads so maybe it will be better. You should put the if outside the loops, and keep the existing fast case with the memcpys and add a separate slower way for when alpha needs patching. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: getting started...
by Dan Kegel Aug. 30, 2007

Aug. 30, 2007

Ed wrote: >I'm brand new to the list and would like to get a Windows application that >I wrote (uCon) to work with wine/winelib. I've submitted it to the application >database. I've tried it on Wine and it *almost* works, so I'd like to pursue >this further by building uCon with Winelib (as is recommended somewhere >in the documentation). Egads. Where does it recommend that? Using winelib is a terrible idea unless you really need it (e.g. on non-x86 platforms, it's your only option). The downside is that your app suddenly becomes very fragile with respect to user updates of wine; they need a synchronized version of your app that matches their version of Wine. I've seen this happen, and it's not pretty. Also, this means double the QA and release trouble. The Right Thing To Do IMHO is just make your app and wine work better together, not use winelib. So your next move is to file bugs in http://bugs.winehq.org describing how your app doesn't work with wine, and work with us to solve them. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 7

Re: [2/5] WineD3D: Clear unused channels on R32F and R16F textures on readback
by H. Verbeet Aug. 29, 2007

Aug. 29, 2007

On 29/08/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can you even use those formats as render target on any cards?

2 1

Re: notepad: Add program icon
by Pedro Araújo Aug. 29, 2007

Aug. 29, 2007

On 8/27/07, Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> wrote: > notepad: Add program icon > > And now for the usual Wine oath: :) > I swear under pain of treason that the icon is my own work. > > .png attached if anyone wants to look at it. It's really not all that pretty. > > Alexander N. Sørnes I had this quick and dirty (okay, *very* dirty) mockup lying around for a while (not at all a very long while) and thought somebody might find some use for it... just in case. Ah, yeah, I too "swear under pain of treason" that I did it myself. :-) (I still have the original svg here if anyone wants it) - Pedro.

2 1

Re: try2:patch for sysparams.c
by L. Rahyen Aug. 29, 2007

Aug. 29, 2007

On Wednesday August 29 2007 09:15, Ivan Sinitsin wrote: > Has corrected "logpixels=72" to " logpixels = 96 " and has changed the > indentation > > This patch adds an opportunity for fonts of the menu, statusbar and > messages to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. With your patch applied to current GIT head I have too large fonts in all menus even in notepad if for example I have set logpixels to 120 dpi using winecfg. "Too large" means MUCH larger than in, for example, winecfg itself (you need to restart the program to see the effect). See atached snapshot to see how notepad looks like with your patch if I set 120 dpi in winecfg. Font size is ridiculously big! For testing I have used clean WINE with your patch only and clean WINEPREFIX. In Windows and current WINE without your patch in clean WINEPREFIX all fonts are of same size no matter what DPI I set in LogPixels or winecfg and this is correct behavior. What application you are trying to fix?

1 0

Re: winex11.drv[2/2]: Support GdiAlphaBlend with blendfn.AlphaFormat == 0 (fixes bug #9262)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -1600,6 +1603,16 @@ #endif > for(; y >= y2; y--) { > memcpy(dstbits, (char *)dib.dsBm.bmBits + y * dib.dsBm.bmWidthBytes + xSrc * 4, > widthSrc * 4); > + if (!(blendfn.AlphaFormat & AC_SRC_ALPHA)) > + { > + int i; > + RGBQUAD *quad = (RGBQUAD *)dstbits; > + for (i = 0; i < widthSrc; i++) > + { > + quad->rgbReserved = blendfn.SourceConstantAlpha; > + quad++; > + } > + } It would be nicer to have a separate loop for that case, and do everything in one go instead of patching up the values after the copy. Also RGBQUAD is meant for color tables, it's not an appropriate type for the bitmap data itself. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (3rd try, with testcase, fixes bug #9195)
by Alexandre Julliard Aug. 29, 2007

Aug. 29, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > Is there something wrong with this patch? You should use IntersectClipRect or ExtSelectClipRgn to avoid intermediate copies. Also GetClipRgn doesn't return a region code so checking it against NULLREGION is wrong. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: patch for sysparam.c
by Paul Vriens Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > Changelog: > This patch does a font for the menu,statusbar and messages dependent from > logpixels. > > > ------------------------------------------------------------------------ > > With the latest release winecfg can set this value. The default there is 96 and the range is 96..120. How does that relate to the 72 in your code? : +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) + logpixels=72; Cheers, Paul.

1 0

Re: patch for sysparam.c
by Robert Shearman Aug. 29, 2007

Aug. 29, 2007

Ivan Sinitsin wrote: > This patch adds an opportunity for fonts of the menu, statusbar and messages > to increase depending on logpixels. > > > +size=sizeof(DWORD); > +RegOpenKeyExW( HKEY_LOCAL_MACHINE, registry_key, > + 0, KEY_QUERY_VALUE, &myhKey ); > +if (!RegQueryValueExW( myhKey, log_pixels, NULL, &type, > + (LPBYTE) &logpixels, &size )==ERROR_SUCCESS) > + logpixels=72; > +ncm.lfMenuFont.lfHeight=-MulDiv(ncm.lfMenuFont.lfHeight,logpixels,72); > +RegCloseKey( myhKey ); You're missing some indentation here. -- Rob Shearman

1 0

Re: [PATCH] Support for animated cursors
by H. Verbeet Aug. 28, 2007

Aug. 28, 2007

On 28/08/07, Trent Waddington <trent.waddington(a)gmail.com> wrote: > On 8/28/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > You should use the timing and frame sequence info from the .ani. > > Also, Xcursor actually supports proper animated cursors, so it would > > be better to handle the animation in winex11.drv > > Can you please direct me to some example code of defining and using an > animated cursor with Xcursor? > http://repo.or.cz/w/wine/hacks.git?a=blob;f=dlls/winex11.drv/mouse.c;h=b344… should be a decent start. > > As explained in the comment at the top of cursoricon.c, you can't do > > that, because it will break win16 applications. > > Umm.. what comment would that be? This one: > * Cursors and icons are stored in a global heap block, with the > * following layout: > * > * CURSORICONINFO info; > * BYTE[] ANDbits; > * BYTE[] XORbits; > * > * The bits structures are in the format of a device-dependent bitmap. > * > * This layout is very sub-optimal, as the bitmap bits are stored in > * the X client instead of in the server like other bitmaps; however, > * some programs (notably Paint Brush) expect to be able to manipulate > * the bits directly :-( > Should I replace hNext with a CURSORICONINFO *? This is what I had > initially.. or should I be using something else? Or should I just > make it an BYTE bFrames and append multiple data blocks to the end of > the CURSORICONINFO struct? > Well, what it comes down to is that you can't change the cursor memory layout for win16 applications at all, which complicates things a bit.

3 12

[PATCH] the function called is cdecl, not WINAPI
by Juan Lang Aug. 28, 2007

Aug. 28, 2007

Hi Marcus, > the function called is cdecl, not WINAPI No it isn't. It's declared that way, but it's wrong. Calling it that way in Windows crashes. That's why I sent this patch: http://www.winehq.org/pipermail/wine-cvs/2007-August/035682.html --Juan

2 2

Re: winex11.drv: test for out-of-bound src coordinates in GdiAlphaBlend (fixed, with testcase, fixes bug #7428)
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > The previous version didn't take into account that dib.dsBmih.biHeight > can be negative. You should check for negative widthSrc/heightSrc too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: tests: some values of _mbctype are dependent on the version of Windows
by Alexandre Julliard Aug. 28, 2007

Aug. 28, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -144,10 +144,18 @@ static int result_cp_949_mbctype[] = { 0 > static int result_cp_950_mbctype[] = { 0x0,65, 0x8,1, 0x18,26, 0x8,6, 0x28,26, 0x8,4, > 0x0,2, 0x4,32, 0xc,94, 0,1 }; > > +/* these characters may differ on different Windows versions */ > +static int fuzzy_cp_1252_mbctype[] = {142, 158, 170, 181, 186, -2}; > +static int fuzzy_cp_1250_mbctype[] = {131, 141, 142, 143, 157, 158, 159, 163, 165, 170, 175, 179, 181, 185, 186, 188, 190, 191, -2}; > +static int fuzzy_cp_932_mbctype[] = { -2 }; > +static int fuzzy_cp_936_mbctype[] = { -2 }; > +static int fuzzy_cp_949_mbctype[] = { -2 }; > +static int fuzzy_cp_950_mbctype[] = { -2 }; What this shows is that the exact values don't matter, and that apps are very unlikely to depend on them. This also means that having slightly different tables in Wine is not a problem, so I'd suggest to not try to test every single char, but just pick a few that are the same on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

Old versions of Photoshop Elements tryout?
by Dan Kegel Aug. 27, 2007

Aug. 27, 2007

Hi all, I have a copy of Photoshop Elements 1.0, and can easily download a tryout of Photoshop Elements 5, but I don't know where to get trial versions of 2 through 4. Anyone know? Thanks, Dan

2 3

Re: 0001-Basic-starting-point-for-implementing-d3dx9_yz.dll.patch
by Detlef Riekenberg Aug. 27, 2007

Aug. 27, 2007

On Mo, 2007-08-27 at 14:13 +0200, Martijn Berger wrote: > > --- > .gitignore | 1 + > Makefile.in | 1 + > configure.ac | 1 + > dlls/Makefile.in | 1 + > dlls/d3dx9/Makefile.in | 15 +++++++++++++++ > 5 files changed, 19 insertions(+), 0 deletions(-) > --- /dev/null > +++ b/dlls/d3dx9/Makefile.in > @@ -0,0 +1,15 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +MODULE = d3dx9.dll > +IMPORTS = wined3d kernel32 > + > +C_SRCS = \ > + d3dx9_main.c > + > +RC_SRCS = version.rc This will not work: Your Makefile.in referenced "version.rc" and "d3dx9_main.c", but this files are missing in this Patch. You should never autogenerated modifications in any Patch: http://wiki.winehq.org/Developers-Hints#head-30a7f7f51ce0e42b4141749c9832ba… -- By by ... Detlef

1 0

DIB Driver code available
by Jesse Allen Aug. 27, 2007

Aug. 27, 2007

Hi, I have my DIB driver code available on a public git host now: http://repo.or.cz/w/wine/dibdrv.git I'm going to briefly describe it. The dib driver (or engine) is a gdi driver. It is loaded into a dc when an application selects a dib, and overrides the existing driver. The magic takes place in SelectBitmap. Safe interaction is provided in gdi32 in four patches. If the winedib.drv.so library is available, then gdi will use the dib driver for drawing into the selected dib. If winedib.drv.so is not available, then gdi will continue using winex11 for example just as before. So these four patches can be safely integrated with the main tree if that is decided to be done. The rest of the code is the driver itself. It can handle all the standard uncompressed dib formats. It can convert between formats, and it can Get/SetDIBits/Blt. Get/SetPixel is implemented too. No other drawing code is done yet, so only simple GDI apps work. I've tested several apps and I'll list my results. notepad -- no regressions found winefile -- visual artifacts, but usable bmp loading -- works fine for what has been tested pixel setting -- works fine for every supported format opengl app -- Tribes 1 -- no regressions found d3d app -- Star Wars Battlefront -- no regressions found ddraw app -- Diablo shareware -- no regressions found ddraw app -- Diablo prerelease -- discovered one visual artifact These are the deficiencies in current code (non-stubs): No RLE support Missing raster operations in *Blt Get/SetDIBits does not conform exactly yet Bottom-up DIB's not tested for (and probably broken) DIB_PAL_COLORS not tested for No stretching No forwarding calls back to original driver* *For forwarding back the calls, what I think can be done is use the hbitmap handle originally given, convert it to a DDB, select it, and make the same gdi call again which will then go to the actual device. I do probably need to make sure the dibdrv's physdev persists and doesn't get deleted during this ;) (probably something in Create/Delete DC) Performance Originally I was going to state not to expect there really to be any performance improvements. I feel that there are optimizations possible that I have not done, but I left room for. My first concern was correct pixel by pixel operation. So I thought not to expect anything but last night I discovered this, so I might as well share. I have written a program that performs Get/SetPixel to test the various formats. There are 13 total tests, and the program produces 52 MB of output. Just for fun I ran my program without the dib driver and found it took a very long time (I was thinking it hung up at first since it took so long!): timed with winex11.drv real 0m53.903s user 0m19.807s sys 0m5.869s So I tried it with my driver: timed with winedib.drv real 0m3.924s user 0m3.537s sys 0m0.191s Indeed, my tests show that there is a 50 second difference with GDI Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Still, I wouldn't expect *your* app to seem much different (or work at all :P) So will all the interested parties take a look at the driver and I'd sure appreciate feedback on the direction this is going, so we move towards finishing this project beyond the summer of code. :) Jesse

3 7

Re: 0002-Basic-d3dx9-stub.patch
by H. Verbeet Aug. 27, 2007

Aug. 27, 2007

On 27/08/07, Martijn Berger <martijn.berger(a)gmail.com> wrote: > +WINE_DEFAULT_DEBUG_CHANNEL(d3d10); That's not a good idea. Also, since the dll isn't actually called d3dx9.dll, how do you intend to handle the different versions? (Arguably these dlls are outside Wine's scope, since they're not installed as part of the OS, and should be installed by the application that is using them.)

2 1

getting started...
by Ed Sutter Aug. 27, 2007

Aug. 27, 2007

Hi, I'm brand new to the list and would like to get a Windows application that I wrote (uCon) to work with wine/winelib. I've submitted it to the application database. I've tried it on Wine and it *almost* works, so I'd like to pursue this further by building uCon with Winelib (as is recommended somewhere in the documentation). That being said, I'm a bit confused... The winelib users guide mentions "winemaker", but doesn't point to where I get it. It doesn't appear to come with the Wine package (as expected); however, aside from the entire Wine source tree, I don't see anything else to download. Do I need/want the entire Wine source tree if my next step is to attempt to build my application using Winelib? Thanks in advance Ed BTW... I'm going to be doing this on a RH9 linux box.

2 3

[PATCH] Support for animated cursors
by Trent Waddington Aug. 27, 2007

Aug. 27, 2007

Test program at: http://rtfm.insomnia.org/~qg/animatedcursor.exe Probably doesn't support all the possible animated cursors supported under windows, and correct timing of animation hasn't been attempted. Trent

3 2

Re: wintrust(4/5): Test and implement SoftpubLoadMessage (with patch)
by Alexandre Julliard Aug. 27, 2007

Aug. 27, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > + ret = data->pPDSip->pSip->pfGet(data->pPDSip->psSipSubjectInfo, > + &data->dwEncoding, 0, &size, buf); > + if (ret) > + { > + data->hMsg = CryptMsgOpenToDecode(data->dwEncoding, 0, 0, data->hProv, > + NULL, NULL); > + if (data->hMsg) > + ret = CryptMsgUpdate(data->hMsg, buf, size, TRUE); > + } > + > + if (!ret || !data->hMsg) > + err = GetLastError(); > + data->psPfns->pfnFree(buf); > + return err; That style of coding is dangerous, it assumes that all the error paths of the called functions will set last error properly. It's better to return a success/failure boolean and fetch the last error only when the actual error is needed, not as an error indication. -- Alexandre Julliard julliard(a)winehq.org

1 0

[git] Playing with gitstat (can we change date for the tags?)
by Paul Vriens Aug. 27, 2007

Aug. 27, 2007

Hi, I was just playing with gitstat (http://tree.celinuxforum.org/gitstat/) to see if it give some nice graphs for Wine as well (on my local box). I can see all the tags but for some reason a lot of tags (from wine-0.0.2 to wine-0.7 and after that wine-940201 to wine-980927, so basically every tag before Alexandre's "Initial revision") have nearly the same tagger/author date (around November 30th 2005). This messes up the ordering of the tags. Is there something I can do about this? (man git-tag tells me one shouldn't change tags afterwards). (I've changed the necessary perl-script to only include the tags that are correct so I do have some output). -- Cheers, Paul.

2 1

Re: Imm32: Update position of default IME window
by Alexandre Julliard Aug. 27, 2007

Aug. 27, 2007

Aric Stewart <aric(a)codeweavers.com> writes: > + > + /* make sure we are on the desktop */ > + GetClientRect(GetDesktopWindow(),&desk_rect); You have to use GetMonitorInfo to support multi-monitor setups correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [patch] Garbage code in text string display
by Guan Xin Aug. 27, 2007

Aug. 27, 2007

On 8/23/07, Juan Lang <juan.lang(a)gmail.com> wrote: > You may generally post source to wine-devel if it's short and to the > point. Please don't post a binary. Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests. > Right to the first point, which is why we write tests that pass on > Windows, and fix Wine to match the tests. This obviates the need to > look at Windows source. You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition. Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.

2 2