February 2009 - Wine-Devel - list.winehq.org

Re: Wine & viruses

by Ben Klein

2009/2/18 IneedAname <wineappdb(a)googlemail.com>: > Why not make Wine honor the noexe flag on the mount? This might not be a bad idea, if it's possible. Make Wine refuse to run apps on noexec filesystems.

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Francois Gouget

On Tue, 17 Feb 2009, Steven Edwards wrote: > On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget <fgouget(a)free.fr> wrote: > > --- > > > > I moved them after the windows.h include though in practice the needed > > winnt.h has already been included by the time we include winetest.h. So > > maybe windows.h should be nuked altogether... > > Conversely maybe using windows.h usage should be fixed and used more > often. Wine is an oddball when it comes to win32 program with the > excessive lengths it goes to, to avoid using windows.h. I am starting > to think even avoiding it internally like we do causes more harm than > good as far as being source compatible with MSVC. My remark was not so much about including windows.h rather than winfoo.h, but about including it in winetest.h when the parent C file has already included the winxxx.h files it needs. That is, in Wine it seems we have a policy to put include statements primarily in the C files, rather than in private header files. Also: * I don't see what depends on windows.h in winietest.h (besides my newly added annotations). * if I remember correctly, removing this include did not cause any warning or compilation error (even with my newly added annotations). But maybe it's different if you compile with MinGW or MSVC (in which case Wine's headers should be fixed). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by King InuYasha

On Wed, Feb 18, 2009 at 2:11 AM, Roderick Colenbrander < thunderbird2k(a)gmx.net> wrote: > > On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson > > <chris.kcat(a)gmail.com>wrote: > > > > > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > > > > I had an interesting thought the other day, and that is to having > some > > > > built in support for forwarding windows dlls to linux .so's. > > > > > > IIRC, this kind of thing is generally discouraged, except in cases > where > > > needed (eg. opengl32). Part of the problem is internal differences.. > for > > > example, what would a Linux .so do if it's given a Win32 filename path? > > > Other > > > problems would be if the Linux equivalent wants a Window for a function > > > argument and the DLL wants an HWND instead, or if the DLL has > > > more/different > > > functions (eg. CUDA on Win32 has functions for dealing with D3D > objects; > > > CUDA > > > on Linux doesn't, and it wouldn't be straight forward to even implement > > > them > > > through wined3d). > > > > > > Something like OpenGL, and even OpenAL to some degree, would directly > > > benefit > > > from having the DLLs forwarded to their host equivalents as it provides > > > better > > > access to the hardware and better integration with the host system. > > > Something > > > like zlib or ogg/vorbis and stuff wouldn't though, since the code > should > > > largely be the same, and save for some bugs/inefficiencies in Wine > > (which > > > should be fixed), would work identically. > > > > > > > > > > > Does Wine yet have the capability to interface with HAL for Win32 > hardware > > access similar to NT? It looks like it doesn't from all this talk of > > forwarding DLLs. What we should do instead of trying to forward DLLs, > > which > > is asking for more trouble than its worth, is try to get the NT layer to > > connect to UNIX HAL so that DLLs can link directly to HAL and operate the > > hardware. > > This can't be done. You would be writing your own operating system and > hardware can't be shared. It is not that hard to write wrapper libraries. > Second even if libraries look similar between OSes take for instance Cuda it > does offer OS-specific functionality like e.g. Direct3D integration. > > Roderick > -- > Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL > für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a > So it wouldn't be possible to hook Wine's Direct3D implementation into Gallium3D on Linux and use the hardware directly instead of translating it to OpenGL and then sending it to the hardware?

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Steven Edwards

On Wed, Feb 18, 2009 at 3:16 AM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Is there a specific problem you are trying to point out indirectly, > or that's just a speculation? I was just thinking perhaps we need a better way of making sure the headers match up with the PSDK. I know we can do a MSVC configuration for Windows headers and libraries for building winetest but I've not looked at how well it works recent. The last time I attempted building any major part of Wine with the PSDK in the include path first the results were not very pleasing. I'll add reviewing this to the list of hundreds of other things I mean to look at when I have the time ;) >> Maybe someone should drop those Chromium guys a note as they seem to >> include windows.h in a lot of places.... > > That's a commeon practice among windows programmers, want to mail > all of them? There is a good prediction where they will tell you > to go. Hehe I am sure ;) -- 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

Feb. 18, 2009

Status of USB driver support?

by emiliano

Hi, first of all, thanks for your great effort in adding USB to Wine! I have an app. needing a Marx Cryptobox USB, here drivers and info: http://www.marx.com/rc1/en/support_downloads.php I would like to help by testing it. I've tried to download the etherhack branch of wine sources and compile it, compiling succeeds, but the application behaves a bit erratically (graphic buttons are missing, for example), and this also makes it freeze. I've also compiled the master git branch, and that is instead working. Now I kindly ask: is there a simple way to integrate the official branch with just the USB patches? I've tried to understand by reading wine wiki and git manual pages but couldn't figure it out. Some sort of link (or help, if you can) would be greatly appreciated. If that USB Key is not of a supportable kind, then I apologize for asking. Thank you, Regards. E.E.

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Dmitry Timoshkov

"Steven Edwards" <winehacker(a)gmail.com> wrote: > I've agreed with the logic and the reasons behind it for the Wine > libraries. My point was that we already avoid it more than enough in > libraries, and maybe its a good thing after far as winelib goes to > insure the apps in the programs directory always do include windows.h > so that whenever someone does a true winelib port they don't have to > make unnecessary changes just to please Wine. Is there a specific problem you are trying to point out indirectly, or that's just a speculation? > Maybe someone should drop those Chromium guys a note as they seem to > include windows.h in a lot of places.... That's a commeon practice among windows programmers, want to mail all of them? There is a good prediction where they will tell you to go. -- Dmitry.

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by Roderick Colenbrander

> On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson > <chris.kcat(a)gmail.com>wrote: > > > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > > > I had an interesting thought the other day, and that is to having some > > > built in support for forwarding windows dlls to linux .so's. > > > > IIRC, this kind of thing is generally discouraged, except in cases where > > needed (eg. opengl32). Part of the problem is internal differences.. for > > example, what would a Linux .so do if it's given a Win32 filename path? > > Other > > problems would be if the Linux equivalent wants a Window for a function > > argument and the DLL wants an HWND instead, or if the DLL has > > more/different > > functions (eg. CUDA on Win32 has functions for dealing with D3D objects; > > CUDA > > on Linux doesn't, and it wouldn't be straight forward to even implement > > them > > through wined3d). > > > > Something like OpenGL, and even OpenAL to some degree, would directly > > benefit > > from having the DLLs forwarded to their host equivalents as it provides > > better > > access to the hardware and better integration with the host system. > > Something > > like zlib or ogg/vorbis and stuff wouldn't though, since the code should > > largely be the same, and save for some bugs/inefficiencies in Wine > (which > > should be fixed), would work identically. > > > > > > > Does Wine yet have the capability to interface with HAL for Win32 hardware > access similar to NT? It looks like it doesn't from all this talk of > forwarding DLLs. What we should do instead of trying to forward DLLs, > which > is asking for more trouble than its worth, is try to get the NT layer to > connect to UNIX HAL so that DLLs can link directly to HAL and operate the > hardware. This can't be done. You would be writing your own operating system and hardware can't be shared. It is not that hard to write wrapper libraries. Second even if libraries look similar between OSes take for instance Cuda it does offer OS-specific functionality like e.g. Direct3D integration. Roderick -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Steven Edwards

On Tue, Feb 17, 2009 at 10:40 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > The reason why we avoid windows.h inclusion in Wine is compilation > time by avoiding inclusion of all-in-one headers windows.h does. It's > always a good programming practice to include only those .h files that > are really needed, inclusion of windows.h usually shows the ignorance > and lack of knowledge of a programmer. I've agreed with the logic and the reasons behind it for the Wine libraries. My point was that we already avoid it more than enough in libraries, and maybe its a good thing after far as winelib goes to insure the apps in the programs directory always do include windows.h so that whenever someone does a true winelib port they don't have to make unnecessary changes just to please Wine. Maybe someone should drop those Chromium guys a note as they seem to include windows.h in a lot of places.... -- 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

Feb. 18, 2009

Re: Wine & viruses

by Kai Blin

On Tuesday 17 February 2009 17:11:20 Martin Hinner wrote: > Hi, > > I will start one more hot discussion. Sorry if it was discussed > earlier, I am not regular reader of this mailing-list. I tried to > search google, found several discussions, but no real result: > > http://www.linux.com/feature/42031 > http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus > https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 > wine-devel mailing list google results > > The problem is that some (almost all?) distributions simply execute > .exe file when you click on it. I was amazed when testing JTAGTest on > Linux! This is in my opinion quite big issue as ordinary users do not > have problem clicking on "New folder.exe" on their flashdisk etc. It's > good that wine is so compatible that it runs even viruses, but I think > there should be some (optional) protection. The biggest problem seem > to be removable media, in many distributions mounted under /mnt or > /media. Please think about this twice before writing "problem is in > Microsoft not in Wine", "it's not a bug but feature", etc. It's too > childish IMO. People who analyze malware seem to use wine to figure out what API calls the malware is making. Seems like a very good use of Wine to beat the bad guys. I don't see anything childish about Wine's decision to be bug-for-bug compatible with Windows. > - What about creating a configurable list of directories, where wine > would first ask if you really want to execute the program? It would be > up to distribution what is set-up by default. What about having the system virus scanner scan all files you download before executing them in Wine or any other program? Just because there's not that many viruses/trojans for Linux yet doesn't mean it's going to stay that way. > - It's long time I have been interested in viruses, but I think that > 90% of most common virus infected/trojan .exe files can be pretty > easily identified. Yes, if you keep a virus data base like virus scanners do. It's a huge pain to keep those up-to-date. We don't want to deal with that stuff in Wine, there's enough work left without also pretending to be a virus scanner. > Almost every modern virus is trying to connect to > the internet either by opening socket or using few standard DLL > functions. What about adding some checks to Wine that would check the > calling function code sample against some small database to see if > this is a virus and ask user? Or adding some "API" functions to allow > someone to write such program? I have done quite a lot of work with PE > loading and code modification and I think it could be moved to level > when it works without crashing anything. Right. A pop-up box is going to be the solution. Especially as users (especially people used to Windows, like most Wine users) learned that these pop-ups have two buttons, one saying "Go away and do what I told you" and one saying "Annoy me by not running my program". How many normal users will ever bother to read the text on Vistas UAC pop-ups? > Obviously this would have to be global for wine (libwine.so?), not as > a PE exported API function. Pre-loaded "antivirus" would be able to > hook Winsock functions + some other important stuff and then check if > the binary code is not on the list. If you're really interested, look into resurrecting http://wiki.winehq.org/ClamAntiVirusIntegration It has probably bitrottet in the last two years, but it'd at least get you an idea how something like this could be done. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 18, 2009

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.

by Dmitry Timoshkov

"Steven Edwards" <winehacker(a)gmail.com> wrote: > Conversely maybe using windows.h usage should be fixed and used more > often. Wine is an oddball when it comes to win32 program with the > excessive lengths it goes to, to avoid using windows.h. I am starting > to think even avoiding it internally like we do causes more harm than > good as far as being source compatible with MSVC. The reason why we avoid windows.h inclusion in Wine is compilation time by avoiding inclusion of all-in-one headers windows.h does. It's always a good programming practice to include only those .h files that are really needed, inclusion of windows.h usually shows the ignorance and lack of knowledge of a programmer. -- Dmitry.

Feb. 18, 2009