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, 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: 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: [AppDB] Use objectMakeLink()/Url() in more places
I can not open the attachment on this message - Original Message - From: "Alexander Nicolaysen Sørnes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Chris Morgan" <[EMAIL PROTECTED]> Sent: Sunday, April 01, 2007 4:38 PM Subject: [AppDB] Use objectMakeLink()/Url() in more places Use objectMakeLink()/Url() in more places. Regards, Alexander N. Sørnes
Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg +update Czech locales for Winecfg
You can send the patches as you want/will Martin J. Schmidt 1007 Bechtel Street Monaca, Pa. 15061-1733 724-774-6826 0r 724-622-4939 [EMAIL PROTECTED] - Original Message - From: "Stefan Dösinger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; Sent: Thursday, March 29, 2007 1:59 PM Subject: Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg +update Czech locales for Winecfg Am Mittwoch 28 März 2007 23:09 schrieb Vit Hrachovy: Hi Stephan, GLSL depends on Czech localization update. Should I split them into two separate patches with different numbers? Should I send them split in two different requests? Regards Send the localization update first, then GLSL. Number the patches, for example [1/2] winecfg: czech localization update [2/2] winecfg: add d3d options You can send them at once, but in different mails
Re: [2/2] wined3d: Fix GLSL cnd instruction for INF and NAN arguments
Can you send me a patch?? - Original Message - From: "Fabian Bieler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 29, 2007 1:00 PM Subject: [2/2] wined3d: Fix GLSL cnd instruction for INF and NAN arguments From 1bca82ab76f27dd0e636305da74ec428caf9a919 Mon Sep 17 00:00:00 2001 From: Fabian Bieler <[EMAIL PROTECTED]> Date: Thu, 29 Mar 2007 19:59:11 +0200 Subject: [PATCH] wined3d: Fix GLSL cnd instruction for INF and NAN arguments --- dlls/wined3d/glsl_shader.c | 37 +++-- 1 files changed, 23 insertions(+), 14 deletions(-) diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c index 3d04f45..3ceb935 100644 --- a/dlls/wined3d/glsl_shader.c +++ b/dlls/wined3d/glsl_shader.c @@ -1156,26 +1156,35 @@ void shader_glsl_cnd(SHADER_OPCODE_ARG* arg) { glsl_src_param_t src0_param; glsl_src_param_t src1_param; glsl_src_param_t src2_param; -DWORD write_mask; -size_t mask_size; - -write_mask = shader_glsl_append_dst(arg->buffer, arg); +DWORD write_mask, cmp_channel = 0; +unsigned int i, j; if (shader->baseShader.hex_version < WINED3DPS_VERSION(1, 4)) { -mask_size = 1; +write_mask = shader_glsl_append_dst(arg->buffer, arg); shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], WINED3DSP_WRITEMASK_0, &src0_param); -} else { -mask_size = shader_glsl_get_write_mask_size(write_mask); -shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], write_mask, &src0_param); +shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1], write_mask, &src1_param); +shader_glsl_add_src_param(arg, arg->src[2], arg->src_addr[2], write_mask, &src2_param); +shader_addline(arg->buffer, "%s < 0.5 ? %s : %s);\n", +src0_param.param_str, src1_param.param_str, src2_param.param_str); +return; } +/* Cycle through all source0 channels */ +for (i=0; i<4; i++) { +write_mask = 0; +/* Find the destination channels which use the current source0 channel */ +for (j=0; j<4; j++) { +if ( ((arg->src[0] >> (WINED3DSP_SWIZZLE_SHIFT + 2*j)) & 0x3) == i ) { +write_mask |= WINED3DSP_WRITEMASK_0 << j; +cmp_channel = WINED3DSP_WRITEMASK_0 << j; +} +} +write_mask = shader_glsl_append_dst_ext(arg->buffer, arg, arg->dst & (~WINED3DSP_SWIZZLE_MASK | write_mask)); +if (!write_mask) continue; -shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1], write_mask, &src1_param); -shader_glsl_add_src_param(arg, arg->src[2], arg->src_addr[2], write_mask, &src2_param); +shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], cmp_channel, &src0_param); +shader_glsl_add_src_param(arg, arg->src[1], arg->src_addr[1], write_mask, &src1_param); +shader_glsl_add_src_param(arg, arg->src[2], arg->src_addr[2], write_mask, &src2_param); -if (mask_size > 1) { -shader_addline(arg->buffer, "mix(%s, %s, vec%d(lessThan(%s, vec%d(0.5);\n", -src2_param.param_str, src1_param.param_str, mask_size, src0_param.param_str, mask_size); -} else { shader_addline(arg->buffer, "%s < 0.5 ? %s : %s);\n", src0_param.param_str, src1_param.param_str, src2_param.param_str); } -- 1.4.4.1
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? Just a thought. :) --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
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: 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/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: 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: 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: 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
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: 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/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: 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/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: 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: 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: 0.9.17 and other issues
Hi Roland... It's not nice to yell. --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
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: 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, 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 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
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, 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
Ole-BSTR-Concat broken?
Hi *.*, seems, that the Ole-BSTR-Concat doesn't work anymore: (Debian Sid, from wine 0.9.12 upwards - wine configured, to use the builtin Ole-Stuff) In VB-Applications (wich are using (wide) Ole-BSTRs under the hood), I can reduce the problem to the following: If I define two Strings with the Content: S1, containing a Zero WChar (BSTR-LenDescriptor=2, ByteSequence 0 0) and S2, containing "A|Zero|B" (BSTR-LenDescriptor=6, ByteSequence 65 0 | 0 0 | 66 0) and then do the concat: SResult = S1 + S2 the resulting string contains only an "A" (BSTR-LenDescriptor=2, ByteSequence 65 0) instead of the correct ByteSequence: 0 0 | 65 0 | 0 0 | 66 0 That means, that the current implementation does not use the BSTR-Len-Descriptor anymore (it has worked in 0.9.10 or 0.9.11 - not very sure, but think it was 0.9.11 in my last tests) Instead it now behaves like routines, wich have to concat Zero-Terminated Strings. Nothing changed in my wine-configuration - only apt-getted to 0.9.12 first -> then to the latest 0.9.16 (ubuntu-deb) -> same problem. Do you handle the OLE-BSTR-stuff directly in wine, or do you give that jobs to other Libs in the system (the 0.9.12er winelib- update has also changed some dependencies (Gtk, libc* and others)? Olaf Schmidt
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: Cross-Machine COM-Calls under Wine... (RePost from wine.user)
> I assume you mean cross-process COM calls? No, no it works cross-machine. We've designed our own binary protocol (Variant-ParamArray-Serialization + support for IPersistStream regarding Object-Transport + ZLib-based Compression + built-in Strong-Encryption + MITM-secured Diffie-Hellman-Auth.). It has its own Server-Part, uses only one Port (where DCOM needs a complete Port-Range), it has a runtime- adjustable ThreadPool, it is working completely independent of DCOM and - most important - of the Windows-Registry. We've developed this some years ago, because we were annoyed by the DCOM-Config-Orgies and the Dll-Hell regarding correct Proxy/Stub- Interface-Registrations, the difficulties, to change COM-Binaries whilst continous operation - all those problems -> gone since we implemented our own "RPC-Server". If you have an XP- or W2K-VM somewhere, there's no setup needed, to test our Download (VB6-Runtime and ADO are then already present). Just copy the Server- and Client-Folders, start the appropriated Apps and play around, to get an idea of the whole thing (needs 5 minutes). >The D-part of DCOM is not currently supported. I know, but as said, we don't need it. > >So Wine has ca. 3 times the Call-Overhead, regarding Object- > >Instantiation and Method-Invoking-By-Name... > This is expected and it is on my todo list to fix this... Good to know... :-) > >1. Running as Service... > No. It doesn't really make sense at the moment. We don't recommend > that Wine be run as root and we don't support impersonating other Unix > users that would be necessary to maintain security in this environment. Ok, no big problem. > >2. Win-Authentication and -Impersonation > > (LogonUser- and ImpersonateLoggedOnUser-APIs ... > The probably both do nothing. Since you shouldn't be running as root, > then this isn't a problem. Ok, no big problem under Linux, but the MS-SQLServer for example, supports (besides DB-Internal Security-Accounts) Win-Based-Security (Tables/Views/etc., wich are secured using Win-Auth.) and this feature is often used by MSSQL-Admins - that's why impersonation is (among other things) important under Windows inside the "Pre-DB-Layer". But someone who decides, to do COM-Hosting under Linux, probably uses Postgre or Firebird and their builtin DB-Security/Usermanagement. > >3. "Global ServerSingletons" using ROT-Entries with FileMonikers... > Not supported yet. During a recent rewrite of the ROT implementation > I made it easier to do this, but our midl replacement "widl" isn't quite > at the point where this can be implemented yet. Ok, no big problem, if we can get '4.' to work (it's anyway the more recommended way to work with "Stateful Objects". > >4. "RPCServer-internal Singletons" ... > > CoMarshalInterThreadInterfaceInStream and > > CoGetInterfaceAndReleaseStream ... > I'm not sure what you mean here by "RPCServer-internal singletons". > Please elaborate. Normally RPCs should use stateless objects (Object-Instantiation, Method- Calling, Object-Destroying). That's what we do inside our WorkerThreads. Now there's often the need, to "pin" an object or some data somewhere between two or more RPCs (for Transactions, Session-Management, Object-Pooling, usage of serverside resources like COM-Ports , etc.). So we allow instantiation of Singleton-Objects inside the RPC- Serverprocess on their own threads (beside the WorkerThreadPool). The two types of singletons behave the same regarding their access from inside the workerthreads (handled unter Windows by the Free- Threaded-Marshaler) - but only the Singletons of Type '3.' can also be accessed from outside (and marshaled) X-Process per GetObject(...). > Both of the APIs you mention should be fully functional. I've just tested this using the following VB-Code: Inside the same Thread it works without problems under Wine (altough that makes no sense of course). Cross-Thread it is failing under Wine, whilst the cast of the IUnkn.-Proxy to a second ObjectVariable of Type IDispatch. Maybe, the problem is related to VBs Apartment-Threading and its usage of Thread-Local-Storage (TLS), but it could also be related to incorrect Ref-Counting inside Wine. Here's the Debug-Output of WINEDEBUG=+ole: (First two parts are sucessful, the 3rd-part fails - I've intermitted the Output using "MessageBox-related-Breaks" http://www.datenhaus.de/Downloads/WineDebug.txt 'here the Types and WinAPI-Declares Private Type GUID Data1 As Long '32Bit-Value Data2 As Integer '16Bit Data3 As Integer '16Bit Data4(0 To 7) As Byte End Type Declare Function CoMarshalInterThreadInterfaceInStream& Lib "ole32.dll" _ (ByRef rIID As Any, ByVal pUnk As IUnknown, ByRef ppStm as Long) Declare Function CoGetInterfaceAndReleaseStream& Lib "ole32.dll" _ (ByVal pStm As Long, ByRef rIID As Any, ByRef pUnk As IUnknown) 'And here the used Functions (last one is failing with a valid pStream-Ptr - 'but only in a Cross-Thread-Scenario) Function GetStreamPtr(ByVal Obj As Object) As
Cross-Machine COM-Calls under Wine... (RePost from wine.user)
are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. If you want to test a Server/Client-Pair - here's our free Download: www.datenhaus.de/Downloads/dh_RPC.zip For a successful test under Wine, you have to Install the Redistributables of an actual VB6-Runtime and some ADO-Distributable >=2.5 first. I've tested the whole thing under a Debian-Sid with a somewhat older Kernel (2.6.9), but with a new "apt-getted" Wine-Version (0.97). The Installation of the VB6-Runtime and the ADO-Redist was not possible, until I figured out, that a prior install of IE6 was helpful, to install the two above mentioned packages. After installing these prerequisites, I removed the IE6-ProgramFolder, unpacked our ZIP to c:\dh_RPC, started the Server and the Client - eh voilà - all was working fine (Linux->Linux and XP->Linux). The complete set of COM-DemoCalls was working "OutOfTheBox", even the "Disconnected ADO-Recordset"-Call was successful. (For the Linuxers, that are serialized DB-Resultsets, wich are often used in distributed COM-Scenarios). No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. Thanks. Olaf Schmidt
Cross-Machine COM-Calls under Wine... (RePost from wine.user)
are working here, using our own implementation of a COM-based RPC-Server. Its speciality is the hosting of COM-Binaries, that don't have to be registered, to instantiate Classes and invoke Methods on them. If you want to test a Server/Client-Pair - here's our free Download: www.datenhaus.de/Downloads/dh_RPC.zip For a successful test under Wine, you have to Install the Redistributables of an actual VB6-Runtime and some ADO-Distributable >=2.5 first. I've tested the whole thing under a Debian-Sid with a somewhat older Kernel (2.6.9), but with a new "apt-getted" Wine-Version (0.97). The Installation of the VB6-Runtime and the ADO-Redist was not possible, until I figured out, that a prior install of IE6 was helpful, to install the two above mentioned packages. After installing these prerequisites, I removed the IE6-ProgramFolder, unpacked our ZIP to c:\dh_RPC, started the Server and the Client - eh voilà - all was working fine (Linux->Linux and XP->Linux). The complete set of COM-DemoCalls was working "OutOfTheBox", even the "Disconnected ADO-Recordset"-Call was successful. (For the Linuxers, that are serialized DB-Resultsets, wich are often used in distributed COM-Scenarios). No Memory-Leaking, even under Stress (the server was able, to deliver max. 700 small COMRequsest per second, stressed from multiple Clients (XP-Box, comparable Hardware, reached ca. 2000). So Wine has ca. 3 times the Call-Overhead, regarding Object-Instantiation and Method-Invoking-By-Name. But the more realistic Recordset-Call was finished after 14ms, where the XP-Box needed 9ms - so for realistic Calls, we now see only factor 1.5 under Wine. And in the "Large-String- Reflection-Test" (2MB Up- and 4MB-Download) - Wine was a little bit faster than XP - good job, regarding your socket-bindings. Minimizing to the "KDE-SysTray", all was working; I was impressed. Now the bad news: ;-) Not working was: 1. Running as Service (Service-Registering was successful, but ...) (Ok, no big problem, running as UserProcess was working, but are there plans, to simulate the Win-ServiceControlmanager?) 2. Win-Authentication and -Impersonation (LogonUser- and ImpersonateLoggedOnUser-APIs - already mapped to...?) 3. "Global ServerSingletons" using ROT-Entries with FileMoniker-Binding 4. "RPCServer-internal Singletons" (CoMarshalInterThreadInterfaceInStream and CoGetInterfaceAndReleaseStream against the IUnknown-Interface). Any Ideas, especially for 3. and 4.?--> a good working X-Process-, respective X-Thread-Marshaling would be important, to take COM- Hosting under Linux/Wine seriously into account. My attempts, to get any useful information per WineDebug were not successful. It would be great, if anybody with more "Wine-Debugging-Experience" could look at the appropriate Calls using our free Server-Download. Thanks. Olaf Schmidt P.S. As Dan Kegel has recommended in 'wine.user', I will try to isolate the Problems 3. und 4. in separate Binaries and post a link later.
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: Allow FindExSearchLimitToDirectories
Vincent Béron wrote: Please use diff -u format for patches, they're the standard here now. Eek. I've got diff -c hardcoded in .cvsrc for gcc work. Here's a unidiff. Bernd 2005-11-01 Bernd Schmidt <[EMAIL PROTECTED]> * dlls/kernel/file.c (FIND_FIRST_INFO): Add new member search_op. (FindFirstFileExW): Set it. Allow FindExSearchLimitToDirectories. (FindNextFileW): Skip non-directories if using that search mode. Index: dlls/kernel/file.c === RCS file: /home/wine/wine/dlls/kernel/file.c,v retrieving revision 1.43 diff -c -p -u -r1.43 file.c --- dlls/kernel/file.c 26 Oct 2005 13:57:45 - 1.43 +++ dlls/kernel/file.c 1 Nov 2005 18:13:35 - @@ -55,15 +55,16 @@ HANDLE dos_handles[DOS_TABLE_SIZE]; /* info structure for FindFirstFile handle */ typedef struct { -DWORDmagic; /* magic number */ -HANDLE handle; /* handle to directory */ -CRITICAL_SECTION cs; /* crit section protecting this structure */ -UNICODE_STRING mask;/* file mask */ -UNICODE_STRING path;/* NT path used to open the directory */ -BOOL is_root; /* is directory the root of the drive? */ -UINT data_pos;/* current position in dir data */ -UINT data_len;/* length of dir data */ -BYTE data[8192]; /* directory data */ +DWORD magic; /* magic number */ +HANDLEhandle; /* handle to directory */ +CRITICAL_SECTION cs; /* crit section protecting this structure */ +FINDEX_SEARCH_OPS search_op; /* Flags passed to FindFirst. */ +UNICODE_STRINGmask;/* file mask */ +UNICODE_STRINGpath;/* NT path used to open the directory */ +BOOL is_root; /* is directory the root of the drive? */ +UINT data_pos;/* current position in dir data */ +UINT data_len;/* length of dir data */ +BYTE data[8192]; /* directory data */ } FIND_FIRST_INFO; #define FIND_FIRST_MAGIC 0xc0ffee11 @@ -1500,7 +1501,8 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR TRACE("%s %d %p %d %p %lx\n", debugstr_w(filename), level, data, search_op, filter, flags); -if ((search_op != FindExSearchNameMatch) || (flags != 0)) +if ((search_op != FindExSearchNameMatch && search_op != FindExSearchLimitToDirectories) + || flags != 0) { FIXME("options not implemented 0x%08x 0x%08lx\n", search_op, flags ); return INVALID_HANDLE_VALUE; @@ -1572,6 +1574,7 @@ HANDLE WINAPI FindFirstFileExW( LPCWSTR info->magic= FIND_FIRST_MAGIC; info->data_pos = 0; info->data_len = 0; +info->search_op = search_op; if (!FindNextFileW( (HANDLE)info, data )) { @@ -1650,6 +1653,9 @@ BOOL WINAPI FindNextFileW( HANDLE handle { if (!check_dir_symlink( info, dir_info )) continue; } + if (info->search_op == FindExSearchLimitToDirectories && + (dir_info->FileAttributes & FILE_ATTRIBUTE_DIRECTORY) == 0) + continue; data->dwFileAttributes = dir_info->FileAttributes; data->ftCreationTime = *(FILETIME *)&dir_info->CreationTime;
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: Let's fix Steam!
Hey guys, sorry to intrude, but I've been out of the Windows gaming scene for longer than I can remember. I own copies of Half-life and a few other games, but am I to understand that they can be played (for free?) through steam? I see that you can purchase a few games through steam as well ( I remember hearing about it some time ago... most of the work done on it was done by the bittorrent guy right?). --tim On Sun, 13 Mar 2005 14:08:13 +0100, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Sonntag, 13. März 2005 11:13 schrieb Scott Ritchie: > > On Sun, 2005-03-13 at 10:47 +0100, Stefan Dösinger wrote: > > > > Did you try the latest version? Did you install IE with Winetools? I > > > > still can't get past my "no text visible" error that I linked to with a > > > > screenshot earlier. > > > > > > I use Wine CVS from yesterday, steam updates itself automatically. I > > > installed MSIE manually into a fresh wine installation. > > > > > > I can see all the text in steam(at least I don't miss anything). I can > > > send you my config files, etc if you need it. > > > > > > My DLLoverrides: > > > > > > General: > > > > > > "advapi32" = "builtin" > > > "shdocvw" = "native, builtin" > > > > > > "msvcrt"= "native, builtin" > > > "advapi"= "builtin" > > > "urlmon"= "native, builtin" > > > "advpack" = "native, builtin" > > > "shlwapi" = "native, builtin" > > > ;shlwapi.dll.GetLongPathNameWrapA > > > "wininet" = "native, builtin" > > > > > > Steam Appdefault: > > > "mshtml" = "native, builtin" ;could crash steam > > > "crypt32" = "native, builtin" > > > "msvcrt" = "native, builtin" > > > "shlwapi" = "native, builtin" > > > "shdocvw" = "native, builtin" > > > "shfolder" = "native, builtin" > > > "shell" = "builtin, native" > > > "wininet" = "native, builtin" > > > "urlmon" = "native, builtin" > > > "wininet" = "native, builtin" > > > > > > I have to run Steam in a Desktop window, otherwise I can't type anything. > > > > > > Stefan > > > > Hmm, I think I will need your config files, I've been playing around > > with this for hours and can't quite get it. > > > > Maybe it's something stupid I did like forget to include something at > > compile time (I have all the build depends, I think, unless a new one > > got added recently.) > > Config file and system.reg is attached. I didn't do anything special when > installing wine. Do you have the needed fonts? I copied C:\windows\fonts from > a Windows XP system some time ago and I have all the font's in my X > installation. > > Can you send me the screenshot again? I've lost the mail in which you sent it. > As far as I can remember it occured during account creation, right? I created > my account some time ago. I just clicked on the "new account button" and I > see 9 lines of text and only a few pixels of the 10th line. Strange... > > Stefan > > >
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. > >