On Tuesday 13 January 2004 10:50, Boaz Harrosh wrote:
No! it is there for a purpose.
OK. Thanks all for educating me!
-Hans
On Tuesday 13 January 2004 05:47, Chris Morgan wrote:
I'm trying to get some of the wine tests compiling and running under
windows, oleaut32 test specifically. I've got the project file built and
everything opens fine under visual studio 6. The only issue is that during
linking of the
Hi,
If you try to go to a WWN article from the status page's
they don't work.
example : Wine's fundamental architecture #154
=
http://www.winehq.com/site/status_wine?issue=154#Kernel%20Module%20/%20Shared%20Memory%20Revisited
the current link is:
a
Mike McCormack a écrit :
This closes bug 521, and removes a couple of wine_todos from the
regression test for pathes. The test for setting lastpart in both
GetFullPathNameA/W was wrong (would always pass).
for the record, I also sent a patch regarding (among other things) this
issue, which
Title: Re: WWN Links are busted
the current link is:
a
href="">
I think it should be:
href="">
sed -e s/href="">
---
Brian Vincent
Copper Mountain Telecom
[EMAIL PROTECTED]
Alexandre Julliard wrote:
There's no reason to reformat all of shell32. If a given function is
messed up you can fix it (in a separate patch), but otherwise it
doesn't really matter if all functions don't use the exact same style.
Proposal:
add source code formatting at check-in - with a
On Tue, 13 Jan 2004, Hans Leidekker wrote:
[...]
Let's see if I can sum up the issues. In Wine uuids are put in
a lib called libwine_uuid. It's called like that because a
libuuid already exists. Second thing is that in MinGW and MSVC
there are two separate libraries with uuids, uuid and
On Tue, 13 Jan 2004, Francois Gouget wrote:
this particular problem. However this should let msvcmaker generate the
right set of import libraries (currently it hard-codes the list of .lib
files to link to, including uuid.lib but not dxguid.lib).
For MinGW it would be harder though. This is
Dimitrie O. Paun [EMAIL PROTECTED] writes:
The way it should work is the following:
-- winemaker generates MinGW compatible Makefiles. In it, it
uses -luuid and -ldxguid to link to these things.
-- on MinGW, this will work just fine
-- under Wine, winegcc will translate this into
Eric Pouech [EMAIL PROTECTED] writes:
Mike McCormack a écrit :
This closes bug 521, and removes a couple of wine_todos from the
regression test for pathes. The test for setting lastpart in both
GetFullPathNameA/W was wrong (would always pass).
for the record, I also sent a patch regarding
Hmm I don't remember that one, it may have gotten lost in the vacation
backlog. Could you please resend?
here we go
A+
diff -u -N -r -x '*~' -x '.#*' -x CVS dlls/kernel38/Makefile.in dlls/kernel/Makefile.in
--- dlls/kernel38/Makefile.in 2003-12-06 16:09:08.0 +0100
+++
Hmm I don't remember that one, it may have gotten lost in the vacation
backlog. Could you please resend?
and by the way, this one got lost too
A+
Name: ntkrnl_37
ChangeLog:
- got rid of FILE_Dup2 export from kernel32
- move all dos handle related code into dlls/kernel32
License:
On Thursday 08 January 2004 17:51, Dimitrie O. Paun wrote:
On January 8, 2004 01:22 am, Robert Lunnon wrote:
Here are a buch of Solais compatibility patches for wine (Some but not
all of them). Within the enclosed tarball the diffs are structured
according to the wine cvs tree. There is a
On Wed, 14 Jan 2004, Robert Lunnon wrote:
It would be relatively easy to send a dozen or so emails though, providing you
don't want me to collect up the dependencies into a single e-mail
Well, a patch should be a logical atomic change, no matter how many files
it touches. You can't for
Robert Lunnon [EMAIL PROTECTED] writes:
There are quite a few patches in that kit, they are organised as separate
patches for each file and a description to make application easy. After
extracting you could construct a single liner that would apply the entire
kit.
Actually it doesn't make
I have just finished embelishing the cdrom driver to support solaris but I
have nothing to test it against. Can anyone recommend a good test program for
excercising CDROM ioctls ?
Thanks
Bob
Mike Hearn [EMAIL PROTECTED] writes:
The other reason it might have bounced is if we're not allowed to extend
WND, though as it's purely internal and not accessible from the APIs that
should be OK? I'm not sure how to do this otherwise without exporting the
currently locked window variable
On Tue, 13 Jan 2004, Alexandre Julliard wrote:
The current problem is that Wine itself is not built with winegcc so
this doesn't help.
Right. For some reason I've read winetest and understook winemaker :)
Sorry for the confusion. But we could build the tests with winegcc
right now, no? And
On Tue, 13 Jan 2004 13:39:48 -0800, Alexandre Julliard wrote:
Extending the WND structure is OK (though it doesn't seem necessary in
that case), but accessing it from x11drv is a violation of dll
separation. We still do that in a number of places but they will have
to be fixed, so we probably
Well, I used c:\windows\cdplayer.exe :) It works perfectly, in fact...
On Wed, 14 Jan 2004 07:40:04 +1000, Robert Lunnon wrote:
I have just finished embelishing the cdrom driver to support solaris but I
have nothing to test it against. Can anyone recommend a good test program for
excercising
Mike Hearn [EMAIL PROTECTED] writes:
Alright. It'd be nice if somebody who knew all the rules of DLL separation
would write them up somewhere. At the moment I basically have to guess.
Apologies if it's already written up or the rules are obvious to all
except me :)
Basically you can only use
On Tue, 13 Jan 2004 [EMAIL PROTECTED] wrote:
[...]
Ahh yes, this appears to be the issue. If I go to project
settings-link-object/library modules and add uuid.lib to the list
then the test compiles without many other issues. Shouldn't the
script be adding this to the .dsp/.dsw?
That's
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Right. For some reason I've read winetest and understook winemaker :)
Sorry for the confusion. But we could build the tests with winegcc
right now, no? And programs/* as well. We can't deal with DLLs in
winegcc, I'm a lazy bum, I admit :/
The main
Mike Hearn [EMAIL PROTECTED] writes:
On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote:
The current problem is that Wine itself is not built with winegcc so
this doesn't help. A possibility could be to rename the library to
libuuid but install it in /usr/lib/wine to avoid
It doesn't show up in the object/library modules list, maybe something is
wrong there?
Chris
On Tuesday 13 January 2004 07:33 pm, Francois Gouget wrote:
On Tue, 13 Jan 2004 [EMAIL PROTECTED] wrote:
[...]
Ahh yes, this appears to be the issue. If I go to project
Mike McCormack [EMAIL PROTECTED] wrote:
ChangeLog:
Tim Ferguson [EMAIL PROTECTED]
Mike McCormack [EMAIL PROTECTED]
* Port Tim Ferguson's ICCVID codec to Wine
Mike, could you put the iccvid sources at the same place
as msrle32 (dlls/msvideo) and resend the patch?
--
Dmitry.
Mike McCormack [EMAIL PROTECTED] wrote:
I asked Alexandre where it should go, and he said wine/dlls was an
appropriate place. I don't mind either way...
I don't mind either, but if the new iccvid code will be placed under
dlls/ then dlls/msvideo/msrle32 should be moved there as well.
--
27 matches
Mail list logo
