wine-devel April 2007

wine-devel@winehq.org

139 participants
312 discussions

Re: rpcrt4: Implement RpcMgmtWaitServerListen
by Robert Shearman 12 Apr '07

12 Apr '07

Dan Hipschman wrote: > @@ -94,7 +95,8 @@ struct connection_ops { > RpcConnection *(*alloc)(void); > RPC_STATUS (*open_connection_client)(RpcConnection *conn); > RPC_STATUS (*handoff)(RpcConnection *old_conn, RpcConnection *new_conn); > - int (*read)(RpcConnection *conn, void *buffer, unsigned int len); > + int (*read)(RpcConnection *conn, void *buffer, unsigned int len, BOOL check_stop_event); > + int (*signal_to_stop)(RpcConnection *conn); > int (*write)(RpcConnection *conn, const void *buffer, unsigned int len); > int (*close)(RpcConnection *conn); > size_t (*get_top_of_tower)(unsigned char *tower_data, const char *networkaddr, const char *endpoint); > Hmm, I'm not sure it needs to be this complicated. > HeapFree(GetProcessHeap(), 0, msg); > } > > -static DWORD CALLBACK RPCRT4_worker_thread(LPVOID the_arg) > -{ > - RpcPacket *pkt = the_arg; > - RPCRT4_process_packet(pkt->conn, pkt->hdr, pkt->msg); > - HeapFree(GetProcessHeap(), 0, pkt); > - return 0; > -} > - > static DWORD CALLBACK RPCRT4_io_thread(LPVOID the_arg) > { > RpcConnection* conn = (RpcConnection*)the_arg; > @@ -319,10 +322,14 @@ static DWORD CALLBACK RPCRT4_io_thread(LPVOID the_arg) > RpcBinding *pbind; > RPC_MESSAGE *msg; > RPC_STATUS status; > - RpcPacket *packet; > > TRACE("(%p)\n", conn); > > + EnterCriticalSection(&client_connections_cs); > + list_add_head(&client_connections, &conn->client_entry); > + ResetEvent(clients_completed_event); > + LeaveCriticalSection(&client_connections_cs); > + > for (;;) { > msg = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(RPC_MESSAGE)); > > @@ -338,17 +345,17 @@ static DWORD CALLBACK RPCRT4_io_thread(LPVOID the_arg) > break; > } > > -#if 0 > RPCRT4_process_packet(conn, hdr, msg); > -#else > - packet = HeapAlloc(GetProcessHeap(), 0, sizeof(RpcPacket)); > - packet->conn = conn; > - packet->hdr = hdr; > - packet->msg = msg; > - QueueUserWorkItem(RPCRT4_worker_thread, packet, WT_EXECUTELONGFUNCTION); > -#endif > - msg = NULL; > } > + > + EnterCriticalSection(&client_connections_cs); > + list_remove(&conn->client_entry); > + if (list_empty(&client_connections)) { > + TRACE("last in the list to complete (%p)\n", conn); > + SetEvent(clients_completed_event); > + } > + LeaveCriticalSection(&client_connections_cs); > + > RPCRT4_DestroyConnection(conn); > return 0; > } > I'm not sure your reasoning for doing this. If I'm not mistaken, this change makes it so that only one RPC call at a time is processed. -- Rob Shearman

2 1

Re: wined3d: Mark vertex shader 3.0 as foggy shaders if they write out the fog coord
by Ivan Gyurdiev 12 Apr '07

12 Apr '07

Fabian Bieler wrote: > Vertex shaders are marked as 'foggy shaders' in wined3d if they write out the > fog coord. Previously this was not done for vertex shaders 3.0. This patch > corrects this problem. > Please don't do that - the design is flawed enough as it is (GLSL being invoked from vertexshader and such..). The reg_maps was meant to be: - computed in shader pass 1 [ register tracking ] - used in shader pass 2 [ code generation ]. Here you're doing this: - computing reg_maps at the very end of shader pass 2 [ unpack stage ] - using this right afterwards in the calling function to set yet another flag (This->usesFog). I'm not sure what needs to be done instead, since it all looks so broken... - I would say this type of analysis about shader usage needs to go into pass 1 (baseshader), since it is backend independent. It's kind of vertex-shader specific, but we're trying to merge vertex and pixel shaders, and remove code from these two files, not add more of it. - The usesFog looks like it's trying to persist information about register usage after the shader has been compiled for optimization purposes...except that this information is already persisted - if you look in baseshader, you will see the entire reg_maps structure is kept in there, exactly for that purpose [ was done for software shaders actually, but that never happened ]. - Also, other code outside the shaders should not be accessing these flags directly - there should be a function which looks inside the reg_maps, and code from other file should call that function (we are emulating OOP programming in C, so we should try to use encapsulation). Ivan

2 2

Re: Add Windows Vista option to winecfg
by H. Verbeet 12 Apr '07

12 Apr '07

On 12/04/07, Kovács András <andras(a)csevego.net> wrote: > This patch is needed, because DirectX 10 is Vindows Vista only feature. > You'll need to change more than that, eg. see my attachment to bug 7558. Note that I only guessed the values used in that patch, to make the dx sdk installer happy. They would still have to be verified to be correct on an actual Vista install.

1 1

Patches / a proposal for the mystic DIB engine
by Felix Nawothnig 12 Apr '07

12 Apr '07

Okay, I've spent the last days looking into this matter and I'd like to suggest a way to get it started. So. This is the plan: 1. In winex11.drv: -INT X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL lossy) +HBITMAP X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL force) Lossy isn't used anywhere for LockDIBSection anyway. Force means that the function will only lock if the DIB is already in AppMod. The returned bitmap is ofcourse physDev->bitmap->hbitmap. Rationale: If you lock the DIB to write on it it makes sense that the function actually provides you with that DIB. 2. Export LockDIBSection/Unlock to gdi32. Adding more exports is not nice but there really is no way around that, right? 3. Move dc->funcs to dc->physDev->funcs. Many changes but mostly mechanical work. Rationale: This really belongs there. And I need it. :) 4. Now we write dibdrv.c for now just containing DIBDRV_Install and DIBDRV_Remove. That function will go through the physDev->funcs list and overwrite each function pointer which is actually implemented with DIBDRV_PutPixel(), whatever. DIBDRV_Install/DIBDRV_Remove will be called from BITMAP_SelectObject() when we switch from non-DIB to DIB vice versa. Note that we can't use DRIVER_load_driver here because of the wanted "forward to original driver when not implemented". For this we will need to extend the "for DIB objects" part in BITMAPOBJ by const DC_FUNCTIONS *orig_funcs; DC_FUNCTIONS local_funcs; where orig_funcs to the old physDev->funcs and the new physDev->funcs points to &bmp->local_funcs. 5. In dibdrv.c we get us: enum { DIBDRV_MIXED, /* Choose driver depending on current AppMod */ DIBDRV_ALWAYS, /* Always use DIBDRV (unless function not implemented) */ DIBDRV_NEVER /* Always use DC driver */ } DIB_Mode = DIBDRV_MIXED; and DIB_Lock(PHYSDEV physDev) / DIB_Unlock(PHYSDEV). Now, here comes the reason we need the HBITMAP from LockDIBSection() and funcs inside PHYSDEV: Since we don't have the DC here we have no way of calling LockDIBSection(), forwarding to the original driver if NEVER/MIXED or writing to the actual DIB in case of MIXED/ALWAYS. 6. From this point we can start implementing one function at a time, touching nothing but dibdrv.c. So far so good. I did all those steps (except 3., I hacked around that in my local tree) in a clean way and it works nice (for 6. I implemented SetPixel() and tried that with a test-app). I attached patches for the steps 1 2 and 4 so you can see where this is going. Comments? Felix

7 9

Questions about using native vs implementing our own
by Tom Spear 12 Apr '07

12 Apr '07

Hi again all, before I go and file another needless bug, I thought I would ask for opinions. I decided to try to run Process Explorer today with wine. When I first ran it, I got a dialog about missing a function. So I looked back thru the traces and it was because we were missing acledit.dll.. So I imported that from my windows xp install, and got the dialog again. Turned out I was also missing netui0.dll, netui1.dll, and netui2.dll and those in turn needed netrap.dll and samlib.dll. Once I got all of those imported from XP, Process Explorer now runs beautifully. I looked at the version information, and here is the description of each dll acledit is an access control list editor netui0 is NT LM UI Common Code - GUI Classes netui1 is NT LM UI Common Code - Networking classes netui2 is NT LM UI Common Code - GUI Classes netrap is Net Remote Admin Protocol DLL and samlib is SAM Library DLL I assume SAM is the Security Accounts Manager service, so that last dll would go for that and most likely would never be implemented with wine. But, how about the others? Is doing one of these something possibly feasible for a SoC project? I'm sure that there are other projects that use these dll's as well, but I dont know of them.. My biggest question is when is it appropriate for us to build our own DLL's vs just saying to use native? I would personally like to at least see the NTLM stuff get built since I know one of the developers is working on NTLM right now Also, should I file a bug for Process Explorer needing native dll's, or should I maybe file a bug to build our own versions of these dll's, OR should I just leave it alone altogether? I am creating an AppDB page for the program now. Does anyone object to me putting notes about which native dll's are needed on that page? -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

6 10

Windows dll as Linux Shared Object
by Phil Lodwick 12 Apr '07

12 Apr '07

Greetings, My googling skills are letting me down today. I believe I have seen several people requesting to do the same and answers indicating it is possible. However, after several hours of reading email archives from 2000-2007 are am officially confused :-( I have successfully ported an application using winelib. However, what I really want to do is port a DLL to an SO which I can use natively from a Linux application. I believe this is something that can be done with winemaker/winebuild etc if I just get the recipe right -- correct? ie: WindowsDLL.cpp int AndTheAnswerIs() { Return 42; } WindowsDLL.def EXPORTS: AndTheAnswerIs Use winemaker/winebuild to create WindowsDLL.dll.so Linux.cpp: main() { printf("AndTheAnswerIs: %d\n", AndTheAnswerIs()); } g++ linux.cpp -lWindowsDLL Is this possible, or am I missing something? Thanks much! Phil

3 5

Re: Add Windows Vista option to winecfg
by Felix Nawothnig 12 Apr '07

12 Apr '07

Kovács András wrote: > This patch is needed, because DirectX 10 is Vindows Vista only feature. Nothing wrong with adding Vista to the list but how is this needed? You don't want to disallow usage of dx10 unless Vista is selected, do you? Felix

2 1

How come individual applications can't be put on a virtual desktop in winecfg?
by Scott Ritchie 12 Apr '07

12 Apr '07

I have a single, very old application that needs to run in Windows 98 mode with a 640x480 virtual desktop. But, I'd like to run other applications at the same time. How come I can't set winecfg to make a virtual desktop for just this application, and handle everything else in the window manager? Thanks, Scott Ritchie

5 7

Re: [winealsa] add support for mixer devices
by Dmitry Timoshkov 12 Apr '07

12 Apr '07

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > +/************************************************************************** > + * mxdMessage (WINEALSA.3) > + */ > +DWORD WINAPI ALSA_mxdMessage(UINT wDevID, UINT wMsg, DWORD dwUser, > + DWORD dwParam1, DWORD dwParam2) It would be nice when adding new code make it 64-bit safe from the start, in this case using a proper DRVCALLBACK prototype for the driver callback, and using proper data types for passing in/out parameters around. -- Dmitry.

2 1

Cast-Qual warnings
by Mike Schaadt 12 Apr '07

12 Apr '07

I've been seeing a lot of work done on fixing these warnings, so I thought I would rerun the check and see how many warnings appear(ignoring the ones caused by unicode.h of course). The results are in. Total number of warnings in make depend: 0 Total number of warnings in make from .h files: 0 Total number of warnings in make from .c files: 664 I've included the file with all of the warnings in this post. Any thoughts? Should I bother to keep creating updates like this? What ones can we mark as required? What ones can we mark as should be fixed?

1 0

← Newer
1
...
20
21
22
23
24
25
26
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2007