Re: Porting WIne to D
On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph cds.w...@gmail.com wrote: of sucess? D has the speed of C, but is a garbage collected language and OOP. And that would help how, exactly? --Stephen Sent from my Emacs
Re: Porting WIne to D
On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph cds.w...@gmail.com wrote: Well, being a garbage collected language, it would help with the memory leaks in Wine. Being OOP it could extend the design of the code to make it cleaner and reusable. The assertions above are opinions, not facts. Also, it requires a full rewrite. Wine Initial release(per Wikipedia):4 July 1993 Good luck. --Stephen Sent from my Emacs
Re: Three year sever outstanding bug requiring minor fix
On Wed, Jun 9, 2010 at 12:52 PM, velociraptor Genjix aphi...@hotmail.com wrote: Hey, Please look into this issue, http://bugs.winehq.org/show_bug.cgi?id=15118 It seems like a fairly trivial fix which renders this application useless. A detailed description of the implementation needed is provided in that ticket. Thank you Seriously. I fail to see how you can find the fix easy. I've read the problem description and it doesn't appear to be easy at all. How is Wine supposed to support transparent windows? With Compiz? With the Composite extension? How to check for them? What if they are not available? Yes, one could just set the appropriate xatom flags and be done with it, but if a compositing window manager is not present it won't do anything. Also, I am not sure about the click through flag, that would require some spelunking to find out how wine supports it, if at all. All in all, it doesn't appear to be trivial. It doesn't even have a proposed patch! Repeating assertions in the bug report and the mailing list is a good way to annoy people. One thing that you should understand is that widely wanted features mean exactly nothing. Being widely wanted won't make the feature easier to implement, test or integrate. You could offer a business proposition to CodeWeavers or Transgaming, for them to implement a feature, offer a bounty, code it yourself or even pay someone you know to do it for you. You could even work with other people in UK who like playing poker to pool the resources for such task. That would be more productive. -- Stephen Sent from my Emacs
Re: Add .cvsignore entries for .fake files
On Mon, Nov 23, 2009 at 7:07 AM, Paul Chitescu pa...@voip.null.ro wrote: On Friday 20 November 2009 05:43:48 pm Charles Davis wrote: Paul Chitescu wrote: On Monday 16 November 2009 04:11:25 pm Paul Chitescu wrote: Changelog: Add .cvsignore entries for .fake files. What's wrong with this? Applies cleanly to my pristine wine-CVS, tried with patch taken from wine-patches bounce. Whoever rejected with fails to apply please reply with the output. We don't use CVS anymore. Now we use git. You need to first upgrade to git, then modify the .gitignore file. Chip Obviously I use CVS and the ? ..fake status reports are a nuissance. The fact you don't care about CVS doesn't mean everybody has to switch, especially since git isn't supported as widely as CVS. What do you mean by git isn't supported as widely as CVS? In any case, CVS is *ancient*. You really should learn how to use git, specially if you want to contribute to wine. It'll make your life easier, after the initial learning curve. For instance, I'd hate to do regression testing using CVS, instead of a git bisect. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: Bug for beginners
On Fri, Aug 21, 2009 at 12:58 AM, Andrew Eikum and...@brightnightgames.comwrote: Alexandros Dermenakis wrote: Hi all, I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future. thank you Hi Alexandros, When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work. Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into crosstests) and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests. If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere. Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :) No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in. Good luck and thanks for your interest, Andrew As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: Bug for beginners
On Fri, Aug 21, 2009 at 12:25 PM, Juan Lang juan.l...@gmail.com wrote: As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be which application requires this function?. We certainly prioritize functions that an application needs, but we don't prohibit code that doesn't identify an application that needs it. It's true that we often ask on this mailing list which application needs a function, but I think that's generally when a patch looks strange for some other reason. One of the usual reasons is that it's lacking a test. So, going back to the original advice: if you can write good test cases for a function, then there's a decent chance you can implement it, and both tests and the implementation can find their way into Wine. If you can't write good test cases, you'll have a much harder time getting your code into Wine. --Juan Thanks for the clarification. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: about video memory detection in wine
On Fri, Aug 14, 2009 at 4:23 PM, King InuYasha ngomp...@gmail.com wrote: This seems like the wrong way to go. I'm wondering if there is another way to detect VRAM? There should be a way to determine VRAM from Xorg? Why should OpenGL or DirectDraw be the method that Wine uses to determine video RAM? Why should Wine have a fixed value based on a list? Maybe I'm being stupid, but I think it would make sense for the display server (xorg) to know how much VRAM a graphics card has... Just a nitpick: Wine does not *use* DirectDraw, it *implements* DirectDraw, as there's no DirectDraw anywhere other than win32. I see no problem querying OpenGL, if the extensions can be trusted to provide useful values - even if they are undocumented or not always available. The problem with the approach so far seems to be that this extension is ATI-specific. Then again, the current fallback can be left in place if Wine does not find a way to properly detect the VRAM amount. As for asking Xorg, I do not have the knowledge to say if it is feasible - but one would think that would've been tried long ago if it were straightforward. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
Re: WINE and iTunes
I have seen patches in that bug report to add the firewall stubs. Is there
any problem with those patches?
Or, more to the point, is there any way I could contribute? I am not too
familiar with the firewall API or Marteen's work, but I am sure that can be
mitigated with some study :)
I might have found my personal Wine itch to scratch :)
--Stephen
programmer, n:
A red eyed, mumbling mammal capable of conversing with inanimate
monsters.
On Wed, Jul 29, 2009 at 9:21 AM, Reece Dunn mscl...@googlemail.com wrote:
2009/7/29 Roderick Colenbrander thunderbir...@gmail.com:
According to appdb there is indeed some small installer regressions
and for that some hack is posted there (see
http://appdb.winehq.org/objectManager.php?sClass=versioniId=14793).
Using this hack the program apparently installs and runs. The main
limitation is that we don't have USB support for ipod/iphone
synchronization. Maarten Lankhorst worked a bit on that last year but
his work needs to be finished and cleaned up. Fixing the msi issue
might be easy but it requires writing of a small msi test case I
think.
It is failing because the installer is running a custom action that is
trying to update the Windows firewall configuration (see
http://bugs.winehq.org/show_bug.cgi?id=15533). So this isn't an error
specific to MSI -- MSI is doing the right thing here.
Particularly:
--- Comment #10 From Reece Dunn 2009-01-06 11:30:58 ---
MSI error 1603 is a generic something went wrong error.
WiX is an open source MSI installer creator by Microsoft, available on
sourceforge. Using the power of Google, I suspect that this functionality
is
mentioned in
http://www.joyofsetup.com/2008/05/17/new-wix-feature-firewall-extension/.
It looks like iTunes is trying to query the Windows Firewall services and
is
failing because Wine does not implement this interface yet (bug 15563, bug
12876 and others).
Do you know if the logs mention trying to CoCreate
{304ce942-6e39-40d8-943a-b913c40c9cd4} (CSLID_NetFwMgr)? If it does, then
this
seems the most likely scenario.
--- Comment #11 From Cheba 2009-01-07 17:04:20 ---
(In reply to comment #10)
Do you know if the logs mention trying to CoCreate
{304ce942-6e39-40d8-943a-b913c40c9cd4} (CSLID_NetFwMgr)? If it does, then
this
seems the most likely scenario.
Yes it tries. I see this lines in terminal:
err:ole:CoGetClassObject class {304ce942-6e39-40d8-943a-b913c40c9cd4} not
registered
err:ole:CoGetClassObject no class object
{304ce942-6e39-40d8-943a-b913c40c9cd4}
could be created for context 0x1
--
NOTE: It appears that other applications are failing for similar
reasons (lack of firewall API implementation in Wine). AFAIU, the API
implementation does not actually need to do anything, it just needs to
be sufficiently stubbed to allow the applications that are using it to
succeed.
- Reece
Wine Profiling
Hi, I'd like to know what's the procedure being used to profile Wine's code. More specifically, I want to try to track down slowdowns in some applcations, which requires profiling to identify where the bottlenecks are. Are there any specific procedures or utilities to instrument and generate profiling reports? Stephen
Re: Better sound support
Kacper Pluta wrote: Hey, do you plan on enabling handling of 24bit sound and sampling frequencies 96000 or 192000? Lots of musicians using Linux need to use VST and VSTi plugins (through FST and other methods). Unfortunately quality of music you can acquire isn't realy high if you wish to use it professionally. I'd also suggest correcting MIDI handling and integrating wine with wineasio, which would enable using VST and VSTi on a quite high level, as well as use other programmes. I'd suggest creating a bug report in bugs.winehq.org, detailing the broken applications and/or plugins while you wait for a developer answer. Stephen
Re: dsound.dll, dlls/dsound/mixer.c -- DSOUND_MixerVol() optimization
Isn't this just a matter of #ifdefs? I don't really think Wine should
stick to the lowest common denominator.
I do think that such optimizations should be very well documented and
in sync with the original code.
Stephen
On 10/8/06, Roderick Colenbrander [EMAIL PROTECTED] wrote:
I was reading through dlls/dsound/mixer.c and I came across the function
DSOUND_MixerVol() that really stood out. The purpose of the code it to
apply a volume amplification by multiplying the channel data by the
amplification factor. What *really* struck me was the parallelism that
could be achieved using SIMD instructions (I am the author of the
project SIMDx86 on Sourceforge):
for (i = 0; i len; i += 2) {
*bps = (*bps * dsb-cvolpan.dwTotalLeftAmpFactor) 16;
bps++;
}
The segment below it for stereo sound not shown but is basically the
same thing.
This could be done extremely easily using MMX, which could process 32
samples/loop interation, or SSE2 which could process 64 samples/loop
(actually, more, but cache lines aren't that big yet). With the
addition of some aggressive prefetching, there could be a signifigant
speed up.
As mentioned in another part of this thread asm optimizations in Wine aren't
preferred.
If you want to optimize Wine's audio performance this isn't really the area
where you should look. The main bottlenecks are located in the interaction of
dsound with wine's audio layer (oss/alsa) and the native sound drivers
(oss/alsa). That is the area which is far from optimal and causes bad sound
quality, latencies and other issues.
Roderick
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Already Error while installing MS Office 2003
On 9/16/06, Roland Kaeser [EMAIL PROTECTED] wrote: Are you a software developer of any kind? This is a professional open source product, and we only allow the cleanest code in our tree. Wine is one of the most impressive pieces of software I've ever had the chance to work on. I, and all the other developers of Wine, do not want hacks in the code base, and am very thankful they are not allowed. If someone really wants an application to work, they can spend time and effort on writing proper fixes for the Wine tree, as we all do. Yes, I'm a software developer and I know from a uncountable amout of projects that perfect and absolute clean code is IMPOSSIBLE. Its always a calculation between the efforts and the expected results. Yes, You can write absolute (as far as this is generally possible) code but then wine will be arrive version 1.0 in 2020. Just think about the goal, users don't interst the coding quality of the sourcecode, they just want to run their windows apps on linux. I know a lot of people where have no idea about opensource. They just wan't to run their apps. And they wan't do it asap not after waiting 10 years. Look for all the alternate opensource project for properitary software, such as gimp,scribus,inkscape,openoffice,firefox,kdenlive,cinelerra,etc. Soon, the time will come where is no longer need for wine because the opensource apps are much better and more performant than actually the windows apps are. Don't You think wine (version 1.0) should be finished before this time? Roland If they start allowing all sort of creepy hacks, the end result won't be Wine getting done faster. If anything, it will become completely unmanageable and require a rewrite. By then, it might be hopelessly broken. Since you are a developer, why don't you clean codeweaver's hacks and resubmit the code? You are wasting time and effort arguing here that could be better spent writing code. Stephen
Re: AW: Already Error while installing MS Office 2003
I like the deadline idea, but I do think they've got this already, just not in terms of working applications, but subsystems. For the *weekly* application list, who is going to compile it? Wine is not Microsoft, therefore they do not have access to something along the lines of Microsoft's Compatibility Lab (and I think not even Microsoft itself could release this weekly list). Furthermore, applications have to be legally purchased to be tested, as far as I know. I'm not a [wine]developer, but I think you have absolutely no idea of the amount of effort you are talking about. There is Wine Application Database. I've contributed one entry myself. Not much, I know, but at least it is a start. Stephen On 9/16/06, Roland Kaeser [EMAIL PROTECTED] wrote: You want stable software, don't you? Yes but not for the price of developing 10 years for a software. And break other Applications. Not urgently Hey guys can't anybody see the reason? The wine project (or the finish of itself) could bring linux the breakthrough. I know a lot of people who asks as first question: Is this or the other app working on linux? Then I will think about a migration. Yes, faster development is paid by a less of stability. But is wine currently stable? By many tests with windows apps could I recognize that it is not ever! We should make a weekly public list of currently working applications (out of the box). I strongly think this is the measurement of the development progress of wine. This is is also the only thing users are interested in! So if the developers has a huge effort to develop things in wine but the count of working apps is not increasing over the time so its a strong indicator that something goes wrong. Think about commercial software dev projects they have milestones and deadlines and they have to fulfil it. Why not making hard milestones and a hard deadline which the project itself can measure against it . Lets say the deadline of a version 1.0 is end of next year (2008-01-01). So if everybody has this deadline in brain, it meight make the whole thing a bit more efficient. Its easier to make hard priority decisions. Roland - Ursprüngliche Mail Von: Detlef Riekenberg [EMAIL PROTECTED] An: Roland Kaeser [EMAIL PROTECTED] CC: Jim White [EMAIL PROTECTED]; wine-devel@winehq.com Gesendet: Samstag, den 16. September 2006, 19:16:34 Uhr Betreff: Re: AW: Already Error while installing MS Office 2003 On Sa, 2006-09-16 at 06:34 +, Roland Kaeser wrote: Why don't just accept the code? You want stable software, don't you? There is enough time later to make it more beautiful or correct it to a better quality. Who will do it later? Nobody! But for the moment, some of the code directly allows important apps to work. And break other Applications. -- By by ... Detlef
