Re: RFC: Revised patchset to fix Bug 7929 (C&C 3 network does not work)
On Sun, Sep 19, 2010 at 1:13 PM, Mike Kaplinskiy wrote: > On Sun, Sep 19, 2010 at 1:33 PM, Erich Hoover wrote: >> On Sat, Sep 18, 2010 at 9:59 PM, Mike Kaplinskiy >> wrote: >>> There's enough #ifdef's to make this mostly unreadable. >> Sorry about this, I was concerned that pushing these out so that >> changes do not appear directly in the relevant code would make things >> too obfuscated. Please look at the revised patchset (at bottom). > Thanks that helps a bit. You could still do a few more of those > cleanups. These defines are no-longer in socket.c at all and they are extremely minimal in the shim ... > Also please don't make a function like WS2_shim_poll; either > make it poll-like or call it WS2_shim_select. I apologize here, this is an unfortunate case of over-zealous copy-pasting from the old code - please see the revised patches below. > ... you can still have funky stuff happening (returning 0 from > recv because all the packets were filtered out). You really need to > return EWOULDBLOCK from WS2_recv for it all to fix itself. When these additions filter out a packet after a recv() it then re-calls recv(), so it would return EWOULDBLOCK if there were no un-filtered packets. >>> You do some filtering in the server, some filtering in wine-userspace ... >> The filtering in the server is done to handle throwing packets away >> from async polls and calls that come through ReadFile. > That's what I mean - if you need to do filtering for ReadFile - do it > in ReadFile (conditionally, there is a way to check if the fd is a > socket). Besides the little scheme in the server would only fix async > ReadFile requests. If you just called ReadFile with some data pending > you would still get it even if it wasn't to the right interface. Please examine the revised patches below, patch 3 redirects ReadFile and WriteFile. >>> Alexandre's comments from last year still apply. >> Unless you're talking about the problem where descriptors are not >> invariant enough then I don't see how, these changes should make the >> peek/read combo safe across threads and processes. > This will probably have to be Alexandre's call. I was referring to his > first comment mostly. > >>> For example, now we wouldn't be able to use poll anywhere reliably on >>> sockets. >> This case should be handled in one of the patches, the revised set >> (see bottom) should make this more obvious. It looks like I missed >> locking around some polls, this issue should be corrected in the >> revised set. > That just fixes the problem in ws2_32. We still can't use poll on > sockets anywhere else (notably the server). As a consequence FD_READ > socket events would now fire for every packet. To fix that you filter > out POLLIN when necessary (which is ok), just your reasoning for doing > it is a little wrong. WSARecv overlapped requests end up on that queue > as well. It seems the comment I put on the server side is from before I had a better understanding of the server-side poll, I apologize and have corrected this issue in the patches below. I believe that I've now covered the different socket poll() cases, is there something else I'm missing here? This issue seemed to be the crux behind previous reservations on implementing this feature (such as Alexandre's first comment), so I would like to make sure that I have satisfactorily resolved this problem. Thank you for your help on all these issues, it is much appreciated. I believe the patches below will be more to your liking: [1/4] http://www.compholio.com/wine-kane/patches/2010-09-25/0001-ws2_32-tests-Add-UDP-broadcast-tests.patch [2/4] http://www.compholio.com/wine-kane/patches/2010-09-25/0002-server-Add-mechanism-for-storing-an-interface-ID-wit.patch [3/4] http://www.compholio.com/wine-kane/patches/2010-09-25/0003-ntdll-Pass-ReadFile-and-WriteFile-requests-on-socket.patch [4/4] http://www.compholio.com/wine-kane/patches/2010-09-25/0004-ws2_32-Selectively-bind-UDP-sockets-to-interfaces-wh.patch Erich Hoover ehoo...@mines.edu
Request for Assistance/Advice for Richedit EM_SETMARGINS test
All:
I've been trying to get the attached patch to pass on both the testbot
and a copy of WindowsXP that I possess.
It appears that the statement in MSDN that the USEFONTINFO information
is either incorrect or I'm doing something wrong.
The MSDN page for this information is:
http://msdn.microsoft.com/en-us/library/bb761649%28VS.85%29.aspx
I remember that WindowsXP does have Richedit 3.0
Thank you.
James McKenzie
--- a/dlls/riched20/tests/editor.c 2010-06-20 16:47:44.0 -0700
+++ b/dlls/riched20/tests/editor.c 2010-06-20 14:51:01.0 -0700
@@ -50,9 +50,13 @@
static HWND new_window(LPCTSTR lpClassName, DWORD dwStyle, HWND parent) {
HWND hwnd;
- hwnd = CreateWindow(lpClassName, NULL, dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
- |WS_VISIBLE, 0, 0, 200, 60, parent, NULL,
- hmoduleRichEdit, NULL);
+/* hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+ |WS_VISIBLE, 0, 0, 200, 60, parent, NULL,
+ hmoduleRichEdit, NULL); */
+ /* Set screen to VGA proportions for teasing purposes, will be removed from
final patch release */
+hwnd = CreateWindow(lpClassName, NULL,
dwStyle|WS_POPUP|WS_HSCROLL|WS_VSCROLL
+|WS_VISIBLE, 0, 0, 480, 640, parent, NULL,
+hmoduleRichEdit, NULL);
ok(hwnd != NULL, "class: %s, error: %d\n", lpClassName, (int)
GetLastError());
return hwnd;
}
@@ -7067,6 +7071,280 @@
DestroyWindow(hwRichEdit);
DestroyWindow(hwParent);
}
+static INT CALLBACK find_font_proc(const LOGFONT *elf, const TEXTMETRIC *ntm,
DWORD type, LPARAM lParam)
+{
+return 0;
+}
+
+static void test_em_setmargins(void)
+{
+HWND hwndRichEdit;
+RECT old_rect, new_rect;
+
+hwndRichEdit = new_richedit(NULL);
+
+HDC hdc = GetDC (hwndRichEdit);
+LOGFONTW lf;
+LOGFONTW sentLogFont;
+HFONT hfont, hfont2;
+CHARFORMAT2W CharFont1Unicode;
+
+TEXTMETRICW tmw;
+
+UINT ret;
+
+CharFont1Unicode.cbSize = sizeof(CharFont1Unicode);
+memset(&sentLogFont, 0, sizeof(LOGFONTW));
+
+if(EnumFontFamiliesA(hdc, "Arial", find_font_proc, 0))
+{
+trace("Arial not found - skipping font change margin tests\n");
+ReleaseDC(hwndRichEdit, hdc);
+return;
+}
+
+HFONT testFont = CreateFontW (12,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET,
+OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
DEFAULT_PITCH |
+FF_DONTCARE, "Courier");
+
+HFONT testFont2 = CreateFontW (12,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET,
+OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH |
+FF_DONTCARE, "MS Sans Serif");
+
+HFONT testFont3 = CreateFontW (16,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET,
+OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH |
+FF_DONTCARE, "Arial");
+
+HFONT testFont4 = CreateFontW (30,0,0,0,FW_LIGHT, 0, 0, 0, ANSI_CHARSET,
+OUT_TT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH |
+FF_DONTCARE, "Arial");
+
+memset(&lf, 0, sizeof(lf));
+strcpy(lf.lfFaceName, "Arial");
+lf.lfHeight = 16;
+lf.lfCharSet = DEFAULT_CHARSET;
+hfont = CreateFontIndirectW(&lf);
+lf.lfHeight = 30;
+hfont2 = CreateFontIndirectW(&lf);
+
+/*Initialize old_rect variable to be the size of the entire richedit
window */
+SendMessage(hwndRichEdit, EM_SETRECT, 0, (LPARAM)&old_rect);
+SendMessage(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&old_rect);
+
+/*Set Left Margin to five pixels in size */
+SendMessage(hwndRichEdit, EM_SETMARGINS, EC_LEFTMARGIN, MAKELONG (5,0));
+SendMessage(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect);
+ok(new_rect.left == old_rect.left + 5, "The left border of the rectangle
is wrong. The value of it is %d.\n", new_rect.left);
+ok(new_rect.right == old_rect.right, "The right border was changed\n");
+ok(new_rect.top == old_rect.top, "The top border was changed\n");
+ok(new_rect.bottom == old_rect.bottom, "The bottom border was changed\n");
+
+/*Set Right Margin to five pixels in size. The left margin should remain
at 5 pixels*/
+SendMessage(hwndRichEdit, EM_SETMARGINS, EC_RIGHTMARGIN, MAKELONG (0,5));
+SendMessage(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect);
+ok(new_rect.right == (old_rect.right - 5), "The right border of the
rectangle is wrong. The value of it is %d. The value of the prior margin was
%d.\n", new_rect.right, old_rect.right);
+ok(new_rect.left == old_rect.left + 5, "The left border was changed. It
changed to %d from %d\n", new_rect.left, old_rect.left);
+ok(new_rect.top == old_rect.top, "The top border was changed\n");
+ok(new_rect.bottom == old_rect.bottom, "The bottom border was changed\n");
+
+/* Test changing of Margins to a larger margin size */
+SendMessage(hwndRichEdit, EM_SETMARGINS, EC_LEFTMARGIN |
Re: [3/5] msxml3/httprequest: Add basic bind callback for moniker binding
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5482 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000 domdoc.c:2930: Test failed: got 0x8000 domdoc.c:2936: Test failed: got 0x8000 domdoc.c:2964: Test failed: got 0x domdoc.c:2979: Test failed: got 0x8000 === W2KPROSP4 (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000 domdoc.c:2930: Test failed: got 0x8000 domdoc.c:2936: Test failed: got 0x8000 domdoc.c:2964: Test failed: got 0x domdoc.c:2979: Test failed: got 0x8000 === WXPPROSP3 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === WVISTAADM (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === W2K8SE (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === W7PRO (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === W7PROX64 (32 bit domdoc) === domdoc.c:2964: Test failed: got 0x === W7PROX64 (64 bit domdoc) === domdoc.c:2964: Test failed: got 0x
Re: [5/5] msxml3/httprequest: Implement ::get_status()
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5483 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000 domdoc.c:2922: Test failed: got 0x8000 domdoc.c:2939: Test failed: got 0x8000 domdoc.c:2945: Test failed: got 0x8000 domdoc.c:2961: Test failed: got 0x8000 domdoc.c:2979: Test failed: got 0x domdoc.c:3003: Test failed: got 0x8000 === W2KPROSP4 (32 bit domdoc) === domdoc.c:2914: Test failed: got 0x8000 domdoc.c:2922: Test failed: got 0x8000 domdoc.c:2939: Test failed: got 0x8000 domdoc.c:2945: Test failed: got 0x8000 domdoc.c:2961: Test failed: got 0x8000 domdoc.c:2979: Test failed: got 0x domdoc.c:3003: Test failed: got 0x8000 === WXPPROSP3 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === WVISTAADM (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === W2K8SE (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === W7PRO (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === W7PROX64 (32 bit domdoc) === domdoc.c:2979: Test failed: got 0x === W7PROX64 (64 bit domdoc) === domdoc.c:2979: Test failed: got 0x
Re: Memory Management
Am 25.09.2010 um 05:32 schrieb Luis Carlos Busquets Pérez: > Concerning the e-mail > http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html If I remember correctly d3dx is broken by design in that regard. See D3DXCONSTTABLE_LARGEADDRESSAWARE in D3DXGetShaderConstantTableEx: http://msdn.microsoft.com/en-us/library/bb943959(v=VS.85).aspx It seems that by default native makes the assumtion that there are no pointers with the highest bit set. If the app requests large address spaces via the flag in the .exe file it is supposed to pass D3DXCONSTTABLE_LARGEADDRESSAWARE to d3dx. Obviously there are apps that don't do that, like Eve Online. Of course it'd be perfect if you can find a way that provides all the features native d3dx9 provides and doesn't rely on the address space layout. I think that the constant table functions are called often and are performance critical, so maybe this is all a nasty performance hack.
Re: [2/5] msxml3/httprequest: Implement IXMLHttpRequest::setRequestHeader()
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5481 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:2926: Test failed: got 0x8000 domdoc.c:2932: Test failed: got 0x8000 domdoc.c:2960: Test failed: got 0x === W2KPROSP4 (32 bit domdoc) === domdoc.c:2926: Test failed: got 0x8000 domdoc.c:2932: Test failed: got 0x8000 domdoc.c:2960: Test failed: got 0x === WXPPROSP3 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === WVISTAADM (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === W2K8SE (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === W7PRO (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === W7PROX64 (32 bit domdoc) === domdoc.c:2960: Test failed: got 0x === W7PROX64 (64 bit domdoc) === domdoc.c:2960: Test failed: got 0x
WineAPI wiki status update
The wiki is at http://sourceforge.net/apps/mediawiki/wineapi/index.php and this address should *not* require a Sourceforge login. At least one person has complained that this project is too Wine specific. They want it to be more generic. I do *not* plan to remove the Wine specific content, but I have labeled it with the prefix 'Wine/' so there will be space for content specific to other projects. I have to admit that the format is pretty UGLY with too much information crammed into too little space. I have received some suggestions on how this can be improved. I intend to act on those suggestions, but not right now. I need to put the content in and assure that it is correct before I get into aesthetics. If someone wants to help with this, let me know. There are now links to every directory and file in the repository and a mechanism is in place to assure that this will continue to be the case. Significant repository entries have their own wiki pages with at least one place where editable content can be added that will not be over-written by the automatic update process. There are also the usual wiki discussion pages. Most of the file related pages are simply place holders at this time, with the exception of '.spec' file pages. Please see the section below on plans before complaining about this. Statistics (very approximate) 400 Directories 3000 Files 55000 APIs identified Plans and problems. The current maintenance process is based on bash scripts with different scripts doing different parts of the analysis. Scheduling is based on a list of work items. The scripts add work items as they are discovered and remove work items as they are finished. If someone wants to try their hand at them, let me know and I'll post them to the wiki. I expect that re-writes in other languages are in order, but I do bash scripts well. My other strong languages are C and C++. I am very interested in learning Python, Perl and others. Some of the pages are HUGE and cause problems when some wiki operations are tried. In particular there are at least two '.spec' files with more than 8000 entries. The scripts need to be taught how to split these monsters into managable pieces. Some of the APIs are class-object based and their names have been mangled in the usual C++ manner. They are currently displayed in their raw form. De-mangling is needed and a separate hierarchy should be established for indexing them. A section in each standard directory has been set aside to hold API descriptions for each executable but are currently empty (and invisible as a result). Once the names have been de-mangled, I plan to fill in these sections. Header and code analysis are on queue after that, as is improving the page format. There are a bunch of old pages without the 'Wine/' prefix. They are being removed. Advice on wiki-bots would be helpful. - Max
Re: [PATCH] user32: Update Finnish translation.
On 09/25/2010 03:43 PM, Lauri Kenttä wrote: Hi! Great to see that someone is picking up the Finnish translations again (last real contribution is from 2006). I'm a bit sorry I didn't have time for this before the 1.2 release, but better late than never. :) My girlfriend will maybe send patches as well. No problem. We are all volunteers and a life besides Wine ;) Two volunteers for Finish is even better. I seem to remember that you know a lot about these resource things, so I'll bother you with a few questions: - Is it ok to use the same accelerator key for multiple items? Maybe in different submenus (File> &Save and Other> &Something)? One shouldn't have the same accelerators in one submenu. Different submenu's with same accelerators is no problem. So your example is correct. Maybe we should teach our resource compiler to warn about duplicate accelerators (or maybe even error out). - Is there some easy way to know which strings should NOT be translated, e.g. "Microsoft\\Windows\\GameExplorer" and "OEM Links" and such? Or does the resource file contain only the things that basically should be translated? I guess 99% is translatable. The ones you mention have more to do with how a Finish Windows version would show up. These should be translated if users would otherwise be confused. - What about the license? FSF doesn't provide a Finnish version. Which one is best: English only, unofficial translation only, or both? If there is no official LGPL license in your language, you can just use the English one. Thanks for your help. It's is me/us who should thank you! -- Cheers, Paul.
Re: Memory Management
Luis Carlos Busquets Pérez wrote: > Concerning the e-mail > http://www.winehq.org/pipermail/wine-devel/2010-April/082900.html > > it seems that it is broken because in wine there is no way to ensure > that the string will be in the lower 2GB. Wine behaviour depends on what application requests. You can't make Wine implementation rely on something that could change from app to app. -- Dmitry.
Re: parallel make broken somehow
Works fine here with -j7/-j8 on an i7 860 (today's git). J. Leclanche On Sat, Sep 25, 2010 at 9:18 AM, Marcus Meissner wrote: > Hi, > > + make -j4 depend > config.status: creating tools/Makefile > config.status: creating tools/Makefile > make[1]: Entering directory > `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools' > gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 > -D__WINESRC__ -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits > -Wwrite-strings -Wpointer-arith -Wno-unused-result -DLDAP_DEPRECATED=1 > -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector > -funwind-tables -fasynchronous-unwind-tables -g -o makedep.o makedep.c > make[1]: Entering directory > `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools' > gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o makedep > makedep.o > makedep.o: file not recognized: File truncated > collect2: ld returned 1 exit status > make[1]: *** [makedep] Error 1 > make[1]: Leaving directory `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools > > It seems we start to build tools/ twice at the same time. > > Ciao, Marcus > > >
parallel make broken somehow
Hi, + make -j4 depend config.status: creating tools/Makefile config.status: creating tools/Makefile make[1]: Entering directory `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools' gcc -c -I. -I. -I../include -I../include -I/usr/include/freetype2 -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wno-unused-result -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o makedep.o makedep.c make[1]: Entering directory `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools' gcc -DLDAP_DEPRECATED=1 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o makedep makedep.o makedep.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [makedep] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/wine-1.3.3.20100924/tools It seems we start to build tools/ twice at the same time. Ciao, Marcus
