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

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

On Mon, Mar 21, 2011 at 5:12 PM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Dnia poniedziałek, 21 marca 2011, Roderick Colenbrander napisał(a): >> Okay, as I expected no ARB_fragment_program support. Give the attached >> patch a try. For the time being (hope to get a little bit of time to >> finish what I started..) this patch may be acceptable. > > No crash with your patch, so probably it is OK. Good :) I guess I should submit the patch as it is now, I hope Henri would be fine with doing it this way for the time being (the FBO code is doing something equivalent). > > > So what now? I'm new here, and I don't know should I in any way cancel my > patch? Or it is enough you to send yours? I'm not fully sure how Alexandre works. I think typically when he sees a patch being discussed, he may already drop it. Roderick

March 21, 2011

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Juan Lang

Hi Joerg, > 2. Consequently, the players must implement a message loop and > dispatch regular window messages using DispatchMessageA/W > Currently, Wine does not. This IMHO has potential for dead locks. > Music and animations can play for a long time and messages ought to be serviced. > > I'm not familiar with windows messages at all. > What do you think about the consequence? Are you concerned about the applications introducing deadlocks by not servicing messages quickly enough, or about MCI introducing deadlocks by not processing messages in the current thread? If the former, I'd say that it's possible that Microsoft would consider this to be a buggy app, and not an issue for us. It's common to require that applications continue to "pump" the message loop when calling some blocking function. Modal dialog boxes continue to do so, for example. If the latter, this probably requires that MCI pump the message loop while it's processing. > Point 2 should be testable by playing a long piece of video or music > and prequeuing or injecting (how?) some windows events. How to test > this in a convincing manner? Perhaps call SetTimer with a period shorter than the duration of something you're about to play, and show that the thread receives a WM_TIMER before playing is complete? > Would the obligation to service messages disappear if the players ran > in their own thread (like w9x seems to do)? The obligation to process messages within MCI? Possibly. Since nothing since Win9x seems to use threads, however, I wouldn't be surprised if some app expects that it can post messages from its callbacks. In other words, don't expect all applications to be "Win9x safe." Hope that helps, --Juan

March 21, 2011

Must multimedia players check the message queue and invoke DispatchMessage?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, In Bug #3930 http://bugs.winehq.org/show_bug.cgi?id=3930#c41 I conjectured that: 1. Since w2k, winmm hijacks the application's thread to play multimedia content. Wine does this as well with MCI_WAIT, but it should as well affect winmm:playSound, winmm:midi* and winmm:wave*. 2. Consequently, the players must implement a message loop and dispatch regular window messages using DispatchMessageA/W Currently, Wine does not. This IMHO has potential for dead locks. Music and animations can play for a long time and messages ought to be serviced. I'm not familiar with windows messages at all. What do you think about the consequence? Point 1 explains why tests reveal the current thread as the one executing all callbacks but one since w2k. Point 2 should be testable by playing a long piece of video or music and prequeuing or injecting (how?) some windows events. How to test this in a convincing manner? Would the obligation to service messages disappear if the players ran in their own thread (like w9x seems to do)? Thanks for your help, Jörg Höhle

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Konrad Rzepecki

Dnia poniedziałek, 21 marca 2011, Roderick Colenbrander napisał(a): > Okay, as I expected no ARB_fragment_program support. Give the attached > patch a try. For the time being (hope to get a little bit of time to > finish what I started..) this patch may be acceptable. No crash with your patch, so probably it is OK. So what now? I'm new here, and I don't know should I in any way cancel my patch? Or it is enough you to send yours? -- Konrad Rzepecki (Hannibal)

March 21, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Thanks for the reply Stefan! It sounds like it is possible to do this project. I'll send my application to Google on the 28th. On Sun, Mar 20, 2011 at 11:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > Thanks for your proposal! > > I don't know the functions you suggest well enough personally to judge the > amount of work that is needed. Potential mentors are Roderick, Matteo, Henri > and me. I don't know who has time and is willing to mentor, but I think it is > safe to say that we'll find somebody :-) > > We had two d3dx9-centered gsoc projects in the past, namely Matteo's shader > assembler work and Tony Wasserka's texture loading work. Matteo's project > succeeded and the code is in Wine now. Tony's code didn't make it in during > the project, but at least parts(everything?) of it got committed later. > > As you can see we have another developer who's interested in d3dx9. Two > projects on the same library are doable if they target independent parts. > Luckily d3dx9 is a big collection of mostly independent helper functions. > > I don't want to jump to conclusions just yet, the formal application process > will decide which proposals are accepted. > > Best regards > Stefan > > On Sunday 20 March 2011 18:09:24 Michael Mc Donnell wrote: >> Dear Wine developers, >> >> I would like implement some of the missing mesh functions in Wine's >> D3DX9 for Google Summer of Code 2011. I would like to implement the >> following functions: >> - CloneMesh >> - CloneMeshFVF >> - ConvertPointRepsToAdjacency >> - ConvertAdjacencyToPointReps >> - GenerateAdjacency >> >> They seem to be suitable in size to implement during a summer, and I >> have a good idea of how to implement them. I expect to first implement >> tests and then implement the functions. >> >> I am a masters student at the Technical University of Denmark nearing >> the end of my studies, and I have specialized in 3D computer graphics, >> studying both real-time and physically based techniques, as well as >> how to use existing 3D modeling tools to create animations. The mesh >> functions should be fairly straight forward for me to implement as I >> have recently taken an advanced course on geometry processing which >> involved a lot of mesh manipulation. I have, furthermore, already >> tests (for a shell32 function) in the wine test suite so I have some >> knowledge of Wine development. >> >> Roderick Coldenbrander is listed as a possible mentor for "Direct3D - >> Implement missing D3D9_xx DLLs" on the wiki. Are you still interested, >> or would someone else like to be a mentor? >> >> Regards, >> Michael Mc Donnell >

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

Okay, as I expected no ARB_fragment_program support. Give the attached patch a try. For the time being (hope to get a little bit of time to finish what I started..) this patch may be acceptable. Roderick On Mon, Mar 21, 2011 at 8:36 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Dnia poniedziałek, 21 marca 2011, napisałeś(aś): > >> You should try to figure out why blit_priv is NULL. That's the real >> issue. > > I wish to know, where to search. But my patch prevent crash if blit_priv > is NULL form some reason. This is best place I found to fallback to software. > >> What drivers are you using? > > Binary NVIDIA on GF Ti4200 > >> Do they support arb fragment program? > > Im not sure, it is OGL 1.5.8 but with these extensions available (only > revelant part): > GL_ARB_shader_objects, GL_ARB_shading_language_100, > GL_ARB_vertex_program, GL_ARB_vertex_shader, > GL_NV_register_combiners, GL_NV_register_combiners2, > GL_NV_texture_env_combine4, GL_NV_texture_shader, > GL_NV_texture_shader2, GL_NV_texture_shader3, > GL_NV_vertex_program, GL_NV_vertex_program1_1 > > For sure hardware support vertex and fragment 1.X. > >> Right now we may still call arbfp_blit_surface when the >> extension isn't around (was working on this a year ago, haven't had >> time since then :( ), this could explain why there is no priv_data >> since in ffp_blit_alloc we don't do any allocation. > > I can't help with that, for now we can print FIXME when blit_priv is NULL so > this situation is not forget. > > -- > Konrad Rzepecki (Hannibal) > > >

March 21, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Ken Thomases

On Mar 21, 2011, at 8:52 AM, Charles Davis wrote: > On 3/10/11 3:27 PM, Ken Thomases wrote: >> On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: >> >>> I doubt Alexandre would accept reworking wineserver around CFRunLoop, > > I know. Then again, I've often wondered if doing this might be > beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5. I have a vague recollection of that, too, but we seem to have worked around it. kqueue is working well enough. The problem with CFRunLoop is that it's implemented really stupidly for sources which are not Mach ports, file descriptors in particular, at least on older versions of Mac OS X. >>> 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. > > Yeah. That makes me think AJ might not accept this, either. Then again, > it's not like this thread will actually be servicing requests from Wine > processes. Personally, I like it the best (or rather, hate it the least) > of all the options you mentioned. > >>> 2) Do this in Wine's userland, like in a service. > > But then we'd suffer the overhead of (even more) IPC. It's bad enough > that we have to talk to the server, but this way the app has to talk to > wineserver to talk to a service, and the service has to talk to > wineserver so it can talk back to the app. That's a lot of IPC, and > that's something I'd rather avoid if possible. Is the overhead material, though? I don't know that file change notification is such a high-frequency API that the calls back and forth will be a significant portion of total program time. After all, it's all ultimately gated by disk I/O. > Plus, it seems to me that > the inotify/dnotify support would have to be reworked in terms of this; > otherwise, we'd have to have ugly #ifdef blocks in ntdll's change > functions (in addition to the ones already in the server). > > Alternatively, we could just have the change functions run the run loop > themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to > waiting for directory changes. I'm not sure how you or AJ feel about > that, though. We'd still have to have #ifdef blocks in ntdll, though, if > we do it this way. I have to confess I haven't read the current inotify/dnotify-based implementation. >>> 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. > > If we do it this way, we may as well just spin off a new thread > (suggestion 1). The point of using a separate process is that it minimizes the exposure of wineserver to bugs, either in our new code or in the Mac frameworks. Currently, for example, the wineserver is only linked against libgcc and libSystem. That's another desirable quality, like its single-threaded nature. > It's cheaper to spawn threads rather than processes. We're talking about one process, right? >> 4) Use kqueue directly, with its vnode filter. It would entail opening every directory in a hierarchy, which might be deemed prohibitive. > > We could run out of Unix handles pretty quickly if we do it that way. As > I recall, the limit on the number of open FDs a process can have is > pretty low by default (only 2560 on my system). Of course, the user > could raise this limit (the hard limit is unlimited), but still I don't > feel comfortable painstakingly opening tens, hundreds, possibly even > thousands of file descriptors at once just to watch for changes to them. Hence, "deemed prohibitive". ;) Regards, Ken

March 21, 2011

Re: msi: Add an offset to sequence numbers belonging to files added by a patch. (try 2)

by Hans Leidekker

On Mon, 2011-03-21 at 14:14 +0100, David Hedberg wrote: > +static void msi_patch_offset_list_init(struct msi_patch_offset_list **pos) > +{ > + *pos = msi_alloc(sizeof(struct msi_patch_offset_list)); > + list_init( &(*pos)->files ); > + (*pos)->count = (*pos)->max = 0; > + (*pos)->min = 999999; > +} It would be nicer to have a _create function that returns an initialized structure.

March 21, 2011

Re: [PATCH 2/4] comdlg32: Add stub implementation of the Common Item dialogs.

by Nikolay Sivov

On 3/21/2011 16:37, David Hedberg wrote > + */ > + > +#include<stdarg.h> > + > +#define COBJMACROS > +#define NONAMELESSUNION > +#define NONAMELESSSTRUCT > + > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "wingdi.h" > + > +#include "commdlg.h" > +#include "cdlg.h" > + > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL(commdlg); > + > +typedef struct FileDialogImpl { > + IFileDialog2 IFileDialog2_iface; > + IFileOpenDialog IFileOpenDialog_iface; > + IFileSaveDialog IFileSaveDialog_iface; > + LONG ref; > +} FileDialogImpl; Maybe it's better to use a union and enum type field here, if it can't be open and save at the same time. > + > +/************************************************************************** > + * IFileDialog implementation > + */ > +static inline FileDialogImpl *impl_from_IFileDialog2(IFileDialog2 *iface) > +{ > + return (FileDialogImpl *)((char*)iface - FIELD_OFFSET(FileDialogImpl, IFileDialog2_iface)); > +} > + Use CONTAINING_RECORD macro please. > +static HRESULT WINAPI IFileDialog2_fnQueryInterface(IFileDialog2 *iface, > + REFIID riid, > + void **ppvObject) > +{ > > + } > + else > + FIXME("Unknown interface requested.\n"); It's better to dump guid here. > +} > + > +static ULONG WINAPI IFileDialog2_fnRelease(IFileDialog2 *iface) > +{ > + FileDialogImpl *This = impl_from_IFileDialog2(iface); > + LONG ref = InterlockedDecrement(&This->ref); > + TRACE("%p - ref %d\n", This, ref); > + > + if(!ref) > + { > + TRACE("Freeing object.\n"); > + HeapFree(GetProcessHeap(), 0, This); > + } > + > + return ref; > +} No need for additional trace I think, ref == 0 is enough to indicated that. > +static HRESULT FileDialog_constructor(IUnknown *pUnkOuter, REFIID riid, void **ppv, REFCLSID type) > +{ > + FileDialogImpl *fdimpl; > + HRESULT hr; > + TRACE("%p, %s, %p\n", pUnkOuter, debugstr_guid(riid), ppv); > + > + if(!ppv) > + return E_POINTER; > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + fdimpl = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(FileDialogImpl)); > + if(!fdimpl) > + return E_OUTOFMEMORY; Zero initialization is useless here. > + > + fdimpl->IFileDialog2_iface.lpVtbl =&vt_IFileDialog2; > + > + if(IsEqualCLSID(type,&CLSID_FileOpenDialog)) > + fdimpl->IFileOpenDialog_iface.lpVtbl =&vt_IFileOpenDialog; > + else > + fdimpl->IFileSaveDialog_iface.lpVtbl =&vt_IFileSaveDialog; > + > + IUnknown_AddRef((IUnknown*)fdimpl); > + hr = IUnknown_QueryInterface((IUnknown*)fdimpl, riid, ppv); > + IUnknown_Release((IUnknown*)fdimpl); > + That looks strange, you only need one QueryInterface here.

March 21, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Charles Davis

Sorry I waited so long to get back to you. On 3/10/11 3:27 PM, Ken Thomases wrote: > On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: > >> I doubt Alexandre would accept reworking wineserver around CFRunLoop, I know. Then again, I've often wondered if doing this might be beneficial. I seem to remember kqueue(2) being broken until Mac OS 10.5. >> but I can think of several alternatives: Unfortunately, each of them has a disadvantage. Quite frankly, I'm not liking our options at this point. >> >> 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. Yeah. That makes me think AJ might not accept this, either. Then again, it's not like this thread will actually be servicing requests from Wine processes. Personally, I like it the best (or rather, hate it the least) of all the options you mentioned. >> >> 2) Do this in Wine's userland, like in a service. But then we'd suffer the overhead of (even more) IPC. It's bad enough that we have to talk to the server, but this way the app has to talk to wineserver to talk to a service, and the service has to talk to wineserver so it can talk back to the app. That's a lot of IPC, and that's something I'd rather avoid if possible. Plus, it seems to me that the inotify/dnotify support would have to be reworked in terms of this; otherwise, we'd have to have ugly #ifdef blocks in ntdll's change functions (in addition to the ones already in the server). Alternatively, we could just have the change functions run the run loop themselves, in a special mode (see CFRunLoopRunInMode()) dedicated to waiting for directory changes. I'm not sure how you or AJ feel about that, though. We'd still have to have #ifdef blocks in ntdll, though, if we do it this way. >> >> 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. If we do it this way, we may as well just spin off a new thread (suggestion 1). It's cheaper to spawn threads rather than processes. There's an argument to be made for saving Unix handles in the server, but I don't think saving one handle (the write end of a pipe) just for this is worth it. There's also the whole "wineserver should be single-threaded" argument, but I already wrote about that under 1). > > 4) Use kqueue directly, with its vnode filter. It would entail opening every directory in a hierarchy, which might be deemed prohibitive. We could run out of Unix handles pretty quickly if we do it that way. As I recall, the limit on the number of open FDs a process can have is pretty low by default (only 2560 on my system). Of course, the user could raise this limit (the hard limit is unlimited), but still I don't feel comfortable painstakingly opening tens, hundreds, possibly even thousands of file descriptors at once just to watch for changes to them. Chip

March 21, 2011

Re: user32: Fix return value when passing a non-sibling preceding window to SetWindowPos.

by Dmitry Timoshkov

David Hedberg <dhedberg(a)codeweavers.com> wrote: > +#define ERROR_ABORT_WITH_TRUE 30000 ... > /* Fix redundant flags */ > - if (!fixup_flags( winpos )) return FALSE; > + ret = fixup_flags( winpos ); > + if(ret == ERROR_FUNCTION_FAILED) > + return FALSE; > + else if(ret == ERROR_ABORT_WITH_TRUE) > + return TRUE; Please try to avoid made up names and internal conditions. I'd suggest to add a test case which shows the problem first with todo_wine around the failing test, and only then send a fix, so it's clear what actually your patch is doing. Tiny nitpick, in the code below: if (condition1) return something1; else if (contition2) return something2; 'else' statement is redundant. -- Dmitry.

March 21, 2011

Re: [1/4] wined3d: don't create VBOs in buffer::preload

by Henri Verbeet

On 20 March 2011 20:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm not so sure about this patch. I think preload() should conceptually be "wined3d_resource_load_location(resource, WINED3D_RESOURCE_LOCATION_GPU, NULL);", and this patch seems to move away from that rather than towards it. I'm also not sure about how the bug you're describing would actually happen. Although device_stream_info_from_declaration() seems to assume preload() can only drop buffer objects, it does correctly call buffer_get_sysmem(), so the resulting stream info should be consistent, even though perhaps somewhat sub-optimal. Shouldn't this just be a matter of fixing device_stream_info_from_declaration() to not assume preload() can only drop buffer objects?

March 21, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Konrad Rzepecki

Dnia poniedziałek, 21 marca 2011, napisałeś(aś): > You should try to figure out why blit_priv is NULL. That's the real > issue. I wish to know, where to search. But my patch prevent crash if blit_priv is NULL form some reason. This is best place I found to fallback to software. > What drivers are you using? Binary NVIDIA on GF Ti4200 > Do they support arb fragment program? Im not sure, it is OGL 1.5.8 but with these extensions available (only revelant part): GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texture_env_combine4, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_program, GL_NV_vertex_program1_1 For sure hardware support vertex and fragment 1.X. > Right now we may still call arbfp_blit_surface when the > extension isn't around (was working on this a year ago, haven't had > time since then :( ), this could explain why there is no priv_data > since in ffp_blit_alloc we don't do any allocation. I can't help with that, for now we can print FIXME when blit_priv is NULL so this situation is not forget. -- Konrad Rzepecki (Hannibal)

March 21, 2011

Re: Xbox 360 controller compatibility

by Alesh Slovak

On 21 March 2011 05:46, Austin English <austinenglish(a)gmail.com> wrote: > http://www.winehq.org/pipermail/wine-patches/2008-November/064302.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064304.html > http://www.winehq.org/pipermail/wine-patches/2008-November/064305.html > These patches appear to only add a stub and implement test cases. As far as I can tell, it seems the stub and test cases in current git are based on these patches. I've also found a set of patches by Michael Gruber from 2009 that appear to actually implement xinput: http://marc.info/?l=wine-patches&m=124710119700598&w=4 http://marc.info/?l=wine-patches&m=124710124200662&w=4 http://marc.info/?l=wine-patches&m=124710129100718&w=4 http://marc.info/?l=wine-patches&m=124710132300760&w=4 What do people think of these?

March 21, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 15:47, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On 3/20/11 10:28 PM, Ben Klein wrote: >> On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> On 3/20/11 9:31 PM, Ben Klein wrote: >>>> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>>> interface. Even if other systems use int 80h for their syscall vector >>>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>>> aren't the same across different platforms. >>>> >>>> Does this also mean it will fail to work on amd64/ia64 systems? >>> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >>> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >>> keep the old int 80h interface around solely for the benefit of old >>> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >>> AJ fixed it) that expect it to be there. >>> >>> In fact, even if 64-bit code supported the int 80h interface, it still >>> wouldn't work, because even across different architectures on Linux, the >>> syscall numbers are different. >> >> Thanks for explaining it. >> >> Something else I noticed in this patch though; what happens to the >> environment variables handled by the loader script? > Nothing. He even hard-coded the path to the 'wine' binary (as a series > of DWORDs, no less!). I suspected that's what was going on. Basically, this patch makes absolutely no logical sense at all.

March 21, 2011

Re: Xbox 360 controller compatibility

by Roderick Colenbrander

On Sun, Mar 20, 2011 at 3:48 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 20 March 2011 21:46:34 Austin English wrote: >> > There are some patches still around (would have to look them up) and >> > they work. > <warn reason="clueless"> > I think the main problem with implementing xinput.dll isn't xinput itself, it > is the lack of a proper joystick infrastructure in wine. Currently dinput.dll > reads the /dev/js* devices directly, but preferably joystick input should be > done over the X server and winex11.drv. This needs some tricky adjustments, > winex11.drv isn't a place where you can just add some hacky code and hope > Alexandre doesn't notice. > </warn> > Yeah, that was indeed part of the discussion we had last year when this came up. With the direction X11 is taking, I doubt there will ever be proper joystick support in X11. I fear the only way is /dev/evdev (not that portable)... which was what the patches were using. Roderick

March 20, 2011

Re: wined3d: Prevent crash when blit_priv is NULL.

by Roderick Colenbrander

Hi Konrad, You should try to figure out why blit_priv is NULL. That's the real issue. What drivers are you using? Do they support arb fragment program? Right now we may still call arbfp_blit_surface when the extension isn't around (was working on this a year ago, haven't had time since then :( ), this could explain why there is no priv_data since in ffp_blit_alloc we don't do any allocation. Roderick On Sun, Mar 20, 2011 at 3:58 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Might&Magic VII from gog.com crash in bink movie plaing: > > Backtrace: > =>0 0x7e70c4b9 arbfp_blit_set+0x28b(blit_priv=0x0(nil), gl_info=0x135b08, surface=0x1dc788) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7058] in wined3d (0x0033f98c) > 1 0x7e70d3db arbfp_blit_surface+0xa2(device=0x16cdc0, src_surface=0x1dc788, src_rect=0x33fa74, dst_surface=0x168140, dst_rect_in=0x33fa84, blit_op=BLIT_OP_BLIT, Filter=0x2) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7192] in wined3d (0x0033f9dc) > 2 0x7e7d28f7 IWineD3DSurfaceImpl_BltOverride+0xf1b(dst_surface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3787] in wined3d (0x0033fbac) > 3 0x7e7d3013 IWineD3DSurfaceImpl_Blt+0x29e(iface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3930] in wined3d (0x0033fc2c) > 4 0x7e8687f2 ddraw_surface7_Blt+0x380(iface=0x135308, DestRect=0x33fcf8, SrcSurface=0x1dc560, SrcRect=0x33fce8, Flags=0x1000000, DDBltFx=(nil)) [/mnt/skopia/devel/winegit/wine/dlls/ddraw/surface.c:908] in ddraw (0x0033fc9c) > 5 0x004a18cd in mm7-rel (+0xa18cc) (0x0033fcc8) > 6 0x004beda4 in mm7-rel (+0xbeda3) (0x0033fd08) > 7 0x004be721 in mm7-rel (+0xbe720) (0x00000000) > --- > dlls/wined3d/surface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 745bd77..baa032b 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3924,8 +3924,8 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_Blt(IWineD3DSurface *iface, const RECT > } > > /* Special cases for RenderTargets */ > - if ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > - || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET))) > + if (This->resource.device->blit_priv && ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > + || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET)))) > { > if (SUCCEEDED(IWineD3DSurfaceImpl_BltOverride(This, DestRect, src, SrcRect, flags, DDBltFx, Filter))) > return WINED3D_OK; > -- > 1.7.4.1 > > >

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 10:28 PM, Ben Klein wrote: > On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> On 3/20/11 9:31 PM, Ben Klein wrote: >>> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>> interface. Even if other systems use int 80h for their syscall vector >>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>> aren't the same across different platforms. >>> >>> Does this also mean it will fail to work on amd64/ia64 systems? >> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >> keep the old int 80h interface around solely for the benefit of old >> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >> AJ fixed it) that expect it to be there. >> >> In fact, even if 64-bit code supported the int 80h interface, it still >> wouldn't work, because even across different architectures on Linux, the >> syscall numbers are different. > > Thanks for explaining it. > > Something else I noticed in this patch though; what happens to the > environment variables handled by the loader script? Nothing. He even hard-coded the path to the 'wine' binary (as a series of DWORDs, no less!). Chip

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > On 3/20/11 9:31 PM, Ben Klein wrote: >> On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>> because the 'start' code invokes execve(2) using the interrupt 80h >>> interface. Even if other systems use int 80h for their syscall vector >>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>> aren't the same across different platforms. >> >> Does this also mean it will fail to work on amd64/ia64 systems? > For 32-bit (x86) code running on an x86-64/IA64 system, it will work. > For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels > keep the old int 80h interface around solely for the benefit of old > 32-bit programs (like old versions of Wine, before Maarten Lankhorst and > AJ fixed it) that expect it to be there. > > In fact, even if 64-bit code supported the int 80h interface, it still > wouldn't work, because even across different architectures on Linux, the > syscall numbers are different. Thanks for explaining it. Something else I noticed in this patch though; what happens to the environment variables handled by the loader script?

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 9:31 PM, Ben Klein wrote: > On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> Also, as near as I can tell, this will only work on x86 Linux. It won't >> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >> because the 'start' code invokes execve(2) using the interrupt 80h >> interface. Even if other systems use int 80h for their syscall vector >> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >> aren't the same across different platforms. > > Does this also mean it will fail to work on amd64/ia64 systems? For 32-bit (x86) code running on an x86-64/IA64 system, it will work. For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels keep the old int 80h interface around solely for the benefit of old 32-bit programs (like old versions of Wine, before Maarten Lankhorst and AJ fixed it) that expect it to be there. In fact, even if 64-bit code supported the int 80h interface, it still wouldn't work, because even across different architectures on Linux, the syscall numbers are different. Chip

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Ben Klein

On 21 March 2011 12:26, Charles Davis <cdavis(a)mymail.mines.edu> wrote: > Also, as near as I can tell, this will only work on x86 Linux. It won't > work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is > because the 'start' code invokes execve(2) using the interrupt 80h > interface. Even if other systems use int 80h for their syscall vector > (Mac OS does, at least for Unix syscalls), the syscall numbers usually > aren't the same across different platforms. Does this also mean it will fail to work on amd64/ia64 systems?

March 20, 2011

Re: Xbox 360 controller compatibility

by Alesh Slovak

Thanks all for the info and insight. On 21 March 2011 07:48, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Sunday 20 March 2011 21:46:34 Austin English wrote: > > > There are some patches still around (would have to look them up) and > > > they work. > <warn reason="clueless"> > I think the main problem with implementing xinput.dll isn't xinput itself, > it > is the lack of a proper joystick infrastructure in wine. Currently > dinput.dll > reads the /dev/js* devices directly, but preferably joystick input should > be > done over the X server and winex11.drv. This needs some tricky adjustments, > winex11.drv isn't a place where you can just add some hacky code and hope > Alexandre doesn't notice. > </warn> > If dinput is currently implemented this way, what's the problem with implementing xinput in the same way, at least for now? It can always be refactored later if needed. Is this the only reason why the patches didn't make it in before?

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by James McKenzie

On 3/20/11 4:14 AM, Pali Rohár wrote: > 2011/2/19 Pali Rohár<pali.rohar(a)gmail.com>: >> 2011/2/4 Pali Rohár<pali.rohar(a)gmail.com>: >>> Hello, >>> >>> I created patch which implement correct _start section in ELF shared >>> libraries/binaries which generate winegcc. >>> Into _start section this patch add calling execve syscall which start >>> wine with all arguments. So it is not needed to generate shell wrapper >>> and .exe.so binary. >>> >>> This replace code on: >>> http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so >>> >>> $ winegcc app.c --> generate only a.exe (shared object ELF binary), no >>> aditional a.exe.so >>> $ ./a.exe --> start binary correctly without shell wrapper >>> >>> -- >>> Pali Rohár >>> pali.rohar(a)gmail.com >>> >> I rewrited my patch. Now set up correctly enviromental variables too. >> Assembler code is only for x86. >> >> -- >> Pali Rohár >> pali.rohar(a)gmail.com >> > Can anybody review my patch? > Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Charles Davis

On 3/20/11 6:54 PM, Chris Robinson wrote: > On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote: >> On 03/20/2011 05:14 AM, Pali Rohár wrote: >>> Can anybody review my patch? >> >> Not sure what you trying to do exactly. Wine already has wrapper that makes >> all wine binaries executable after they are being installed into system. > > Wine installs wrapper scripts which call wine with the appropriate .exe.so > DSO. The .exe.so file can't be run directly. > > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. It's not enough to have a 'start' symbol. The binary has to be of the right type, too. On Mac OS, for example, the binary has to be of the MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or you won't be able to execve(2) it. With ELF, the binary type has to be ET_EXEC (instead of ET_DYN). Also, I don't know if Mac OS, Linux, or any other platform allows you to dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS, ET_DYN on ELF platforms). In that case, the right answer might just be to leave this alone. Another solution might be to re-implement the Wine loader logic in the executable itself, but I'm not sure if that's a good idea. Also, as near as I can tell, this will only work on x86 Linux. It won't work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is because the 'start' code invokes execve(2) using the interrupt 80h interface. Even if other systems use int 80h for their syscall vector (Mac OS does, at least for Unix syscalls), the syscall numbers usually aren't the same across different platforms. Chip

March 20, 2011

Re: [PATCH] winegcc - do not create .exe.so

by Vitaliy Margolen

On 03/20/2011 06:54 PM, Chris Robinson wrote: > As far as I can tell, the patch makes it so the .exe.so file can be run > directly, by adding a _start section that automatically execs wine with all > the same arguments passed on the command line. As a result, it removes the .so > extension so you can, for example, just run the 'winecfg.exe' executable > itself, with no 'winecfg' wrapper script needed. This is what I understood as well. My problems with the patch are: - This should be platform independent and working everywhere Wine works - It should be optional at very minimum. It's not possible to run shared libraries for a reason. - Calling something .exe doesn't magically make it a PE-executable. You can't call ELF shared library a windows executable. File can stay .exe.so and still be executable as they are now Vitaliy.

March 20, 2011