Re: Fwd: Draft XI 2 protocol specification
Roderick Colenbrander wrote: > Hi Vitaliy, > > Peter Hutterer has submitted a draft specification of Xinput2 to the xorg > mailinglist. As you know it will offer relative mouse movements. He is asking for feedback. Since I have no experience with Xinput you might want to review it and see if it works out for Wine. > I'd say I like it so far. Should work really nicely for DInput. And I think it should work for "RawInput" as well - one more API introduced in XP. However someone needs to see how well this will work for tablet input? The next big question - joysticks. If Wine ever decides to use X11 for joysticks we'll need much more then what's available now in XI 1.x (force-feedback anyone?) or spec'ed here. The other direction (to the device) is IMHO needed as well. Also not sure where all the extra keyboard add-ons belongs in. XI or something else? Things like extra displays, LEDs - all the cool stuff on some gaming devices. Vitaliy.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Wed, 14 Jan 2009, Alexandre Julliard wrote: > Yes, it's better to avoid it, because then you may be testing things > that you know the function is doing internally but that may not actually > matter. Tests have to treat the target dll as a black box, and if you > looked inside then it's no longer a true black box. Sorry about that, > but we really have to play it safe, for obvious reasons. I understand. But, can we at least get the [1/2] patch in, that adds stubs for OleLoadPictureFile and OleLoadPictureFileEx that just trace FIXMEs and return E_NOTIMPL? There's definitely nothing in there that I could have learned from disassembly, and it would at least keep my app from crashing.
Re: Wine being targeted for adware
On Wed, Jan 14, 2009 at 7:23 PM, Eduardo Menezes wrote: > I think a "isolate prefix" option in winecfg (or even winetricks) would be > very useful. > Undoing symlinks and editing the registry to take out the reference to the > root is boring (and I'm not sure only doing this is entirely safe) and this > kind of option would make it possible to run untrusted software without > worrying. > I even ran some malwares in isolated wine prefixes and used diff to see what > it did. Learned a lot from this. > Anyway, a "nice to have" feature. > > Best wishes and thanks for this amazing software, > > 2009/1/14 >> >> Date: Wed, 14 Jan 2009 15:07:06 -0500 >> From: Nicholas LaRoche >> Subject: Re: Wine being targeted for adware >> To: Stefan D?singer >> Cc: wine-devel@winehq.org >> Message-ID: <496e45ea.9060...@vt.edu> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Stefan D?singer wrote: >> >> As long as the facilities exist for keeping an entire wine bottle >> >> isolated from other bottles (and ~/) I don't see this being a major >> >> issue. >> > They don't. >> > >> > Even if you don't have a drive link pointing out of a bottle, a Windows >> > app >> > running in Wine can still call Linux syscalls(int 0x80). This is >> > possible/needed because Windows apps run as a regular Linux process that >> > links in Linux libraries which perform linux syscalls. >> > >> > So any Windows malware can break out of the Wine "sandbox"(which isn't a >> > sandbox really) by simply using linux syscalls. >> > >> > >> > >> >> On more recent distros (FC9/10) SELinux is enabled by default. Rolling a >> policy specifically for an untrusted bottle would severely limit the >> damage it could do. It could restrict all unnecessary read/write/execute >> access outside of the ~/.wine folder for wineserver and the program. >> >> I see your point though, since none of the aforementioned security >> precautions are commonplace or specifically targeted to wine. >> > > -- > Eduardo > "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky) > > > > Windows doesn't provide this, why would wine? P.S., please bottom post on wine mailing lists. -- -Austin
Re: Wine being targeted for adware
Stefan Dösinger wrote: >> I see your point though, since none of the aforementioned security >> precautions are commonplace or specifically targeted to wine. > A security measure targetted to wine would be a wrong thing IMO. > > Either its designed for Windows, then it will protect the Windows apps in > Wine the same way. With exceptions of course, anything based on rootkits > will probably never work, and it may not know how to deal with int 0x80 > syscalls > > Or design it for a generic Linux app, and it will protect the Windows app > running in Wine(Windows app + Wine == regular Linux process). Again there > are possible exceptions. Some security measures can break Windows apps, for > example Adress space randomization can break apps. > > What works only in a very limited fashion is using Windows apps to protect > the Linux system. You can use a virus scanner to do a manual check over your > drives, but scan-file-on-open features will likely fail. > > > I've run into problems with ASR when using wine with some apps. If you do a: `setarch $(uname -p) RL wine ./app` and disable ASR then it works again. Any security policy would have to be targeted as if the program was written for Linux. It wouldn't be much more involved than limiting what it can see and do just like policies that target httpd and other services.
Re: Running a simple .Net 3.0 application.
On Wed, Jan 14, 2009 at 3:59 PM, Louis Lenders wrote: > gdi32.GdiEntry13 > kernel32.WerRegisterMemoryBlock > ntdll.NtSecureConnectPort > ntdll.RtlEnumerateGenericTableWithoutSplaying > ntdll.RtlIsGenericTableEmpty > > Well, that was enough to get the app running. > I was not able to work around a problem in d3d9 ( the app just hang, > displaying nothing, probably due to some unimplemented stuff in d3d9) > but fortunaly disabling d3d9, was enough to get it running > (WINEDLLOVERRIDES="d3d9=""" wine AnimatedApplication.exe) > > I'm not sure if it would be useful to open bugs already for the > unimplemented functions. If so, just shout, and i'll open some bugs. Or you can send diff's ;) -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
RE: Wine being targeted for adware
I think a "isolate prefix" option in winecfg (or even winetricks) would be very useful. Undoing symlinks and editing the registry to take out the reference to the root is boring (and I'm not sure only doing this is entirely safe) and this kind of option would make it possible to run untrusted software without worrying. I even ran some malwares in isolated wine prefixes and used diff to see what it did. Learned a lot from this. Anyway, a "nice to have" feature. Best wishes and thanks for this amazing software, 2009/1/14 > Date: Wed, 14 Jan 2009 15:07:06 -0500 > From: Nicholas LaRoche > Subject: Re: Wine being targeted for adware > To: Stefan D?singer > Cc: wine-devel@winehq.org > Message-ID: <496e45ea.9060...@vt.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Stefan D?singer wrote: > >> As long as the facilities exist for keeping an entire wine bottle > >> isolated from other bottles (and ~/) I don't see this being a major > >> issue. > > They don't. > > > > Even if you don't have a drive link pointing out of a bottle, a Windows > app > > running in Wine can still call Linux syscalls(int 0x80). This is > > possible/needed because Windows apps run as a regular Linux process that > > links in Linux libraries which perform linux syscalls. > > > > So any Windows malware can break out of the Wine "sandbox"(which isn't a > > sandbox really) by simply using linux syscalls. > > > > > > > > On more recent distros (FC9/10) SELinux is enabled by default. Rolling a > policy specifically for an untrusted bottle would severely limit the > damage it could do. It could restrict all unnecessary read/write/execute > access outside of the ~/.wine folder for wineserver and the program. > > I see your point though, since none of the aforementioned security > precautions are commonplace or specifically targeted to wine. > > -- Eduardo "Toda Revolução é IMPOSSÍVEL até que se torne INEVITÁVEL!!!" (Leon Trotsky)
Re: Download Link at budgetdedicated.com not working
On Wed, Jan 14, 2009 at 4:05 PM, James McKenzie wrote: > Jeremy Newman: > > Looks like the download-deb page on winehq.org has gone missing again. > Everything looks ok here. http://wine.budgetdedicated.com/ looks in tact, http://winehq.org/download/deb works too.
Re: Download Link at budgetdedicated.com not working
2009/1/15 James McKenzie : > Jeremy Newman: > > Looks like the download-deb page on winehq.org has gone missing again. > > James McKenzie http://winehq.org/download/ << Both the Ubuntu and Lenny links work Though if we are going to provide Debian packages separately to Ubuntu (which is what I've been meaning to do, just have to talk to Scott or someone else about hosting my packages), I object to using download/deb for Ubuntu. download/ubuntu would be more appropriate, and then have variations on download/deb for Debian distros.
Download Link at budgetdedicated.com not working
Jeremy Newman: Looks like the download-deb page on winehq.org has gone missing again. James McKenzie
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
2009/1/14 Dan Kegel : > On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn wrote: >> 2008/11/15 Dan Kegel : >>> BTW, has anybody noticed a speed problem with our >>> theme support? >> >> Yes. >> >> If you use some themes (e.g. the Zune theme from Microsoft) then the >> performance is ok. If you try other themes (e.g. the Gem theme from >> the StyleXP program) then it renders very slowly - the performance >> killer in the Gem theme is rendering the parent background for >> property sheets (e.g. winecfg). This can clearly be seen in winecfg >> when switching themes. > > FWIW, > http://www.ubuntuproductivity.com/journal/software/01/2009/theme-wine-integrate-with-ubuntu-human/ > is a report of a happy user, so I guess the Human theme is ok. > Maybe the Ubuntu package should come with that theme applied, > or at least included and easy to turn on. That's great :). Not everything works yet (particularly state changes in buttons -- such as pressing a button, or it becoming disabled -- revert it to non-themed behaviour), but it is getting there. >> In addition, the DIB engine is likely to prove invaluable here, as >> there will be a lot of drawing and blitting, which will certainly be >> killing performance at the moment with the X server round trip. >> >> Do you know if the DIB engine is advanced enough to test this? Theming >> would make an interesting test case. > > Give it a try - somebody posted patches for his own mashup of the DIB > engine recently... Will do. I'll also give some games a spin to see if it makes a difference there as well. - Reece
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On Sat, Nov 15, 2008 at 8:37 AM, Reece Dunn wrote: > 2008/11/15 Dan Kegel : >> On Sun, Nov 2, 2008 at 10:58 PM, Reece Dunn wrote: >>> .. the first step for Wine is making the >>> uxtheme/msstyles support work well so that it can be used by >>> distributions to theme Wine. >> >> BTW, has anybody noticed a speed problem with our >> theme support? > > Yes. > > If you use some themes (e.g. the Zune theme from Microsoft) then the > performance is ok. If you try other themes (e.g. the Gem theme from > the StyleXP program) then it renders very slowly - the performance > killer in the Gem theme is rendering the parent background for > property sheets (e.g. winecfg). This can clearly be seen in winecfg > when switching themes. FWIW, http://www.ubuntuproductivity.com/journal/software/01/2009/theme-wine-integrate-with-ubuntu-human/ is a report of a happy user, so I guess the Human theme is ok. Maybe the Ubuntu package should come with that theme applied, or at least included and easy to turn on. > I believe there were discussions about this earlier that tracked it > down to theme parts having alpha channels in their bitmaps. > > It may also be that as several of the theming APIs are using double > buffering. Vista has some APIs that help out with double buffered > drawing (http://blogs.msdn.com/e7/ has a nice video (requires > Silverlight) from the latest PDC - > http://channel9.msdn.com/pdc2008/PC43/ - that covers them in some > detail). These may help improve performance. > > In addition, the DIB engine is likely to prove invaluable here, as > there will be a lot of drawing and blitting, which will certainly be > killing performance at the moment with the X server round trip. > > Do you know if the DIB engine is advanced enough to test this? Theming > would make an interesting test case. Give it a try - somebody posted patches for his own mashup of the DIB engine recently... - Dan
RE: Wine being targeted for adware
> I see your point though, since none of the aforementioned security > precautions are commonplace or specifically targeted to wine. A security measure targetted to wine would be a wrong thing IMO. Either its designed for Windows, then it will protect the Windows apps in Wine the same way. With exceptions of course, anything based on rootkits will probably never work, and it may not know how to deal with int 0x80 syscalls Or design it for a generic Linux app, and it will protect the Windows app running in Wine(Windows app + Wine == regular Linux process). Again there are possible exceptions. Some security measures can break Windows apps, for example Adress space randomization can break apps. What works only in a very limited fashion is using Windows apps to protect the Linux system. You can use a virus scanner to do a manual check over your drives, but scan-file-on-open features will likely fail.
Re: Dead code in winedbg
Francois Gouget a écrit : > Hi, > > I have noticed that expr_alloc_uconstant() is unused in winedbg. > Is that normal? > the main point is that the lexer only returns signed integers, while it should return both signed and unsigned integers therefore this code was left to handle possibly unsigned:s from 0x8000 up to 0xf (which current code doesn't) the proper fix would be to fix the lexer to return both signed and unsigned integers for example: WineDbg> p 0x8000 -2147483648 while it should be 2147483648 A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Running a simple .Net 3.0 application.
I saw some good progress is being made on getting the .net 3.0 installer fixed in wine. Nice. As it will take yet quite some time until the installer is fixed, i wondered if wine is in good shape to run .net 3.0 apps, once the installer is finished. Today I saw someone mentioning a program called InstallRite on the users-list, and using this program, I was able to get a a simple .Net 3.0 app running in wine. I thought just share my experience here, in case anyone finds it useful. The application i got running is very simple: AnimatedApplication from http://www.longhorncorner.com/UploadFile/rahul4_saxena/AnAnimatedApplication07112007042303AM/AnAnimatedApplication.aspx (You just need register, then you can download the file) This way I got it running: 1. Fire up Windows Xp (a snapshot from a clean install) in my VirtualBox 2. Install Installrite from http://www.epsilonsquared.com/ in VirtualBox. 3. Start InstallRite, and from within InstallRite you can fire up the dotnetfx3.exe (after downloaded it) 4. After the dotnetfx3.exe finshed the install, there's an option, that you can make a "Build Install Kit". I did that, it creates an executable (foo.exe). Save it in a place where you can access it from linux 5. In wine, first do 'winetricks dotnet20' (needed for l_int.nls i guess, otherwise I got crash very early in the app) 6. Run foo.exe in wine, it will extract all files, and write all registry-keys, as if it were a successfull dotnetfx3 installation in wine. 7. Now Run the app, it crashes into a bunch of unimplemented functions. Fortunately just simple stubs were enough to make the app happy. I added stubs for gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty Well, that was enough to get the app running. I was not able to work around a problem in d3d9 ( the app just hang, displaying nothing, probably due to some unimplemented stuff in d3d9) but fortunaly disabling d3d9, was enough to get it running (WINEDLLOVERRIDES="d3d9=""" wine AnimatedApplication.exe) I'm not sure if it would be useful to open bugs already for the unimplemented functions. If so, just shout, and i'll open some bugs. Conclusion: once the installer is fixed, there's good chance simple .net 3.0 at least apps will run quickly
Re: Wine being targeted for adware
Stefan Dösinger wrote: >> As long as the facilities exist for keeping an entire wine bottle >> isolated from other bottles (and ~/) I don't see this being a major >> issue. > They don't. > > Even if you don't have a drive link pointing out of a bottle, a Windows app > running in Wine can still call Linux syscalls(int 0x80). This is > possible/needed because Windows apps run as a regular Linux process that > links in Linux libraries which perform linux syscalls. > > So any Windows malware can break out of the Wine "sandbox"(which isn't a > sandbox really) by simply using linux syscalls. > > > On more recent distros (FC9/10) SELinux is enabled by default. Rolling a policy specifically for an untrusted bottle would severely limit the damage it could do. It could restrict all unnecessary read/write/execute access outside of the ~/.wine folder for wineserver and the program. I see your point though, since none of the aforementioned security precautions are commonplace or specifically targeted to wine.
Re: Yearly commit statistics
Zachary Goldberg wrote: > All, > > I received an email in response to the top article in WWN 355 about > generating commit stats. See below. > >> I just saw that you used "git log" with some funny >> options to filter out certain dates... You might be interested in the >> --min-age and --max-age options, which have been there almost forever. > > Useful? > -Zach > He/she probably means "--after" and "--before" ? But then you need to change the date formats as well (git 1.6.0.6). So useful? Yes as I've learned new options and no as it doesn't really simplify the command(s). -- Cheers, Paul.
Yearly commit statistics
All, I received an email in response to the top article in WWN 355 about generating commit stats. See below. > I just saw that you used "git log" with some funny > options to filter out certain dates... You might be interested in the > --min-age and --max-age options, which have been there almost forever. Useful? -Zach
Re: [PATCH] quartz: Add a filtergraph test for mpeg files.
On Tue, Jan 13, 2009 at 10:59 PM, Paul Vriens wrote: > Lei Zhang wrote: >> >> Hi, >> >> I cleaned up dlls/quartz/tests/filtergraph.c a bit so we can drop in a >> 'test.mpg' file and test the rendering of MPEG files. >> >> >> >> >> > Please stick to the CreateFileA (instead of W) to have these tests run on > win9x. > > -- > Cheers, > > Paul. > Ok, will resend.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
Jeremy Drake writes: > Right. That's why I abandoned writing a patch to implement the functions, > and instead focused on writing test cases so others could implement them. > Is writing test cases also verboten for someone who has seen disassembly? Yes, it's better to avoid it, because then you may be testing things that you know the function is doing internally but that may not actually matter. Tests have to treat the target dll as a black box, and if you looked inside then it's no longer a true black box. Sorry about that, but we really have to play it safe, for obvious reasons. -- Alexandre Julliard julli...@winehq.org
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
"Hans Leidekker" wrote: > On Wednesday 14 January 2009 17:01:06 Juan Lang wrote: > >> + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW >> >> Out of curiosity, what's the reason for using SHELL32_704 as the name, >> instead of GUIDFromStringW? > > I just followed a pattern already there in shell32, I don't know the exact > rules that apply here, to be honest. According to http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/history/ords471.htm&tx=51,40,37-39;41 shell32.704 GUIDFromStringW redirected to SHLWAPI in version 5.00 and higher -- Dmitry.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
On Wed, 14 Jan 2009, Alexandre Julliard wrote: > Jeremy Drake writes: > > > Is there anything wrong with these two patches? I'd really like to see > > these tests go in, so hopefully someone will decide to tackle this > > olepicture stuff. At the very least, putting the stubs in for > > OleLoadPictureFile (patch 1/2) keeps my app from crashing... > > Sorry but I'm not going to accept your patches in this area since you > looked at the disassembled code. Probably your best bet is to file a bug > about the missing function and hope that someone else picks it up. Right. That's why I abandoned writing a patch to implement the functions, and instead focused on writing test cases so others could implement them. Is writing test cases also verboten for someone who has seen disassembly? It was my understanding that that was the acceptable way for me to move forward with this.
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
Hans Leidekker writes: > On Wednesday 14 January 2009 17:01:06 Juan Lang wrote: > >> + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW >> >> Out of curiosity, what's the reason for using SHELL32_704 as the name, >> instead of GUIDFromStringW? > > I just followed a pattern already there in shell32, I don't know the exact > rules that apply here, to be honest. If there's a known official name you should use it, and most likely make it a -noname export. -- Alexandre Julliard julli...@winehq.org
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
On Wed, Jan 14, 2009 at 10:15 AM, Hans Leidekker wrote: > On Wednesday 14 January 2009 17:01:06 Juan Lang wrote: > >> + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW >> >> Out of curiosity, what's the reason for using SHELL32_704 as the name, >> instead of GUIDFromStringW? > > I just followed a pattern already there in shell32, I don't know the exact > rules that apply here, to be honest. > > -Hans > > > Stefan Leichter sent a patch in last week to rename SHELL32_526 to its 'pretty' name, 'SHFlushSFCache', see: http://source.winehq.org/git/wine.git/?a=commitdiff;h=2ca9f2c5368f33137ac58d5f67a1cda3335cdcb7 -- -Austin
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
> I just followed a pattern already there in shell32, I don't know the exact > rules that apply here, to be honest. I neither, I was seeking illumination. In case there's an absence of clear rules, I'd suggest the more readable GUIDFromStringW is better. --Juan
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
On Wednesday 14 January 2009 17:01:06 Juan Lang wrote: > + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW > > Out of curiosity, what's the reason for using SHELL32_704 as the name, > instead of GUIDFromStringW? I just followed a pattern already there in shell32, I don't know the exact rules that apply here, to be honest. -Hans
Re: shell32: Implement ordinal 704, also known as GUIDFromStringW.
Hi Hans, + 704 stdcall @(wstr ptr) SHELL32_704 # GUIDFromStringW Out of curiosity, what's the reason for using SHELL32_704 as the name, instead of GUIDFromStringW? --Juan
Re: Wine being targeted for adware
On Wed, Jan 14, 2009 at 9:38 AM, James Mckenzie wrote: > Jeff Zaroyko wrote: > >>In an interesting interview, former adware author Matt Knox mentions >>that he was able to run his adware client on Wine: >> >>S: In your professional opinion, how can people avoid adware? >>M: Um, run UNIX. >> >>S: [ laughs] >>M: We did actually get the ad client working under Wine on Linux. >> >>S: That seems like a bit of a stretch! >>M: That was a pretty limited market, I'd say. >> > One: This shows how well we run Windows programs. > Two: The last comment should show how much respect we have in the community. > Things have changed since the release of Wine 1.0, but we have a long way to > go to be on every Linux desktop and most of the MacIntosh community. > > However, we should attempt to block adware as a matter of policy? That is up > to the Wine User Community and not based on the opinions of one or two > people. I for one would like to see if this is possible and feasible. I do > know that some of the virus testing community are using Wine as a Virtual > Machine to see how much damage can be done by viruses in that environment. > > James McKenzie > > > That really depends on your definition of Adware. What is adware to some, is vitally important software to others. Besides, last I checked, Wine let's you "run Windows programs on Unix like OS's", not "run only safe and approved applications on Unix like OS's". -- -Austin
Re: Wine being targeted for adware
Jeff Zaroyko wrote: >In an interesting interview, former adware author Matt Knox mentions >that he was able to run his adware client on Wine: > >S: In your professional opinion, how can people avoid adware? >M: Um, run UNIX. > >S: [ laughs] >M: We did actually get the ad client working under Wine on Linux. > >S: That seems like a bit of a stretch! >M: That was a pretty limited market, I'd say. > One: This shows how well we run Windows programs. Two: The last comment should show how much respect we have in the community. Things have changed since the release of Wine 1.0, but we have a long way to go to be on every Linux desktop and most of the MacIntosh community. However, we should attempt to block adware as a matter of policy? That is up to the Wine User Community and not based on the opinions of one or two people. I for one would like to see if this is possible and feasible. I do know that some of the virus testing community are using Wine as a Virtual Machine to see how much damage can be done by viruses in that environment. James McKenzie
Re: [1/2] richedit: Clip painting to formatting rectangle (try 2)
Dylan Smith writes:
> @@ -29,6 +29,17 @@ void ME_PaintContent(ME_TextEditor *editor, HDC hDC, BOOL
> bOnlyNew, const RECT *
>ME_Context c;
>int yoffset;
>int ys, ye;
> + HRGN oldRgn, clipRgn;
> +
> + oldRgn = CreateRectRgn(0, 0, 0, 0);
> + if (!GetClipRgn(hDC, oldRgn))
> + {
> +DeleteObject(oldRgn);
> +oldRgn = NULL;
> + }
> + clipRgn = CreateRectRgnIndirect(rcUpdate);
> + ExtSelectClipRgn(hDC, clipRgn, RGN_AND);
> + DeleteObject(clipRgn);
IntersectClipRect would be a lot easier.
--
Alexandre Julliard
julli...@winehq.org
Re: [setupapi/tests] Fix some test failures on win9x
Paul Vriens writes: > Win9x returns the system directory instead of system32. Decided against using > broken() for this but could be convinced otherwise ;). GetSystemDirectory is probably better. -- Alexandre Julliard julli...@winehq.org
Re: [2/5] wined3d: Remove AddDirtyBox() from the public interface.
2009/1/14 Stefan Dösinger : > I realized that you just removed the calls from surface and volume, where > they don't exist in the public d3d9 API. However, textures have such a call > in the public d3d9 API - do you know what it is supposed to do, and if this > has any implications on this change? > They're used to ecplicitly mark parts of a texture dirty for UpdateTexture(). This patch obviously has no impact on those, since it doesn't change how the function works, just where it's visible.
RE: Wine being targeted for adware
> As long as the facilities exist for keeping an entire wine bottle > isolated from other bottles (and ~/) I don't see this being a major > issue. They don't. Even if you don't have a drive link pointing out of a bottle, a Windows app running in Wine can still call Linux syscalls(int 0x80). This is possible/needed because Windows apps run as a regular Linux process that links in Linux libraries which perform linux syscalls. So any Windows malware can break out of the Wine "sandbox"(which isn't a sandbox really) by simply using linux syscalls.
RE: [2/5] wined3d: Remove AddDirtyBox() from the public interface.
I realized that you just removed the calls from surface and volume, where they don't exist in the public d3d9 API. However, textures have such a call in the public d3d9 API - do you know what it is supposed to do, and if this has any implications on this change? > -Original Message- > From: wine-patches-boun...@winehq.org [mailto:wine-patches- > boun...@winehq.org] On Behalf Of Henri Verbeet > Sent: Wednesday, January 14, 2009 10:05 AM > To: wine-patc...@winehq.org > Subject: [2/5] wined3d: Remove AddDirtyBox() from the public interface. >
Dead code in winedbg
Hi,
I have noticed that expr_alloc_uconstant() is unused in winedbg.
Is that normal?
It causes all of the code in the attached patch to essentially be dead
code since expr.type is never set to EXPR_TYPE_U_CONST. Should we just
remove all that code? Just the expr_alloc_uconstant() function? Or
is this unused just because of a bug? Or maybe it will be used 'soon'?
--
Francois Gouget http://fgouget.free.fr/
Good judgment comes from experience, and experience comes from bad judgment
-- Barry LePatnercommit 2ba68f2545e363fc6ceac514f32a84e7cd54df0e
Author: Francois Gouget
Date: Wed Jan 14 11:41:03 2009 +0100
winedbg: expr_alloc_uconstant() is unused so remove it and the corresponding dead code.
diff --git a/programs/winedbg/debugger.h b/programs/winedbg/debugger.h
index 319f0dc..cc82a03 100644
--- a/programs/winedbg/debugger.h
+++ b/programs/winedbg/debugger.h
@@ -324,7 +324,6 @@ extern void expr_free_all(void);
extern struct expr* expr_alloc_internal_var(const char* name);
extern struct expr* expr_alloc_symbol(const char* name);
extern struct expr* expr_alloc_sconstant(int val);
-extern struct expr* expr_alloc_uconstant(unsigned val);
extern struct expr* expr_alloc_string(const char* str);
extern struct expr* expr_alloc_binary_op(int oper, struct expr*, struct expr*);
extern struct expr* expr_alloc_unary_op(int oper, struct expr*);
diff --git a/programs/winedbg/expr.c b/programs/winedbg/expr.c
index 3d5cef1..02e8b4c 100644
--- a/programs/winedbg/expr.c
+++ b/programs/winedbg/expr.c
@@ -100,7 +100,6 @@ struct expr
};
#define EXPR_TYPE_S_CONST 0
-#define EXPR_TYPE_U_CONST 1
#define EXPR_TYPE_SYMBOL 2
#define EXPR_TYPE_INTVAR 3
#define EXPR_TYPE_BINOP 4
@@ -176,17 +175,6 @@ struct expr* expr_alloc_sconstant(int value)
return ex;
}
-struct expr* expr_alloc_uconstant(unsigned int value)
-{
-struct expr*ex;
-
-ex = expr_alloc();
-
-ex->type = EXPR_TYPE_U_CONST;
-ex->un.u_const.value = value;
-return ex;
-}
-
struct expr* expr_alloc_string(const char* str)
{
struct expr*ex;
@@ -348,12 +336,6 @@ struct dbg_lvalue expr_eval(struct expr* exp)
rtn.type.module = 0;
rtn.addr.Offset = (ULONG_PTR)&exp->un.string.str;
break;
-case EXPR_TYPE_U_CONST:
-rtn.cookie = DLV_HOST;
-rtn.type.id = dbg_itype_unsigned_int;
-rtn.type.module = 0;
-rtn.addr.Offset = (ULONG_PTR)&exp->un.u_const.value;
-break;
case EXPR_TYPE_S_CONST:
rtn.cookie = DLV_HOST;
rtn.type.id = dbg_itype_signed_int;
@@ -689,9 +671,6 @@ int expr_print(const struct expr* exp)
case EXPR_TYPE_INTVAR:
dbg_printf("$%s", exp->un.intvar.name);
break;
-case EXPR_TYPE_U_CONST:
-dbg_printf("%u", exp->un.u_const.value);
-break;
case EXPR_TYPE_S_CONST:
dbg_printf("%d", exp->un.s_const.value);
break;
@@ -789,7 +768,6 @@ struct expr* expr_clone(const struct expr* exp, BOOL *local_binding)
case EXPR_TYPE_INTVAR:
rtn->un.intvar.name = strcpy(HeapAlloc(GetProcessHeap(), 0, strlen(exp->un.intvar.name) + 1), exp->un.intvar.name);
break;
-case EXPR_TYPE_U_CONST:
case EXPR_TYPE_S_CONST:
break;
case EXPR_TYPE_STRING:
@@ -845,7 +823,6 @@ int expr_free(struct expr* exp)
case EXPR_TYPE_INTVAR:
HeapFree(GetProcessHeap(), 0, (char*)exp->un.intvar.name);
break;
-case EXPR_TYPE_U_CONST:
case EXPR_TYPE_S_CONST:
break;
case EXPR_TYPE_STRING:
Re: [3/5] user32: Resend: Move character conversion logic todde_server.d & remove todo's
Dmitry Timoshkov wrote: > Then the first thing to do is to write some test cases. I will set some up.
Re: [3/5] user32: Resend: Move character conversion logic todde_server.d & remove todo's
"Jeff Latimer" wrote: > The problem is complicated by the data type of LPBYTE. The application > does not pass the type of the data to the client. I am at a loss as to > how DDE actually determines the type at the client side. Then the first thing to do is to write some test cases. -- Dmitry.
Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicturePath (resend) [2/2]
Jeremy Drake writes: > Is there anything wrong with these two patches? I'd really like to see > these tests go in, so hopefully someone will decide to tackle this > olepicture stuff. At the very least, putting the stubs in for > OleLoadPictureFile (patch 1/2) keeps my app from crashing... Sorry but I'm not going to accept your patches in this area since you looked at the disassembled code. Probably your best bet is to file a bug about the missing function and hope that someone else picks it up. -- Alexandre Julliard julli...@winehq.org
Re: [3/5] user32: Resend: Move character conversion logic to dde_server.d & remove todo's
Hans Leidekker wrote: > On Wednesday 14 January 2009 08:29:33 Jeff Latimer wrote: > > >> I have tested this a number of ways and I can not see a mechanism that >> DDE can determine whether data passed is UNICODE (pData is of type >> LPBYTE). In my tests, the case of the server uses a UNICODE window it >> is immaterial as to the type of window the client uses but is dependent >> on the type of data passed. >> > > This has been discussed before, we cannot rely on IsTextUnicode since > it's just a heuristic. MSDN mentions that the character set depends on > whether the client called DdeInitializeA or DdeInitializeW, and it can > be overridden by setting iCodePage in the CONVCONTEXT structure. > > This suggests to me that we'll need some form of IPC. > > -Hans The problem is complicated by the data type of LPBYTE. The application does not pass the type of the data to the client. I am at a loss as to how DDE actually determines the type at the client side. Jeff
Re: [3/5] user32: Resend: Move character conversion logic to dde_server.d & remove todo's
On Wednesday 14 January 2009 08:29:33 Jeff Latimer wrote: > I have tested this a number of ways and I can not see a mechanism that > DDE can determine whether data passed is UNICODE (pData is of type > LPBYTE). In my tests, the case of the server uses a UNICODE window it > is immaterial as to the type of window the client uses but is dependent > on the type of data passed. This has been discussed before, we cannot rely on IsTextUnicode since it's just a heuristic. MSDN mentions that the character set depends on whether the client called DdeInitializeA or DdeInitializeW, and it can be overridden by setting iCodePage in the CONVCONTEXT structure. This suggests to me that we'll need some form of IPC. -Hans
Re: setupapi: Add the Romanian translation.
Paul Vriens wrote: > Michael Stefaniuc wrote: >> +/* >> + * English resources for SETUPAPI >> + * > > I guess that should be Romanian resources. Thanks Paul! I have removed that part of the comment and resubmitted the patch. I always remove those comments as they are redundant information. bye michael
Re: Wine being targeted for adware
2009/1/14 Ben Klein : > 2009/1/14 David Gerard : >> 2009/1/14 Jeff Zaroyko : >> >>> http://philosecurity.org/2009/01/12/interview-with-an-adware-author >>> In an interesting interview, former adware author Matt Knox mentions >>> that he was able to run his adware client on Wine: >> >> >> The amazing thing about that interview was how jaw-droppingly insecure >> Windows actually is, inherently and incurably. >> >> I hope Wine doesn't emulate some of those wackie characteristics too well. > > Technically, it has to for legitimate apps to work. I'm sure there's > some malware that doesn't work in Wine, but there's probably a large > subset of that will work some day. > Oops, missed "Reply to all"
Re: Wine being targeted for adware
2009/1/14 Jeff Zaroyko : > http://philosecurity.org/2009/01/12/interview-with-an-adware-author > In an interesting interview, former adware author Matt Knox mentions > that he was able to run his adware client on Wine: The amazing thing about that interview was how jaw-droppingly insecure Windows actually is, inherently and incurably. I hope Wine doesn't emulate some of those wackie characteristics too well. - d.
Re: Wine being targeted for adware
2009/1/14 Jeff Zaroyko : > http://philosecurity.org/2009/01/12/interview-with-an-adware-author > > In an interesting interview, former adware author Matt Knox mentions > that he was able to run his adware client on Wine: > > S: In your professional opinion, how can people avoid adware? > M: Um, run UNIX. > > S: [ laughs] > M: We did actually get the ad client working under Wine on Linux. > > S: That seems like a bit of a stretch! > M: That was a pretty limited market, I'd say. "Some adware can work under Wine on Linux" does NOT mean that Wine is being targeted in any way. Note that viruses also work in Wine. Not much you can do about it, since they are valid Win32 applications ...
Re: Wine being targeted for adware
Jeff Zaroyko wrote: > http://philosecurity.org/2009/01/12/interview-with-an-adware-author > > In an interesting interview, former adware author Matt Knox mentions > that he was able to run his adware client on Wine: > > S: In your professional opinion, how can people avoid adware? > M: Um, run UNIX. > > S: [ laughs] > M: We did actually get the ad client working under Wine on Linux. > > S: That seems like a bit of a stretch! > M: That was a pretty limited market, I'd say. > > > As long as the facilities exist for keeping an entire wine bottle isolated from other bottles (and ~/) I don't see this being a major issue. Unlike disinfecting on a Windows box, which might not completely eradicate the software, with Wine `rm -rf ~/.wine` and its gone :) The cool thing is that you can identify exactly what the junkware does with KDiff3 if it runs at all. -Nick
Re: Wine being targeted for adware
On Wed, Jan 14, 2009 at 05:08:50PM +1100, Jeff Zaroyko wrote: > http://philosecurity.org/2009/01/12/interview-with-an-adware-author > > In an interesting interview, former adware author Matt Knox mentions > that he was able to run his adware client on Wine: > > S: In your professional opinion, how can people avoid adware? > M: Um, run UNIX. > > S: [ laughs] > M: We did actually get the ad client working under Wine on Linux. > > S: That seems like a bit of a stretch! > M: That was a pretty limited market, I'd say. Well, I spotted some Adware in my Wine lately that got installed with some "free" Web Media Player. It seems to fail to inject stuff into the Windows Firefox 3 though. Ciao, Marcus
