September 2006 - Wine-Devel

WineD3D: glBlend* fixes
by Roland Scheidegger Sept. 27, 2006

Sept. 27, 2006

> Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does > the spec. I don't know what exactly uses the min_max form. Is this a > typo? Apart from the blend_minmax typo, it appears to be me this patch has some other problems. >> This patch changes the detection extension detection for >> glBlendColor/glBlendEquation. The function glBlendColor is part of >> OpenGL 1.1 and is supported on all OpenGL implementations. No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color is an imaging subset feature, and is only allowed when the imaging subset is supported"). It is however part of OpenGL 1.4. So, a really correct detection would be to check for ogl version 1.4, EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be omitted, but it is possible there are drivers out there which only announce support for ARB_imaging but not EXT_blend_color, according to www.delphi3d.net there are indeed some tnt2's out there which claim support for ARB_imaging but not EXT_blend_color - if I'd have to guess I'd suspect the call to glBlendColor results in a sw fallback. >> Further glBlendEquation is part of GL_ARB_imaging aswell. For the >> same reason GL_ARB_imaging can't be used to detect glBlendEquation. >> This call isn't supported on all OpenGL implementations. Luckily it >> is part of 'GL_EXT_blend_min_max' so that is used now. This is not quite so simple. If OGL 1.4 is supported, or the version is lower but ARB_imaging itself is supported, all the blend function stuff from ARB_imaging is ok. If only either EXT_blend_minmax or EXT_blend_subtract is supported, then glBlendEquation is supported, but only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). But if all you care is that glBlendEquation is available, you should probably detect ogl 1.4, and EXT_blend_subtract (some cards only support EXT_blend_subtract but not EXT_blend_minmax), but really for correctness EXT_blend_minmax and ARB_imaging should be checked too. Roland (not subscribed to wine-devel - include me in cc for answers)

4 8

re: shlwapi: Resupply array sizes stripped by function interface
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

Andrew Talbot wrote: >A formal parameter declared as an array is treated as a pointer; any size >specifier is ignored. So here, sizeof decimal_buffer, for example, would >equate to the size of a pointer to WCHAR, not to that of an array of eight >WCHARs. Why are you doing this? - Dan

3 8

re: start.exe: New feature allowing to specify the shell operation name
by Dan Kegel Sept. 27, 2006

Sept. 27, 2006

>The new /O[peration] command line option allows to specify a shell >operation other than "open". > This is very valuable for testing or implementing actions from shell scripts. Hmm. I don't see that option in the Win XP documentation: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en… There's already one clash (/l) between wine's start and Windows'. I hesitate to say that adding another extension is a good idea. I'd feel better if the help mentioned that this is a Wine-specific extension. - Dan

2 2

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Hi, Dmitry Timoshkov wrote: > > > How many projects have you ever participated in? Every developers' > mailing list > of an open source I personally participated in *doesn't guarantee* not > only patch > acceptance, but even a reply with explanations why the patch has been > silently > dropped, and it doesn't matter how many maintainers a project has. Why > do you > request that from Wine, and particularly from Alexandre? > > Alexandre is not a robot, he is a human. Please take that into account. Sounds like he need more help. > > It's a metter of the fact, that if you can't cope with other people's > requirements, > you can't work in a team. > Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine . It is your job to provide support for this product, I spend money and I need help, where do I go? Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list? This project needs a course in technical sales support. Good idea for the next WineConf! Remember you represent CodeWeavers, start acting like it. 8^D, James

6 7

Re: cabinet: Fix NULL pointer dereference (Coverity)
by James Hawkins Sept. 26, 2006

Sept. 26, 2006

On 9/26/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Changelog: > cabinet: Fix NULL pointer dereference (Coverity). > > diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c > --- a/dlls/cabinet/fci.c 2006-09-12 23:59:28.000000000 +0100 > +++ b/dlls/cabinet/fci.c 2006-09-26 18:27:03.000000000 +0100 > @@ -176,18 +176,22 @@ > if ((!perf) || (!pfnalloc) || (!pfnfree) || (!pfnopen) || (!pfnread) || > (!pfnwrite) || (!pfnclose) || (!pfnseek) || (!pfndelete) || > (!pfnfcigtf) || (!pccab)) { > - perf->erfOper = FCIERR_NONE; > - perf->erfType = ERROR_BAD_ARGUMENTS; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_NONE; > + perf->erfType = ERROR_BAD_ARGUMENTS; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_BAD_ARGUMENTS); > return NULL; > } > > if (!((hfci = ((HFCI) (*pfnalloc)(sizeof(FCI_Int)))))) { > - perf->erfOper = FCIERR_ALLOC_FAIL; > - perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > - perf->fError = TRUE; > + if (perf) { > + perf->erfOper = FCIERR_ALLOC_FAIL; > + perf->erfType = ERROR_NOT_ENOUGH_MEMORY; > + perf->fError = TRUE; > + } > > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > This last check is pointless. If perf is NULL, we bail out and return NULL a few lines up. Also, please add a test showing that native does not crash if a NULL perf is sent in. It's weird, but we need to be consistent with native, as some apps depend on such a crash. -- James Hawkins

2 1

Re: Alexandre Julliard : explorer: Work around the latest HAL binary compatibility breakage.
by Marcus Meissner Sept. 26, 2006

Sept. 26, 2006

On Tue, Sep 26, 2006 at 03:04:47PM -0500, Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 9ae4e8d98efc952918bcdae86b2f640c4b062a3b > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9ae4e8d98efc952918bcdae… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Sep 26 20:29:15 2006 +0200 > > explorer: Work around the latest HAL binary compatibility breakage. > - if (!(dbus_handle = wine_dlopen(SONAME_LIBDBUS_1, RTLD_NOW, error, sizeof(error)))) goto failed; > - if (!(hal_handle = wine_dlopen(SONAME_LIBHAL, RTLD_NOW, error, sizeof(error)))) goto failed; > + /* Load libhal with RTLD_GLOBAL so that the dbus symbols are available. > + * We can't load libdbus directly since libhal may have been built against a > + * different version but with the same soname. Binary compatibility is for wimps. */ Yet another Redhat stumbling block ;) But they warn in pretty large letters: cat /usr/lib/pkgconfig/hal.pc ... Cflags: -DDBUS_API_SUBJECT_TO_CHANGE -I${includedir}/hal ... #ifndef DBUS_API_SUBJECT_TO_CHANGE #error "Please define DBUS_API_SUBJECT_TO_CHANGE to acknowledge your understanding that D-BUS hasn't reached 1 .0 and is subject to protocol and API churn. See the README for a full explanation." #endif ciao, Marcus

1 0

Using gdb
by Craig Keogh Sept. 26, 2006

Sept. 26, 2006

Hi, I am trying to use gdb for debugging. I run the command: winedbg --gdb sol.exe I then get the following output: WineDbg starting on pid 0xa fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for wine-pthread fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ntdll<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for msvcrt<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for advapi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for gdi32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for user32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for cards<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shell32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for shlwapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ole32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for rpcrt4<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for iphlpapi<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for comctl32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for winex11<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for imm32<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for uxtheme<elf> 0x7eecaf5a start_process+0xde in kernel32: movl %edi,0x0(%esp) I don't end up with a gdb prompt. It is just stuck there. I am following: http://www.winehq.com/site/docs/winedev-guide/dbg-others I compiled wine (from GIT) using gcc v4.0.3, I am using gdb v6.4-debian. Running without gdb ('winedbg sol.exe') works fine. Thanks in advance,

2 2

Problem with NtReadVirtualMemory and wine server connection
by Peter Oberndorfer Sept. 26, 2006

Sept. 26, 2006

Hi, throught a problem in winedbg i found out that NtReadVirtualMemory has a problem, when reading into a invalid local buffer. it uses wine_server_set_reply( req, buffer, size ); to read the data supplied by the server directly into application memory of unknown state. when the read call hits bad(non present/readonly ) memory it returns EFAULT and the client dies with "wine client error:<process id>: read: Bad address" i see 3 ways to deal with this problem 1. allocate a temporary buffer in NtReadVirtualMemory, read server answer to this buffer, and then inside a try / catch block copy to application memory 2. change server protocol so it is not as sensitive when read returns EFAULT (i do not really like this idea) 3. just fix the bug in winedbg and wait until a real world app needs this behavior. (of course i will send a patch for windbg even if one of the other ways is choosen) Any ideas? Greetings Peter PS: attached a testcase for NtReadVirtualMemory(testcase itself not tested on windows, but tests were) the test should probably also live in its own file, but i didn't want to create a almost empty file

1 0

Re: msi [1/5]: Implement MsiDatabaseImport
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

"James Hawkins" <truiken(a)gmail.com> writes: > +static const WCHAR insert_fmts[][100] = > +{ > + {'I','N','S','E','R','T',' ','I','N','T','O',' ','`','%','s','`',' ','(',' ',0}, > + {'`','%','s','`',',',' ',0}, > + {' ',')',' ','V','A','L','U','E','S',' ','(',' ',0}, > + {'\'','%','s','\'',',',' ',0}, > + {'%','s',',',' ',0}, > + {' ',')',0}, > +}; It would be cleaner to use separate variables for the separate strings, there's no reason this needs to be an array. It would avoid wasting a lot of space, and make it more explicit what the strings mean, unlike something like insert_fmts[3]. Also since all you do is copy strings, it may be even cleaner to avoid sprintf and simply strcat the strings and the separators. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: D3D9: Add a pitch test for a 1x1 texture
by H. Verbeet Sept. 26, 2006

Sept. 26, 2006

On 26/09/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > To verify that the 32 bit alignment is true for 1x1 textures too. > >+ /* test is deactivated until out np2 support doesn't report the full power of 2 pitch to the app */ >+ todo_wine ok(lockedRect.Pitch == 4, "Got pitch %d, expected 4\n", lockedRect.Pitch); Shouldn't the test be about alignment, rather than the exact size? I that case the power-of-two stuff shouldn't matter either, as long as it's properly aligned. I do have an initial patch for native NPOT support, but it will (of course) only work on cards that support the relevant extension.

2 3

Re: [D3D9] Update state test framework
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Ivan Gyurdiev <ivg231(a)gmail.com> writes: > Changelog: > ========== > 1) Abandon central memory allocation, and the tracking that involves. > Write a setup() and teardown() handler for each test, and use heap > allocation. > > 2) Make the main test function configure test arguments. > Replace get/set arguments with a single test_arg. > > 3) Remove some const qualifiers on test data. > Const qualifiers should go on function parameters instead. When you find yourself writing a Changelog like this, it's a clear sign that it should be 3 separate patches. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: user: test and fix SwitchToThisWindow [3rd try]
by Alexandre Julliard Sept. 26, 2006

Sept. 26, 2006

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > diff --git a/dlls/user/winpos.c b/dlls/user/winpos.c > index 6bc9056..e78f484 100644 > --- a/dlls/user/winpos.c > +++ b/dlls/user/winpos.c > @@ -152,7 +152,20 @@ UINT WINAPI ArrangeIconicWindows( HWND p > */ > void WINAPI SwitchToThisWindow( HWND hwnd, BOOL restore ) > { > - ShowWindow( hwnd, restore ? SW_RESTORE : SW_SHOWMINIMIZED ); > + HWND hwndOld = GetForegroundWindow(); > + SetActiveWindow( hwnd ); > + SetForegroundWindow( hwnd ); > + if ( restore ) > + { > + if ( IsIconic( hwnd ) ) > + ShowWindow( hwnd, SW_RESTORE ); > + } > + else > + { > + if ( !( GetWindowLongW( hwndOld, GWL_EXSTYLE ) & WS_EX_TOPMOST ) ) > + SetWindowPos( hwndOld, HWND_BOTTOM, 0, 0, 0, 0, > + SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE ); > + } That HWND_BOTTOM thing looks very wrong, SwitchToThisWindow is supposed to move things to the front. Most likely your test case is flawed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Tips for vim users
by n0dalus Sept. 26, 2006

Sept. 26, 2006

Hi, Recently I learned a way to have vim automatically change settings when I'm editing wine source code: At the bottom of my ~/.vimrc (create it if it doesn't exist): if !exists("loaded_vimrc_autocmd") let loaded_vimrc_autocmd=1 autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8 softtabstop=4 endif In my case my wine tree is in /data/wine, so replace this with the first part of the path to your wine tree. Using the same syntax you can also put custom settings for other projects you might work on. This is helpful for me since I usually like to indent using tabs and a 4 space tab width, but now I can edit most of wine's code without having to worry about fixing my indents all the time. If anyone is interested, I've also got another Vim tip on the wiki (from last year), to automate the creation of wide character arrays: http://wiki.winehq.org/Character_arrays_in_Vim If any other vim users have tips that help out with wine coding, I'd love to hear them! Maybe we can make a page on the wiki for them. n0dalus.

2 4

Re: Governance revisited (Wineconf report)
by Ge van Geldorp Sept. 26, 2006

Sept. 26, 2006

> From: Kai Blin > > Now, getting back to the patch submission process, you're talking about a > patch management system. How would that look like, in your opinion. We were > discussing a couple of ideas, but in the end figured that most of those would > slow down the submission speed of patches that are accepted. > > Our idea was to have patches be recieved by the subsytem maintainers, and > Alexandre would only apply patches he got from those guys. We voted that one > down. > > Now I would be interested in your idea for such a system. I figure that > writing an emacs frontend won't be too troublesome if it's reasonably > designed, so let's ignore that for now. A patch management system isn't exactly a new idea. It came up last year, during the same type of discussion we're having now (and it will probably come up next year when we have the same discussion again). See e.g. http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and note this sentence: "However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered." The users of such a patch management system would fall into 3 categories: Developers/patch submitters, subsystem maintainers and Alexandre. I can take a guess at what subsystem maintainers and Alexandre would want from such a system, but of course I can only really speak as a patch submitter. My primary requirements would be to be able to: - Submit a patch - Specify a subsystem - Keep track of its progress - Resubmit after receiving feedback - Get an overview of patches in the queue - Apply a queued patch to my working copy - Provide feedback to others - Withdraw a patch In addition to the patch submitter requirements, subsystem maintainers would probably like to be able to: - Get an overview of patches relevant to their subsystem - Recommend a patch for inclusion In addition to all of the above, I guess Alexandre would need to be able to: - Get an overview of recommended patches - Commit a patch - Reject a patch - All from within emacs Moving on to implementation, I see a set of database tables giving a patch the following attributes: - Submitter - Short description - Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed, Rejected) - Subsystem - Patch text (multiple versions, to allow resubmits and still keep a history) - Comments Some status changes are restricted (e.g. only a subsystem maintainer would be able to recommend a patch). Everyone would be able to submit a patch, which would initially have Queued status. When feedback is provided, the feedback provider (anyone) could change the status to Waiting for developer. If a patch is in "Waiting for developer" status too long (say a month) it could be automatically rejected. When "Waiting", the submitter could provide a new version or respond with a comment, setting the status back to Queued again. Or he could decide to Withdraw the patch. When a patch makes it into the tree it will gain the most holy of all statuses, Committed. I envision manually Rejecting a patch to be a pretty rare case, normally feedback would be provided and the Waiting status would be set. Uncommittable patches would then exit the system via the automatic clean up (in "Waiting" too long) or via a Withdraw. The heart of the system would be a couple of web pages. However, not everyone likes web pages and the current system with mailing lists does have its strong points too. So, there could be a two-way gateway between the web system and the mailing lists. If a patch is submitted via the web, it could be sent out via wine-patches too. If a patch comes in via wine-patches, it could be added to the database automatically (when that doesn't succeed a notification is sent to the author). Same for comments, they could be fed from the web page to wine-devel. If there is genuine interest to make this work I could put up a few mock webpages to get a better idea of how it would work. Gé van Geldorp.

6 6

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

James Hawkins wrote: > On 9/25/06, jimtabor <jimtabor(a)users.sourceforge.net> wrote: > >> >> Every Wine developer needs to read this, >> http://www.codeweavers.com/services/ and >> http://www.codeweavers.com/services/wine . >> > > I'm a Wine developer, and I don't work for codeweavers. Why should I > read that? > You don't need to. >> It is your job to provide support for this product, I spend money and I >> need help, where do >> I go? >> > > It is not my job to provide support for this product. Even if you're > referring to Dmitry and everyone else that works at Codeweavers, > you're still wrong. This is the wine-devel mailing list, and has > nothing to do with Codeweavers. You confuse Crossover Office and Wine > as being the same product/project. Just because they work at > Codeweavers, can they not also work on Wine and not have affiliation > with Codeweavers? Of course they can, as can anyone else who has a > real job outside of Wine. > NO! You are WRONG, sir! ~and I quote from http://www.codeweavers.com/services/ "Since 1999, CodeWeavers has been hiring the very best Wine developers. Chief among these is Alexandre Julliard <http://www.codeweavers.com/about/people/alexandre/>, the long-time maintainer of the Wine Project itself. In addition to Alexandre's prodigious talents, we have consistently hired the very best Wine resources, recruiting them literally worldwide." Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW would not have a product. They get paid for working on Wine to support CO. Don't you see that?! > First, he doesn't represent Codeweavers on the wine-devel mailing > list. Second, there's nothing unprofessional about his actions. > Missed my point! If his address has "name(a)codewreavers.com", than yes, that person does represent that organization. This project is NOT LINUX or X11, it is a paid for add on to it. I pay good money for support and I expect to get it. It is shocking to most FOSS code writers that maybe this is a real, truly, paid for project. "No! It can not be! I contribute to someones profit? NOOoooooooo~~~!". Thanks, James

3 2

Re: Governance revisited
by jimtabor Sept. 26, 2006

Sept. 26, 2006

Wow, just like that! James Hawkins wrote: >> It is shocking to most FOSS code writers that maybe this is a real, >> truly, paid for project. "No! It can not be! I contribute to someones >> profit? NOOoooooooo~~~!". > The above is a famous quote I read from Linux Journal magazine. > > I am well aware that Codeweavers funds most of Wine development, and I > appreciate every bit of support coming from them, but this project > would continue even without their support. > > -- > James Hawkins > >> NO! You are WRONG, sir! >> NOOoooooooo~~~! > > > P.S. You should really calm down. It's hard to take you seriously > when you act immature. > I am calm, lol! immature? just a little! 8^D So, after reading this ML for years and assessing. Seriously, If I was a contractor representative researching code weavers ability to support their product, the last thing I would expect from any of their developers would be the lack of customer support and poor attitude on IRC. At lest if one of my employees does go out and join wine IRC, I would hope they will not get kicked or banned for asking to many questions. Understanding this, has made my mind up and forced to stop linux migration due to the lack of support and maturity of wine and code weavers. We do have contracts with Red Hat, SCO, Solaris, Raytheon,,,,, Oh the shock of that, yes we are considering the use of wine for moving away from Microsoft windows. Wine was the stop gap in our mission to provide both Linux and Window applications in a real time environment. That M$ update thingy is a ass kicker on real time systems, that must operate 24/7. Having said that,,,, sorry I can't authorize any contracts with code weavers. Sorry, you just never know sometime, James

1 0

make test failing in shell32
by Kai Blin Sept. 25, 2006

Sept. 25, 2006

Hi folks, running make test repeatedly in a new wine prefix finally gives this error: make[2]: Entering directory `/home/nowhere/dev/wine/wine-build/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 I've attached the +shell trace bzip2ed, the uncompressed trace is 2.2 megs. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > Changelog: > * Makes RPCRT4 use Winsock2 instead of native sockets (needed for > event object support) > * Adds support for TCP (ncacn_ip_tcp protocol) servers I appreciate your attempt at solving this hard problem, but I don't believe this is the right approach. Using winsock2 instead of Unix sockets adds overhead in terms of wineserver calls and extra processing time to mangle arguments, which we shouldn't need. The reasoning for this is that at some point I want to use Unix domain sockets for the ncalrpc provider, so it should be as fast as possible. More detailed comments inline: > > --- a/include/ws2tcpip.h 2006-08-28 20:35:33.000000000 +0200 > +++ b/include/ws2tcpip.h 2006-09-16 08:55:45.000000000 +0200 > @@ -137,6 +137,8 @@ > #define WS_IFF_MULTICAST 0x00000010 /* multicast is supported */ > #endif /* USE_WS_PREFIX */ > > +#define INET_ADDRSTRLEN 16 > + > #ifndef USE_WS_PREFIX > #define IP_OPTIONS 1 > #define IP_HDRINCL 2 > This change looks good. Please submit it separately. > +static const char *gai_strerror(int errcode) > +{ > + switch (errcode) > + { > + case EAI_AGAIN: return "Temporary failure in name resolution"; > + case EAI_BADFLAGS: return "Bad value for ai_flags"; > + case EAI_FAIL: return "Non-recoverable failure in name resolution"; > + case EAI_FAMILY: return "ai_family not supported"; > + case EAI_MEMORY: return "Memory allocation failure"; > + case EAI_NONAME: return "Name or service not known"; > + case EAI_SERVICE: return "Servname not supported for ai_socktype"; > + case EAI_SOCKTYPE: return "ai_socktype not supported"; > + } > + return "Unknown error"; > +} > + > +static const char *inet_ntop(int af, const void *src, char *dst, int cnt) > +{ > + if (af == AF_INET) > + { > + unsigned int addr = * (unsigned int*) src; > + if (cnt < INET_ADDRSTRLEN) > + return NULL; > + snprintf(dst, cnt, "%u.%u.%u.%u", (addr >> 24) & 0xFF, > + (addr >> 16) & 0xFF, (addr >> 8) & 0xFF, addr & 0xFF); > + return dst; > + } > + else > + return NULL; > +} > + > These should obviously not be here. I believe gai_strerror is implemented as a macro in one of the winsock header files. I think inet_ntop should be implemented in ws2_32.dll. > @@ -506,51 +516,115 @@ > continue; > } > > - if (0>connect(sock, ai_cur->ai_addr, ai_cur->ai_addrlen)) > + if (Connection->server) > { > - WARN("connect() failed\n"); > - close(sock); > - continue; > + BOOL success = FALSE; > + if (bind(sock, ai_cur->ai_addr, ai_cur->ai_addrlen) == 0) > + { > + if (listen(sock, 5) == 0) > + { > + if ((tcpc->event = WSACreateEvent()) != NULL) > + { > + if (WSAEventSelect(sock, tcpc->event, FD_ACCEPT) == 0) > + success = TRUE; > + else > + WARN("WSAEventSelect() failed\n"); > Using WSAEVENTs is an interesting approach, but I'd rather see Unix sockets being used with a thread that select's on the socket and sets a Win32 event instead. Also, I think this amount of nesting is confusing and could be avoided. > > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, > void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > - return r; > + int rtotal = 0; > + int r = 0; > + do > + { > + r = recv(tcpc->sock, buffer, count, 0); > + if (r > 0) > + rtotal += r; > + else > + break; > + } while (rtotal < count); > + if (r < 0) > + rtotal = r; > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); > + return rtotal; > } > Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that should be fixed there. > > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, > const void *buffer, unsigned int count) > { > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; > - int r = write(tcpc->sock, buffer, count); > + int r = send(tcpc->sock, buffer, count, 0); > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); > return r; > } > This is a good change. Please submit this as a separate fix. Thanks, -- Rob Shearman

3 3

Re: [RPCRT4] support for RPC TCP servers
by Robert Shearman Sept. 25, 2006

Sept. 25, 2006

Damjan Jovanovic wrote: > On 9/22/06, Robert Shearman <rob(a)codeweavers.com> wrote: >> Using WSAEVENTs is an interesting approach, but I'd rather see Unix >> sockets being used with a thread that select's on the socket and sets a >> Win32 event instead. Also, I think this amount of nesting is confusing >> and could be avoided. > > Are you working on that approach, or am I free to try it? No, I am not working on that so you are free to try it. (You would be free to try it anyway, since your implementation might be better than an implementation I was working on.) > >> > >> > static int rpcrt4_conn_tcp_read(RpcConnection *Connection, >> > void *buffer, unsigned int count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = recv(tcpc->sock, buffer, count, MSG_WAITALL); >> > - TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > - return r; >> > + int rtotal = 0; >> > + int r = 0; >> > + do >> > + { >> > + r = recv(tcpc->sock, buffer, count, 0); >> > + if (r > 0) >> > + rtotal += r; >> > + else >> > + break; >> > + } while (rtotal < count); >> > + if (r < 0) >> > + rtotal = r; >> > + TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal); >> > + return rtotal; >> > } >> > >> >> Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that >> should be fixed there. > > It isn't supported in the native winsock either. You think too highly > of winsock - remeber it was made by Microsoft ;-). Both MSDN and dlls/ws2_32/socket.c suggest that it is supported, although only in non-blocking mode. Is that the problem? > >> > >> > static int rpcrt4_conn_tcp_write(RpcConnection *Connection, >> > const void *buffer, unsigned int >> count) >> > { >> > RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection; >> > - int r = write(tcpc->sock, buffer, count); >> > + int r = send(tcpc->sock, buffer, count, 0); >> > TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r); >> > return r; >> > } >> > >> >> This is a good change. Please submit this as a separate fix. > > But if we use UNIX sockets, it shouldn't matter? Correct. This won't make any difference either way, so we should use send. -- Rob Shearman

1 0

Re: kernel32: Remove unwanted null terminator
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > kernel32: Remove unwanted null terminator. There's no null terminator since the array size is specified explicitly. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: dmime: Dangling references fix
by Alexandre Julliard Sept. 25, 2006

Sept. 25, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Changelog: > dmime: Dangling references fix. The right way is to use wine_dbg_sprintf("%s") to allocate a copy of the buffer to return. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine translations statistics
by Mikołaj Zalewski Sept. 25, 2006

Sept. 25, 2006

To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Mikolaj Zalewski

6 7

Re: wined3d: fix typo in ResourceReleased
by Stefan Dösinger Sept. 25, 2006

Sept. 25, 2006

Hi, > if (This->stateBlock != NULL ) { > if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] == resource) { > TRACE("Vertex buffer released whlst bound to a state block > stream %d\n", streamNumber); > TRACE("Vertex buffer released while bound to a state block stream %d\n", streamNumber); > This->stateBlock->streamSource[streamNumber] = 0; > } > } This is not your code, but this is wrong, even if the msdn says otherwise. Once I had a hacky test for testing this stuff. What my test did was: 1) Create a Vertex buffer 2) check device refcount: increased 3) Bind to a stream 4) check the vb refcount: unchanged(still 1) 5) release the vb(release returns 0) 6) check the device refcount: decreased 7) GetStreamSource: returns old vertex buffer 8) Check device refcount: increased 9) check vb refcount: 1 It seems that the stream source is not uset if the buffer is released. And it seems that ms implements holding the reference to the device in VertexBuffer::AddRef if(oldref == 0) IDirect3DDevice9_AddRef(This->device) or something like that, simmilar to our release. CreateVertexBuffer seems to init the ref to 0 and call VertexBuffer::AddRef. To be sure I did tested the following too: 1) Create VB 2) Check device refcount: increased 3) Release vb. Device refcount decremented 4) AddRef the just destroyed vb: Device refcount increased I didn't submit the test because it doesn't contain anything really new, and the GetStreamSource which returns the released buffer works just by chance. Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as any app depending on that would randomly break on windows. Or is there some COM magic behind this, which keeps objects from beeing destroyed? Stefan

1 0

Re: Governance revisited
by Ge van Geldorp Sept. 25, 2006

Sept. 25, 2006

> From: Steven Edwards <winehacker(a)gmail.com> > > Which is why we want to have the ambassadors project to help > new people in to wine. The thinking goes that if we have some > people to help hold the hands of new developers and the > developers that are defacto maintainers of a certain section > of code will respond to patches as they seem them, this will > free julliard from having to answer every single patch with a > reply. You can have ambassadors and subsystem maintainers all you want, but in the end it's still going to be Alexandre who decides if a patch goes in. That means the end-responsibility of informing developers why a patch was rejected needs to be with Alexandre. If an ambassador or subsystem maintainer already explained it, fine, no need to create double work for Alexandre, but if noone responded I'd still expect Alexandre to send a notification. Just for the record, my own policy on patch submission (and I really hope to get back to working on Wine and submitting patches Real Soon Now :-)) is to submit a patch once. If I get feedback I'll try to improve and resubmit, but if it goes the black hole route I'm not going to beg for an explanation. If the Wine community can't be bothered to provide feedback I can't be bothered to resubmit. After all, I've already scratched my itch, the bug is already fixed in my tree, it's the communities loss, not mine. Ge van Geldorp

2 1

Last update to git 5 days ago?
by Paul Vriens Sept. 25, 2006

Sept. 25, 2006

Hi, is Alexandre on a holiday again? Or is this to recuperate from WineConf? Cheers, Paul

1 0