Re: The WINE Project should solicit grants to hire professional developers
Richard Yao wrote: Dear All: I am a senior undergraduate applied mathematics/computer science student and this year, I migrated from Windows 7 to Gentoo Linux on my computers. I tried using Linux alternatives to many applications I used on Windows, but not all software has good alternatives, so I have been using WINE for certain things. The WINE project's accomplishments so far have been extremely impressive, but at the same time, WINE's implementation of the Windows API is deficient in many ways and I think that the WINE project will need to improve its own organization before progress toward true API parity with Windows can be made. Thank you for the kind comments. What you suggest is a taxation nightmare. Having worked with 501(c)(3) organizations, you HAVE to prove that your grants were used in an appropriate manner. Using them to pay the wages of a for-hire person is NOT appropriate (and will result in the IRS coming down on you like a ton of bricks). If you are looking for a job/internship, contact CodeWeavers. Donations to the Wine Project are used to support developers at WineConf (Wine Conference). We cannot LEGALLY pay wages to others without encountering the wrath of United States taxation laws. Sorry to be so harsh, but that's the reality of the FOSS world. Either you volunteer your time, or you look for a company that will pay wages for your 'support' efforts. James McKenzie
Re: ntdll: add stub for NtSystemDebugControl (try 2)
2010/6/28 Austin English : > with correct spec file this time > > -- > -Austin > > > > The spec argument that corresponds to the PULONG prototype argument should also be ptr.
Re: ntdll: add stub for NtSystemDebugControl
On Mon, Jun 28, 2010 at 8:16 PM, Austin English wrote: > See http://bugs.winehq.org/show_bug.cgi?id=23431 > > -- > -Austin > > > > The NtSystemDebugControl spec types don't match the prototype arguments.
The WINE Project should solicit grants to hire professional developers
Dear All: I am a senior undergraduate applied mathematics/computer science student and this year, I migrated from Windows 7 to Gentoo Linux on my computers. I tried using Linux alternatives to many applications I used on Windows, but not all software has good alternatives, so I have been using WINE for certain things. The WINE project's accomplishments so far have been extremely impressive, but at the same time, WINE's implementation of the Windows API is deficient in many ways and I think that the WINE project will need to improve its own organization before progress toward true API parity with Windows can be made. I can divide WINE's development resources into two groups, volunteer and professional. The volunteer group is predominantly focused on games.The professional group is comprised of CodeWeavers and Google. CodeWeavers does what its customers want it to do, and as such, it has a large focus on games. Google on the other hand, paid CodeWeavers to make some improvements to WINE, mostly for Picasa, but also for Adobe Photoshop CS2, the reason for which I cannot imagine. Google also has its annual Summer of Code program. Each source of manpower has its own special interest and I do not believe that WINE will ever obtain any kind of API parity with Windows as long as this remains the case. With these things in mind, I would like to propose that the WINE project solicit grants from charitable organizations so that it could hire professional developers to augment its existing resources, specifically in the areas for which special interests could care less. If the Wine project could solicit sufficient funding to hire a few dozen developers for a period of several years, then I think that having WINE become as good as Windows would enter the realm of possibility. I know that many people will laugh at my suggestion (especially when they read the organization I suggest that the WINE project contact), but as far as I can tell, the WINE project has not solicited grants to be able to hire professional developers and I think that failing to solicit such grants places a handicap on the WINE project. There exist charitable organizations that seek to fund solutions to "global problems that are ignored by governments and other organizations" (as stated in Wikipedia). Because enabling Windows programs to run on free UNIX operating systems would reduce the cost of computing for all people, including those in third world countries, I am certain that such organizations that would be willing to fund WINE, provided that the WINE project inform them of its existence. The specific organization from which I think that the WINE project should attempt to solicit grant money is the Bill and Melinda Gates Foundation. In consideration of their guiding principles and the fact that they must spend $1.5 billion a year, it seems only logical to me that they would provide funding for the WINE project if asked: http://www.gatesfoundation.org/about/Pages/guiding-principles.aspx http://en.wikipedia.org/wiki/Bill_%26_Melinda_Gates_Foundation#Activities The Bill and Melinda Gates Foundation is not the only organization for which the WINE project could solicit funding, but I think that it is a good place to start. Please consider the possibility of soliciting grants so that the WINE project could hire professional developers. Also, I am not registered on the mailing list, so please CC me any responses made either directly or indirectly to this email, even if it ridicules my suggestion. Yours truly, Richard Yao
Re: configure.ac: Don't try to rm dirs.
2010/6/28 Alexandre Julliard : > Nicolas Le Cam writes: > >> Hi, >> >> This patch allows to do a make clean in a wine tree configured with >> with-wine64 option and fix following errors : >> rm: cannot remove `fonts': Is a directory >> rm: cannot remove `server': Is a directory > > These should be symlinks in a wow64 tree. Probably you didn't start from > a fresh tree. > > -- > Alexandre Julliard > julli...@winehq.org > You're right even if I can't remember creating it so long ago. Sorry for the noise. -- Nicolas Le Cam
Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
On 06/28/2010 01:44 PM, Reece Dunn wrote:
> On 28 June 2010 12:26, Alexandre Julliard wrote:
>
>> Wolfram Sang writes:
>>
>>
>>> According to TestBot (#2851), all non-crashing Windows versions return 0.
>>>
>>> Found while working on Bug 21012. Although this patch doesn't cure this
>>> bug, I think it is still worth adding the check because the pointer
>>> may come from the (always evil ;)) user-application.
>>>
>> Do you have an actual application that does this, or is this just hiding
>> a Wine bug?
>>
> When running winedbg on bfginstaller.exe (trying to track down
> http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in
> the cursoricon.c code (line 771 --
> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9a1810e22a1a77c698a14e0d6a9a33c5d036bce0;hb=d474d3f142b6e5f50ca3253cd170695ac3cc8930#l771):
>
> 767 /* pre-multiply by alpha */
> 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4)
> 769 {
> 770 unsigned int alpha = ptr[3];
> 771 ptr[0] = ptr[0] * alpha / 255;
> 772 ptr[1] = ptr[1] * alpha / 255;
> 773 ptr[2] = ptr[2] * alpha / 255;
> 774 }
>
> The app itself does not crash there when not running without winedbg,
> but is generating an issue later on that does not make sense (which I
> am suspecting is a stack corruption issue, possibly triggered by this
> issue).
>
> I'm not sure if this is a wine bug, whether Wolfram's patch gets past
> the break triggered or whether it addresses the Big Fish Games issue.
>
> I'll test the patch tonight.
>
> - Reece
>
>
>
>
>
When debugging another application I got a page fault at the same
position. You can either type "pass" or you can set |BreakOnFirstChance
to false to prevent the debugger from running into that "first chance"
page faults. That's expecially usefull when your application triggers
the page fault very frequently. See
http://www.winehq.org/docs/winedev-guide/dbg-config for more information.
The application I were debugging has a stack corruption bug too but I
don't think it's related.
|
Re: ddraw: Move complex surface destruction into its own function
On 28 June 2010 21:51, Luke Benstead wrote: > Ok I wasn't sure as it's pretty trivial. I'll resend along with the others > after 1.2. > It's trivial, but also mostly pointless on its own.
Re: ddraw: Move complex surface destruction into its own function
Ok I wasn't sure as it's pretty trivial. I'll resend along with the others after 1.2. On Jun 28, 2010 8:36 PM, "Henri Verbeet" wrote: On 28 June 2010 20:03, Luke Benstead wrote: > Needed to properly fix ddraw surfac... That's of course not appropriate during code freeze.
Re: ddraw: Move complex surface destruction into its own function
On 28 June 2010 20:03, Luke Benstead wrote: > Needed to properly fix ddraw surface refcounting as it must be called from > the surface thunks. > That's of course not appropriate during code freeze.
Re: kernel32: Add NERR_UserNotFound to Norweigan winerr
On Mon, Jun 28, 2010 at 1:24 PM, Paul Vriens wrote: > On 06/28/2010 08:15 PM, Austin English wrote: >> >> See http://bugs.winehq.org/show_bug.cgi?id=11168 >> > > Hi Austin, > > Applying the patch gives: > > [p...@acer wine-git]$ patch -p 1 -i /home/paul/kernel32_nor.txt > (Stripping trailing CRs from patch.) > patching file dlls/kernel32/nls/winerr_nor.mc > > Compiling gives: > > ../../../wine-git/dlls/kernel32/nls/winerr_nor.mc:3737:2: Error: Unexpected > EOF > make: *** [nls/winerr_nor.mc.rc] Error 1 > > You need to add a '.' at the end of the mc file (see the others). Crap, thanks. Was on a slow machine, didn't test compiling it. I'll resend. -- -Austin
Re: kernel32: Add NERR_UserNotFound to Norweigan winerr
On 06/28/2010 08:15 PM, Austin English wrote: See http://bugs.winehq.org/show_bug.cgi?id=11168 Hi Austin, Applying the patch gives: [p...@acer wine-git]$ patch -p 1 -i /home/paul/kernel32_nor.txt (Stripping trailing CRs from patch.) patching file dlls/kernel32/nls/winerr_nor.mc Compiling gives: ../../../wine-git/dlls/kernel32/nls/winerr_nor.mc:3737:2: Error: Unexpected EOF make: *** [nls/winerr_nor.mc.rc] Error 1 You need to add a '.' at the end of the mc file (see the others). -- Cheers, Paul.
Re: Wine on cygwin now compiles!
On Sun, Jun 27, 2010 at 4:59 AM, Aleksey Bragin wrote: > Is there any real, practical interest in Wine on Windows? For doing a full port, other than the argument of climbing the mountain because it's there, I doubt it. > I've been making some progress in this direction recently (though I think my > approach would be to have a ported, NT-version of wineserver.exe which just > uses native functions of the OS instead of emulating them over cygwin, which > emulates those features using its own code once again; discussable anyway). I think as we have discussed before, taking arwinss, or at least the core parts of it and attempting to make an independent subsystem that runs under Windows has value. I believe there is a worthwhile product based upon your work with arwinss using Wine user32/gdi32/x11drv with the rest of the Windows stack to support remotely displaying Win32 applications over X11 to OS X, Solaris and Linux clients. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Possible patch for #12706
Hi Jeff, 2010/6/25 Jeff Cook : > This is a patch that makes WINE detect snd_usb_audio mics and assign > them a mixer and working master control. See bug #12706 for more > information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706 > > I wasn't able to test it completely because I wasn't able to switch my > default input device to the USB mic and no one in IRC is helping with > this, but it might make things work because theoretically the only > problem was that WINE was ignoring devices that looked like > snd_usb_audio's microphones. I suggest that someone who CAN get > snd_usb_audio mic as their default test it out and confirm, I would > really appreciate that. If you really want to force it, do lsmod |grep snd and do modprobe -r over all driver modules, snd-usb-audio and usually snd-hda-intel or something like that. Then modprobe snd-usb-audio and it will be the only audio device, so its always the default. ;) ~Maarten
Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
On 28/06/10 13:26, Alexandre Julliard wrote: > Wolfram Sang writes: > >> According to TestBot (#2851), all non-crashing Windows versions return 0. >> >> Found while working on Bug 21012. Although this patch doesn't cure this >> bug, I think it is still worth adding the check because the pointer >> may come from the (always evil ;)) user-application. > > Do you have an actual application that does this, or is this just hiding > a Wine bug? Nope, no application (yet). As said, I found this flaw while checking #21012. The accompanying tests, which sadly crash some windows versions, backup the changes AFAICS. I can repost after 1.2 if you prefer that. Regards, Wolfram
Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
Reece Dunn writes:
> When running winedbg on bfginstaller.exe (trying to track down
> http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in
> the cursoricon.c code (line 771 --
> http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9a1810e22a1a77c698a14e0d6a9a33c5d036bce0;hb=d474d3f142b6e5f50ca3253cd170695ac3cc8930#l771):
>
> 767 /* pre-multiply by alpha */
> 768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4)
> 769 {
> 770 unsigned int alpha = ptr[3];
> 771 ptr[0] = ptr[0] * alpha / 255;
> 772 ptr[1] = ptr[1] * alpha / 255;
> 773 ptr[2] = ptr[2] * alpha / 255;
> 774 }
>
> The app itself does not crash there when not running without winedbg,
> but is generating an issue later on that does not make sense (which I
> am suspecting is a stack corruption issue, possibly triggered by this
> issue).
That's a DIB exception. Perfectly normal, and nothing whatsoever to do
with the patch.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
On 28 June 2010 12:26, Alexandre Julliard wrote:
> Wolfram Sang writes:
>
>> According to TestBot (#2851), all non-crashing Windows versions return 0.
>>
>> Found while working on Bug 21012. Although this patch doesn't cure this
>> bug, I think it is still worth adding the check because the pointer
>> may come from the (always evil ;)) user-application.
>
> Do you have an actual application that does this, or is this just hiding
> a Wine bug?
When running winedbg on bfginstaller.exe (trying to track down
http://bugs.winehq.org/show_bug.cgi?id=14343), winedbg will trap in
the cursoricon.c code (line 771 --
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/cursoricon.c;h=9a1810e22a1a77c698a14e0d6a9a33c5d036bce0;hb=d474d3f142b6e5f50ca3253cd170695ac3cc8930#l771):
767 /* pre-multiply by alpha */
768 for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4)
769 {
770 unsigned int alpha = ptr[3];
771 ptr[0] = ptr[0] * alpha / 255;
772 ptr[1] = ptr[1] * alpha / 255;
773 ptr[2] = ptr[2] * alpha / 255;
774 }
The app itself does not crash there when not running without winedbg,
but is generating an issue later on that does not make sense (which I
am suspecting is a stack corruption issue, possibly triggered by this
issue).
I'm not sure if this is a wine bug, whether Wolfram's patch gets past
the break triggered or whether it addresses the Big Fish Games issue.
I'll test the patch tonight.
- Reece
Re: user32: Make sure the desktop window is created before caps enumeration.
Dmitry Timoshkov writes: > This patch fixes the problem reported in the bug 21709. That's just hiding the bug. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/3] shell32: Use more accurate PathIsURL instead of searching for a colon
Andrew Eikum writes:
> diff --git a/dlls/shell32/shfldr_desktop.c b/dlls/shell32/shfldr_desktop.c
> index 30aea3b..54d13dc 100644
> --- a/dlls/shell32/shfldr_desktop.c
> +++ b/dlls/shell32/shfldr_desktop.c
> @@ -193,7 +193,7 @@ static HRESULT WINAPI ISF_Desktop_fnParseDisplayName
> (IShellFolder2 * iface,
> *ppidl = pidlTemp;
> return S_OK;
> }
> -else if (strchrW(lpszDisplayName,':'))
> +else if (PathIsURLW(lpszDisplayName))
> {
A better way would be to check the result of the ParseURLW call.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
Wolfram Sang writes: > According to TestBot (#2851), all non-crashing Windows versions return 0. > > Found while working on Bug 21012. Although this patch doesn't cure this > bug, I think it is still worth adding the check because the pointer > may come from the (always evil ;)) user-application. Do you have an actual application that does this, or is this just hiding a Wine bug? -- Alexandre Julliard julli...@winehq.org
Re: configure.ac: Don't try to rm dirs.
Nicolas Le Cam writes: > Hi, > > This patch allows to do a make clean in a wine tree configured with > with-wine64 option and fix following errors : > rm: cannot remove `fonts': Is a directory > rm: cannot remove `server': Is a directory These should be symlinks in a wow64 tree. Probably you didn't start from a fresh tree. -- Alexandre Julliard julli...@winehq.org
