March 2009 - Wine-Devel - list.winehq.org

Re: [1/2](try 2)advapi32: alias some sids in LookupAccountName and make comparison case insensitive
by Paul Vriens March 31, 2009

March 31, 2009

Aric Stewart wrote: > > with tests > --- > dlls/advapi32/security.c | 10 +++++-- > dlls/advapi32/tests/security.c | 56 > ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 63 insertions(+), 3 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi Aric, Could you have a look at the test results as you are still busy with this stuff. - Some (all?) of the new tests fail on a Non-English locale. - None of the newly checked names are available on NT4. - LocalService and NetworkService are not available on W2K (all?) -- Cheers, Paul.

1 0

httpapi compile broken on OpenBSD
by Austin English March 31, 2009

March 31, 2009

Howdy, The compile is broken on OpenBSD in httpapi/httpapi_main.c: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith -I/usr/local/include -I/usr/local/include -I/usr/local/include/libpng -o httpapi_main.o httpapi_main.c In file included from ../../include/http.h:25, from httpapi_main.c:27: ../../include/ws2tcpip.h:60: error: conflicting types for `socklen_t' /usr/include/sys/types.h:163: error: previous declaration of `socklen_t' *** Error code 1 Stop in /home/austin/wine-git/dlls/httpapi (line 92 of /usr/share/mk/sys.mk). Talking with Vincent, narrowed it down to the file ignoring Wine's definition of socklen_t. Is there any reason we shouldn't be defining it, like we already do in iphlpapi/iphlpapi_main.c, winhttp/net.c, wininet/netconnection.c, wsock32/protocol.c and server/sock.c? E.g.,: diff --git a/dlls/httpapi/httpapi_main.c b/dlls/httpapi/httpapi_main.c index 7b29a15..b96f730 100644 --- a/dlls/httpapi/httpapi_main.c +++ b/dlls/httpapi/httpapi_main.c @@ -18,6 +18,8 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA */ +#define USE_WS_PREFIX + #include "config.h" #include <stdarg.h> -- -Austin

1 0

SoC: JavaScript implementation
by Piotr Caban March 30, 2009

March 30, 2009

Hi, I'm planning to participate in Google Summer of Code this year. I was thinking about working on recently added jscript.dll implementation. Its engine looks almost complete, but I can see that there are many unimplemented APIs. That's what I'd like to improve. I've already talked about this idea with Jacek, who has written jscript.dll, and he says that he likes it. I was looking for pages that intensively use JavaScript as well as simple real life test cases. My goals would be, in order: - Look at Wine jscript.dll related bugs. These would be: 15432, 15582, 16208, 16594 and 17152. I'm not sure if they are JScript or MSHTML bugs yet as they require deeper analyze. I will fix their JScript part of problem. - Fix W3School (http://www.w3schools.com/js/default.asp) JavaScript examples. These seem to be a nice tests for me. They test commonly used APIs in real life scenarios. I believe that if these tests work, most web sides should work as well. - Test complex web pages Pages like GMail or Google Office would be really cool to have working with our JavaScript. Unfortunately I'm afraid that it may be too much work for SoC to fix them. I'd like to do some testing and find some complex web pages that I could use as tests. If someone has any more ideas about tests I'm open for suggestions. For testing JavaScript on web pages I'm planning to use IE working on Wine with built-in jscript.dll. This way I will be able to test jscript.dll on web pages that is currently impossible to do with Wine MSHTML and iexplore.exe. What do you think about this idea? Thanks, Piotr Caban

2 2

GSoC: Improving DOS graphics
by Daniel Kraft March 30, 2009

March 30, 2009

Hi, I would be interested in working on WINE for Google Summer of Code (as I would like to get into WINE and learn more about it from the developer's side of view; I imagine this is a very educational and interesting experience in addition to being simply an interesting free software project to work on). On the ideas list is a project about improving handling of DOS graphics mode, this sounds interesting to me. I've got good experience with C, C++ and other programming languages as well as programming in general, but so far no knowledge at all about WINE apart from using it. Do you think this would be a good project to apply for and get into WINE? (Thus both useful for the community as well as a good point for me without WINE experience so far.) Regarding free software in general, I've already worked with some projects including Mozilla and GCC, so I should be familiar with standard development practices involved. Thank you very much, Daniel

2 1

Re: rpcrt4: Compile in RPC over HTTP support even if HAVE_SOCKETPAIR is not defined.
by Alexandre Julliard March 30, 2009

March 30, 2009

Rob Shearman <robertshearman(a)gmail.com> writes: > socketpair is only needed for the server functions for ncacn_ip_tcp. > The tower implementation that ncacn_http and ncacn_ip_tcp share > doesn't depend on it. It doesn't need socketpair, but it needs getaddrinfo and friends so it still won't build on Mingw, that's why I disabled the whole thing. We could put that part inside a #ifdef HAVE_GETADDRINFO instead, but the end result would be the same. -- Alexandre Julliard julliard(a)winehq.org

2 1

16bit code generation
by Tijl Coosemans March 30, 2009

March 30, 2009

I was reading through binutils documentation and came across this. Maybe it can be used to compile 16 bit tests. 3.2.4. 16-bit mode Binutils (2.9.1.0.25+) now fully support 16-bit mode (registers and addressing) on i386 PCs. Use .code16 and .code32 to switch between assembly modes. Also, a neat trick used by several people (including the oskit authors) is to force GCC to produce code for 16-bit real mode, using an inline assembly statement asm(".code16\n"). GCC will still emit only 32-bit addressing modes, but GAS will insert proper 32-bit prefixes for them.

8 13

Re: [1/6] WineD3D: Merge index buffers into base buffers
by Henri Verbeet March 30, 2009

March 30, 2009

2009/3/30 Stefan Dösinger <stefan(a)codeweavers.com>: > - hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, &wined3d_desc, > - (IUnknown *)object, &object->wined3d_buffer); > + hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, desc->ByteWidth, > + desc->Usage, 0, WINED3DFMT_UNKNOWN, WINED3DPOOL_MANAGED,· > + &object->wined3d_buffer, 0, (IUnknown *)object); You're adding trailing space here. More importantly though, the wined3d_desc variable is now essentially unused. I already mentioned on IRC a couple of weeks ago that I don't think changing the CreateBuffer() call like this is an improvement. I also mentioned that I think the patch is too big, I really don't want to fix regressions in this. The patch can be split in at least 4 separate patches without trying too hard.

1 0

Advice on where to place new private methods and access to private methods across modules.
by Damian Dixon March 30, 2009

March 30, 2009

Hi, I am working on creating a patch for X11DRV_AlphaBlend to allow Bitmap's with no DIBSECTION to work. The code to do this is fairly generic so I created a new method: DIB_CreateDIBSectionFromBitmap. I initially placed this in winex11.drv/dib.c, however the method required access to private methods in gdi32/dib.c. I then considered moving the method to gdi32, however again access to private methods seems to be an issue. I would prefer not to duplicate code across the dib.c files. Is there an accepted approach for acessing support methods across the modules? or should I just duplicate the necessary methods? Thanks Damian

2 1

Re: [2/2](try 2)advapi: handle fully qualified account names for well known sids in LookupAccountName
by Alexandre Julliard March 30, 2009

March 30, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > @@ -2667,11 +2669,23 @@ BOOL WINAPI LookupAccountNameW( LPCWSTR lpSystemName, LPCWSTR lpAccountName, PSI > } > > /* Check well known SIDs first */ > + if (strchrW(lpAccountName,'\\')) > + { > + lpAccountNamePtr = strrchrW(lpAccountName,'\\'); > + lpAccountNamePtr++; > + lpDomainNamePtr = lpAccountName; > + } > + else > + lpAccountNamePtr = lpAccountName; > > for (i = 0; i < (sizeof(ACCOUNT_SIDS) / sizeof(ACCOUNT_SIDS[0])); i++) > { > - if (!strcmpiW(lpAccountName, ACCOUNT_SIDS[i].account) || > - (ACCOUNT_SIDS[i].alias && !strcmpiW(lpAccountName, ACCOUNT_SIDS[i].alias))) > + /* check domain first */ > + if (lpDomainNamePtr && strncmpiW(lpDomainNamePtr, ACCOUNT_SIDS[i].domain, strlenW(ACCOUNT_SIDS[i].domain))) > + continue; You always need to check that the next char is a terminator when using functions like strncmpiW. -- Alexandre Julliard julliard(a)winehq.org

1 0

[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.18
by Paul TBBle Hampson March 30, 2009

March 30, 2009

Hi. I've rebased the arb_vertex_program ffp vertex pipeline patchset to 1.1.18. This time I managed to get the fog correct, and all the d3d9 tests pass. I also did some benchmarks this time in both 3DMark 2000 and 2001SE, and have attached the results. Generally there's a fairly large slowdown in the fixed-function code, particularly in 3DMark 2000. Some of 2001SE's tests appear unaffected, which isn't surprising since some of them are D3D8 shader-based tests, not FFP tests. The fillrate tests appeared unaffected too. This is on a Core 2 Duo machine with an nVidia 8600M GT, if it makes a difference. I wasn't watching too carefully, but I did't notice any visual artefacts in the tests. As I understand it, Stefan's not got the time or inclination to work on this at the moment, and my knowledge of ARB vertex programs and the D3D fixed-function pipeline is rather limited, so in all likelihood getting this going faster will require someone to get stuck into gen_arbvp_ffp_shader and its callees in arb_program_shader.c and get it feature-complete and sufficiently optimised to be on-par with the ffp-based vertex pipeline. I guess a GLSL-based vertex pipeline might be desired too...? Then people can add features such as vertex-blending, and get No One Lives Forever 2 and bug #6955 cleared up. As before, the code is entirely Stefans, but bugs may certainly have been introduced by me. Since it now passes the unit tests, it might be reasonable to actually consider this for mainline, with a registry key or env var to force a specific choice of fixed-function vertex pipeline. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

3 4