On Mon, May 25, 2009 at 8:39 AM, oiaohm<wineforum-user@xxxxxxxxxx> wrote: > If wine is reliability detectable this can be used by virus writers to attack host OS. Problem is for support wine would have to expose wine version and host OS reason some bugs are particular to like Mac OS or Linux or BSD... Once you know the host OS you can code to syscall the hosting OS and attack it. Downside of giving it up is cross platform viruses become simpler. > If Wine is running on Linux, it can always be detected by making Linux syscalls. Wine cannot fix this. And of course if you're going to code to syscalls, you can always detect the os by trying them and seeing what happens. On Windows you'd just get an exception, which can easily be caught. ANY security provided by Wine is security by obscurity because the program can do anything the underlying libraries can do. Claiming that Wine provides some kind of sandboxing or other security is dishonest, and using it as such is dangerous. If you want a sandbox, use something that provides real security. If an OS is applying security to Wine beyond what would be applied to a normal program, that is completely different and irrelevant to the question of whether detecting Wine should be possible/easy. On Mon, Jun 1, 2009 at 2:35 AM, majkl<wineforum-user@xxxxxxxxxx> wrote: > Its regarding UpdateLayeredWindow() function and transparency of the window. The problem is, that wine cannot show the window that uses alpha channel to specify transparency level for its every pixel. This is hard, and at best when it is implemented it can only really work with a compositing window manager. I think in this case it's best to work around the bug. It would be better if you could detect the failure directly rather than check for Wine (so that if it is fixed, your program will work better), but I can't think of a reasonable way to do this. I would ask that you make sure the user has a way to disable any wine-specific hacks. I don't think it's terribly important what the default is. utorrent has an "enable wine hacks" setting that is default on in Wine, and I think this is fine. On Wed, Jun 3, 2009 at 6:21 AM, andreaplanet<wineforum-user@xxxxxxxxxx> wrote: > First you say it is wrong to detect Wine, now you say let the user detect Wine (choose on which OS you are running). > Every developer have to write that question, save that info somewhere in the registry or a INI file. What a duplication. > Honestly a simple API call for everyone would be much easier without bothering the end-user. > As a end-user I would ask myself "isn't the program intelligent enough to detect on what system it is running?" > ... > > For example personally I want that my application use the native Open File Dialog and not the ugly default windows open file dialog. By reading the currently running OS I can run a specified native executable/library that offer this feature and interact with the EXE application through a pipe for example. The Wine community will refuse to use such a hack because it changes the natural behaviour of the Windows environment. And I want this change only for my own application, so that other applications will run without problems. Here a reason why a simple API to let me know the name of currently OS is welcome, and it should work both at least on Windows, Linux and Mac OS X. I would be in favor of the creation of such API calls. Wine could include (or someone could write one separately using winelib) a library that exports a function that tells the calling program the Wine version. It could also have functions to run a native filechooser if it's available; this is a perfectly reasonable thing to implement. With such a library, saying to the program "I am not Wine" is as easy as disabling the library. We already have environment variables and registry settings for doing this. Vincent Povirk
