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

Re: appdb issue: can't search for apps platinum on 1.0.x!

by Scott Ritchie

Ben Klein wrote: > 2009/2/26 Dan Kegel <dank(a)kegel.com>: >> Our currently released version is 1.0, but the appdb's >> browse feature acts as if that version no longer exists. >> This will seriously confuse newcomers who are using >> the 1.0.1 version (e.g. anybody who installs a fresh >> copy of Ubuntu!). >> >> To fix this, we should add 1.0 (or 1.0.1) back into the search box in >> http://appdb.winehq.org/objectManager.php?sClass=application > > Someone mentioned on another thread (or possibly on IRC, I don't > recall) that 1.0-series is too old to be of concern to us. We don't > want test data for 1.0.x; we don't want bug reports for 1.0.x unless > they're still apparent in the development version. Development has > stopped on 1.0.x. > > The problem is that 1.0.1 is not actually "stable" in that it doesn't > crash/runs lots of apps. It's "stable" in that the code doesn't > change, kind of like Debian Stable. If a massive security issue (like > a rootkit) becomes apparent in 1.0.1, I'm pretty sure we want to know > about that, but in general, if it can be fixed by upgrading to 1.1.x, > then that's what you should do. > > There have been plenty of cases in #winehq where users have some > problem with 1.0.1 (Warcraft 3 appears to be a popular candidate). > When they upgrade to 1.1.15, suddenly it starts working. Are there > even any winehq-supplied binary packages for any distro that supply > 1.0.1 by default? Scott's Ubuntu packages are the dev versions, though > 1.0.1 is accessible through his archives; my Debian packages only go > back to about 1.1.12 or so. > > What this means, quite simply, is that we need more frequent releases of a stable Wine version. I know Alexandre wants to cram in a major feature before starting the stabilization process, but unless that happens really soon we're only going to see issues like this get even worse. Thanks, Scott Ritchie

Feb. 26, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > So, in theory, Wine could simply run itself on top of Linux (basically a > ReactOS desktop on top of Linux instead of the NT kernel) and work just like > Windows because it operates in a native app style? Granted, that probably > would require quite a bit of tweaking to get it done, and the devs probably > wouldn't want to do it, but because of its design, that would be possible? Yes, it's possible to run a win32 userland on Linux via Wine. It's been tried before, but none of the projects have survived. It's also not possible to make EVERY application that works in Windows work in Wine. This might be reduced if Gallium3D or GEM allows DirectX calls to the graphics cards, but there would still be apps that do checksums of system DLLs that would fail on Wine ... Anyway, this is diverging from the topic :)

Feb. 26, 2009

Re: Malware on Wine review

by Remco

On Thu, Feb 26, 2009 at 2:37 AM, Ben Klein <shacklein(a)gmail.com> wrote: > It's a compatibility layer. It doesn't actually interpret individual > instructions. As described earlier, Wine sets up an environment > suitable for the Windows apps to run in (which is primarily > *implementations* of win32 calls that "translate" in one way or > another into *nix/X11 calls) and then just lets it do its thing. > Unlike in Java, scripting languages etc, Wine does not read in the > application one instruction at a time and do a mapping/translation > into executable functionality. The assembly components (such as > mathematical operations) run as if it was a native application. Indeed. You could say that Linux userland is a "Linux compatibility layer" just like Wine is one for Windows. It's mostly the same level of abstraction. Except of course for D3D. There are no drivers that expose the GPU. Only OpenGL. But that may change with Gallium3D. I don't know what problem that would solve though. Remco

Feb. 26, 2009

Re: Malware on Wine review

by King InuYasha

On Wed, Feb 25, 2009 at 7:37 PM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > > On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein <shacklein(a)gmail.com> wrote: > >> > >> 2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > >> > Now that Nautilus has the desktop file requiring execute bit, I have a > >> > question for all of you to consider. Do JAR files require the +x bit > to > >> > load > >> > them, or are they treated like associated files and run through the > >> > interpreter? Really, Windows apps on Linux is basically the same > >> > situation > >> > as Java applications run through the bytecode interpreter. > >> > >> You just answered your own question. Java is interpreted and has to be > >> passed through a compatible byte-code interpreter. Wine does not > >> interpret PE files in this fashion, and cannot because it is not and > >> does not have a CPU emulator. So a JAR file should run if passed as an > >> argument to the interpreter, just like what happens with the scripting > >> languages that open the file for reading instead of trying to fork and > >> execute. > >> > > > > But, doesn't Wine translate Win32 calls into its equivalent calls for > Linux? > > GDI to X11, D3D to OpenGL, etc.? > > That sounds like an interpreter to me. It may not necessarily a bytecode > > interpreter, but it still interprets the Win32 API and translates it to > the > > appropriate UNIX APIs. Isn't this what makes Wine not an emulator? > > It's a compatibility layer. It doesn't actually interpret individual > instructions. As described earlier, Wine sets up an environment > suitable for the Windows apps to run in (which is primarily > *implementations* of win32 calls that "translate" in one way or > another into *nix/X11 calls) and then just lets it do its thing. > Unlike in Java, scripting languages etc, Wine does not read in the > application one instruction at a time and do a mapping/translation > into executable functionality. The assembly components (such as > mathematical operations) run as if it was a native application. > So, in theory, Wine could simply run itself on top of Linux (basically a ReactOS desktop on top of Linux instead of the NT kernel) and work just like Windows because it operates in a native app style? Granted, that probably would require quite a bit of tweaking to get it done, and the devs probably wouldn't want to do it, but because of its design, that would be possible?

Feb. 26, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein <shacklein(a)gmail.com> wrote: >> >> 2009/2/26 King InuYasha <ngompa13(a)gmail.com>: >> > Now that Nautilus has the desktop file requiring execute bit, I have a >> > question for all of you to consider. Do JAR files require the +x bit to >> > load >> > them, or are they treated like associated files and run through the >> > interpreter? Really, Windows apps on Linux is basically the same >> > situation >> > as Java applications run through the bytecode interpreter. >> >> You just answered your own question. Java is interpreted and has to be >> passed through a compatible byte-code interpreter. Wine does not >> interpret PE files in this fashion, and cannot because it is not and >> does not have a CPU emulator. So a JAR file should run if passed as an >> argument to the interpreter, just like what happens with the scripting >> languages that open the file for reading instead of trying to fork and >> execute. >> > > But, doesn't Wine translate Win32 calls into its equivalent calls for Linux? > GDI to X11, D3D to OpenGL, etc.? > That sounds like an interpreter to me. It may not necessarily a bytecode > interpreter, but it still interprets the Win32 API and translates it to the > appropriate UNIX APIs. Isn't this what makes Wine not an emulator? It's a compatibility layer. It doesn't actually interpret individual instructions. As described earlier, Wine sets up an environment suitable for the Windows apps to run in (which is primarily *implementations* of win32 calls that "translate" in one way or another into *nix/X11 calls) and then just lets it do its thing. Unlike in Java, scripting languages etc, Wine does not read in the application one instruction at a time and do a mapping/translation into executable functionality. The assembly components (such as mathematical operations) run as if it was a native application.

Feb. 26, 2009

Re: Malware on Wine review

by King InuYasha

On Wed, Feb 25, 2009 at 6:50 PM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > > Now that Nautilus has the desktop file requiring execute bit, I have a > > question for all of you to consider. Do JAR files require the +x bit to > load > > them, or are they treated like associated files and run through the > > interpreter? Really, Windows apps on Linux is basically the same > situation > > as Java applications run through the bytecode interpreter. > > You just answered your own question. Java is interpreted and has to be > passed through a compatible byte-code interpreter. Wine does not > interpret PE files in this fashion, and cannot because it is not and > does not have a CPU emulator. So a JAR file should run if passed as an > argument to the interpreter, just like what happens with the scripting > languages that open the file for reading instead of trying to fork and > execute. > > But, doesn't Wine translate Win32 calls into its equivalent calls for Linux? GDI to X11, D3D to OpenGL, etc.? That sounds like an interpreter to me. It may not necessarily a bytecode interpreter, but it still interprets the Win32 API and translates it to the appropriate UNIX APIs. Isn't this what makes Wine not an emulator?

Feb. 26, 2009

Re: Malware on Wine review

by Ben Klein

2009/2/26 King InuYasha <ngompa13(a)gmail.com>: > Now that Nautilus has the desktop file requiring execute bit, I have a > question for all of you to consider. Do JAR files require the +x bit to load > them, or are they treated like associated files and run through the > interpreter? Really, Windows apps on Linux is basically the same situation > as Java applications run through the bytecode interpreter. You just answered your own question. Java is interpreted and has to be passed through a compatible byte-code interpreter. Wine does not interpret PE files in this fashion, and cannot because it is not and does not have a CPU emulator. So a JAR file should run if passed as an argument to the interpreter, just like what happens with the scripting languages that open the file for reading instead of trying to fork and execute. > Also, NTFS DOES have a concept of execute bits, but Windows itself does not > use them. An implementation of this is the "trusted" app scheme in the > properties in Windows Vista and above (I don't remember if XPSP2 had it > also). Although this scheme is mostly broken, it was intended to stop the > execution of apps just downloaded from the internet from a non-trusted > source. NTFS has the concept of metadata. Windows does not use it as an equivalent for +x bit though. And even if it did, it wouldn't be a big help for Wine, because Wine doesn't like NTFS :) 2009/2/26 Scott Ritchie <scott(a)open-vote.org>: >> It's hardly annoying as it takes all of two seconds (or less). It's part of >> normal system operation that the user will already have to deal with outside >> of Wine. And at least they'll know that it's something that is going to be >> executing, instead of simply opened/read. Trading safety for user convenience >> like that is a bad habit to pick up. > > It takes about 2 seconds once you've learned how to do this, but this is > hardly an easily discoverable task. One word for you: EDUCATION. Newbies should be taught how things work. We shouldn't base all our usability decisions based on what they expect. They expect it to "just work". The only case we're talking about here where it won't "just work" is when they download an app to install; in this case they have to +x it explicitly. Just like if it was a regular ELF executable. > Regardless, when a user says "open the program" twice in a row - by > clicking on it and then clicking "run this program" on the associated > dialog box, I think it best we got out of their way rather than assume > they actually meant "no, don't run it until I make 4 more clicks on a > different tab in the preferences dialog." Wow 4 more clicks? That might give me RSI! Why don't we get out of their way entirely and automatically run wineboot when they log on to an X session, so they get Steam and all their trojans running without warning? People seem to forget that security comes at the cost of convenience. In my opinion, requiring +x is not just about security (for downloaded applications in particular) but about correctness. Wine is not an interpreter, it's a binary loader. It should act like a binary loader and respect +x. If possible, it should respect noexec mount option too. > Does Wine do this in all cases (mark installed executables as +x)? I believe so. As it's been mentioned, Wine goes to great lengths to make sure EXEs are marked +x, but it doesn't do anything else with it. I expect that this is mostly to keep binfmt-misc happy. What this thread needs now is a final decision from AJ. :)

Feb. 26, 2009

Re: appdb issue: can't search for apps platinum on 1.0.x!

by Ben Klein

2009/2/26 Dan Kegel <dank(a)kegel.com>: > Our currently released version is 1.0, but the appdb's > browse feature acts as if that version no longer exists. > This will seriously confuse newcomers who are using > the 1.0.1 version (e.g. anybody who installs a fresh > copy of Ubuntu!). > > To fix this, we should add 1.0 (or 1.0.1) back into the search box in > http://appdb.winehq.org/objectManager.php?sClass=application Someone mentioned on another thread (or possibly on IRC, I don't recall) that 1.0-series is too old to be of concern to us. We don't want test data for 1.0.x; we don't want bug reports for 1.0.x unless they're still apparent in the development version. Development has stopped on 1.0.x. The problem is that 1.0.1 is not actually "stable" in that it doesn't crash/runs lots of apps. It's "stable" in that the code doesn't change, kind of like Debian Stable. If a massive security issue (like a rootkit) becomes apparent in 1.0.1, I'm pretty sure we want to know about that, but in general, if it can be fixed by upgrading to 1.1.x, then that's what you should do. There have been plenty of cases in #winehq where users have some problem with 1.0.1 (Warcraft 3 appears to be a popular candidate). When they upgrade to 1.1.15, suddenly it starts working. Are there even any winehq-supplied binary packages for any distro that supply 1.0.1 by default? Scott's Ubuntu packages are the dev versions, though 1.0.1 is accessible through his archives; my Debian packages only go back to about 1.1.12 or so.

Feb. 26, 2009

Re: TrainingPeaks WKO+ Version 22 build 105

by Chris Teague

I'm connecting to a Saris PowerTap 2.4SL bike computer, but really it's a usb cradle using a standard FTDI chip. The device enumerates and works fine as a ttyUSB device under Linux. I have gotten closer to the root of this problem, and I now see why EV_RXFLAG was never implemented in Wine. I'll explain the problem, maybe someone with more Wine knowledge can nudge me in the direction of a good solution. RXFLAG is a parameter in the COM32 interface, there is one RXFLAG value for each COM port. Other per COM port parameters in the COM32 interface are "end of file character", "parity", etc. RXFLAG is set to any character the user wants - and when that character is actually received on the COM port, a special EV_RXFLAG event is sent to the client. This is used for example to implement a Start-of-Message in a serial protocol. In Linux (and Wine) the per serial port device configuration data is stored in a standard unix termios structure associated with the file descriptor. This structure has members for most of the COM32 parameters, EOF, EOL, etc. However, it does NOT have anything that would correspond to RXFLAG. We could store RXFLAG inside of some unused termios member - but that feels like a really bad idea. So the crux of the problem is: How do I store per serial port configuration data which does not fit into termios? I have been looking at dlls/ntdll/serial.c mostly. I see there is some server side serial code in server/serial.c. Maybe I need to store this config data in the server, and provide access to it? Possibly in async_commio.hDevice? On Fri, Feb 20, 2009 at 8:07 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Chris! > >> I think I know how to implement this feature of Win32 serial comm, but >> before I attempted I wanted to broadcast my intent to do so. Is >> anyone else working on this, or in the serial.c area that would like >> to discuss it? > > No one that I know of is working in this area. Periodically someone > might work on serial comm stuff, particularly Uwe Bonnes, but in > general this area languishes until someone motivated comes along. > > So please, work away :) Out of curiosity, which device are you playing with? > > Cheers, > --Juan >

Feb. 26, 2009

Re: Malware on Wine review

by Scott Ritchie

Chris Robinson wrote: > On Tuesday 24 February 2009 8:57:23 pm Scott Ritchie wrote: >> Worse, you could actively irritate them - suppose they do double click >> and you DONT offer the ability to open it, but instead instruct them to >> go through that annoying procedure. > > It's hardly annoying as it takes all of two seconds (or less). It's part of > normal system operation that the user will already have to deal with outside > of Wine. And at least they'll know that it's something that is going to be > executing, instead of simply opened/read. Trading safety for user convenience > like that is a bad habit to pick up. > It takes about 2 seconds once you've learned how to do this, but this is hardly an easily discoverable task. Regardless, when a user says "open the program" twice in a row - by clicking on it and then clicking "run this program" on the associated dialog box, I think it best we got out of their way rather than assume they actually meant "no, don't run it until I make 4 more clicks on a different tab in the preferences dialog." >>> Not necessarily. Along with the .desktop trojan, the blog I read also >>> showed how to override system menu entries (by placing a replacement in >>> the local folder which will override the system one). So the link you >>> clicked on may not be what you intended.. >> But in order to do that a malicious script has to already be running! >> Such a system is already owned. > > True enough, I suppose. It just seems unnecessary to me to special-case it > since a program installed via Wine (that would have created such a menu entry) > is already marked as +x. What kind of scenario would there be for a user to > have a menu entry and the program its pointing to to unknowingly be -x? Does Wine do this in all cases (mark installed executables as +x)? Thanks, Scott Ritchie

Feb. 25, 2009