Re: Suggestion to the list maintainer
On Jan 18, 2008 1:06 PM, Tomas Kuliavas [EMAIL PROTECTED] wrote: Zimbra is commercial groupware suite. SquirrelMail is free webmail application. You are suggesting to replace whole user's email system with some proprietary locked product. There's an (at least in name) FOSS version of Zimbra... but eeew. I am tasked with the unfortunate duty of admining a machine running Zimbra and I can say it's not worth the trouble. Unless you like Java processes that gobble 2Gb of ram like cookies, that is. --tim
Re: The Spouse Test
On 9/24/07, Stephan Rose [EMAIL PROTECTED] wrote: That reminds me, one of the things I personally would love to see Wine support is Solidworks. It's about the only thing at work I still need to boot into Windows for occasionally. Same here. Solidworks actually installs now, it didn't earlier this year. And actually, the most recent version of wine even allows it to run about 5 seconds longer than the previous version, which is a definite improvement. =) Which version(s) are you using? Could you please update the AppDB? --tim
Re: Should Wine move to LGPL 3?
On 7/13/07, Victor [EMAIL PROTECTED] wrote: Also Wine isn't just a library. (LGPL) Nor is the LGPL a license exclusively for libraries. --tim
Re: Contributing money to WINE?
On 4/6/07, Frank Russo [EMAIL PROTECTED] wrote: As a WINE user, I find myself in a (seemingly) unique situation. I'll do my best to explain my motivations, and what resources are at my disposal. Basically, I would like to give money to the WINE project. I find myself in a similar dilemma... What if a few of us banded together and put a bounty on a feature / app, or contracted codeweavers to implement it? I think that would be great. Assuming we can agree on something we'd like to fund, it would be a little more targeted than just voting in CW's appdb. --tim
Re: Contributing money to WINE?
On 4/6/07, Dan Kegel [EMAIL PROTECTED] wrote: Lots of folks have thought about how to solve the problem, but dealing with money is complicated. It'd be better for you to donate time triaging bugs, IMHO. ( http://kegel.com/wine/qa/ ) Just reproduce one bugzilla entry a day for a week, and document what you find, and we'd be very happy! I'm actually in a position to do some of that on paid time... So I certainly will. They'll all be for boring engineering apps, but hey, a bug's a bug. Even $8,000 doesn't sound impossible... In fact, I'm sure that could be raised in the name of a popular game. $10,000 didn't turn out to be too hard a figure to rustle up to buy 8800 cards for the nouveau folks. If there are a couple big-name games that are only a few shared bugs away from working reasonably well, it might be do-able. I don't know enough about the bleeding edge state of Wine to know if that situation might exist somewhere, however. --tim
Re: Road to 1.0
On 3/20/07, Kai Blin [EMAIL PROTECTED] wrote: http://code.google.com/soc/wine/about.html Like that? Yeah. That was me attempting something resembling humor. GSoC is exactly what I meant. --tim
Re: Road to 1.0
On 3/20/07, Dan Kegel [EMAIL PROTECTED] wrote: The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. ... That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. Pay students $4500 to interest themselves in the Wine codebase over the summer and to make some well defined and useful contribution... ... ... until all the bugs are fixed? ducks Just a thought. :) --tim
DirectX related question
Already looking at buying a new computer to play Supreme Commander (http://en.wikipedia.org/wiki/Supreme_commander), is there anything I can do (including, but not limited to purchasing hardware) to help get this game running under Wine? I can't promise miracles, but if I can break down a few obstacles, consider it done. --tim
Re: DirectX related question
On 2/11/07, Tom Wickline [EMAIL PROTECTED] wrote: Fix the bugs in Wine and send your patches to wine-patches. File bug reports pertaining to this game, as well as become a maintainer for the game in our AppDB: http://appdb.winehq.org/appview.php?iAppId=4051 Purchase a copy of CrossOver and vote for DirectX support: http://www.codeweavers.com/compatibility/browse/name?app_id=249 I'll purchase crossover, but it looks like SupComm wants pixel shader 2.0, so I was thinking more along the lines of someone who wants to hack on DirectX 10, but has no DirectX 10 capable hardware. Or no DirectX 10 games to test against, etc. Anyone? --tim
Re: Copy protection
On 10/6/06, Vincent Povirk [EMAIL PROTECTED] wrote: On 10/5/06, Tim Schmidt [EMAIL PROTECTED] wrote: An application you are running (Application Name) is attempting to access a disk in a potentially unsafe way. Would you like it to access a safe virtual disk instead? Yes No A dialog like this would only serve to confuse people. If a setting is needed, it can default to the safe case. People who really know what they are doing (and therefore might want to use such an option) can modify the registry. Works for me. Assuming modification of the appropriate registry setting is doable through winecfg. Is this really about having raw access to drive letters? If it is, the answer is simple: allow raw access if the drive letter has a device associated with it. If it doesn't (c: doesn't), then either don't allow it or simulate it. That easily covers both cases since copy protection would presumably work on c: and disk utilities would work with real disks. Again, works for me. I believe the only part missing for this case is the simulation. Of course, there's the added possibility that apps will go mucking about with data other apps care about, in which case a per-executable simulated device would be best. If it's really about what drives the program can see and not drive letters, then you need to store the information of which raw devices (/dev/hdX or an image file somewhere) the program sees independently of the drive letters. It sounds to me like it's more trouble than it's worth then to make disk utilities run in Wine. It doesn't seem to be something a lot of people want to do. It's not something they should want to do if it's with disks that they care about. And, well, virtual machines are much more suited to this than Wine is. So if copy protection wants to do things to physical hard disks rather than drive letters for some reason, I say simulate them and make copy protection happy. Again, no arguments. I just want to see apps work. --tim
Re: Copy protection
On 10/6/06, Kai Blin [EMAIL PROTECTED] wrote: On Friday 06 October 2006 10:19, Tim Schmidt wrote: Again, works for me. I believe the only part missing for this case is the simulation. Of course, there's the added possibility that apps will go mucking about with data other apps care about, in which case a per-executable simulated device would be best. Wouldn't that break on Windows, too? If I have have two apps that muck about in my mbr, I expect them both to work, so they better do whatever they do in a sane way. I don't see how this would be different for a simulated drive. Yeah. you're right. I just don't trust every app that mucks about with the MBR to be courteous and correct ;) --tim
Re: Copy protection
On 10/5/06, Christoph Frick [EMAIL PROTECTED] wrote: and its very unlikely, that a sane person would WINE allow writing to the MBR (or close to it). right? OK... This discussion is veering off somewhat, but I believe it's heading in a fairly constructive direction. What we're talking about here is a class of applications that expect raw (or nearly-raw) disk access: - copy-protection that writes mysterious things to or near the MBR - various utility software (virus scanners, disk defragmenters, forensic tools, etc.) - other possibilities? Some of these tools - the forensic tools and copy-protected apps especially - would be nice if they worked on Wine. The two have different needs though... Presumably the forensic tools would be working on real drives - or copies of real drives. They need actual access. The copy-protection schemes do potentially dangerous things to actual drives - they need to be sandboxed in virtual drives that appear real. It sounds like a general framework for routing these kind of raw disk i/o would be useful... probably configurable by app would be most useful. thoughts?
Re: Copy protection
On 10/5/06, Mike McCormack [EMAIL PROTECTED] wrote: UML has a COW (copy-on-write) layer [1]. If we had something like this, conceivable we could allow Wine to read raw disks (or the COW file), then write back to the COW file. QEMU has nice support for several different COW and sparse formats... might be a slightly friendlier place to borrow code from than UML. --tim
Re: Copy protection
On 10/5/06, Christoph Frick [EMAIL PROTECTED] wrote: the #2 folks are proficient enough with their systems to know what they are doing. the #1 folks hope to get away from the world of #2 things they are forced on the windows world when they change to unix. Not nescessarily. I'm thinking specifically of some of the more exotic forensic data-recovery software. Think Joe User (Joe Friday?) prefers to use *nix, however, the software he uses to simplify gathering all the various data he needs for an investigation (could be law-related, could be an intrusion, etc.) runs only on Windows. It'd be nice to grab an image of the drive with dd and work with it on his Linux machine. Just a note... this might be possible today... I believe setting up raw disk access for an actual disk or a file is possible under Wine currently... It would be nice to handle this case in a somewhat more regular-person-friendly way - and it's logical to include handling of sandboxed raw disk access in the same way. --tim
Re: Copy protection
To clarify my thoughts, and throw this out there... Here's how I'm imagining this working: Assuming there's no problem intercepting the raw disk i/o attempts, the first time an app attempts a raw disk access, Wine can throw a popup (I know, I hate them too) with something like the following text: An application you are running (Application Name) is attempting to access a disk in a potentially unsafe way. Would you like it to access a safe virtual disk instead? Yes No Pressing Yes results in nice, safe behavior. Pressing No runs winecfg opened to the Drives tab, with perhaps an added checkbox Allow potentially unsafe raw access for each (relevant) drive. --tim
Re: A wine success story
On 10/5/06, Martin Owens [EMAIL PROTECTED] wrote: I wonder if we can get the shockwave player working with the linux version of linux via some kind of wine layer instead of installing firefox for windows. http://www.codeweavers.com/products/cxoffice/ If you'd like to duplicate effort... nspluginwrapper (http://www.gibix.net/projects/nspluginwrapper/) might be a good place to start. --tim
Re: Adobe Photoshop idea
On 10/3/06, Hiji [EMAIL PROTECTED] wrote: Sun Microsystems can't be killed. Many of the world's infrastructure literally relies on them (though, it's not quite evident from the end user standpoint.) The only way they would go away is if they were bought out, and then, the Sun name was axed. What's the old addage? No one's indispensible. --tim
Re: Copy protection
On 10/3/06, Robert Lunnon [EMAIL PROTECTED] wrote: Part 3 Applies, however it could be read as being permissible for the purpose of implementing a compatible interface. IE for the purpose of making the copy protection work under Wine. I think it would be much safer to make the protection work from a circumvention point of view. IANAL More defensible? Certainly. Advisable? Of course. Strictly necessary as per the letter of the law? I suppose it's up to interpretation (what law isn't?), but the way I read it, Wine is completely protected - being that 'enabling interoperability of an independently created computer program with other programs' is it's sole purpose for existing. So, in summary, I pretty much agree entirely. --tim
Re: Copy protection
On 10/2/06, James Courtier-Dutton [EMAIL PROTECTED] wrote: The easiest way round this is to simply recognise the executable with the copy protection, and simply install a hook to catch the appropriate file system or registry calls and divert them to a special handling routine to satisfy the application. The difficulty would come from actually implementing the copy protection part. I.e. Preventing the wine user from copying the software. Since we're not getting cooperation from the copy protection software houses, I don't think that's a major goal of this work. We'd like _copy protected_ software to work with Wine, who cares if the _copy protection_ software actually works beyond allowing the program to run? --tim
Re: Copy protection
On 10/2/06, Marcus Meissner [EMAIL PROTECTED] wrote: We can't, this kind of circumvention is likely to be illegal in the US. The relevant portion of the DMCA reads as follows: (http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105bzNC4v:e11559:) `(2) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that-- `(A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; `(B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or `(C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title. I believe we don't match A, B, or C. Further, `(f) REVERSE ENGINEERING- (1) Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title. `(2) Notwithstanding the provisions of subsections (a)(2) and (b), a person may develop and employ technological means to circumvent a technological measure, or to circumvent protection afforded by a technological measure, in order to enable the identification and analysis under paragraph (1), or for the purpose of enabling interoperability of an independently created computer program with other programs, if such means are necessary to achieve such interoperability, to the extent that doing so does not constitute infringement under this title. `(3) The information acquired through the acts permitted under paragraph (1), and the means permitted under paragraph (2), may be made available to others if the person referred to in paragraph (1) or (2), as the case may be, provides such information or means solely for the purpose of enabling interoperability of an independently created computer program with other programs, and to the extent that doing so does not constitute infringement under this title or violate applicable law other than this section. Appears to grant specific permission for the kinds of work the Wine devs need to do. --tim
Re: Adobe Photoshop idea
Wow... looks like Chris, and other members of that forum are 'actively hostile' to the Linux community. The difference in tone between this thread and that, about the same topic, is incredible. --tim
Re: Wine release 0.9.20
On 9/2/06, Roland Schama [EMAIL PROTECTED] wrote: Hello Alexandre, Is your group affiliated with CodeWeavers? They claim to have a wine product called Crossover Mac that will have a final release soon. If you are not the same group, what are the differences? From Wikipedia (http://en.wikipedia.org/wiki/Codeweavers): CodeWeavers is a company that sells a proprietary version of Wine called CrossOver Office, for running Windows applications on Linux. The company was founded in 1996 as a consultancy, eventually moving entirely over to Wine support. Crossover is regularly rebased to new Wine snapshots, and patches that the company's employees write are sent back to the project almost immediately http://en.wikipedia.org/wiki/Wine_(software) has more information as well. And this page: http://www.codeweavers.com/products/cxmac/truth_in_advertising/the_real_dirt/ pretty much defines the differences between Wine and Crossover. --tim
Re: wine autorun utility
On 6/30/06, William Knop [EMAIL PROTECTED] wrote: 1) While I agree maintaining a staunch security policy is important, that has nothing to do with autorun. Making the user browse to find an executable is not security. Yet again... when a user sticks an audio CD in his computer and gets a rootkit because of autorun, that's _b_a_d_ That user isn't going to browse out to the rootkit and install it him/her self. --tim
Re: wine autorun utility
On 6/30/06, William Knop [EMAIL PROTECTED] wrote: Yeah, then in that situation the user wouldn't run `wine --media- autorun /mountpoint/autorun.inf` either. I fail to see your point. Hey... If all you want to do is write a parser for autorun.inf files and attach it to a command line switch, that sounds pretty easy. Where's the patch? That said, as others have mentioned, KDE and Gnome already have similar functionality. No reason the parser can't go there (where, perhaps, people might be a little less hostile to the idea?) --tim
Re: wine autorun utility
On 6/30/06, William Knop [EMAIL PROTECTED] wrote: Parsing a windows inf hardly belongs anywhere but wine. Actually, Troy makes that point rather well in an earlier mail: This is not true. The existing action-on-CD-insertion programs provided by the desktop environment try to detect the contents of the CD to see what they should do, so they will be looking for the autorun.inf file. Additionally the autorun.inf file format is designed to include specifications of different commands for multiple environments, so if autorun.inf files are to be respected at all it makes sense that they should also be able to start a native Linux executable or shell script (discovered from an [autorun.linux.i386] section, for example). There is nothing in this that requires or enhances the Win32 API facilities that Wine seeks to provide. Only once the native Windows executable has been identified as the only (or best) target for autorun would Wine become involved, when the program in the desktop environment invoked Wine to run the executable. --tim
Re: wine autorun utility
The Sony rootkit fiasco alone should be enough to end this conversation. Period. Say what you want about the theoretical integrity of the media, and the user's security habits. The fact is that hundreds (possibly thousands or millions) of _real_ people were infected by rootkits because of autorun and an unscrupulous corporation. As you've so aptly demonstrated, average users are all too willing to trust people who don't deserve to be trusted. If Wine can protect some of those people sometimes, great. If Wine can protect people without any developers having to do any work, that's simply amazing. Well done Wine devs. --tim
Re: wine autorun utility
On 6/29/06, Chris [EMAIL PROTECTED] wrote: If you notice, Sony got into a lot of trouble over that. And the problem wasn't autorun. The problem was that the disc installed the rootkit anyway /even if the user said no/. The same exact thing would've happened if the user had to browse the CD and double-click setup.exe, or whatever the file was called. Should Wine disable running .exe files because they may install rootkits on users' machines? Of course not, because that would be couter-productive to what Wine is trying to achieve. It's the same thing with autorun. It may or may not cause problems, but it's the user's responsibility to take proper care of their machine. It's just as true in Windows as it is in Linux, or any other OS. Of course. You're right. Everyone's computers _should_ run arbitrary code from any un-authorized source automatically without the user's knowledge or permission. I was wrong. The fact that Windows ran _anything_ upon inserting a CD meant to contain audio only is crap. I understand that Sony exploited a 'feature' of Windows. It's all Sony's fault. Blame Sony. Problem is, that philosophy pushes the trust all the way out to the people who want to install rootkits on your computer. Bad idea. Better to trust Wine not to do anything to endanger your computer without your explicit attention. --tim
Re: wine autorun utility
On 6/30/06, Chris [EMAIL PROTECTED] wrote: This sounds like you missed my point. I think you're missing our points Chris... it's not inherently detramental (since the user would be instructed to manually do what autorun does automatically Yeah. The Sony rootkit users would have gladly followed the instructions on their _audio CDs_ telling them to install software that prevented fair use and installed illegal software. We're not talking about preventing legitimate use of auto-running CDs. We're talking about a sound, simple, and easy way to prevent illegitimate exploitation. If you can develop a way for Wine to automatically determine whether or not an executable on removable media is something useful or a rootkit, then you may get a little more enthusiasm for this 'feature'. --tim
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. You pretty much directly quoted the first line of his first email. He's also offered to add the status to the wiki once it becomes public knowledge (e.g. when someone from within codeweavers sends an email to the list with a little information). --tim
Re: Just want to make a comment about the current status of the project
On 4/25/06, Philip V. Neves [EMAIL PROTECTED] wrote: I've been really looking at wine for the last couple of months or so. Last little bit I've been helping by doing some testing and filing bug reports. I must say the developers of this project have done an amazing job. Its increadible how close you all are. If you can at least get code associated with making install shield based installers and other installers work flawlessly in the next little while this project will set the being a major thorn in Microsofts side when they bring out Vista. This project has the potential to really deflate them. If anything could be a major encouragement to you this no doubt should be. Ummm... they're not trying to be a thorn in Microsoft's side so much as simply interoperate with them. Think compatibility. The kind that opens markets, creates options, and encourages diversity. If Microsoft can't survive in such an environment, it's their doing. Not ours. --tim
Re: search for /dev/input/js as well as /dev/js
Seems to me that symlinks provided by a distribution would be usefull as a transitional measure only. Until applications eventually move over to the new /dev locations. So... Part of any application's perogerative is to deal with the platform(s) it runs on. Wine makes some special allowances for Solaris, and MacOS... so... there a theme here? --tim On 4/19/06, Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 19 April 2006 20:00, Mike McCormack wrote: Mike Frysinger wrote: dont really know who you're talking about when you say you guys ... sounds like you're trying to say this situation is my fault when really i nor Gentoo has had anything to do with /dev naming schemas Yes, it is Gentoo's fault. Your distro is missing a symlink, and instead of just adding the it, you waste everybody else's time running around fixing their projects. i can see this thread is clearly going to go nowhere so we might as well just kill it now before we waste each other's time trying to educate why the other person is wrong -mike
Re: Direct3D, the kernel and ReactOS
Sounds like a good project to hack on occasionally while putting the majority of effort into improving the current implementation. In other words, some effort is warranted because of the benefits of sharing code, however, wine can always transition to the new layout after it has a complete and (mostly) correct DirectX implementation. There's no reason the GDI and win32k.sys couldn't be going into the wine tree at the same time as improvements to the current system. --tim
Re: has the LGPL licence fell through ?
Trusting perhaps, but not an over-reationist for sure. Has anyone approached SpecObs Labs and asked for the code? Have they said no? This is all just speculation and hardly worthy of a thread until such comes to pass. For a company to (fairly) prominantely state on their product web page that they will release their modified Wine code to the open source community is reassuring. Innocent until proven guilty is always a nice standard to live by I believe. An trust me, a small company like SpecOps Lab certainly doesn't want to bring down the wrath of the open source community down upon it... besides the legal ramifications, the bad press would be enough to cause the severe problems, if not force them to shut down (due to lack of customers). Wine is LGPL as I understand it. Codeweavers takes advantage of that, as do other companies I imagine (Transgaming?). What's one more company basing a product on Wine code, provided they follow the license they agreed to when they received the code? Give them a chance is all I am saying... ... and no I don't want your stink'in swamp :) The SpecOps folks have been contacted before, search the archives. As for Transgaming, they use a pre-LGPL fork of the Wine code, parts of which they've released under the Aladin Public License, parts under a BSD-like license, parts have never been released. I believe it's quite safe to say that out of the three companies, Codeweavers is the only one to have mutually agreeable relations with the wine project. Skepticism and distrust is not an unfounded reaction under such conditions. --tim
Re: DirectDraw over Direct3D
TA 1.0 (fresh off the CD) also wouldn't start for me, however, after installing the v3.1c patch (the last one ever released) it started up just fine. --tim On 12/6/05, James Liggett [EMAIL PROTECTED] wrote: I fired up Total Annihilation just yesterday with Wine 0.9.2 and it was very slow. TA uses 8bit color and I'm running in 24bit at 3200x1200 (2x 19 CRTs) on a Pentium II 450Mhz with a GeForceFX 5900XT -- a bit of an odd combination... I know. If you'd like a speed comparison, perhaps with associated CPU usage I may be able to oblige. --tim Just curious--how did you get TA to even start? I installed it last week to try it out with wine 0.9.2 and it crashes after displaing a blue screen for a second or two. James
Re: DirectDraw over Direct3D
Is Starcraft really that slow? How does this compare with using DGA? I'm not too sure because its speed vaires. I've been testing Starcraft this weekend and it has been plenty speedy. But I do remember when trying to play it multiplayer a few months ago and was burned when it ran slow. In fact it slowed *everyone* down. Not fun. I fired up Total Annihilation just yesterday with Wine 0.9.2 and it was very slow. TA uses 8bit color and I'm running in 24bit at 3200x1200 (2x 19 CRTs) on a Pentium II 450Mhz with a GeForceFX 5900XT -- a bit of an odd combination... I know. If you'd like a speed comparison, perhaps with associated CPU usage I may be able to oblige. --tim
Re: Suggestions for improvement of the emulator
What makes you say that? What would need changing to efficiently accomodate more developpers? I'm asking because I don't see a problem with the current organisation but I may be missing something. If there are issues it's best to get them out in the open so we can work on fixing them. Perhaps he is refering to Alexandre... You know, like Linus, he doesn't scale. I don't see that as a problem for quite some time though. --tim
Nifty FIXME hack
I was looking at a new (to me) video editor for Linux and noticed the author had put together a rather nice system for tracking (and presumably obliterating) his FIXME's. Here's the link: http://diva.mdk.org.pl/2005/08/03/fix-the-fixme Or, if you want to skip straight to the result, here's what it produces (try clicking on the FIXME's): http://diva.mdk.org.pl/wp-content/fixmes.html Just thought you guys may find something like this marginally useful. Hope I helped ;)
Re: gmail accounts on offer
And just in case Ivan runs out, I have 50 more. --tim On Sun, 20 Feb 2005 11:54:32 +0100, Ivan Leo Puoti [EMAIL PROTECTED] wrote: I'm offering a gmail invitation to any wine dev that wants one. Private mail me for an invitation, I have enough invites for all. Ivan.
