Re: FW: RE: My 1.0 wish list
The bug is in file.c under ready_media_for_file() at the query statement. I hacked the actual wine code and ran some queries aganist actual msi installer databases. I tested a couple different queries in the actual wine installer against actual msi databases on a couple different tables to diagnose the problem, then I iterated through the results returned by the queries. Here are my findings: SELECT * FROM `MEDIA` - works fine SELECT * FROM `MEDIA` ORDER BY `LastSequence` - works fine SELECT * FROM `FILES` - works fine SELECT * FROM `FILES` ORDER BY `Sequence` - works fine SELECT * FROM `FILES` WHERE `Sequence` = 10 - upon viewing results it returns Sequences 1 through 10 - failed SELECT * FROM `Media` WHERE `LastSequence` = any number you wish - fails and returns LastSequence numbers from the table, less than the number in your comparison. This means that the bug is either in the WHERE clause, or the conditional statement immediately after the WHERE clause. I'm not sure, and I don't feel like spending another 10 hours learning how the underlying SQL code in wine works or learning how Bison parses things as the underlying code is even more confusing than what I've looked at so far, but I've narrowed down where the bug is, and what part of the query fails at in particular. I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the database that was being created, then I inserted the `id` of 8 into it and then I ran the query SELECT * FROM phone where `id` 6, and it returned the correct results with `id` of 8. But in the actual wine installer code a similar query doesn't return the correct results. I don't know if its because the wine installer is taking the query as a character array and it isn't in db.c, or if files.c is doing other things than in db.c, but I couldn't replicate it in db.c and I give up, the query is broken in the actual installer code, and when Iterating through the results it returns the wrong results from tables. From: Hans Leidekker [EMAIL PROTECTED] To: wine-devel@winehq.org CC: EA Durbin [EMAIL PROTECTED] Subject: Re: FW: RE: My 1.0 wish list Date: Sat, 3 Jun 2006 20:30:16 +0200 On Saturday 03 June 2006 18:45, EA Durbin wrote: That can't be used for a test case, for a test case I, or most likely someone elsewho has the ability and the time has to write code under dlls/msi/tests/db.c and make a program in windows to re-illustrate this bug. Do you know SQL? Could you write a few SQL statements that reproduce the exact conditions of the bug? I'm thinking of something like this: 1) create a table 2) insert a few rows 3) select a row from the table If you do, I'll have a go at writing a test case for it. -Hans
Re: FW: RE: My 1.0 wish list
On Sunday 04 June 2006 09:08, EA Durbin wrote: I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the Could you share it? database that was being created, then I inserted the `id` of 8 into it and then I ran the query SELECT * FROM phone where `id` 6, and it returned the correct results with `id` of 8. But in the actual wine installer code a Is the table in db.c comparable? Does it have the same fields and types? Also, you're using in your select but the failing select statement has = which may make a difference. -Hans
Re: FW: RE: My 1.0 wish list
On Sunday 04 June 2006 11:01, EA Durbin wrote: It shouldnt matter whether its = or , they both return the wrong results in the actual msi installer and the right results in db.c. Does this patch help? -Hans diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y index b32c417..47f858a 100644 --- a/dlls/msi/cond.y +++ b/dlls/msi/cond.y @@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera return a = b; case COND_LE: case COND_ILE: -return a = b; +return a = b; case COND_SS: case COND_ISS: return ( a b ) ? 1 : 0;
Re: FW: RE: My 1.0 wish list
Nice Catch!!! But unfortunately no, it doesn't fix the problem, the test SELECT * FROM TABLE WHERE testcondition = testinteger is still returning the wrong results. are we using the case COND_ILE when we compare for greater than or equal to? Or just when less than or equal to? or does SELECT * FROM TABLE WHERE = or only call IGE or IGT? From: Hans Leidekker [EMAIL PROTECTED] To: EA Durbin [EMAIL PROTECTED] CC: wine-devel@winehq.org Subject: Re: FW: RE: My 1.0 wish list Date: Sun, 4 Jun 2006 11:29:49 +0200 On Sunday 04 June 2006 11:01, EA Durbin wrote: It shouldnt matter whether its = or , they both return the wrong results in the actual msi installer and the right results in db.c. Does this patch help? -Hans diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y index b32c417..47f858a 100644 --- a/dlls/msi/cond.y +++ b/dlls/msi/cond.y @@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera return a = b; case COND_LE: case COND_ILE: -return a = b; +return a = b; case COND_SS: case COND_ISS: return ( a b ) ? 1 : 0;
Re: FW: RE: My 1.0 wish list
I think i might actually see the problem. Let me test it.
In cond.tab.c the regexes are all wrong for matching the comparison tests.
{ {'~','','=',0}, COND_IGE },
This should be parsing as
{ {'~','','=',0}, COND_IGE },
and
{ {'~','',0}, COND_IGT },
we're matching a less than sign, so if it is matching the it runs
COND_IGT it should be
{ {'~','',0}, COND_IGT },
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 11:59:25 -0500
Nice Catch!!!
But unfortunately no, it doesn't fix the problem, the test SELECT * FROM
TABLE WHERE testcondition = testinteger is still returning the wrong
results.
are we using the case COND_ILE when we compare for greater than or equal
to? Or just when less than or equal to?
or does SELECT * FROM TABLE WHERE = or only call IGE or IGT?
From: Hans Leidekker [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 4 Jun 2006 11:29:49 +0200
On Sunday 04 June 2006 11:01, EA Durbin wrote:
It shouldnt matter whether its = or , they both return the wrong
results
in the actual msi installer and the right results in db.c.
Does this patch help?
-Hans
diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y
index b32c417..47f858a 100644
--- a/dlls/msi/cond.y
+++ b/dlls/msi/cond.y
@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera
return a = b;
case COND_LE:
case COND_ILE:
-return a = b;
+return a = b;
case COND_SS:
case COND_ISS:
return ( a b ) ? 1 : 0;
Re: FW: RE: My 1.0 wish list
Why when i edit the code to change this, does it revert back when i compile
it?
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 12:12:18 -0500
I think i might actually see the problem. Let me test it.
In cond.tab.c the regexes are all wrong for matching the comparison tests.
{ {'~','','=',0}, COND_IGE },
This should be parsing as
{ {'~','','=',0}, COND_IGE },
and
{ {'~','',0}, COND_IGT },
we're matching a less than sign, so if it is matching the it runs
COND_IGT it should be
{ {'~','',0}, COND_IGT },
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 11:59:25 -0500
Nice Catch!!!
But unfortunately no, it doesn't fix the problem, the test SELECT * FROM
TABLE WHERE testcondition = testinteger is still returning the wrong
results.
are we using the case COND_ILE when we compare for greater than or equal
to? Or just when less than or equal to?
or does SELECT * FROM TABLE WHERE = or only call IGE or IGT?
From: Hans Leidekker [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 4 Jun 2006 11:29:49 +0200
On Sunday 04 June 2006 11:01, EA Durbin wrote:
It shouldnt matter whether its = or , they both return the wrong
results
in the actual msi installer and the right results in db.c.
Does this patch help?
-Hans
diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y
index b32c417..47f858a 100644
--- a/dlls/msi/cond.y
+++ b/dlls/msi/cond.y
@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera
return a = b;
case COND_LE:
case COND_ILE:
-return a = b;
+return a = b;
case COND_SS:
case COND_ISS:
return ( a b ) ? 1 : 0;
Re: FW: RE: My 1.0 wish list
disregard that last stupid question, I looked at the Makefile. Like i said
I'm not a C hacker, had to edit cond.y and not cond.tab.c.
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 12:49:41 -0500
Why when i edit the code to change this, does it revert back when i compile
it?
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 12:12:18 -0500
I think i might actually see the problem. Let me test it.
In cond.tab.c the regexes are all wrong for matching the comparison
tests.
{ {'~','','=',0}, COND_IGE },
This should be parsing as
{ {'~','','=',0}, COND_IGE },
and
{ {'~','',0}, COND_IGT },
we're matching a less than sign, so if it is matching the it runs
COND_IGT it should be
{ {'~','',0}, COND_IGT },
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 11:59:25 -0500
Nice Catch!!!
But unfortunately no, it doesn't fix the problem, the test SELECT * FROM
TABLE WHERE testcondition = testinteger is still returning the wrong
results.
are we using the case COND_ILE when we compare for greater than or equal
to? Or just when less than or equal to?
or does SELECT * FROM TABLE WHERE = or only call IGE or IGT?
From: Hans Leidekker [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 4 Jun 2006 11:29:49 +0200
On Sunday 04 June 2006 11:01, EA Durbin wrote:
It shouldnt matter whether its = or , they both return the wrong
results
in the actual msi installer and the right results in db.c.
Does this patch help?
-Hans
diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y
index b32c417..47f858a 100644
--- a/dlls/msi/cond.y
+++ b/dlls/msi/cond.y
@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera
return a = b;
case COND_LE:
case COND_ILE:
-return a = b;
+return a = b;
case COND_SS:
case COND_ISS:
return ( a b ) ? 1 : 0;
Re: FW: RE: My 1.0 wish list
On Sun, Jun 04, 2006 at 12:49:41PM -0500, EA Durbin wrote: Why when i edit the code to change this, does it revert back when i compile it? You need to edit cond.y (bison generates cond.tab.c). Huw.
Re: FW: RE: My 1.0 wish list
I still can't fix it, perhaps you could have a deeper look Hans.
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 12:49:41 -0500
Why when i edit the code to change this, does it revert back when i compile
it?
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 12:12:18 -0500
I think i might actually see the problem. Let me test it.
In cond.tab.c the regexes are all wrong for matching the comparison
tests.
{ {'~','','=',0}, COND_IGE },
This should be parsing as
{ {'~','','=',0}, COND_IGE },
and
{ {'~','',0}, COND_IGT },
we're matching a less than sign, so if it is matching the it runs
COND_IGT it should be
{ {'~','',0}, COND_IGT },
From: EA Durbin [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 04 Jun 2006 11:59:25 -0500
Nice Catch!!!
But unfortunately no, it doesn't fix the problem, the test SELECT * FROM
TABLE WHERE testcondition = testinteger is still returning the wrong
results.
are we using the case COND_ILE when we compare for greater than or equal
to? Or just when less than or equal to?
or does SELECT * FROM TABLE WHERE = or only call IGE or IGT?
From: Hans Leidekker [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sun, 4 Jun 2006 11:29:49 +0200
On Sunday 04 June 2006 11:01, EA Durbin wrote:
It shouldnt matter whether its = or , they both return the wrong
results
in the actual msi installer and the right results in db.c.
Does this patch help?
-Hans
diff --git a/dlls/msi/cond.y b/dlls/msi/cond.y
index b32c417..47f858a 100644
--- a/dlls/msi/cond.y
+++ b/dlls/msi/cond.y
@@ -463,7 +463,7 @@ static INT compare_int( INT a, INT opera
return a = b;
case COND_LE:
case COND_ILE:
-return a = b;
+return a = b;
case COND_SS:
case COND_ISS:
return ( a b ) ? 1 : 0;
RE: My 1.0 wish list
I just tested the latest Kidspiration install. The self extracting .exe extracts the Trial.exe file into windows/temp, and then complains about not having a program associated with Kid's Trial.exe. After traversing into the .wine/drive_c/windows/temp folder and typing Wine Kid's Trial.exe the program installed and ran just fine. From: Dan Kegel [EMAIL PROTECTED] To: wine-devel wine-devel@winehq.org Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
Re: FW: RE: My 1.0 wish list
I have compiled a list of applications that are affected by the bug in which the query in ready_media_for_file() in MSI returns the wrong results, it returns LastSequence less than the file-Sequence being passed. Here is a detailed analysis of the multiple types of errors this bugs causes. Common debug outputs of this bug are: Error #1: err:msi:ACTION_InstallFiles compressed file wasn't extracted This error is usually caused by the results of the query returning a LastSequence number of Less than that of the working install media and the installer is trying to extract the file from the wrong install medium. Error #2: err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media There is a zero in LastSequence Value of the Media table and the query in ready_media_for_file() returns it. For some reason the msi file has a zero in the LastSequence but its really a dummy cabinet file and doesn't exist. The file sequence being passed for the first file is most likely 1, and the query of = 1 is returning 0 falsely causing this error. This problem in MSI spans a multitude of bugs. America's Army - bug #5139 J2SE - bug # 4280 Half Life 2 - bug # 5004, 4533 Dawn of War Demo - bug # 3749 E-Sword 6.5 - bug # 4251 Rush for Berlin demo - bug #5187 ATI demo(Rendering With Natural Light ) - bug # 4712? There are probably other bugs resulting from this, but the log doesn't detail it well enough, alot of them just have the debug dump at the end and not the pertainent msi err lines. I only included applications where it was obvious from the log, or I tested personally. From: Mike McCormack [EMAIL PROTECTED] To: EA Durbin [EMAIL PROTECTED] Subject: Re: FW: RE: My 1.0 wish list Date: Sun, 04 Jun 2006 00:30:41 +0900 You can send me as many mails as you like, but I'm not doing anything until there's a test case showing the problem. Mike I wrote a test showing the results of the query in the wine installer and included the source code and resulting logs which clearly displays the problem. That's the best I can do. I'm not up to snuff on my C programming, nor am I familiary with how the official test case for wine is supposed to be layed out. If someone else wants to work on it then thats fine, but I layed out the problem, and debugged it, and I've proven this with code and resulting logs. This problem affects a multitude of applications in wine. If your not willing to work on it then either someone else can, or it can remain broken.
Re: FW: RE: My 1.0 wish list
On 6/3/06, EA Durbin [EMAIL PROTECTED] wrote: This problem in MSI spans a multitude of bugs. ATI demo(Rendering With Natural Light ) - bug # 4712? I noticed yesterday that just about every ATI Demo had similar installer problems. Just try a few from here if you need some quick test cases: http://www.ati.com/developer/demos.html Thanks, and good luck!
Re: FW: RE: My 1.0 wish list
That can't be used for a test case, for a test case I, or most likely
someone elsewho has the ability and the time has to write code under
dlls/msi/tests/db.c and make a program in windows to re-illustrate this bug.
From: Jason Green [EMAIL PROTECTED]
To: EA Durbin [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], wine-devel@winehq.org
Subject: Re: FW: RE: My 1.0 wish list
Date: Sat, 3 Jun 2006 12:02:15 -0400
On 6/3/06, EA Durbin [EMAIL PROTECTED] wrote:
This problem in MSI spans a multitude of bugs.
ATI demo(Rendering With Natural Light ) - bug # 4712?
I noticed yesterday that just about every ATI Demo had similar
installer problems. Just try a few from here if you need some quick
test cases:
http://www.ati.com/developer/demos.html
Thanks, and good luck!
Index: dlls/msi/files.c
===
RCS file: /home/wine/wine/dlls/msi/files.c,v
retrieving revision 1.37
diff -u -p -r1.37 files.c
--- dlls/msi/files.c 23 May 2006 12:48:16 - 1.37
+++ dlls/msi/files.c 3 Jun 2006 16:34:07 -
@@ -387,7 +387,7 @@ static UINT ready_media_for_file( MSIPAC
'`','L','a','s','t','S','e','q','u','e','n','c','e','`',0};
LPCWSTR cab, volume;
DWORD sz;
-INT seq;
+INT seq, diskId;
LPCWSTR prompt;
MSICOMPONENT *comp = file-Component;
@@ -399,6 +399,9 @@ static UINT ready_media_for_file( MSIPAC
}
mi-count ++;
+
+TRACE(DEBUG OF SELECT * FROM `MEDIA` WHERE `LastSequence` = %i ORDER BY `LastSequence` \n, file-Sequence);
+
row = MSI_QueryGetRecord(package-db, ExecSeqQuery, file-Sequence);
if (!row)
{
@@ -408,10 +411,16 @@ static UINT ready_media_for_file( MSIPAC
seq = MSI_RecordGetInteger(row,2);
mi-last_sequence = seq;
+diskId = MSI_RecordGetInteger(row,1);
volume = MSI_RecordGetString(row, 5);
prompt = MSI_RecordGetString(row, 3);
+cab = MSI_RecordGetString(row,4);
+TRACE( Last Sequence returned is: %i \n, seq );
+TRACE( DiskId returned is: %i \n, diskId );
+TRACE( CAB returned is: %s \n, debugstr_w(cab) );
+
msi_free(mi-last_path);
mi-last_path = NULL;
@@ -432,7 +441,6 @@ static UINT ready_media_for_file( MSIPAC
return rc;
}
-cab = MSI_RecordGetString(row,4);
if (cab)
{
TRACE(Source is CAB %s\n,debugstr_w(cab));
Re: FW: RE: My 1.0 wish list
On Saturday 03 June 2006 18:45, EA Durbin wrote: That can't be used for a test case, for a test case I, or most likely someone elsewho has the ability and the time has to write code under dlls/msi/tests/db.c and make a program in windows to re-illustrate this bug. Do you know SQL? Could you write a few SQL statements that reproduce the exact conditions of the bug? I'm thinking of something like this: 1) create a table 2) insert a few rows 3) select a row from the table If you do, I'll have a go at writing a test case for it. -Hans
Re: FW: RE: My 1.0 wish list
EA Durbin wrote: proven this with code and resulting logs. This problem affects a multitude of applications in wine. If your not willing to work on it then either someone else can, or it can remain broken. I told you from the start that I don't have time to work on this now. I've told you already if make it easier for me by condensing your results into a test case and adding it to the Wine test suite I will look into it. I have other real work to do, and fixing this bug would probably take a day of my time, so if it stays broken, that's fine with me, and if somebody else fixes it, that's fantastic! Mike
Re: My 1.0 wish list
On 6/3/06, EA Durbin [EMAIL PROTECTED] wrote: I just tested the latest Kidspiration install. The self extracting .exeextracts the Trial.exe file into windows/temp, and then complains about not having a program associated with Kid's Trial.exe. After traversing into the.wine/drive_c/windows/temp folder and typing Wine Kid's Trial.exe theprogram installed and ran just fine. That sounds like a loader problem.. might want to ask one of the senior devels *cough*AJ*cough* to look into it and give at least an explanation of what might be causing it.. with that info, maybe someone could unofficially mentor a fix for it outta one of the SoC kids. g Tom
Re: FW: RE: My 1.0 wish list
hopefully nobody flames me but i just tied all these bugs together thru bug 5350.. they block it now.. maybe i should just make them all dupes instead? plz dont flame me im just trying to help Tom On 6/3/06, EA Durbin [EMAIL PROTECTED] wrote: I have compiled a list of applications that are affected by the bug in whichthe query in ready_media_for_file() in MSI returns the wrong results, it returns LastSequence less than thefile-Sequence being passed.Here is a detailed analysis of the multiple types of errors this bugscauses.Common debug outputs of this bug are:Error #1: err:msi:ACTION_InstallFiles compressed file wasn't extractedThis error is usually caused by the results of the query returning aLastSequence number of Less than that of the working install media and the installer is trying to extract the file from the wrong install medium.Error #2:err:msi:extract_cabinet_file FDICopy failederr:msi:ACTION_InstallFiles Unable to ready mediaThere is a zero in LastSequence Value of the Media table and the query in ready_media_for_file() returns it. For some reason the msi file has a zeroin the LastSequence but its really a dummy cabinet file and doesn't exist.The file sequence being passed for the first file is most likely 1, and the query of = 1 is returning 0 falsely causing this error.This problem in MSI spans a multitude of bugs.America's Army - bug #5139J2SE - bug # 4280Half Life 2 - bug # 5004, 4533 Dawn of War Demo - bug # 3749E-Sword 6.5 - bug # 4251Rush for Berlin demo - bug #5187ATI demo(Rendering With Natural Light ) - bug # 4712?There are probably other bugs resulting from this, but the log doesn't detail it well enough, alot of them just have the debug dump at the end andnot the pertainent msi err lines. I only included applications where it wasobvious from the log, or I tested personally.From: Mike McCormack [EMAIL PROTECTED]To: EA Durbin [EMAIL PROTECTED]Subject: Re: FW: RE: My 1.0 wish listDate: Sun, 04 Jun 2006 00:30:41 +0900 You can send me as many mails as you like, but I'm not doing anything untilthere's a test case showing the problem.MikeI wrote a test showing the results of the query in the wine installer and included the source code and resulting logs which clearly displays theproblem. That's the best I can do. I'm not up to snuff on my C programming,nor am I familiary with how the official test case for wine is supposed to be layed out. If someone else wants to work on it then thats fine, but Ilayed out the problem, and debugged it, and I've proven this with code andresulting logs. This problem affects a multitude of applications in wine. If your not willing to work on it then either someone else can, or it canremain broken.
RE: My 1.0 wish list
I can help debug some of these, and maybe contribute to the code/test cases. I haven't coded much in C in the last few years, I took some in college, but I've never used it yet in my career path, but I'm working on refreshing my memory, and working on trying to understand the most commonly used functions called in wine. From: Dan Kegel [EMAIL PROTECTED] To: wine-devel wine-devel@winehq.org Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
RE: My 1.0 wish list
What is broken in MingW installer?, Upon testing I was able to install 5.0.2 Mingw just fine, and selected all of the components and it installed fine. I also was able to install gdb, as the bug suggests you're not able. From: Dan Kegel [EMAIL PROTECTED] To: wine-devel wine-devel@winehq.org Subject: My 1.0 wish list Date: Fri, 2 Jun 2006 21:55:43 -0700 ... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.
