Dimitrie O. Paun wrote:
On Wed, 3 Sep 2003, Eric Pouech wrote:
if someone wants to work on this, here's a little comparison of wine's
headers (on left hand side) and windows (on the right hand side).
I only listed the headers I add on both sides.
Cool -- I'll fix commctrl.h.
I have already st
On September 3, 2003 03:53 pm, Eric Pouech wrote:
> any comment welcomed!!
This is very nice (from the comments and the code)! I will compile
it soon, but I was hoping Alexandre bits me to it and commits it,
so I can be lazy and just to a 'cvs up' :)
> (thanks to Dimi for his quick fixies on the
On Wed, 3 Sep 2003, Jakob Eriksson wrote:
> Great, except if MSVC tests are the ones that work and the only ones
> that are used, there is little incentice to fix mingw. I think we
> really have to look at mingw > and Wine as part of a greater whole. *)
I don't think the current situation jus
Dimitrie O. Paun wrote:
-- I don't think we need to _distribute_ two binaries. If the
MSVC one works better, the person designated to build and
publicly post the winetests.exe should build the tests
through MSVC. Once we fix everything so that MinGW works
just as well, we might as
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Wed, 3 Sep 2003, Ferenc Wagner wrote:
>
>>> If we need, we can create 2 versions of the
>>> winetests.exe: one with MinGW compiled tests, one with
>>> MSVC. But do we really need to bother?
>>
>> I am afraid yes. The Dsound test does not compile
On Wed, 3 Sep 2003, Dimitrie O. Paun wrote:
[...]
> So, in other words, in Windows, the following program does not compile?
>
> #include
>
> int main() { return 0; }
Yep. In Windows you always have to do:
#include
int main() { return 0; }
And windows.h includes stdarg.h and winbase.h for you
On Wed, 3 Sep 2003, Eric Pouech wrote:
> if someone wants to work on this, here's a little comparison of wine's
> headers (on left hand side) and windows (on the right hand side).
> I only listed the headers I add on both sides.
Cool -- I'll fix commctrl.h.
--
Dimi.
On Wed, 3 Sep 2003, Ferenc Wagner wrote:
> That sounds nice, but I have got the feeling that it is not
> only Wine's fault that the tests do not compile. MinGW also
> has its problems, and although new versions are definitely
> better, they are arguably not perfect (dsound misses some
> uuid feat
On Wed, 3 Sep 2003 18:20:56 +0200, you wrote:
> Changelog:
> - Set appropriate error code for gethostbyname and WSAAsyncGetHostByName
> - Restore NULL name/aq->host_name to NULL at the end of each function respectively
>
> Stephan
>
> aq->host_name = buf;
>
Hi guys, I just tried to access Bugzilla, and it isnt responding, checked
with a ping and a traceroute but both gave me request timed out, although
that could be because of a firewall, I just figured someone might want to
know (jeremy)..
=
Dustin Navea
Minor Contributor, http://www.winehq.c
In case it may be interesting to any of the hackers here,
here is a spattering of messages that get output when
running Visual FoxPro 8. If this isn't of interest, please
forgive the bandwidth.
The NotifyWinEvent messages fill pages of output during
a typical session.
The keyboard: X11DRV_ToUnic
Alexandre Julliard wrote:
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
With this patch, we can get rid of the stdarg.h
include from winbase.h if it weren't for the
FormatMessage() functions:
DWORD WINAPI FormatMessageA(DWORD,LPCVOID,DWORD,DWORD,LPSTR,DWORD,va_list*);
DWORD WINAPI Fo
Please give this a try -- it should fix it.
works great. thx
A+
--
Eric Pouech
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> So, in other words, in Windows, the following program does not compile?
>
> #include
>
> int main() { return 0; }
No it doesn't, and not only because of stdarg.h, our winbase.h also
includes basetsd.h and windef.h that should be removed too. And
s
On Wed, 3 Sep 2003, George Marshall wrote:
>
> Hi I've already submitted this bug to the wine bugzilla but I'm posting
> it here as well 'cause... oh well you know.
In your bug report you say:
Oh, I forgot to say that the same application is wortking correctly on Windows.
i've also tried to
On Wed, 3 Sep 2003, Alexandre Julliard wrote:
> We have to include stdarg.h everywhere we include winbase.h, about 650
> files at last count. That's why we need some kind of script...
So, in other words, in Windows, the following program does not compile?
#include
int main() { return 0; }
--
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> With this patch, we can get rid of the stdarg.h
> include from winbase.h if it weren't for the
> FormatMessage() functions:
>
> DWORD WINAPI FormatMessageA(DWORD,LPCVOID,DWORD,DWORD,LPSTR,DWORD,va_list*);
> DWORD WINAPI FormatMessageW(DW
On Wed, 3 Sep 2003, Ferenc Wagner wrote:
> > Well, we should handle this through the Makefiles. Also the output
> > should specify how the tests were compiled, it may help with error
> > tracking. If we need, we can create 2 versions of the winetests.exe:
> > one with MinGW compiled tests, one wit
On Wed, 3 Sep 2003, Ferenc Wagner wrote:
> And waste precious space... But it is the way if we find a
> way to cope with serveral results per Windows version.
Not really wasting, it shows we are _missing_ important
tests. I would suggest we collapse the tests for the same
version is the same col
This is a followup of my earlied post.
Recap: I was porting my program which resolved Windows
shortcut files (.lnk) using WineLib (Please note that
this program runs flawlessly on Windows).
It used to work fine till I updated my Wine source
from 20030408 to 20030813.
I posted this report here and
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Tue, 2 Sep 2003, Ferenc Wagner wrote:
>
> maybe we should control the columns manually, rather than
> dinamically. We know what we expect, and an empty column
> will also give an indication of what tests we're missing.
And waste precious space..
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Wed, 3 Sep 2003, Jakob Eriksson wrote:
>
>> Am I missing something here? Currently, winetests.exe contains
>> crosscompiled tests, not MS Visual C - compiled ones. *)
>
> Well, we should handle this through the Makefiles. Also the output
> sho
Hi I've already submitted this bug to the wine bugzilla but I'm posting
it here as well 'cause... oh well you know.
Pls. look at the end of the message for .gifs
Bug 1689 follows:
I've got an application which purpose is to just reproduce the wine bug
I'm gonna explain below.
There is, basical
Jakob Eriksson <[EMAIL PROTECTED]> writes:
> I can see the benefit of running MSVC compiled tests too.
> Maybe we can include them too in winetests.exe somehow.
Two different builds should suffice, IMHO.
> Maybe I could do the output exactly like yours.
That would be nice. I am not too rigid,
ons, 03.09.2003 kl. 16.25 skrev Sukumar .S:
> I've one requirement for my company for which there is a need to
> understand wine source fully (there is a time constraint).
Now that's what I call optimism. Before taking on such a task, anyone
who can pull that off need to consider the risk of bein
OK,
Please give this a try -- it should fix it.
Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.360
diff -u -r1.360 listview.c
--- dlls/comctl32/listview.c1 Sep 2003 2
On Wed, 3 Sep 2003, Sukumar .S wrote:
> I've one requirement for my company for which there is a need to
> understand wine source fully (there is a time constraint). i was a windows
how tight is that constraint?
> developer moved to Linux two years back and have good/bit of knowledge on
> win
Dear Developers,
I'm sukumar from Chennai, India.
I've one requirement for my company for which there is a need to
understand wine source fully (there is a time constraint). i was a windows
developer moved to Linux two years back and have good/bit of knowledge on
win32 system programming (win
28 matches
Mail list logo
