Re: [PATCH 2/4] d3d10: Move the effect shader input signature into a separate struct.
2010/4/6 Rico Schüller kgbric...@web.de:
+struct d3d10_effect_shader_signature {
That isn't going to apply. Did you edit the patch? (And please keep
the formatting consistent with the existing code.)
Re: [PATCH 2/4] d3d10: Move the effect shader input signature into a separate struct.
On 7 April 2010 11:29, Henri Verbeet hverb...@gmail.com wrote: That isn't going to apply. Also, 3/4 and 4/4 have similar issues.
Re: ddraw/tests: Added todo_wine test to verify resizing of fullscreen windows
On 6 April 2010 23:14, Johan Gill johan.g...@gmail.com wrote:
+»··»···if (!EqualRect(scrn, orig_rect)) {
+»··»···/* Check that the client rect was resized */
+»··»···rc = GetClientRect(hwnd, test);
+»··»···ok(rc!=0, GetClientRect returned %x\n, rc);
+»··»···rc = EqualRect(scrn, test);
+»··»···todo_wine ok(rc!=0, Fullscreen window has wrong size\n);
+»··»···}
Please don't mix tabs and spaces, just use 4 space indent.
About Wine Test Bot
Hi, I have a suggestion about wineTestBot. It's maybe the wrong place but I'm quite sure interested people read wine-devel. I think it would be great if we could not only run tests (as it already does) but also check if a patch does not break wine (on minGW, on cygwin or on MAC for instance). Thus, we could choose a kind of WINEBUILD VM to tell wineTestBot to only compile wine with our patch. Currently, I can't compile on Linux and cygwin is very slow. So it would make my life easier if I could rely on wineTestBot... Comments are welcome Thanks
Re: About Wine Test Bot
Alexandre Goujon ale.gou...@gmail.com wrote: Currently, I can't compile on Linux and cygwin is very slow. So it would make my life easier if I could rely on wineTestBot... For any productive Wine development you need not only working compiling environment, but a working Wine binary, to run at least 'make test'. -- Dmitry.
Re: [PATCH 2/5] [Server]: correctly set the DR0..7 registers on Linux for x86_64 architecture
Eric Pouech eric.pou...@orange.fr writes: @@ -549,12 +549,21 @@ void get_thread_context( struct thread *thread, context_t *context, unsigned int goto done; } } +#ifdef __i386__ context-debug.i386_regs.dr0 = data[0]; context-debug.i386_regs.dr1 = data[1]; context-debug.i386_regs.dr2 = data[2]; context-debug.i386_regs.dr3 = data[3]; context-debug.i386_regs.dr6 = data[6]; context-debug.i386_regs.dr7 = data[7]; +#else /* __x86_64__ */ +context-debug.x86_64_regs.dr0 = data[0]; +context-debug.x86_64_regs.dr1 = data[1]; +context-debug.x86_64_regs.dr2 = data[2]; +context-debug.x86_64_regs.dr3 = data[3]; +context-debug.x86_64_regs.dr6 = data[6]; +context-debug.x86_64_regs.dr7 = data[7]; +#endif You can't use ifdefs, this needs to depend on the CPU type of the client process. -- Alexandre Julliard julli...@winehq.org
Participation in GSoC
Hello, I'm a student interested in participating in Google's Summer of Code. This isn't my first mail to the wine-devel list; I was a GSoC partiicpant in 2007, where I worked on WIne's WordPad clone. I have also done some work on the AppDB as well as minor bug fixes and lately a (little) work on some dsound tests. Other, non-Wine related code I've written include work with low-level keyboard hoo There are a few projects I have in mind. I've had a look at the Wiki, and both 'Implementing the Internet Explorer GUI' and working on the Control Panel applets seem like interesting projects. Have any students applied for these yet? My only COM experience so far has been implementing a few stubs for DirectPlay, as well as some dsound tests: http://www.winehq.org/pipermail/wine-patches/2010-February/084748.html http://www.winehq.org/pipermail/wine-patches/2010-February/084881.html As for my own project ideas, I think it would have been interesting to implement IPX over TCP in winsock, since most of the games that use IPX require root access for it to work. This feature could perhaps be enabled in winecfg or the Control Panel. I don't have any experience with networkking, though, so I'm concerned that this might be a bit amibitous. I would appreciate feedback of any kind, and yes, I know that time is running out with respect to the application deadline :) Regards, Alexander N. Sørnes
Re: Participation in GSoC
Hi Alexander, Good to see you back in GSoc. I can't comment on IE / control panel as I don't know much about it but I will comment to another small part. As for my own project ideas, I think it would have been interesting to implement IPX over TCP in winsock, since most of the games that use IPX require root access for it to work. This feature could perhaps be enabled in winecfg or the Control Panel. I don't have any experience with networkking, though, so I'm concerned that this might be a bit amibitous. It should be possible to implement IPX over TCP but when you do this, the other side also needs to wrap IPX in a TCP packet. (there are various user space tools I believe which can do this). IPX can be used without root permissions if you use posix file capabilities to enable raw sockets on wineserver. I experimented with this a long time ago and I wasn't able to get it working at that time but this should somehow work. Roderick
winmm: Improve MCI A/W mapping slightly.
Hi, I forgot to mention that this patch was rebased against 1.1.42, supersedes the former Fix A/W mapping for 64bit Wine patch and is not dependent on prior 64bit patches. Currently, I can't think of a fully general solution to the A/W mapping problem. In theory, an unknown driver with new unknown commands and keywords could be registered. We have little idea how large the structure is and which flags controls the validity of the nth slot, e.g. when to call strdupAtoW(). One could think about parsing the command table to obtain this information. However, a) I see no guarantee that there's a unique MCI_STRING value for a given bit that is set in the flags parameter. b) This does not help with baroque commands like SYSINFO which sometimes put a string, sometimes a DWORD into the result buffer or which are documented to count buffer sizes in bytes, unlike other commands. This latter example reveals that calling MCI_Cleanup() before unwrapping is unfortunate, as valuable type information is lost. It is currently encapsulated inside mciSendCommandW. Open questions: - Does Wine actually support hooking in a new native MCI driver? (beside DLL overrides) - Why does Wine copy dwCallback only when MCI_NOTIFY is set? It is not wrong, but why care? To prevent a Valgrind message when that slot was not filled by the caller? BTW, my (unpublished) testing reveals that unlike what MSDN says, dwRetSize is counted in characters in MCI_SYSINFO_PARMSW, not bytes (at least on w2k with SYSINFO_NAME [OPEN]). But that shall be the subject of another patch. Regards, Jörg Höhle
Re: About Wine Test Bot
Dmitry Timoshkov wrote For any productive Wine development you need not only working compiling environment, but a working Wine binary, to run at least 'make test'. Ok so I could not run any test until compiling on cygwin works. But the idea was to be able to remotly compile wine with some of our patches applied. I was told you can't do that, it will break minGW. The WINEBUILD VM exists but we can't use it (or tell me how to do that) Of course I could install MinGW on my PC too...
Re: About Wine Test Bot
Alexandre Goujon ale.gou...@gmail.com wrote: For any productive Wine development you need not only working compiling environment, but a working Wine binary, to run at least 'make test'. Ok so I could not run any test until compiling on cygwin works. Even if compiling under Cygwin works, the tests still require running them under Wine, and Wine can't run under Cygwin (and most likely will never be able to). -- Dmitry.
Re: About Wine Test Bot
Patchwatcher is suppose to sort of do this. It only works for linux, not other systems, but it will not only check your patch against compiling but also against the test suit and mark and regressions.
Re: About Wine Test Bot
I didn't know this tool. It looks quite interesting. Thanks again for your advices
Re: About Wine Test Bot
Hi Alexandre, Ok so I could not run any test until compiling on cygwin works. But the idea was to be able to remotly compile wine with some of our patches applied. I was told you can't do that, it will break minGW. The WINEBUILD VM exists but we can't use it (or tell me how to do that) The WINEBUILD VM is only used to cross-compile tests in case you submit a patch and not a test executable to the bot. Running tests on Wine is outside the scope of WineTestBot (perhaps it should be called WinTestBot...), it is aimed at making sure that the tests themselves are correct (by checking that they don't fail on Windows). Ge van Geldorp.
Re: [PATCH 2/4] d3d10: Move the effect shader input signature into a separate struct.
Am 07.04.2010 11:29, schrieb Henri Verbeet:
2010/4/6 Rico Schüllerkgbric...@web.de:
+struct d3d10_effect_shader_signature {
That isn't going to apply. Did you edit the patch? (And please keep
the formatting consistent with the existing code.)
Sorry, Thunderbird screwed up the patches. I'll send a working version.
Cheers
Rico
Mac OS X technologies
There is a long list of technologies in Mac OS X that could be used to improve Wine on OS X. One of them is ColorSync. ColorSync is a color management software that is HEAVILY integrated into the Mac OS. For instance, you can calibrate your monitor and when OS X starts up, it will read the color profile file and adjust the graphics card output. It will also do color correction automatically in, e.g. Preview to get the best out of an image. However, I do not know how ColorSync influences Mac OS X's X11 system. It is possible that in order to take full advantage of ColorSync, a Mac OS X native front-end will need to be developed. Another interesting Mac OS X technology is Image Capture. This technology is used by the OS to scan images from a scanner as well as import images from a camera (iPhoto). It provides a wrapper around TWAIN drivers so they can be used by applications that don't support TWAIN. This is a purely C Framework. Although a sub-framework of the Carbon Framework, the functions are available in 64-bit code. This should not be confused with the ImageCaptureKit framework, which is most likely an Objective-c wrapper around the main Image Capture framework.
Re: (try2)[PATCH 3/4] d3d10: Implement ID3DEffectVariable::GetInputSignatureElementDesc().
2010/4/7 Rico Schüller kgbric...@web.de:
+/* Check desc for NULL, this crashes on W7/DX10 */
+if (!desc)
+{
+WARN(This should crash on W7/DX10!\n);
+return E_FAIL;
+}
It's perfectly fine to require a parameter to be non-NULL, and just
crash if it isn't. You'll get a nice backtrace, or at least an
exception, which helps debugging as well.
+/* Check shader_index, this crashes on W7/DX10 */
+if (shader_index = This-effect-used_shader_count)
+{
+WARN(This should crash on W7/DX10!\n);
+return E_FAIL;
+}
Similar as above. In general if Windows doesn't check something, we
don't either. However, it's worth noting that if we'd be writing to
that index we sometimes do check those, because there's the potential
for memory corruption in those cases.
Re: [PATCH 01/10] server: allow polling for no events in set_fd_events
On Tue, Apr 6, 2010 at 2:03 PM, Alexandre Julliard julli...@winehq.org wrote: Mike Kaplinskiy mike.kaplins...@gmail.com writes: Would allowing adding the fd to the poll loop after it has been removed be more sane? Otherwise we have to resort to ugly things like sock_try_event (which only half work). I don't think that makes sense either. The error condition is not going to go away so you can no longer poll on it anyway, you really need to close the socket and create a new one. -- Alexandre Julliard julli...@winehq.org That's only true in the case of a full close; if you do shutdown(,SD_SEND) on the remote end, we will get POLLIN/0 recv, but if we decide to do a send after that and the connection gets broken (either the remote fully closes the socket or we get connection reset), we will receive a POLLHUP/POLLERR with a different error code, which is what windows reports. The problem is that there are two halves of the connection to hang up (when both have hangup we get a POLLHUP, otherwise just a POLLIN/0 recv). (data from http://www.greenend.org.uk/rjk/2001/06/poll.html ) But I see your point that perhaps it doesn't belong in the main loop when one of the halves gets closed. I guess we can keep sock_try_event around but only use it when the socket has been removed from the main loop. I'll also add detection of half-closed connection and drop that event if the other half hasn't hung up yet. Sadly looks like MacOS will be left out of that detection since it reports POLLIN|POLLHUP for everything. Does that sound good? Mike.
Re: [GSoC] IUri Implementations
In general, the idea looks right, that's how it probably should be implemented. This is an implementation detail through. The bigger and more important problem is URI parsing and canonicalization. That's where most of work needs to be done. In this case tests will be also very important. You don't know how it should work until you have a test. The first step would be to write a test infrastructure some tests (adding new test shouldn't be harder than filling a table with more data). Once it's done, you'll be able to decide on best way to implement parser and IUri interface. The project should result in many tests and good support for at least more useful flags and IUri functions. Hi Jacek, Sorry for my delayed response. Thank you for your suggestions. For the testing infrastructure, I was thinking about writing a few Windows programs that use Microsoft's IUri implementation to generate the results that my testing infrastructure would use to make sure my implementation is working correctly. Is this the right approach or would you recommend doing it another way? Also, I have finished a rough draft of my proposal and I was wondering if it would appropriate to post to it to the mailing list in order to receive feedback from you and others.
Re: [PATCH] [Server]: correctly set the DR0..7 registers on Linux for x86_64 architecture
Eric Pouech eric.pou...@orange.fr wrote: +case CPU_x86_64: +context-debug.x86_64_regs.dr0 = data[0]; +context-debug.x86_64_regs.dr1 = data[1]; +context-debug.x86_64_regs.dr2 = data[2]; +context-debug.x86_64_regs.dr3 = data[3]; +context-debug.x86_64_regs.dr6 = data[6]; +context-debug.x86_64_regs.dr7 = data[7]; +default: +set_error( STATUS_INVALID_PARAMETER ); +goto done; +} You forgot 'break'. +case CPU_x86_64: +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(0), context-debug.x86_64_regs.dr0 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr0 = context-debug.x86_64_regs.dr0; +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(1), context-debug.x86_64_regs.dr1 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr1 = context-debug.x86_64_regs.dr1; +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(2), context-debug.x86_64_regs.dr2 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr2 = context-debug.x86_64_regs.dr2; +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(3), context-debug.x86_64_regs.dr3 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr3 = context-debug.x86_64_regs.dr3; +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(6), context-debug.x86_64_regs.dr6 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr6 = context-debug.x86_64_regs.dr6; +if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(7), context-debug.x86_64_regs.dr7 ) == -1) goto error; +if (thread-context) thread-context-debug.x86_64_regs.dr7 = context-debug.x86_64_regs.dr7; +default: +set_error( STATUS_INVALID_PARAMETER ); +} Same here. -- Dmitry.
