"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.
-
"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.
On January 13, 2004 09:46 pm, Robert Lunnon wrote:
> +#if !defined sun
>*mtu = ifr.ifr_mtu;
> +#else
> + *mtu=ifr.ifr_metric;
> + #endif
The #endif is not properly indented, any special reason?
--
Dimi.
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
> > settings->link->o
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 c
"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
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?
Tha
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 conflicts. This will
> require winegcc and win
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 onl
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
> excercisi
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 probab
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
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 p
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 examp
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
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 variab
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
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:
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
+++ dlls/kernel/Makefile
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?
I'm having great troubles compiling the test against vs6 he
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
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 al
"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 th
On Tue, 13 Jan 2004, Dimitrie O. Paun wrote:
> 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 dxgu
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
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 dxg
Title: Re: WWN Links are busted
> the current link is:
>
> 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 twist.
On Tue, 2004-01-13 at 06:56, Tom wrote:
> 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 i
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:
#154
when I think it should be:
#154
Jeremey N i
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 ol
No! it is there for a purpose.
When doing winelib apps. The actual app is a shared library. Therefor
the compiler will not warn about missing symbols since they can be
resolved on load time by the running process. What the check-link stage
does, is compile the winelib as an ELF executable. to se
33 matches
Mail list logo
