Re: [Wine] How should I educate myself in order to code for WineHQ?
"James McKenzie" <[EMAIL PROTECTED]> wrote: > Dan Kegel wrote: >> On Wed, Mar 12, 2008 at 5:11 PM, jingo811 <[EMAIL PROTECTED]> wrote: >> >>> So I was wondering can you give me an ordered to-do-list in becoming a >>> Code Monkey for WineHQ? >>> >>> Like do I have to know both C and C++ to code for Wine. >>> >> >> Nope, just C. Go through "The C Programming Language" by >> Kernighan and Ritchie, and do all the exercizes. >> >> > If you can make it through the book, you are very good and will work > well for the Wine project. > > BTW, anyone want a spare copy of this book? Unfortunately that's not that simple. Wine programming requires Windows API programming skills as well, one needs an experience of using at least APIs for the component(s) of Wine he/she is going to write the code for, and a good knowledge how it's supposed to work/operate internally. One should be prepared to write lots of tests to investigate/clarify behaviour described/missing in MSDN. -- Dmitry.
Re: [Wine] How should I educate myself in order to code for WineHQ?
Dan Kegel wrote: > On Wed, Mar 12, 2008 at 5:11 PM, jingo811 <[EMAIL PROTECTED]> wrote: > >> So I was wondering can you give me an ordered to-do-list in becoming a Code >> Monkey for WineHQ? >> >> Like do I have to know both C and C++ to code for Wine. >> > > Nope, just C. Go through "The C Programming Language" by > Kernighan and Ritchie, and do all the exercizes. > > If you can make it through the book, you are very good and will work well for the Wine project. BTW, anyone want a spare copy of this book? James
Re: [3/6] kernel32: Add the MOVEFILE_WRITE_THROUGH flag (stub) for MoveFileEx.
Yup, ignore.
On Thu, Mar 13, 2008 at 04:00:32PM -0700, Dan Hipschman wrote:
>
> NOTE: I thought I sent this with the other five patches, but I don't see
> it. Sorry if it ends up being a resend.
>
> This feature of MoveFileEx is technically needed by
> IBackgroundCopyJob_Complete
> to return the correct status if it has to move temp files across volumes, but
> since it's a very small point, I'm just adding the flag so we can compile with
> it.
>
> ---
> dlls/kernel32/path.c |3 +++
> include/winbase.h|1 +
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c
> index f0f713f..aad260f 100644
> --- a/dlls/kernel32/path.c
> +++ b/dlls/kernel32/path.c
> @@ -1010,6 +1010,9 @@ BOOL WINAPI MoveFileWithProgressW( LPCWSTR source,
> LPCWSTR dest,
> if (!dest)
> return DeleteFileW( source );
>
> +if (flag & MOVEFILE_WRITE_THROUGH)
> +FIXME("MOVEFILE_WRITE_THROUGH unimplemented\n");
> +
> /* check if we are allowed to rename the source */
>
> if (!RtlDosPathNameToNtPathName_U( source, &nt_name, NULL, NULL ))
> diff --git a/include/winbase.h b/include/winbase.h
> index e2ee515..f3130a0 100644
> --- a/include/winbase.h
> +++ b/include/winbase.h
> @@ -845,6 +845,7 @@ typedef DWORD (CALLBACK
> *LPPROGRESS_ROUTINE)(LARGE_INTEGER, LARGE_INTEGER, LARGE
> #define MOVEFILE_REPLACE_EXISTING 0x0001
> #define MOVEFILE_COPY_ALLOWED 0x0002
> #define MOVEFILE_DELAY_UNTIL_REBOOT 0x0004
> +#define MOVEFILE_WRITE_THROUGH 0x0008
>
> #define REPLACEFILE_WRITE_THROUGH 0x0001
> #define REPLACEFILE_IGNORE_MERGE_ERRORS 0x0002
>
>
Re: GSoC
Christopher Harvey wrote: > I've had a few ideas that I thought of on my own, but now I'm starting > to see they perhaps aren't as useful as the ideas thought of by current > developers, but I'll float it out there one last time. I thought it > would be cool to create a wine GUI overlay for games, exactly like > nvPerfHUD. The thing about doing it in wine that makes it better than > nvPerHUD is the fact the to use nvPerfHUD the apps have to give > permission for nvPerHUD to run on them. A wine version would actually be > able to force every single 3d app, opengl or directX to output nvPerfHUD > like output. Anyway, just a thought. Would I be able to apply for both > of these projects and pick one last minute? > Thanks, > Chris. > After talking about the concept a bit at the Ubuntu Developer Summit, I really don't like the idea of a "Wine GUI" just for running Wine applications. From the user's persepctive, installers for Wine applications shouldn't be substantially different from any old Linux installer - they just click on them, it adds something to their applications menu, and from then on they can run it from there. Most of the futzing with applications, like messing around with native dlls in winecfg, shouldn't have to be done at all. The same goes with editing the registry. Configuration we'll never be able to eliminate completely, like selecting the windows version, should ultimately be done through an intuitive place and not some central "Wine configuration" program. For instance, I should be able to right click a Windows application, select properties, and then change the Windows version from there. So, yes, I agree. Winecfg is ugly and inadequate for the kind of configuration our users are doing now. But before we put too much effort into sprucing up Winecfg, let's instead talk about how feasible it is to make it unneeded in the first place. Thanks, Scott Ritchie
RE: Clipping regions on windows and Expose Xevents issue
Thanks Alexandre, (BTW This createwindow / movewindow / draw to window is all occurring in LBUTTONDOWN processing) >> 1. MoveWindow doesn't update the DCEx clip_region region, and hence when the >> visible region changes, it is merged with the clip region and since there is >> no overlap the visible region is empty so all subsequent processing ends. >> >> Q: Whats the best way to handle that - I was tempted to reset the >> clip_region to the visible_region (as MSDN sort of implies - you cant really >> query them so tests don't help much here) in a movewindow call >You can query the visible region, so with well-chosen dimensions and >clip region it shouldn't be too hard to write test cases. Make sure you >test both GetDCEx with an explicit clip region and BeginPaint, the >behavior is probably different The difficulty here is the inability to directly query the concealed (within the struct DCE) clip_rgn not the visible region. For example, GetClipRgn returns dc->hClipRgn, whereas the dce clip_rgn is internal to user32 painting.c. The only call I can see replaces the region with GetDCEx? What kind of test did you have in mind - The only idea I had was something like CreateWindow at 100,100, begin paint, MoveWindow to 50,50, FillRect into red, endpaint, then read it back to see if it really is read? >> Q: This is getting way outside my understanding of X events, but shouldn't >> the Expose event for the child (popup) window be processed before returning >> from CreateWindow with style WS_VISIBLE? >The way we hack around the asynchronous events is by checking for expose >events in UpdateWindow, but of course if the app doesn't even use that >it won't help. And on a slow connection the expose events will always >arrive too late anyway. We'd need to explicitly wait for the event, but >that would hurt badly on slow connections. The app is processing in a WM_LBUTTONDOWN, and just creates a window and draws to it immediately, and the windows message loop wont redraw it. Is there any workaround for this or is it going to be an impossibility to get it working? (I wondered, for example, if we can do anything about ignoring the first expose if the window was created as visible, or removing the rdw_erase if the window had explicitly painted itself before the first event)? Jason
Please vote for your favorite Wine-1.0 bugs...
The 1.0 release of Wine is tenatively scheduled for the 15th anniversary of the project (roughly 1 June 2008, if you take Dan Dulitz' message as the start of the project, http://groups.google.com/group/comp.os.linux/msg/7f92abdf494ab8b3 ) Over the last six or so months, the wine developers have identified 180 or so bugs as possibly being worth fixing before the 1.0 release. 63 of the Wine 1.0 bugs have already been fixed: http://bugs.winehq.org/buglist.cgi?target_milestone=1.0.0&resolution=FIXED 101 are left to fix: http://bugs.winehq.org/buglist.cgi?target_milestone=1.0.0&resolution=--- We can't fix all of these before the 1.0 release; we'll have to leave some for later. If you want a say in which of these bugs get fixed sooner, please vote for your favorite bugs. To do this, sign into Bugzilla (you need to register, but that's easy), pull up your favorite bug from the above list, and click on the 'Vote for this bug' link on the bug. We can't promise we'll fix the bugs with the most votes, but knowing which ones are most popular can't hurt. Thanks, Dan
Re: wine virus story
On Thu, Mar 13, 2008 at 12:49 PM, L. Rahyen <[EMAIL PROTECTED]> wrote: > Separate user is enough if you don't have world writable files in your > system. And of course user for such purpose shouldn't be in group(s) that > have write access to your personal or system files. > If you are unsure use VirtualBox ( http://virtualbox.org/ ) - it's > free and > open-source, or VMWare ( http://vmware.com/ ) - it's not free. > On Debian (and probably Ubuntu) you can install VirtualBox by running > "sudo > apt-get install virtualbox". > I do not recommend to use QEmu because it's less user friendly than > VirtualBox (BTW, VirtualBox is based on QEmu). > VMWare workstation is not free, but you can get both VMWare server and VMWare player at no charge. It's available from the Canonical repositories as well: http://archive.canonical.com/ubuntu/pool/partner/v/vmware-server/
Configure not throwing error for missing asoundlib.h
Hi, even with "--with-alsa" there is no report on a missing asoundlib.h. This is a bit inconvenient since other missing libs are reported. Valid for wine-0.9.57 Sebastian signature.asc Description: This is a digitally signed message part.
Re: wine virus story
On 3/13/08, L. Rahyen <[EMAIL PROTECTED]> wrote: > Separate user is enough if you don't have world writable files in your > system. No, because the malware could root your Linux system using a local priv escalation exploit. You really want a totally isolated sandbox. - Dan
Re: fonts: Start of the Symbol font.
Huw Davies <[EMAIL PROTECTED]> writes: > --- > fonts/Makefile.in |1 + > fonts/symbol.sfd | 83 > + > 2 files changed, 84 insertions(+), 0 deletions(-) > create mode 100644 fonts/symbol.sfd It fails make test for me: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:1357: Test failed: no fonts should be enumerated: Symbol ANSI_CHARSET font.c:1405: Test failed: SYMBOL_CHARSET should NOT enumerate ANSI_CHARSET for Symbol font.c:1407: Test failed: SYMBOL_CHARSET should enumerate SYMBOL_CHARSET for Symbol font.c:1447: Test failed: no fonts enumerated: Symbol SYMBOL_CHARSET font.c:1458: Test failed: SYMBOL_CHARSET should enumerate SYMBOL_CHARSET for Symbol font.c:1639: Test failed: A: tmLastChar for Symbol 20 != ff font.c:1671: Test failed: W: tmFirstChar for Symbol 00 != 30 make: *** [font.ok] Error 7 -- Alexandre Julliard [EMAIL PROTECTED]
Re: mshtml: Return full patch in res protocol's secure URL.
Jacek Caban <[EMAIL PROTECTED]> writes: > --- > dlls/mshtml/protocol.c | 31 +-- > dlls/mshtml/tests/protocol.c | 41 > - > 2 files changed, 61 insertions(+), 11 deletions(-) This breaks the tests: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so misc.c && touch misc.ok misc.c:775: Test failed: [0] size=39, expected 9 misc.c:777: Test failed: [0] wrong secid make: *** [misc.ok] Error 2 -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine virus story
On Thursday March 13 2008 19:31:49 Edward Savage wrote: > This sounds like some thing I'd be able to do though I'm not sure of > the best way to sand box wine away from the system. What is the best > way to go about this, would simply creating a new user be enough to > protect a system, or does a vm have to be used? Separate user is enough if you don't have world writable files in your system. And of course user for such purpose shouldn't be in group(s) that have write access to your personal or system files. If you are unsure use VirtualBox ( http://virtualbox.org/ ) - it's free and open-source, or VMWare ( http://vmware.com/ ) - it's not free. On Debian (and probably Ubuntu) you can install VirtualBox by running "sudo apt-get install virtualbox". I do not recommend to use QEmu because it's less user friendly than VirtualBox (BTW, VirtualBox is based on QEmu).
Re: wine virus story
> I like that idea. are there any linux tools to watch files for changes? > Or maybe have linux watch the wine processes for their file changing > activities. I've used tripwire for a long time. fschange looks promising, builds upon inotify, but I've never used it yet: http://stefan.buettcher.org/cs/fschange/index.html Cheers Vit
Re: wine virus story
Dan Kegel wrote: > On 3/13/08, Edward Savage <[EMAIL PROTECTED]> wrote: > >> Just as a silly outside thought; would it be worth keeping track of >> some of the bigger windows virus so we can see how good wine >> compatibiliy with all of the nitty gritty bugs of windows really is? >> Also this would allow us to identify dangerous areas in wine were the >> ability to affect the linux environment cross over. >> > > Yes, it would be good to keep an eye on that. > > Ideally we'd have an automated script to set up > a petri dish, try out a bunch of known infectious agents, > and see which one of them reproduce. > > I haven't done anything like that myself, but I imagine > a good place to start might be to script an instance > of mozilla or ies4linux visiting the top sites listed at > http://www.stopbadware.org/home/topsites > and see if they're able to modify the system at all. > - Dan > > > > I like that idea. are there any linux tools to watch files for changes? Or maybe have linux watch the wine processes for their file changing activities.
Re: wine virus story
On 3/13/08, Edward Savage <[EMAIL PROTECTED]> wrote: > This sounds like some thing I'd be able to do though I'm not sure of > the best way to sand box wine away from the system. What is the best > way to go about this, would simply creating a new user be enough to > protect a system, or does a vm have to be used? I would totally do it in a virtual machine.
Re: wine virus story
This sounds like some thing I'd be able to do though I'm not sure of the best way to sand box wine away from the system. What is the best way to go about this, would simply creating a new user be enough to protect a system, or does a vm have to be used? I have a bit of free time tomorrow so I'll make a start and see where I get. On Fri, Mar 14, 2008 at 6:11 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > On 3/13/08, Edward Savage <[EMAIL PROTECTED]> wrote: > > Just as a silly outside thought; would it be worth keeping track of > > some of the bigger windows virus so we can see how good wine > > compatibiliy with all of the nitty gritty bugs of windows really is? > > Also this would allow us to identify dangerous areas in wine were the > > ability to affect the linux environment cross over. > > Yes, it would be good to keep an eye on that. > > Ideally we'd have an automated script to set up > a petri dish, try out a bunch of known infectious agents, > and see which one of them reproduce. > > I haven't done anything like that myself, but I imagine > a good place to start might be to script an instance > of mozilla or ies4linux visiting the top sites listed at > http://www.stopbadware.org/home/topsites > and see if they're able to modify the system at all. > - Dan >
Re: wine virus story
On 3/13/08, Edward Savage <[EMAIL PROTECTED]> wrote: > Just as a silly outside thought; would it be worth keeping track of > some of the bigger windows virus so we can see how good wine > compatibiliy with all of the nitty gritty bugs of windows really is? > Also this would allow us to identify dangerous areas in wine were the > ability to affect the linux environment cross over. Yes, it would be good to keep an eye on that. Ideally we'd have an automated script to set up a petri dish, try out a bunch of known infectious agents, and see which one of them reproduce. I haven't done anything like that myself, but I imagine a good place to start might be to script an instance of mozilla or ies4linux visiting the top sites listed at http://www.stopbadware.org/home/topsites and see if they're able to modify the system at all. - Dan
Re: wine virus story
I remember my last attempt to run a virus under wine caused a total loss of my .wine structure but didn't manage to cause any damage to my sandbox (including a juicy fake address list). I was really let down as I expected carnage. Just as a silly outside thought; would it be worth keeping track of some of the bigger windows virus so we can see how good wine compatibiliy with all of the nitty gritty bugs of windows really is? Also this would allow us to identify dangerous areas in wine were the ability to affect the linux environment cross over. On Fri, Mar 14, 2008 at 3:27 AM, Marcus Meissner <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 13, 2008 at 08:32:23AM -0700, Dan Kegel wrote: > > > http://wearenixed.blogspot.com/2008/03/you-only-know-good-when-youve-seen-bad.html > > > > "I had set her up with a perfect Wine install. She had a bit > > of software that needed to run under wine and I had shown her > > how to install within that environment. Apparently, I wasn't > > specific enough. It never occurred to Paula that the .exe > > programs she had used on her XP machine were the vehicles for > > many of her present viruses. To her, it was perfectly fine to > > use those same .exe's...after all, she was in Linux, right? > > > > I got there within the same hour and checked her > > machine. Yep...Windows viruses will reside and create the same > > havoc within a Wine environment. Now, I've seen it with my own > > eyes. This time I reinstalled for her and made sure I found > > all the infected .exe's on the Windows side and deleted them." > > Fortunately you can run clamscan -r ~/.wine/ without much > fear for rootkits hiding the virii. > > Ciao, Marcus > > >
1 program is separating me from complete windows independence. please help!
Can someone please take a look at this bug for me? http://bugs.winehq.org/show_bug.cgi?id=11953
Google Summer of code
Proposing another thing if implementing d3dx9_36.dll is too much I propose to implement: 1 D3DXAssembleShader 2 D3DXAssembleShaderFromFileA 3 D3DXCompileShader 4 D3DXCompileShaderFromFileA 5 D3DXCreateCubeTextureFromFileExA 6 D3DXCreateCubeTextureFromFileInMemory 7 D3DXCreateEffectCompilerFromFileA 8 D3DXCreateEffectFromFileA 9 D3DXCreateTextureFromFileExA 10 D3DXCreateTextureFromFileInMemory 11 D3DXCreateVolumeTextureFromFileExA 12 D3DXCreateVolumeTextureFromFileInMemory 13 D3DXGetImageInfoFromFileInMemory 14 D3DXGetPixelShaderProfile 15 D3DXGetShaderConstantTable 16 D3DXGetShaderInputSemantics 17 D3DXGetShaderVersion 18 D3DXGetVertexShaderProfile 19 D3DXLoadSurfaceFromSurface 20 D3DXSaveSurfaceToFileA 21 D3DXSaveTextureToFileA Which are the functions that Sid Meier's Civilization 4 calls and are not yet implemented from d3dx9_32 (36)
d3dx8: Implementation of D3DXGetFVFVertexSize
Is ther eany problem with this patch?
---
dlls/d3dx8/d3dx8_main.c | 59
+-
1 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/dlls/d3dx8/d3dx8_main.c b/dlls/d3dx8/d3dx8_main.c
index ee897a8..a1d37b8 100644
--- a/dlls/d3dx8/d3dx8_main.c
+++ b/dlls/d3dx8/d3dx8_main.c
@@ -61,8 +61,63 @@ HRESULT WINAPI D3DXCreateFont(LPDIRECT3DDEVICE8 pDevice, HFONT hFont, LPD3DXFONT
}
UINT WINAPI D3DXGetFVFVertexSize(DWORD FVF) {
- FIXME("(void): stub\n");
- return 0;
+ UINT size=0;
+ UINT i;
+ UINT texture;
+ switch (FVF & D3DFVF_XYZB5) {
+ case D3DFVF_XYZ:
+size=12;
+break;
+ case D3DFVF_XYZRHW:
+size=16;
+break;
+ case D3DFVF_XYZB1:
+size=16;
+break;
+ case D3DFVF_XYZB2:
+size=20;
+break;
+ case D3DFVF_XYZB3:
+size=24;
+break;
+ case D3DFVF_XYZB4:
+size=28;
+break;
+ case D3DFVF_XYZB5:
+size=32;
+break;
+ default:
+FIXME("Not Implemented.");
+break;
+}
+ if (FVF & D3DFVF_NORMAL)
+ size=size + 12;
+ if (FVF & D3DFVF_PSIZE)
+ size=size + 4;
+ if (FVF & D3DFVF_DIFFUSE)
+ size=size + 4;
+ if (FVF & D3DFVF_SPECULAR)
+ size=size + 4;
+ texture = FVF >> 16;
+ for (i=0;i<((FVF&0x0f00) >> 16);i++) {
+ switch (texture && 3) {
+ case D3DFVF_TEXTUREFORMAT1:
+size=size + 4;
+break;
+ case D3DFVF_TEXTUREFORMAT2:
+size=size + 8;
+break;
+ case D3DFVF_TEXTUREFORMAT3:
+size=size + 12;
+break;
+ case D3DFVF_TEXTUREFORMAT4:
+size=size + 16;
+break;
+ }
+ texture = FVF >>2;
+ }
+
+ return size;
}
HRESULT WINAPI D3DXAssembleShader(LPCVOID pSrcData, UINT SrcDataLen, DWORD Flags,
Re: GSoC
MammothTruk wrote: > I read the WineHQ newsletters when they come out to try and keep up on > the goings on of Wine and what will run on it. I noticed that the > Wsock32.dll was suggested as a SoC project. I wanted to point out > that Vista X64 has issues with this dll and some of the newer programs > arent accessing it right. This could be a really good project to take > on for someone as it would give people that are having issues with > Vista to use Wine. > > I also thought that possible control panel rewriting so that it looks > better would be a good project. Make it more user friendly. Easier > to access. My descriptions of what things do on each tab. Just an > overall nice,easy,good looking control panel would be really helpful > to first time users. the current winecfg looks like crap and isnt at > all user friendly to the first time user. I was a first time users a > year ago and I still dont understand half of the control panel. > > Wine Plugin project might be really useful too. It would help > companies that cant afford or wont make direct linux ports to have > some kind of ability to get their porgrams working without official > linux support. > > The three things listed above all come from me playing NeverWinter > Nights 2. OEI wont make a linux port but have been pretty supportive > of Wine in their forums on bioware. .NET is also something needed to > get the toolset working, but I thought that was a little big for a 2-3 > month project. > > Supporter, > Nicholas "MammothTruk" Baldwin > > -- > Lifes to Short. Stop wasting your time. > > > > Hi, I'm going to be applying for GSoC this year, for the mswsock dll mentioned in this e-mail. I've been working on it pretty part time for about week, and with wine as a whole for about 1 month, I think I can handle it. I heard it was a good idea to post and let people know if one is interested in GSoC, so here is my post. I've had a few ideas that I thought of on my own, but now I'm starting to see they perhaps aren't as useful as the ideas thought of by current developers, but I'll float it out there one last time. I thought it would be cool to create a wine GUI overlay for games, exactly like nvPerfHUD. The thing about doing it in wine that makes it better than nvPerHUD is the fact the to use nvPerfHUD the apps have to give permission for nvPerHUD to run on them. A wine version would actually be able to force every single 3d app, opengl or directX to output nvPerfHUD like output. Anyway, just a thought. Would I be able to apply for both of these projects and pick one last minute? Thanks, Chris.
GSoC
I read the WineHQ newsletters when they come out to try and keep up on the goings on of Wine and what will run on it. I noticed that the Wsock32.dllwas suggested as a SoC project. I wanted to point out that Vista X64 has issues with this dll and some of the newer programs arent accessing it right. This could be a really good project to take on for someone as it would give people that are having issues with Vista to use Wine. I also thought that possible control panel rewriting so that it looks better would be a good project. Make it more user friendly. Easier to access. My descriptions of what things do on each tab. Just an overall nice,easy,good looking control panel would be really helpful to first time users. the current winecfg looks like crap and isnt at all user friendly to the first time user. I was a first time users a year ago and I still dont understand half of the control panel. Wine Plugin project might be really useful too. It would help companies that cant afford or wont make direct linux ports to have some kind of ability to get their porgrams working without official linux support. The three things listed above all come from me playing NeverWinter Nights 2. OEI wont make a linux port but have been pretty supportive of Wine in their forums on bioware. .NET is also something needed to get the toolset working, but I thought that was a little big for a 2-3 month project. Supporter, Nicholas "MammothTruk" Baldwin -- Lifes to Short. Stop wasting your time.
Re: RESEND Prototype patch that solves bug 11897
Artur Szymiec wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stefan Dösinger pisze:
>> Am Donnerstag, 13. März 2008 10:19:36 schrieb Artur Szymiec:
>>> This is a corrected patch. The uuid is common to dx8 and dx9
>>> since the UUID is generated inside wined3d.
>> Yes, that looks reasonable. Only two small issues:
>>
>>> +/* Fixes BUG 11897 */
>> That's not really needed, specifying a GUID is correct even if it
>> wouldn't fix a bug report.
>>
>> Also, please attach the patch as an extra file to the mail, if you
>> inline it like you did in your last mails it most likely suffers
>> from line wrapping and can't be applied
> Thank you very much for help Stefan !
>
Few more problems with your patch:
> +const GUID IID_D3DDEVICE_D3DUID = {
> + 0xaeb2cdd4,
> + 0x6e41,
1. Use 4 spaces indentation as the rest of the file not 2.
> +memcpy(pIdentifier->DeviceIdentifier,&IID_D3DDEVICE_D3DUID,sizeof(GUID));
2. Don't use memcpy. They are both structs and you you can assign sctruct to
struct in c:
*pIdentifier->DeviceIdentifier = IID_D3DDEVICE_D3DUID;
Vitaliy.
Re: wine virus story
On Thu, Mar 13, 2008 at 08:32:23AM -0700, Dan Kegel wrote: > http://wearenixed.blogspot.com/2008/03/you-only-know-good-when-youve-seen-bad.html > > "I had set her up with a perfect Wine install. She had a bit > of software that needed to run under wine and I had shown her > how to install within that environment. Apparently, I wasn't > specific enough. It never occurred to Paula that the .exe > programs she had used on her XP machine were the vehicles for > many of her present viruses. To her, it was perfectly fine to > use those same .exe's...after all, she was in Linux, right? > > I got there within the same hour and checked her > machine. Yep...Windows viruses will reside and create the same > havoc within a Wine environment. Now, I've seen it with my own > eyes. This time I reinstalled for her and made sure I found > all the infected .exe's on the Windows side and deleted them." Fortunately you can run clamscan -r ~/.wine/ without much fear for rootkits hiding the virii. Ciao, Marcus
Re: wine virus story
Quoting Dan Kegel <[EMAIL PROTECTED]>: > http://wearenixed.blogspot.com/2008/03/you-only-know-good-when-youve-seen-bad.html > > "I had set her up with a perfect Wine install. She had a bit > of software that needed to run under wine and I had shown her > how to install within that environment. Apparently, I wasn't > specific enough. It never occurred to Paula that the .exe > programs she had used on her XP machine were the vehicles for > many of her present viruses. To her, it was perfectly fine to > use those same .exe's...after all, she was in Linux, right? > > I got there within the same hour and checked her > machine. Yep...Windows viruses will reside and create the same > havoc within a Wine environment. Now, I've seen it with my own > eyes. This time I reinstalled for her and made sure I found > all the infected .exe's on the Windows side and deleted them." Windows virus infecting Linux machines are a huge success for Wine. Take that one Microsoft! Windows viruses run better on Linux than on Windows Vista! -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
wine virus story
http://wearenixed.blogspot.com/2008/03/you-only-know-good-when-youve-seen-bad.html "I had set her up with a perfect Wine install. She had a bit of software that needed to run under wine and I had shown her how to install within that environment. Apparently, I wasn't specific enough. It never occurred to Paula that the .exe programs she had used on her XP machine were the vehicles for many of her present viruses. To her, it was perfectly fine to use those same .exe's...after all, she was in Linux, right? I got there within the same hour and checked her machine. Yep...Windows viruses will reside and create the same havoc within a Wine environment. Now, I've seen it with my own eyes. This time I reinstalled for her and made sure I found all the infected .exe's on the Windows side and deleted them."
Re: RESEND D3D add device uuid solves bug 11897
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Dösinger pisze: > Am Donnerstag, 13. März 2008 14:40:07 schrieb Artur Szymiec: >> Stefan Dösinger pisze: >>> Am Donnerstag, 13. März 2008 10:19:36 schrieb Artur Szymiec: This is a corrected patch. The uuid is common to dx8 and dx9 since the UUID is generated inside wined3d. >>> Yes, that looks reasonable. Only two small issues: +/* Fixes BUG 11897 */ >>> That's not really needed, specifying a GUID is correct even if it >>> wouldn't fix a bug report. >>> >>> Also, please attach the patch as an extra file to the mail, if you inline >>> it like you did in your last mails it most likely suffers from line >>> wrapping and can't be applied >> That's final version with suggested correction >> by Stefan Dösinger > Sorry that I didn't think of that earlier, but do you have to use memcpy? > Doesn't a simple *pIdentifier->DeviceIdentifier = IID_D3DDEVICE_D3DUID; work > as well? > I've corrected this like Vitaliy suggested and sent again to wine-patches. Regards Artur - -- - -- Registered User No 397465 Linux Debian 2.6.24.2 AMD Athlon(tm) 64 X2 Dual Core 5000+ Conquer your Desktop! http://www.kde.org/trykde/ Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird/ - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2TwObB2ld6kq2MsRAsprAKCxRDwygn0VZ4ZglvUbHcPEL0EyAQCggwhv qr236BN0Nv88EkUTooR6z1I= =FxIQ -END PGP SIGNATURE-
Re: RESEND D3D add device uuid solves bug 11897
Am Donnerstag, 13. März 2008 14:40:07 schrieb Artur Szymiec: > Stefan Dösinger pisze: > > Am Donnerstag, 13. März 2008 10:19:36 schrieb Artur Szymiec: > >> This is a corrected patch. > >> The uuid is common to dx8 and dx9 since the UUID is generated > >> inside wined3d. > > > > Yes, that looks reasonable. Only two small issues: > >> +/* Fixes BUG 11897 */ > > > > That's not really needed, specifying a GUID is correct even if it > > wouldn't fix a bug report. > > > > Also, please attach the patch as an extra file to the mail, if you inline > > it like you did in your last mails it most likely suffers from line > > wrapping and can't be applied > > That's final version with suggested correction > by Stefan Dösinger Sorry that I didn't think of that earlier, but do you have to use memcpy? Doesn't a simple *pIdentifier->DeviceIdentifier = IID_D3DDEVICE_D3DUID; work as well? signature.asc Description: This is a digitally signed message part.
Re: RESEND Prototype patch that solves bug 11897
Am Donnerstag, 13. März 2008 13:04:28 schrieb Artur Szymiec: > Thank you very much for help Stefan ! You're welcome. Thanks for your help to make Wine better. Just send the patch to wine-patches, if they're on wine-devel they won't be applied. Also I recommend not to sign mails to wine-patches because the archives can't handle more than one attachment, and if there's a signature the patch isn't accessible from the archives signature.asc Description: This is a digitally signed message part.
Re: RESEND Prototype patch that solves bug 11897
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger pisze:
> Am Donnerstag, 13. März 2008 10:19:36 schrieb Artur Szymiec:
>> This is a corrected patch. The uuid is common to dx8 and dx9
>> since the UUID is generated inside wined3d.
> Yes, that looks reasonable. Only two small issues:
>
>> +/* Fixes BUG 11897 */
> That's not really needed, specifying a GUID is correct even if it
> wouldn't fix a bug report.
>
> Also, please attach the patch as an extra file to the mail, if you
> inline it like you did in your last mails it most likely suffers
> from line wrapping and can't be applied
Thank you very much for help Stefan !
Best regards
Artur
- --
- --
Registered User No 397465
Linux Debian 2.6.24.2 AMD Athlon(tm) 64 X2 Dual Core 5000+
Conquer your Desktop! http://www.kde.org/trykde/
Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird/
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH2RhMbB2ld6kq2MsRAsltAJ0eZzgQoJlZ1jgPc/8YPHoMJyP1MwCg2c+Z
bDKy0V+CgkyilcTdduIKUbQ=
=TvMs
-END PGP SIGNATURE-
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 04af700..2a14979 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -36,6 +36,14 @@
WINE_DEFAULT_DEBUG_CHANNEL(d3d);
WINE_DECLARE_DEBUG_CHANNEL(d3d_caps);
+/* The d3d device ID */
+const GUID IID_D3DDEVICE_D3DUID = {
+ 0xaeb2cdd4,
+ 0x6e41,
+ 0x43ea,
+ { 0x94,0x1c,0x83,0x61,0xcc,0x76,0x07,0x81 }
+};
+
/* Extension detection */
static const struct {
const char *extension_string;
@@ -1594,8 +1602,8 @@ static HRESULT WINAPI IWineD3DImpl_GetAdapterIdentifier(IWineD3D *iface, UINT Ad
*(pIdentifier->DeviceId) = Adapters[Adapter].gl_info.gl_card;
*(pIdentifier->SubSysId) = 0;
*(pIdentifier->Revision) = 0;
-
-/*FIXME: memcpy(&pIdentifier->DeviceIdentifier, ??, sizeof(??GUID)); */
+memcpy(pIdentifier->DeviceIdentifier,&IID_D3DDEVICE_D3DUID,sizeof(GUID));
+
if (Flags & WINED3DENUM_NO_WHQL_LEVEL) {
*(pIdentifier->WHQLLevel) = 0;
} else {
Re: Clipping regions on windows and Expose Xevents issue
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> writes: > 1. MoveWindow doesn't update the DCEx clip_region region, and hence when the > visible region changes, it is merged with the clip region and since there is > no overlap the visible region is empty so all subsequent processing ends. > > Q: Whats the best way to handle that - I was tempted to reset the > clip_region to the visible_region (as MSDN sort of implies - you cant really > query them so tests don't help much here) in a movewindow call You can query the visible region, so with well-chosen dimensions and clip region it shouldn't be too hard to write test cases. Make sure you test both GetDCEx with an explicit clip region and BeginPaint, the behavior is probably different > Q: This is getting way outside my understanding of X events, but shouldn't > the Expose event for the child (popup) window be processed before returning > from CreateWindow with style WS_VISIBLE? The way we hack around the asynchronous events is by checking for expose events in UpdateWindow, but of course if the app doesn't even use that it won't help. And on a slow connection the expose events will always arrive too late anyway. We'd need to explicitly wait for the event, but that would hurt badly on slow connections. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [2/4] qmgr: Add infrastructure for background file transferring. [take 4]
Dan Hipschman <[EMAIL PROTECTED]> writes:
> @@ -129,6 +131,21 @@ ServiceMain(DWORD dwArgc, LPWSTR *lpszArgv)
> return;
> }
>
> +globalMgr.jobEvent = CreateEventW(NULL, TRUE, FALSE, NULL);
> +if (!globalMgr.jobEvent) {
> +ERR("Couldn't create event: error %d\n", GetLastError());
> +UpdateStatus(SERVICE_STOPPED, NO_ERROR, 0);
> +return;
> +}
> +
> +fileTxThread = CreateThread(NULL, 0, fileTransfer, NULL, 0, &threadId);
> +if (!fileTxThread)
> +{
> +ERR("Failed starting file transfer thread\n");
> +UpdateStatus(SERVICE_STOPPED, NO_ERROR, 0);
> +return;
> +}
> +
> UpdateStatus(SERVICE_RUNNING, NO_ERROR, 0);
You also need to shutdown the thread properly when the service
terminates.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: RESEND Prototype patch that solves bug 11897
Am Donnerstag, 13. März 2008 10:19:36 schrieb Artur Szymiec: > This is a corrected patch. > The uuid is common to dx8 and dx9 since the UUID is generated > inside wined3d. Yes, that looks reasonable. Only two small issues: > +/* Fixes BUG 11897 */ That's not really needed, specifying a GUID is correct even if it wouldn't fix a bug report. Also, please attach the patch as an extra file to the mail, if you inline it like you did in your last mails it most likely suffers from line wrapping and can't be applied signature.asc Description: This is a digitally signed message part.
RESEND Prototype patch that solves bug 11897
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Dösinger pisze:
> Am Donnerstag, 13. März 2008 01:02:47 schrieb Artur Szymiec:
>> Stefan Dösinger pisze:
>>> Hi, Note that we do not accept workaround patches into Wine,
>>> because
>> otherwise the
>>
>>> whole software would become a huge workaround collection.
>>>
>>> A potential proper fix for this is to generate an UUID, store
>>> it in a
>> constant
>>
>>> global variable and memcpy it into the deviceidentifier
>> Dear Stefan,
>>
>> ok then. At d3d startup I'll read back UUID from wine registry
>> (or create one if none) -> copy into globar var and then memcopy.
>>
> I don't think you need to store them in the registry. Just hardcode
> it in the code, e.g. like ddraw does it:
>
> const GUID IID_D3DDEVICE_WineD3D = { 0xaef72d43, 0xb09a, 0x4b7b, {
> 0xb7,0x98,0xc6,0x8a,0x77,0x2d,0x72,0x2a } };
>
> which matches an uuidgen output of
> 0xaef72d43-0xb09a-0x4b7b-b798-6c8a773d722a (Don't use this specific
> UUID for d3d9, generate a new one using uuidgen(part of the ext2
> filesystem tools)
>
> Chatter has it that on Windows there is some schematic in DirectX
> GUIDs, additionally to the general way UIDs work. But since that's
> not documented anywhere I could find I don't think any game depends
> on that. In the worst case we'll have to adopt the UIDs ATI and
> Nvidia are using on Windows, if any game compares them.
This is a corrected patch.
The uuid is common to dx8 and dx9 since the UUID is generated
inside wined3d.
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 04af700..809809c 100644
- --- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -36,6 +36,14 @@
WINE_DEFAULT_DEBUG_CHANNEL(d3d);
WINE_DECLARE_DEBUG_CHANNEL(d3d_caps);
+/* The d3d device ID */
+const GUID IID_D3DDEVICE_D3DUID = {
+ 0xaeb2cdd4,
+ 0x6e41,
+ 0x43ea,
+ { 0x94,0x1c,0x83,0x61,0xcc,0x76,0x07,0x81 }
+};
+
/* Extension detection */
static const struct {
const char *extension_string;
@@ -1595,7 +1603,9 @@ static HRESULT WINAPI
IWineD3DImpl_GetAdapterIdentifier(IWineD3D *iface, UINT Ad
*(pIdentifier->SubSysId) = 0;
*(pIdentifier->Revision) = 0;
- -/*FIXME: memcpy(&pIdentifier->DeviceIdentifier, ??,
sizeof(??GUID)); */
+/* Fixes BUG 11897 */
+
memcpy(pIdentifier->DeviceIdentifier,&IID_D3DDEVICE_D3DUID,sizeof(GUID));
+
if (Flags & WINED3DENUM_NO_WHQL_LEVEL) {
*(pIdentifier->WHQLLevel) = 0;
} else {
- --
- --
Registered User No 397465
Linux Debian 2.6.24.2 AMD Athlon(tm) 64 X2 Dual Core 5000+
Conquer your Desktop! http://www.kde.org/trykde/
Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird/
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH2PGnbB2ld6kq2MsRAp3fAJ0QbkQ7Ifo3ukdiu0l1KD3TAaXX+QCgsFhC
7MoBeeM2XNh7SmgHe5tppBs=
=/t0r
-END PGP SIGNATURE-
Re: Question about function "HTMLDocument_write"
>
> What do you mean by hyperlinks don't work?
>
I have such code which create html page:
htmlDoc2->lpVtbl->open(htmlDoc2, L"html/txt", vnull, vnull, vnull, &pdisp);
bstr =SysAllocString(L"Simple text");
if ((pVar->bstrVal = bstr)) {
htmlDoc2->lpVtbl->write(htmlDoc2, sfArray);
}
SysFreeString(bstr);
bstr = SysAllocString(L"Link to the
Yandex");
if ((pVar->bstrVal = bstr)) {
htmlDoc2->lpVtbl->write(htmlDoc2, sfArray);
}
SysFreeString(bstr);
bstr = SysAllocString(L"End of document");
if ((pVar->bstrVal = bstr)) {
htmlDoc2->lpVtbl->write(htmlDoc2, sfArray);
}
SysFreeString(bstr);
htmlDoc2->lpVtbl->close(htmlDoc2);
After creation of page, I try to click on a hyperlink, but nothing occurs.
When I used my patch, hyperlink works good.
>
> As I've explained in comment to your patch, this implementation is wrong.
>
I do not speak, that my patch better than yours or my patch is right. I only
want to understand, why so occurs and where to look?
>
> Jacek
--
Sinitsin Ivan
Re: msi: Ignore the custom action type 51 if the source field is empty
James Hawkins wrote: > Hi, > > Fixes bug 11891. http://bugs.winehq.org/show_bug.cgi?id=11891 > > Changelog: > * Ignore the custom action type 51 if the source field is empty. > > dlls/msi/custom.c|3 ++ > dlls/msi/tests/install.c | 65 > ++ > 2 files changed, 68 insertions(+), 0 deletions(-) > > > > > > Hi James, I was looking at the sudden huge amount of failures for the msi/package tests on Windows: http://test.winehq.org/data/200803121000/ The issue turned out to be with the above patch for the install tests. If I run the install tests a 'MSITEST' package will stay around (can been seen in 'Add/Remove Programs"). If I remove MSITEST the package tests will succeed again. (Reverting the above patch makes the package tests pass again as well, when run after the install tests of course). The thing that surprises me is that we don't see the same failures when running the package tests on Wine? Is this because we have 39 TODO's in there? -- Cheers, Paul.
