May 2005 - Wine-Devel - list.winehq.org

SEH and gcc again
by Daniel Kegel May 11, 2005

May 11, 2005

The old SEH / gcc question came up again on the gcc mailing list; see http://gcc.gnu.org/ml/gcc/2005-05/msg00511.html and followups. If anyone has anything constructive to add to that thread, this is a good chance to get the story right before it shows up on ZDNet.

1 0

Looking for win9x/ME testers
by Stefan Leichter May 11, 2005

May 11, 2005

Hello, the ole32 tests are working now for WinNT again: But they do not load on win9x/ME. Can someone with a Win9x/ME system run ole32_test.exe manualy and report the text displayed in the message box when it is started. ole32_test.exe is included in winetest-latest.exe. You can download winetest-latest.exe from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ You will find ole32_test.exe in c:\temp\wct when the tests are performed. Thanks for your help Stefan

2 1

Flattening of ddraw directory and renaming of files
by Christian Costa May 11, 2005

May 11, 2005

Hi, I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. If this is ok, I plan to submit the changes soon. Bye, Christian struct_convert.c \ convert.c -> ddraw_utils.c helper.c / d3dexecutebuffer.c -> executebuffer.c d3dmaterial.c -> material.c d3dvertexbuffer.c -> vertexbuffer.c main.c -> * regsvr.c -> * d3dcommon.c -> d3d_utils.c d3dlight.c -> light.c d3dtexture.c -> texture.c d3dviewport.c -> viewport.c mesa.c -> opengl.c d3d_private.h -> * ddcomimpl.h -> * ddraw_private.h -> * gl_api.h -> * gl_private.h -> * mesa_private.h -> opengl_private.h d3ddevice/main.c -> device_main.c d3ddevice/main.h -> device_main.h d3ddevice/mesa.c -> device_opengl.c dclipper/main.c -> clipper.c dclipper/main.h -> clipper.h ddraw/hal.c -> ddraw_hal.h ddraw/hal.h -> ddraw_hal.c ddraw/main.c -> ddraw_main.c ddraw/main.h -> ddraw_main.h ddraw/thunks.c -> ddraw_thunks.c ddraw/user.c -> ddraw_user.c ddraw/user.h -> ddraw_user.h direct3d/main.c -> direct3d_main.c direct3d/main.h -> direct3d_main.h direct3d/mesa.c -> direct3d_opengl.c dpalette/hal.c -> palette_hal.c dpalette/hal.h -> palette_hal.h dpalette/main.c -> palette_main.c dpalette/main.h -> palette_main.h dsurface/dib.c -> surface_dib.c dsurface/dib.h -> surface_dib.h dsurface/fakezbuffer.c -> surface_fakezbuffer.c dsurface/fakezbuffer.h -> surface_fakezbuffer.h dsurface/gamma.c -> surface_gamma.c dsurface/hal.c -> surface_hal.c dsurface/hal.h -> surface_hal.h dsurface/main.c -> surface_main.c dsurface/main.h -> surface_main.h dsurface/thunks.c -> surface_thunks.c dsurface/thunks.h -> surface_thunks.h dsurface/user.c -> surface_user.c dsurface/user.h -> surface_user.h dsurface/wndproc.c -> surface_wndproc.c dsurface/wndproc.h -> surface_wndproc.h Note: * = no change

5 9

Re: [QCAP] patch 3, Adding enumMediaType object
by Robert Shearman May 11, 2005

May 11, 2005

Rolf Kalbermatter wrote: >Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/qcap_main.h > dlls/qcap/enummedia.c > Add IEnumMediaType object for use by other class objects. This is >taken > from quartz with only minor adaptions. > > We should be putting these files into a static library that we can link to from quartz, qcap & other DirectShow dependent DLLs. Rob

2 1

Bug 2398
by Dustin Navea May 11, 2005

May 11, 2005

Lionel, it appears that bug 2398 is up your alley. sigh :) I was hoping it would be an easy fix.. Oh well. Its got something to do with the window/gl rewrite, if you could look at it and the regression causing patch when you get time, it would be appreciated. Thanks Dustin

3 2

(no subject)
by Jason Couture May 11, 2005

May 11, 2005

http://www.FreeMiniMacs.com/?r=18190345

1 0

Re: Commercial support
by Shachar Shemesh May 11, 2005

May 11, 2005

MediaHost (TM) wrote: > Hi All, > > I'm not sure, if winehq should be a platform for advertisements of > commercial services (except maybe codeweavers), otherwise there will > be a very long list there, very soon. That's good, in principle. The problem brought up during wineconf was that the lack of commercial support is viewed by potential deployers as a minus, making wine a dangerous technology. Saying "here is a list of companies willing to take your money and give you support" is actually a good thing for Wine. > And who to include and who not? Ah, there you have hit a more serious problem. For example, there is no doubt that CodeWeavers has been both a^Hthe major wine driving force, AND a financial sponsor. However, if we don't allow other companies room, we are unfair towards the other companies, towards CodeWeavers (why should they continue to be practically the only ones carrying the load), and towards Wine (and we don't want Wine to become a CodeWeavers subproject, do we?). I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to "in the past year". At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). Alternatively, we can have several lists. A "Gold" list, which includes companies that have the means to produce fixes to wine itself if necessary (as judged by the above criteria), and a normal list, which merely includes anyone who declares that they are willing to provide commercial support. I would have suggested a nominal fee (i.e. - a $50 contribution to the wine fund per year, or some such thing) from the last list. On the up side, it allows us to know the company is still active in this field. On the down side, I don't think we have the resources to start tracking who paid and who didn't. I could even suggest a platinum list, which would include any company that employs the equivalent of a full time Wine developer or up. Of course, this currently only includes CodeWeavers. The idea I'm trying to push here is that we can do such a list, so long as we keep clear objective criterias for who gets listed where. > Are there such plans to include such links on the website, except for > community based support? That's what we talked about over wineconf. It seems that such a list gives credibility to a project, and as such is a wanted thing. A company considering wine deployment is more likely to accept wine if they know they can get support for it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

16 46

Re: Unknown stab type in crashes
by James Hawkins May 11, 2005

May 11, 2005

On 5/11/05, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > Why not try grepping out the err:debug_help lines, so that you can read > the backtracve ? > I could do that, but the real question is do we have to display all of the debug_help error lines. The output occurrs every crash whether I'm using anything native or not. It seems to me that we could look into why we're running into unknown stab types or whether we can add handlers for these types so they wouldnt be unknown. -- James Hawkins

1 0

Re: listview: Send NM_CLICK notification when listview is clicked
by Alexandre Julliard May 11, 2005

May 11, 2005

James Hawkins <truiken(a)gmail.com> writes: > Hi, > > I verified this with native comctl32. > > Changelog > * Send NM_CLICK notification when listview is clicked. We already send NM_CLICK on button up, it doesn't look right to do it twice... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/msvcrt/files.c: Flush stdio buffers
by Alexandre Julliard May 11, 2005

May 11, 2005

wine.larry.engholm(a)xoxy.net writes: > One of the changes to file.c for revision 1.66 (2004/05/12) moved the > code to flush output buffers from _close() to MSVCRT_fclose(). The > latter function isn't called by msvcrt_free_io() which is called by > DllMain() for DLL_PROCESS_DETACH, so buffers are no longer flushed > when a program exits. Then it's msvcrt_free_io() that should be fixed, not _close(). -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug 2660
by Dustin Navea May 11, 2005

May 11, 2005

Bug 2660 is a regression, and the patch causing it is here: http://www.winehq.org/hypermail/wine-cvs/2004/12/0100.html Could someone take a look at the patch to see what may be wrong? Multiple (over 3) users are having this same problem on multiple versions of lotus notes..

4 3

Re: Assertion fails in riched20; relay debug segfaults
by Adrian Harvey May 11, 2005

May 11, 2005

> On Mon, 09 May 2005 21:44:58 +1200, Adrian Harvey wrote: > > If I try to GDB wine I get all sorts of ugly errors > > Try an strace in "follow forks mode". Does that help? > > thanks -mike Ok, here goes: $ WINEDEBUG=+relay strace -f wine execve("/usr/local/bin/wine", ["wine"], [/* 34 vars */]) = 0 [ Process PID=7877 runs in 32 bit mode. ] uname({sys="Linux", node="orac", ...}) = 0 brk(0) = 0x804a000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(0x3, 0xffffce38) = 0 old_mmap(0x1e7c500000000, 8589934593, PROT_READ|PROT_WRITE, 0xf /* MAP_??? */|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE| MAP_NONBLOCK|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED| 0xfffe06c0, 770, 0x2075c00000000) = 0x55555000 close(3) = 0 open("/usr/local/lib/libwine.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\31"..., 512) = 512 fstat64(0x3, 0xffffcecc) = 0 old_mmap(0x100000000000, 146028888067, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x4 /* MAP_??? */|MAP_FIXED| MAP_ANONYMOUS|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0x560680, 5645560, 0x80055b415) = 0x55574000 old_mmap(0x1888000000000, 8804682956805, PROT_READ|PROT_WRITE, 0x5 /* MAP_??? */|MAP_FIXED|MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE| MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x55575000 old_mmap(0x10005557b000, 8873402433539, PROT_READ|PROT_WRITE, 0x5 /* MAP_??? */|MAP_FIXED|MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE| MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x5557b000 old_mmap(0x118805557c000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x5 /* MAP_??? */|MAP_FIXED| MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE|MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x5557c000 close(3) = 0 open("/lib/tls/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\10l"..., 512) = 512 fstat64(0x3, 0xffffceb0) = 0 old_mmap(0x111dc006bc000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x6bc000 old_mmap(0x2000006ca000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x6ca000 old_mmap(0x11dc006cc000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, MAP_FILE, 0, 0) = 0x6cc000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\237"..., 512) = 512 fstat64(0x3, 0xffffce94) = 0 old_mmap(0x129c9c00565000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0x6cb12400000000) = 0x565000 mprotect(0x688000, 27804, PROT_NONE) = 0 old_mmap(0x400000689000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0x6cb12400000000) = 0x689000 old_mmap(0x1c9c0068d000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, MAP_FILE, 0, 0x6cb12400000000) = 0x68d000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\33"..., 512) = 512 fstat64(0x3, 0xffffcdf8) = 0 old_mmap(0x306400691000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x691000 old_mmap(0x200000693000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x693000 close(3) = 0 old_mmap(0x100000000000, 146028888067, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x4 /* MAP_??? */|MAP_FIXED| MAP_ANONYMOUS|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0x560680, 512, 0x80055b415) = 0x5558e000 mprotect(0x693000, 4096, PROT_READ) = 0 mprotect(0x689000, 8192, PROT_READ) = 0 mprotect(0x6ca000, 4096, PROT_READ) = 0 mprotect(0x561000, 4096, PROT_READ) = 0 set_thread_area(0xffffd644) = 0 munmap(0x55555000, 124869) = 0 set_tid_address(0x5558e928) = 7877 rt_sigaction(SIGRTMIN, {0x4006c0380, [], 0x56d6f8}, NULL, 0) = 0 rt_sigaction(SIGRT_1, {0x10000004006c03f0, [], 0x56d6f8}, NULL, 0) = 0 rt_sigprocmask(SIG_UNBLOCK, [], NULL, 0) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=-4284481536, rlim_max=0}) = 0 Bus error $ 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Well, I got some output at least! Never used strace before, but it looks kinda like a +relay trace for the kernel :-) Not sure what to make of the results, and I won't have time to look into it further til tomorrow... I also happened to be tailing the syslog (I was looking at something completely different) and I noticed that the following was written: May 11 22:50:55 orac kernel: strace[7749] trap stack segment rip:410c86 rsp:800000007b20 error:0 May 11 22:50:55 orac kernel: wine-preloader[7750]: segfault at 000000005575b624 rip 000000005575b624 rsp 00000000ffffc824 error 15 I doubt it's much use, but I thought any information might help here.... Adrian

2 1

Bug 2608 - shrinker compressed dll's cause error
by Dustin Navea May 11, 2005

May 11, 2005

This has been reported on Might and Magic 6. The file mss32.dll is compressed with a program called shrinker, when the game is installed. If another program called DeShrinker is not run on that file, MM6 refuses to run with an error. Once that is run, the game runs fine. According to the notes, there is an extra piece of information in the header in the shrinker compressed dll's called .shrink . I think this has something to do with it, but I am not totally sure. Dustin

2 1

Bug 2919
by Dustin Navea May 11, 2005

May 11, 2005

Bug 2919 is beyond my area, but there is a backtrace posted. Could someone take a look and guide me on what logs to get? Thanks P.S. If you could also tell me how to determine this information for myself, it would save the list and myself a lot of time and typing. :-) Dustin

2 1

Initial popup window and window manager
by Jose Alonso May 11, 2005

May 11, 2005

I have a problem with an application that creates a initial popup window and starts another application. The window for the second application is completely covered by the initial popup window. Investigating the problem, I found that the popup window is not managed by the window manager and no other wine or gnome window can go on top of this window (even on top windows). Making the popup window managed works for me (Fedora core 3, gnome, metacity). I don't know in other configurations. See attached patch. I am attaching also a small program to create the popup window. -- alonso

2 1

New debugging tutorials
by Mike Hearn May 11, 2005

May 11, 2005

Hi, I've added the first of what will hopefully become many debugging tutorials to the wiki: http://wiki.winehq.com/DebuggingTutorials Sometimes fixing Wine can be a bit hard to get into. Hopefully these short "show me" guides will give people a taste for what it involves and help newbies start. Please feel free to add more! They shouldn't be too advanced (so no copy protection, WM or DCOM debugging ;) but multiple levels of difficulty is fine. Ideally they should all be based on real apps. thanks -mike

2 1

Docs at SourceForge
by Dimi Paun May 11, 2005

May 11, 2005

Hi folks, As most of you already noticed, the SGML docs have moved over to the CVS SourceForge: http://sourceforge.net/cvs/?group_id=6241 They clearly did not belong in the tree, and we decided at WineConf05 to move them out of there. So we did. I have renamed the files for a more uniform naming, and dropped couple of unused files in the process. We still need to change WineHQ's scripts to point them to the new location. Help with this would be appreciated. I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to wine-patches(a)winehq.org, but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on wine-devel(a)winehq.org as per normal. The new repository is set up with translations in mind, so hopefully will be able to handle them better in the future. I'll be working with Francois to integrate the French translation shortly. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: shell32 - ShellDDEInit
by Dmitry Timoshkov May 11, 2005

May 11, 2005

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > The ReactOS guys are tired of seeing the fixme message. > > Changelog: > Implement ShellDDEInit > > Index: lib/shell32/shell32_main.c > =================================================================== > --- lib/shell32/shell32_main.c (revision 14808) > +++ lib/shell32/shell32_main.c (working copy) > @@ -979,13 +979,66 @@ > FIXME("%lx: stub\n",dw); > } > > - > +ATOM ProgmanAtom; > +DWORD hDde; > +UINT hProgmanTopic, hProgmanService, hStar, hShell, hAppProps, hFolders; > + > /************************************************************************* > * ShellDDEInit (SHELL32.@) > */ > -void WINAPI ShellDDEInit(BOOL start) > +void WINAPI ShellDDEInit(BOOL Start) > { > - FIXME("stub: %d\n", start); > + WCHAR wszSHELL_PROGMAN[] = {'P','R','O','G','M','A','N',0}; > + WCHAR wszSHELL_TOPIC[] = {'P','r','o','g','m','a','n',0}; > + WCHAR wszSHELL_SERVICE[] = {'P','r','o','g','m','a','n',0}; > + WCHAR wszSHELL_STAR[] = {'*',0}; > + WCHAR wszSHELL_SHELL[] = {'S','h','e','l','l',0}; > + WCHAR wszSHELL_APPPROPS[] = {'A','p','p','P','r','o','p', 'e', 'r', 't', 'i', 'e', 's',0}; > + WCHAR wszSHELL_FOLDERS[] = {'F','o','l','d','e','r','s',0}; > + > + if (Start) > + { > + /* Create Atom */ > + ProgmanAtom = GlobalAddAtomW(wszSHELL_PROGMAN); > + > + /* Initialize DDE */ > + DdeInitializeW(&hDde, NULL, CBF_FAIL_POKES | CBF_FAIL_ADVISES, 0L); > + > + /* Register the Strings */ > + hProgmanTopic = DdeCreateStringHandleW(hDde, wszSHELL_TOPIC, CP_WINUNICODE); > + hProgmanService = DdeCreateStringHandleW(hDde, wszSHELL_SERVICE, CP_WINUNICODE); > + hStar = DdeCreateStringHandleW(hDde, wszSHELL_STAR, CP_WINUNICODE); > + hShell = DdeCreateStringHandleW(hDde, wszSHELL_SHELL, CP_WINUNICODE); > + hAppProps = DdeCreateStringHandleW(hDde, wszSHELL_APPPROPS, CP_WINUNICODE); > + hFolders = DdeCreateStringHandleW(hDde, wszSHELL_FOLDERS, CP_WINUNICODE); > + > + /* Register the Service Names */ > + DdeNameService(hDde, hFolders, 0, DNS_REGISTER); > + DdeNameService(hDde, hProgmanService, 0, DNS_REGISTER); > + DdeNameService(hDde, hShell, 0, DNS_REGISTER); > + } > + else > + { > + /* Unregister the Service Names */ > + DdeNameService(hDde, hFolders, 0, DNS_UNREGISTER); > + DdeNameService(hDde, hProgmanService, 0, DNS_UNREGISTER); > + DdeNameService(hDde, hShell, 0, DNS_UNREGISTER); > + > + /* Free the Handles */ > + DdeFreeStringHandle(hDde, hProgmanTopic); > + DdeFreeStringHandle(hDde, hProgmanService); > + DdeFreeStringHandle(hDde, hStar); > + DdeFreeStringHandle(hDde, hShell); > + DdeFreeStringHandle(hDde, hAppProps); > + DdeFreeStringHandle(hDde, hFolders); > + > + /* Uninitialize DDE */ > + DdeUninitialize(hDde); > + hDde = 0; > + > + /* Delete the Atom */ > + if (ProgmanAtom) ProgmanAtom = GlobalDeleteAtom(ProgmanAtom); > + } > } If ReactOS guys could use 'static const' for unicode strings, make global variables visible inside of the single source file static, check whether DDE connection is being already [de]initialed and a little bit of error checking that would be even better :-) -- Dmitry.

1 0

Bug 2131 - 16-bit support?
by Dustin Navea May 11, 2005

May 11, 2005

I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit. Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason. Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 <-> 16 bit conversions?), or should I just go ahead and close it as WONTFIX? Dustin

7 11

Bug 2947
by Dustin Navea May 11, 2005

May 11, 2005

Bug 2947 is 2 issues in one, but they appear to coincide, so I didn't have him report them separately.. The patch causing this is at: http://www.winehq.org/hypermail/wine-cvs/2005/04/0290.html Its a big one too.. SO Basically, before this patch, the window did not show decorations (titlebar, etc), and the game closed fine using the exit button within the game. After this patch, though, the window shows decorations (which is preferred obviously), but the game hangs when you try to exit.. SO, reverting the patch would fix one issue, but bring back another, and you can see where I am going with this, so I don't have to say it... Dustin

1 0

[AppDB] - Application votes cleared
by Chris Morgan May 11, 2005

May 11, 2005

I cleared out the votes on the appdb tonight after fixing a few bugs with the voting system. The next step is to put into place a system that will expire votes that are older than some value, perhaps a year or two. I'll try to get that into place in the next week or two. Chris

1 0

ExtTextOut() for paths
by Felix Nawothnig May 10, 2005

May 10, 2005

Hi. The attached patch implements ExtTextOut() for "open" paths. It seems to be working correctly for my tests but... well, the code I copied from xrender.c is a total mess IMHO. Calculating cell deltas and calculating the base line origin has to be done for all kind of TrueType rendering (and most of the stuff for all other text rendering too) so most of it should maybe be put into ExtTextOutW() in gdi/font.c instead of duplicating it all over the place. But I'm not sure if this would require the drv API to be changed (which looks like it's modelled after the Win32 API on purpose) or maybe tie gdi to x11drv. Also from looking at the code it seems to me that the ExtTextOut() implementation in x11drv/text.c behaves - well - different than x11drv/xrender.c in several cases. (TA_*, rotation and break-char handling...) I really don't like the attached code but I don't feel like messing around with it more so I'll just post it here - maybe someone else can use it as a starting-point. -flx ? gdi32.spec.def Index: font.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/font.c,v retrieving revision 1.10 diff -u -r1.10 font.c --- font.c 18 Apr 2005 10:30:56 -0000 1.10 +++ font.c 10 May 2005 23:28:05 -0000 @@ -1719,35 +1719,40 @@ { BOOL ret = FALSE; DC * dc = DC_GetDCUpdate( hdc ); - if (dc) + LPWSTR lpReorderedString = NULL; + + if (!dc) return FALSE; + + if (flags&(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY)) + FIXME("flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY unimplemented\n"); + + if( !(flags&(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) && BidiAvail && count>0 ) { - if (flags&(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY)) - FIXME("flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY unimplemented\n"); + /* The caller did not specify that language processing was already done. */ + DWORD dir = WINE_GCPW_FORCE_LTR; - if(PATH_IsPathOpen(dc->path)) - FIXME("called on an open path\n"); - else if(dc->funcs->pExtTextOut) - { - if( !(flags&(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) && BidiAvail && count>0 ) - { - /* The caller did not specify that language processing was already done. - */ - LPWSTR lpReorderedString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR)); - - BIDI_Reorder( str, count, GCP_REORDER, - ((flags&ETO_RTLREADING)!=0 || (GetTextAlign(hdc)&TA_RTLREADING)!=0)? - WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR, - lpReorderedString, count, NULL ); - - ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags|ETO_IGNORELANGUAGE, - lprect,lpReorderedString,count,lpDx,dc->breakExtra); - HeapFree(GetProcessHeap(), 0, lpReorderedString); - } else - ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count, - lpDx,dc->breakExtra); - } - GDI_ReleaseObj( hdc ); + if((flags&ETO_RTLREADING)!=0 || (GetTextAlign(hdc)&TA_RTLREADING)!=0) + dir = WINE_GCPW_FORCE_RTL; + + lpReorderedString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR)); + + BIDI_Reorder( str, count, GCP_REORDER, dir, lpReorderedString, count, NULL ); + + flags |= ETO_IGNORELANGUAGE; + str = lpReorderedString; } + + if(PATH_IsPathOpen(dc->path)) + ret = PATH_ExtTextOut(dc,x,y,flags,lprect,str,count,lpDx); + else if(dc->funcs->pExtTextOut) + ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count, + lpDx,dc->breakExtra); + + if(lpReorderedString) + HeapFree(GetProcessHeap(), 0, lpReorderedString); + + GDI_ReleaseObj( hdc ); + return ret; } Index: gdi_private.h =================================================================== RCS file: /home/wine/wine/dlls/gdi/gdi_private.h,v retrieving revision 1.25 diff -u -r1.25 gdi_private.h --- gdi_private.h 13 Apr 2005 16:11:18 -0000 1.25 +++ gdi_private.h 10 May 2005 23:28:10 -0000 @@ -405,6 +405,8 @@ extern BOOL PATH_LineTo(DC *dc, INT x, INT y); extern BOOL PATH_Rectangle(DC *dc, INT x1, INT y1, INT x2, INT y2); extern BOOL PATH_Ellipse(DC *dc, INT x1, INT y1, INT x2, INT y2); +extern BOOL PATH_ExtTextOut(DC *dc, INT x, INT y, UINT flags, const RECT *lprec, + LPCWSTR str, UINT count, const INT *lpDx); extern BOOL PATH_Arc(DC *dc, INT x1, INT y1, INT x2, INT y2, INT xStart, INT yStart, INT xEnd, INT yEnd, INT lines); extern BOOL PATH_PolyBezierTo(DC *dc, const POINT *pt, DWORD cbCount); Index: path.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/path.c,v retrieving revision 1.5 diff -u -r1.5 path.c --- path.c 24 Mar 2005 21:01:38 -0000 1.5 +++ path.c 10 May 2005 23:28:13 -0000 @@ -101,6 +101,7 @@ double y, POINT *pPoint); static void PATH_NormalizePoint(FLOAT_POINT corners[], const FLOAT_POINT *pPoint, double *pX, double *pY); +static void PATH_PTFXtoPT(POINT *base_line, POINTFX *ptfx, POINT *pt); static BOOL PATH_CheckCorners(DC *dc, POINT corners[], INT x1, INT y1, INT x2, INT y2); /* Performs a world-to-viewport transformation on the specified point (which @@ -717,6 +718,287 @@ CloseFigure(dc->hSelf) ); } +/* PATH_ExtTextOut + * + * Should be called when a call to ExtTextOut is performed on a DC that has + * an open path. Returns TRUE if successful, else FALSE. + * + * TODO: Check if TA_* handling is correct + */ +BOOL PATH_ExtTextOut(DC *dc, INT x, INT y, UINT flags, const RECT *lprec, + LPCWSTR str, UINT count, const INT *lpDx) +{ + GdiPath *pPath = &dc->path; + HDC hdc = dc->hSelf; + TEXTMETRICW tm; + LOGFONTW lf; + POINT cell_origin, pt; + UINT align, ggo_format = GGO_BEZIER; + INT char_extra, adjust_origin = 0; + const WORD *glyphs; + double cosEsc, sinEsc; + int i, k, *deltas = NULL; + struct + { + POINT origin; + UINT width, height, length; + } baseline; + + /* Windows seems to do nothing and report success on ETO_CLIPPED */ + if(flags & ETO_CLIPPED) + return TRUE; + + /* This is also observed native behaviour */ + if(flags & ETO_OPAQUE) + PATH_Rectangle(dc, lprec->left, lprec->top, lprec->right, lprec->bottom); + + /* Now we do: + * - GetGlyphIndicesW() if !GGO_GLYPH_INDEX + * - Calculate cell deltas considering lpDx, + * GetTextExtentPointI() and breakExtra + * - Calculate width of the text to be rendered + * - Calculate cos/sin of rotation angle + * - Adjust text origin according to GetTextAlign(), + * the rotation angle and the text width + * + * FIXME: All this is also done in x11drv/xrender.c and much of + * it a third time in x11drv/text.c. And this is a mess. + */ + + GetObjectW(GetCurrentObject(hdc, OBJ_FONT), sizeof(lf), &lf); + GetTextMetricsW(hdc, &tm); + + if(flags & ETO_GLYPH_INDEX) + { + /* Nothing to do, input data is already in the right format */ + ggo_format |= GGO_GLYPH_INDEX; + glyphs = (const WORD *)str; + } + else + { + glyphs = HeapAlloc(GetProcessHeap(), 0, count * sizeof(WCHAR)); + GetGlyphIndicesW(hdc, str, count, (WORD*)glyphs, 0); + } + + char_extra = GetTextCharacterExtra(hdc); + if(char_extra || dc->breakExtra) + { + deltas = HeapAlloc(GetProcessHeap(), 0, count * sizeof(INT)); + for(i = 0; i < count; i++) + { + if(lpDx) + deltas[i] = lpDx[i] + char_extra; + else + { + SIZE sz; + GetTextExtentPointI(hdc, glyphs + i, 1, &sz); + deltas[i] = sz.cx; + } + + if(dc->breakExtra && str[i] == tm.tmBreakChar) + deltas[i] += dc->breakExtra; + } + } + else if(lpDx) + deltas = (INT*)lpDx; + + /* calculate length of the base line */ + if(deltas) + { + baseline.length = 0; + for(i = 0; i < count; i++) + baseline.length += deltas[i]; + } + else + { + SIZE sz; + GetTextExtentPointI(hdc, glyphs, count, &sz); + baseline.length = sz.cx; + } + + if(lf.lfEscapement != 0) + { + cosEsc = cos(lf.lfEscapement * M_PI / 1800); + sinEsc = sin(lf.lfEscapement * M_PI / 1800); + } + else + { + cosEsc = 1; + sinEsc = 0; + } + + pt.x = baseline.length * cosEsc; + pt.y = baseline.length * sinEsc; + LPtoDP(hdc, &pt, 1); + baseline.width = pt.x; + baseline.height = pt.y; + + /* GetGlyphOutline will rotate around the base line - we have to + calculate the base line origin from the text origin if we need + another reference point */ + + align = GetTextAlign(hdc); + + if(align & TA_UPDATECP) + FIXME("TA_UPDATECP not implemented\n"); + + baseline.origin.x = x; + baseline.origin.y = y; + LPtoDP(hdc, &baseline.origin, 1); + + switch(align & (TA_LEFT | TA_RIGHT | TA_CENTER)) + { + case TA_LEFT: + break; + + case TA_CENTER: + x -= baseline.width / 2; + y += baseline.height / 2; + break; + + case TA_RIGHT: + x -= baseline.width; + y += baseline.height; + break; + } + + if((align & TA_TOP) == TA_TOP) + adjust_origin = tm.tmAscent; + else if((align & TA_BOTTOM) == TA_BOTTOM) + adjust_origin = tm.tmDescent; + + if(adjust_origin) + { + baseline.origin.x += adjust_origin * sinEsc; + baseline.origin.y += adjust_origin * cosEsc; + + /* FIXME: when using TA_TOP or TA_BOTTOM and rotating by >0 degrees + windows shifts down the text by some px... we'll probably never + know how microsoft screwed up the stuff we did above but this + seems to come close to native behaviour: */ + + if(lf.lfEscapement) + baseline.origin.y += tm.tmHeight / 8; + } + /* -- end of code duplication */ + + cell_origin = baseline.origin; + + /* For each glyph */ + for(i = 0; i < count; i++) + { + char buf[65536], *p; + GLYPHMETRICS metrics; + MAT2 identity = { { 0, 1 }, { 0, 0 }, { 0, 0 }, { 0, 1 } }; /* no transformation */ + + DWORD n = GetGlyphOutlineW(hdc, str[i], ggo_format, &metrics, sizeof(buf), &buf, &identity); + + if(n == GDI_ERROR) + { + WARN("GetGlyphOutline() failed\n"); + return FALSE; + } + + p = buf; + + /* For each contour */ + while(p < buf + n) + { + TTPOLYGONHEADER *header = (void *)(p); + TTPOLYGONHEADER *next = (void *)(p + header->cb); + POINT start, pt; + + PATH_PTFXtoPT(&cell_origin, &header->pfxStart, &start); + PATH_AddEntry(pPath, &start, PT_MOVETO); + + p += sizeof(TTPOLYGONHEADER); + + /* For each curve */ + while(p < (char *)next) + { + TTPOLYCURVE *curve = (void *)p; + BYTE flags; + + if(curve->wType == TT_PRIM_LINE) + flags = PT_LINETO; + else if(curve->wType == TT_PRIM_CSPLINE) + flags = PT_BEZIERTO; + else + { + /* This should not happen since we passed GGO_BEZIER */ + ERR("GetGlyphOutlineW() retrieved TTPOLYCURVE type %d\n", curve->wType); + return FALSE; + } + + /* For each point */ + for(k = 0; k < curve->cpfx; k++) + { + PATH_PTFXtoPT(&cell_origin, &curve->apfx[k], &pt); + PATH_AddEntry(pPath, &pt, flags); + } + + p += sizeof(TTPOLYCURVE) + sizeof(POINTFX) * (curve->cpfx - 1); + } + + /* Close contour if necessary */ + if(pt.x != start.x || pt.y != start.y) + PATH_AddEntry(pPath, &start, PT_LINETO); + } + + if(!deltas) + { + cell_origin.x += metrics.gmCellIncX; + cell_origin.y += metrics.gmCellIncY; + } + else + { + cell_origin.x += deltas[i] * cosEsc; + cell_origin.y += deltas[i] * -sinEsc; + } + } + + if(tm.tmStruckOut || tm.tmUnderlined) + { + OUTLINETEXTMETRICW otm; + + GetOutlineTextMetricsW(hdc, sizeof(OUTLINETEXTMETRICW), &otm); + + if(tm.tmStruckOut) + { + POINT a = { sinEsc * otm.otmsStrikeoutPosition, + cosEsc * otm.otmsStrikeoutPosition }, + b = { a.x - sinEsc * otm.otmsStrikeoutSize, + a.y - cosEsc * otm.otmsStrikeoutSize }, + pts[4] = { { baseline.origin.x - a.x, baseline.origin.y - a.y }, + { baseline.origin.x - b.x, baseline.origin.y - b.y }, + { cell_origin.x - b.x, cell_origin.y - b.y }, + { cell_origin.x - a.x, cell_origin.y - a.y } }; + + PATH_Polygon(dc, pts, 4); + } + + if(tm.tmUnderlined) + { + POINT a = { sinEsc * otm.otmsUnderscorePosition, + cosEsc * otm.otmsUnderscorePosition }, + b = { a.x - sinEsc * otm.otmsUnderscoreSize, + a.y - cosEsc * otm.otmsUnderscoreSize }, + pts[4] = { { baseline.origin.x - a.x, baseline.origin.y - a.y }, + { baseline.origin.x - b.x, baseline.origin.y - b.y }, + { cell_origin.x - b.x, cell_origin.y - b.y }, + { cell_origin.x - a.x, cell_origin.y - a.y } }; + + PATH_Polygon(dc, pts, 4); + } + } + + if(deltas && !lpDx) + HeapFree(GetProcessHeap(), 0, deltas); + + return TRUE; +} + + /* PATH_Arc * * Should be called when a call to Arc is performed on a DC that has @@ -1403,6 +1685,18 @@ 2.0 - 1.0; } +/* PATH_PTFXtoPT + * + * Convert TrueType glyph coordinates (relative to the left side of the + * glyph's base line) into absolute coordinates. + */ + +static void PATH_PTFXtoPT(POINT *base_line, POINTFX *ptfx, POINT *pt) +{ + pt->x = base_line->x + ptfx->x.value + (ptfx->x.fract >= 0x8000 ? 1 : 0); + pt->y = base_line->y - ptfx->y.value - (ptfx->y.fract >= 0x8000 ? 1 : 0); +} + /******************************************************************* * FlattenPath [GDI32.@]

1 0

Re: UT2003 Windowing Regression - Another nights effort...
by Ann and Jason Edmeades May 10, 2005

May 10, 2005

I think I have reproduced the same problem with a simple testpgm... Instructions... 1. Start Visual Studio, create a default windows application 2. Comment out the code in the WM_PAINT and replace it with return 1 (important) 3. Run it... On windows you can play with the menu etc and it works. The CPU is at 100% but clicking on menu items works, and menu->exit does actually exit the app. (Menu->About causes a hang) On wine you get the infinite loop and the screen/menu never gets as far as being drawn Note:Its important to to return the 1 (or TRUE) - returning 0 works fine on both! Question... Is wine being too proactive - Perhaps in the case where the redraw is unsuccessful then wine should schedule a WM_PAINT rather than performing it? Note: UT2003 seems to just do: CreateWindowEx(AppWindow, Visible+..., ) ShowWindow(show no activate) UpdateWindow(rdw all children, updatenow) **hang** Jason

1 0

widl and #pragma pack(x)
by Dietrich Teickner May 10, 2005

May 10, 2005

Can it be, that widl does not work with any #pragma pack(x) statements in any header-files called from *.idl ? I have problems with mshtml.dl in the odin environment. lineno = (int)strtol(yytext, &cptr, 10); if(!lineno) yyerror("Malformed '#...' line-directive; invalid linenumber"); after #pragma pack(x) line. All widl-generated headers does never containn any #pragma pack(x) statement. Dietrich

1 0

Re: Commercial support
by gslink May 10, 2005

May 10, 2005

> IBM does very well know the existents of Wine (they even acknowledged > that by themselves lately), but may very well not support it, because of > inter-relation with MS. As of now (just a guess), they don't want to get > into more hot water right now.... > Would it be to the advantage of Microsoft to have Wine succeed? They have given Apple much support and at every class for the past several years the instructors have had a copy of Linux on every machine. A very good case can be made for Microsoft supporting Wine especially since the RH secure kernel came via NSA and may very well become a DOD standard. Perhaps Wine should formally contact Microsoft.

2 2