September 2010 - Wine-devel

[RFC] mmap override patch
by Chris Robinson 21 Sep '10

21 Sep '10

This is a patch that attempts to override mmap, mmap64, and munmap so that host libs can used memory from the Wine heap instead of being restricted to the address space Wine leaves unreserved. It is based on Albert Lee's patch found here: http://bugs.winehq.org/show_bug.cgi?id=13335#c170 It has been enhanced to fix the problem with using off64_t in the wine/library.h header by using ULONGLONG instead, and it should override the aforementioned functions with the correct prototype in 32-bit and 64-bit in a much simpler way. It currently relies on the system having mmap or mmap64 that uses a 64-bit offset type, though if that's a problem, an extra wrapper can probably be made. It also relies on ULONGLONG being a 64-bit type, but from what I can tell, that will always true. If there's a problem with it, or some way it can be improved, please let me know. :)

1 0

BugZilla: Changings for Bug 24177
by Joerg Schiermeier 20 Sep '10

20 Sep '10

--- skins/custom/index.css | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/skins/custom/index.css b/skins/custom/index.css index 2c40719..bf064c4 100644 --- a/skins/custom/index.css +++ b/skins/custom/index.css @@ -7,6 +7,8 @@ } div#login_box { position: relative; - top: 205px; +/** -causes an error- + * top: 205px; + */ text-align: left; } \ No newline at end of file -- 1.7.1

2 1

Any recommendations on 64-bit debugging tools?
by Ben Parker 20 Sep '10

20 Sep '10

For those of you who have developed 64-bit apps with wine, I'd like to ask what debugging tools and techniques you found most effective in that environment. Anyone have good luck with the 64-bit winedbg or remote debugging using Visual Studio? Thanks, Ben Parker ESRI

1 0

Re: libwine: Make addresses above 0x82000000 available on FreeBSD.
by Alexandre Julliard 20 Sep '10

20 Sep '10

Tijl Coosemans <tijl(a)coosemans.org> writes: > With this patch it is possible that a .dll.so is loaded beyond the > 2GiB limit, but this does not seem to be a problem in practice. All > mmap calls from within Wine and thus all .dll stay below 2GiB and core > .dll.so such as ntdll, kernel32, user32,... are also loaded below 2GiB > because they are loaded early and are placed in the 32MiB mentioned > above. Also note that a .dll.so is only loaded above 2GiB when needed, > i.e. the program wouldn't have worked at all without this patch. It is > preferred that Wine at least makes an attempt at running the program > and therefore loosens the restriction on the use of addresses above > 2GiB, especially since it seems to work so far. It would be better to fix this properly. If there's no way to convince FreeBSD's mmap to use all available space, you'll have to move the loader down to make some room. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 2/6] d3dcompiler: Implement D3DGetBlobPart().
by Henri Verbeet 20 Sep '10

20 Sep '10

I think it's close, but not entirely what I had in mind. You can avoid both the callback and some of the data copies if you just let parse_dxbc() create a list / array of sections. So you'd have something like this: struct dxbc_section { DWORD tag; const char *data; SIZE_T data_size; }; struct dxbc { UINT section_size; UINT section_count; struct dxbc_section *sections; }; with parse_dxbc() just calling something like dxbc_add_section() instead of chunk_handler(). The sections can just refer to the original data in the dxbc blob, it's then the responsibility of the caller to either make sure that data stays around for as long as the sections are needed or make a copy of the data. d3dcompiler_get_blob_part() would then just iterate over all the sections and add the relevant ones to a second dxbc struct, which it would pass to dxbc_write_blob() afterwards. I don't think dxbc_remove_section() is very useful in general, you'll pretty much always just want to add sections to a new section list. It's also simply unused in your current patch. dxbc_release() should be called dxbc_destroy(), you're not doing any reference counting, and the naming would be more consistent if you renamed parse_dxbc() to dxbc_parse().

2 3

Re: [PATCH 4/4] gameux: Add stub of IGameStatistics interface implementation
by testbot＠testbot.winehq.org 20 Sep '10

20 Sep '10

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=5355 Your paranoid android. === W98SE (32 bit gamestatistics) === Failure running script in VM: Exceeded timeout limit of 315 sec === W7PRO (32 bit gamestatistics) === gamestatistics.c:314: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists gamestatistics.c:396: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists === W7PROX64 (32 bit gamestatistics) === gamestatistics.c:314: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists gamestatistics.c:396: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists

1 0

Re: [PATCH 2/4] gameux/tests: Add test of storing and reading game statistics
by testbot＠testbot.winehq.org 20 Sep '10

20 Sep '10

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=5354 Your paranoid android. === W98SE (32 bit gamestatistics) === Failure running script in VM: Exceeded timeout limit of 315 sec === W7PRO (32 bit gamestatistics) === gamestatistics.c:314: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists gamestatistics.c:396: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists === W7PROX64 (32 bit gamestatistics) === gamestatistics.c:314: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists gamestatistics.c:396: Test failed: statistics file L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\GameExplorer\\GameStatistics.gamestats1{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}\\{17A6558E-60BE-4078-B66F-9C3ADA2A32E6}.gamestats1" does not exists

1 0

Re: [PATCH 6/6] d3dcompiler: Implement D3DGetDebugInfo().
by Henri Verbeet 20 Sep '10

20 Sep '10

2010/9/19 Rico Schüller <kgbricola(a)web.de>: > --- I don't think this makes a lot of sense. D3DGetDebugInfo() clearly doesn't return a DXBC, so I think you should just memcpy it into the blob directly instead of trying to abuse dxbc_write(). This change would also make it impossible to write any DXBC containing an SDBG chunk, like e.g. the one you'd be parsing for D3DGetDebugInfo().

2 2

Re: ws2_32: implement AcceptEx and GetAcceptExSockaddrs (try 2)
by Alexandre Julliard 20 Sep '10

20 Sep '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > + wsa->read = HeapAlloc( GetProcessHeap(), 0, sizeof(*wsa->read) ); > + if (!wsa->read) > + { > + status = STATUS_NO_MEMORY; > + goto finish; > + } > + wsa->read->hSocket = wsa->accept_socket; > + wsa->read->flags = 0; > + wsa->read->addr = NULL; > + wsa->read->addrlen.ptr = NULL; > + wsa->read->n_iovecs = 1; > + wsa->read->first_iovec = 0; > + /* Includes 1 iovec, and that's all we need */ > + wsa->read->iovec[0].iov_base = wsa->buf; > + wsa->read->iovec[0].iov_len = wsa->data_len; > + SERVER_START_REQ( register_async ) > + { > + req->type = ASYNC_TYPE_READ; > + req->async.handle = wine_server_obj_handle( wsa->accept_socket ); > + req->async.callback = wine_server_client_ptr( WS2_async_recv_accept ); > + req->async.iosb = wine_server_client_ptr( iosb ); > + req->async.arg = wine_server_client_ptr( wsa ); > + status = wine_server_call( req ); > + } > + SERVER_END_REQ; > + > + if (status != STATUS_PENDING) > + goto finish; > + > + return STATUS_SUCCESS; > + > +finish: > + iosb->u.Status = status; > + iosb->Information = 0; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} You cannot allocate or free memory in an async callback, because it can be called from a signal handler. All needed memory needs to be allocated beforehand, and freed in the user apc callback. -- Alexandre Julliard julliard(a)winehq.org

1 0

Regsvr32 running through Gecko
by James McKenzie 20 Sep '10

20 Sep '10

Interestingly enough, when Wine goes to update my .wine prefix, the updater is trying to run regsvr32 through Gecko. Of course, this crashes and the debugger cannot attach to the process as it terminates. err:ole:TLB_ReadTypeLib Loading of typelib L"C:\\windows\\system32\\msdatsrc.tlb" failed with error 2 Is this the desired action or should I 'flush' my .wine and start over? James McKenzie

2 2