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

Re: oleaut32(2/3): Implement VarDecFix

by Dmitry Timoshkov

"Juan Lang" <juan.lang(a)gmail.com> wrote: > + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl); According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter, to it should be fixed instead of casting const out. Same for VarDecInt() patch. -- Dmitry.

Feb. 18, 2009

Re: kernel32: add tests for recasing files

by Dmitry Timoshkov

"Austin English" <austinenglish(a)gmail.com> wrote: > + /* create a temporary file */ > + uUnique = GetTempFileNameA(tempdir, "pfx", 0, source); > + ok(uUnique != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* get the same filename as above with upper case > + prefix and without creating any file */ > + ret = GetTempFileNameA(tempdir, "PFX", uUnique, dest); > + ok(ret != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* MoveFile should be able to change the case of the letters */ > + ret = MoveFileA(source, dest); > + todo_wine { > + ok(ret, "MoveFileA: failed, error %d\n", GetLastError()); > + } The comment above about expected MoveFile behaviour is incorrect since the test doesn't test what it implies. What most likely happens is that MoveFile should be a noop if source and destination file names are the same, and in that case 'MoveFileA(source, source);' is enough to test. -- Dmitry.

Feb. 18, 2009

Re: advapi32: GetNamedSecurityInfoExA Stub

by Dmitry Timoshkov

"Paul Bryan Roberts" <pbronline-wine(a)yahoo.co.uk> wrote: > I did reference the piclist web-page in the analysis I attached to bug > 14334 but accept that no one is ever likely to read it. The description of API parameters in your patch looks like directly copied from that page, so you should either write it in your own words, or completely eliminate it. > Please confirm you don't actually want a web-page reference in the Wine > source. Would that not raise "copyright-tracking" issues ? I said "point out to the source in the patch comment" not in the patch itself. -- Dmitry.

Feb. 18, 2009

Re: Wine & viruses

by IneedAname

On Tue, 17 Feb 2009 17:11:20 +0100 Martin Hinner <martin(a)hinner.info> wrote: > 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. Why not make Wine honor the noexe flag on the mount?

Feb. 18, 2009

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

by Steven Edwards

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. -- 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: Win to Lin Library Wrapper

by King InuYasha

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.

Feb. 18, 2009

Re: kernel32: Free profile before reloading

by Michael Karcher

Am Dienstag, den 17.02.2009, 09:19 +0100 schrieb Michael Karcher: > Should fix bug #17050 Doesn't do. Please ignore.

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Vincent Povirk

> The problems with this concept have already been discussed > (such as calling conventions). This is a problem for trying to expose a linux .so as a windows .dll, as the interface is almost never identical. It's not a problem for a program that is explicitly written to use a linux .so. > I believe all of those things have been looked at already, and > generally has been decided that it's not the "right" solution, and > that it really doesn't belong as a part of Wine's source tree. Except that the "right" solution (using wine_dlopen and friends) turned out to be impossible. The "most correct" solution is to distribute Wine binaries, Windows binaries, and a Winelib wrapper all together. Failing that, one should distribute only Windows binaries, as Winelib binaries won't work across Wine versions. An interface to Linux libraries that Windows binaries can use and be binary compatible across different Linux and Wine versions would be a useful thing. Even if we can't have it in Wine, an open source winelib bridge for this (so that a user can supply a version that works on his own system, and to avoid duplicating the work) would be nice. > Well, can a native Linux lib be loaded on Windows? After all, Wine is > an implementation of Win32, not a series of hacks to integrate Win32 > into the *nix-based host system. My opinion on this particular issue doesn't matter, but we don't strictly prevent Windows apps from seeing the underlying Linux environment. Any app can make linux system calls, access the filename conversion functions, invoke linux programs, and access the unix filesystem using a wine-specific shell extension.

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Ben Klein

2009/2/18 Marco Meijer <marco(a)mandrivaclub.nl>: > It is unfortunate that many discussions here on wine-devel to end this way. > A new developer thinks he has solved a problem he has in wine, and wants to > share the solution with the rest of the community. > And 'the established' developers try to find as much issues they can find > with the implementation to prove that what they have written has no problem > but is so by design Martin has raised an interesting issue. Should it be possible for a completely win32 application to explicitly load a Linux-native .so? I would argue "no, but a winelib application is another matter". Win32 exes and DLLs going direct to .so presents far too many problems for my tastes. The problems with this concept have already been discussed (such as calling conventions). > Maybe it would be better to to have a more constructive respond and to thank > the developer for his attempt to share his work with the community > > And after that then to see if: > > - it is the right solution. > - needs a better implementation > - already has a implementation but needs better documentation. > - other....... I believe all of those things have been looked at already, and generally has been decided that it's not the "right" solution, and that it really doesn't belong as a part of Wine's source tree. 2009/2/18 Martin Hinner <martin(a)hinner.info>: > The solution I have created is the cleanest possible way I think. If > you decide to provide some GetProcAddress method to obtain any > function location (or load library), let me know, we'll remove > WINEGATE.DLL and change it to your way. Otherwise I think it's waste > of time as you are not accepting that Win32 application should be able > to load native Linux lib. Well, can a native Linux lib be loaded on Windows? After all, Wine is an implementation of Win32, not a series of hacks to integrate Win32 into the *nix-based host system.

Feb. 17, 2009

Re: Wine & viruses

by Ben Klein

2009/2/18 Martin Hinner <martin(a)hinner.info>: > 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: It won't be very hot. > 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. Well, that's a problem with, at most, the distribution or, at least, the user being silly. > 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. Removable media can be mounted literally anywhere. It'd be easier to find it with HAL, but it's not something suitable for Wine. > 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. Hmmm, let me think about this ... and again ... it's not a bug, it's a feature. There is no 100% fool-proof way to determine whether the user is about to run some malware or some legitimate application. > - 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. Again, this is not something suitable for Wine. Perhaps getting the distributions to mount removable media with the noexec option would help. Of course, this wouldn't help if .exe files were associated with Wine via the file managers, but maybe you think that should stop too. > - 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. Almost every modern virus is trying to connect to > the internet either by opening socket or using few standard DLL > functions. Gee, this sounds like ever other networking application. Why? Because GOOD viruses, trojans, worms etc. are suitably disguised as genuine applications. > 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? What you're suggesting is to include a standard virus scanner in Wine. Not going to happen. Use clamav instead. It's opensource and has *nix-native versionns. > 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. > > I understand, that none of this is system solution. But are > anti-viruses system solution? They solve real world problem. "System solution"? Anti-viruses are the only reasonable solution. History of computer science has shown us that the harder you try to prevent something the harder other people try to do it. Anti-virus programs mitigate some of that, detecting known viruses and quarantining or deleting them. They're not perfect, but they're a lot better than what other options we have. A new version of Wine is released every 2 weeks. This is too long to keep a virus database up-to-date, and a lot of people don't upgrade as soon as the release comes out any way. > Regarding API I have mentioned above I mean some hookdll() function > that would re-direct GetProcAddress() or PE loader for defined > functions, i.e.: > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Redirecting GetProcAddress() sounds more like a security hazard than a security feature to me. Someone correct me if I'm wrong. > 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. Check out clamav and other *nix-native virus scanners. They're much more suited for this task than adding a full-blown virus scanner to Wine as standard. Who wants to maintain something like that? 2009/2/18 Mihai Donțu <mihai.dontu(a)gmail.com>: > I think that soon there will no longer be a need to hack wine in order to > prevent the spread of malware. There is already work in progress on an API (a > derivative of dazuko) that will allow for antivirus scanners to intercept all > filesystem accesses and scan for, well, viruses. It seems to me that this is > the right way to go. Wine is not intended to prevent the spread of malware. It is assumed that the user is careful and sensible, just like it is assumed on Windows. What you mention here sounds like an API to allow Windows-based virus scanners to run, checking both loaded apps and scanning hardisk when changes occur, but there are better solutions for virus scanning on *nix systems. I keep mentioning clamav.

Feb. 17, 2009