Vitaliy Margolen wrote:
> Since all of the 1.0 blocker bugs being pushed back, wine-1.0 release notes
> should list all of those as major known problems. Otherwise people will get
> a bad impression that wine-1.0 means more then less working release.
>
> Also release notes should mention that wi
Scott Ritchie wrote:
> In any case, we should note why we're making a release in the first
> place, and make it very clear that we believe Wine 1.0 to be the best
> version of Wine yet in all cases (ie, no regressions).
I'd disagree on "the best" part. Looking at bugzilla and forum people thing
t
I would agree and go further.
Wine has made Linux handicapped-accessible for a great number of people,
including me, who have mild repetitive-motion difficulties that make typing for
any length of time uncomfortable.
Many of the people who use Linux are programmers and are technically
proficie
Reece Dunn wrote:
> 2008/6/11 Vitaliy Margolen <[EMAIL PROTECTED]>:
>> In short - that after everyone's hard work and 15 years of development
>> wine-1.0 is just a release tag nothing more.
>
> I think that this is overly harsh. It's like saying that you should
> not celebrate a birthday, as that
>
> I propose we get rid of the page altogether, it's pretty much useless
> for figuring out how good Wine is. This is unfortunate, since it's
> often the first place people click.
>
> Thanks,
> Scott Ritchie
>
>
>
I found it very handy to track down details on mswsock the other day.
I suggest i
2008/6/11 Vitaliy Margolen <[EMAIL PROTECTED]>:
> In short - that after everyone's hard work and 15 years of development
> wine-1.0 is just a release tag nothing more.
I think that this is overly harsh. It's like saying that you should
not celebrate a birthday, as that is just you aging just a day
Austin English wrote:
> On Wed, Jun 11, 2008 at 5:59 PM, Zachary Goldberg <[EMAIL PROTECTED]> wrote:
>> Proposal: Revert the commit referenced in bug #11584 before this
>> Friday, so it can be tested in rc5. I think the weight of the
>> following is greater than breaking a test (making the test a
Hello.
I solved this problem. In my case wine couldn't be compiled with
"-malign-double" option. I compiled it successfully after I had removed
this option in my $CFLAGS and $CXXFLAGS.
--
All the best, Alexandrov Anton.
Adam Petaccia wrote:
> http://winehq.org/site/status is the website showing Wine's status on
> implementing various DLLs, but it hasn't been updated in almost a year!
> The information is not only old, but Wine has added new DLLs that aren't
> listed. With Wine approaching its 1.0 release, perhaps
Vitaliy Margolen wrote:
> Since all of the 1.0 blocker bugs being pushed back, wine-1.0 release notes
> should list all of those as major known problems. Otherwise people will get
> a bad impression that wine-1.0 means more then less working release.
>
> Also release notes should mention that wi
> Proposal: Revert the commit referenced in bug #11584 before this
> Friday, so it can be tested in rc5. I think the weight of the
> following is greater than breaking a test (making the test a todo for
> now would be a good idea I think).
The problem is that I added this broken PreLoad line(witho
On Wed, Jun 11, 2008 at 6:56 PM, Vitaliy Margolen
<[EMAIL PROTECTED]> wrote:
> In short - that after everyone's hard work and 15 years of development
> wine-1.0 is just a release tag nothing more.
I think this deserves more discussion but I am not quite ready. I'll
post a reply on Monday as an RFC
On Wed, Jun 11, 2008 at 5:59 PM, Zachary Goldberg <[EMAIL PROTECTED]> wrote:
> Proposal: Revert the commit referenced in bug #11584 before this
> Friday, so it can be tested in rc5. I think the weight of the
> following is greater than breaking a test (making the test a todo for
> now would be a g
On Tue, Jun 3, 2008 at 5:49 AM, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Stefan Dösinger <[EMAIL PROTECTED]> writes:
>
>> Am Montag, 2. Juni 2008 06:50:15 schrieb Vitaliy Margolen:
>>> This reverts commit 2d0016c5bc872afb562727278cfd341cea182600.
>>> Partially fixes bug 11584.
>> I think we
Since all of the 1.0 blocker bugs being pushed back, wine-1.0 release notes
should list all of those as major known problems. Otherwise people will get
a bad impression that wine-1.0 means more then less working release.
Also release notes should mention that wine-1.0 is not suitable for most
g
Hi,
Can we rename $WINEPREFIX/.update-timestamp to
$WINEPREFIX/update-timestamp? There's been times when I cleaned my
$WINEPREFIX directory by going into that directory and running rm
-Rf... except .update-timestamp didn't get removed. Then I run wine,
but wineboot is a bit confused and does not i
On Wed, Jun 11, 2008 at 12:01 PM, Vitaly Perov <[EMAIL PROTECTED]> wrote:
> Changelog:
> - shell32: test added. It check whether SHFileOperation could correctly work
> with input files mask '*.*'
>
+retval = SHFileOperationA(&shfo);
+ok(retval == ERROR_SUCCESS, "Expected ERROR_SUCCESS
>Does this work for you? When I apply the attached patch and run
>
>wine xcopy /?
>
>I get garbled German umlauts in the output (also tried with
>SUBLANG_NEUTRAL) . Is it the same for you?
>
>
Wine console applications output in the OEMCP (i.e. the DOS codepage
for the given locale) that is
Michael Karcher wrote:
> ---
> programs/xcopy/De.rc | 79
>
> programs/xcopy/rsrc.rc |1 +
> 2 files changed, 80 insertions(+), 0 deletions(-)
> create mode 100644 programs/xcopy/De.rc
>
>
> --
> So why are you adding the check that is not present on windows? What
> are th
> reasoning to have this if it clearly absent in native implementation?
As I understand it, native ddraw.dll(d3d7) has the check, while d3d8/d3d9 do
not. Thus he removed it from WineD3D to have the same behavior as nati
Good afternoon.
I tried to compile wine-1.0-rc3 and got this message:
--
../../tools/winegcc/winegcc -B../../tools/winebuild -shared
./acledit.specmain.o -o acledit.dll.so -lkernel32
../../libs/port/libwine_port.a
winebuild: Cannot read main.o
winegcc: ../../tools/winebuild/wine
Ulrich Hecht wrote:
> Hi!
>
> This fixes sound in Ootake (http://www.ouma.jp/ootake/). Looks like
> DSBPN_OFFSETSTOP is not always the last element.
>
> - /* DSBPN_OFFSETSTOP has to be the last element. So this is */
> - /* OK. [Inside DirectX, p274] */
> - /*
David Adam wrote:
> I sent a patch to removed these test earlier.
>
>
> So why are you adding the check that is not present on windows? What
> are th reasoning to have this if it clearly absent in native
> implementation?
>
>
> That's why I removed it form wined3d. I set the check i
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> "Louis Lenders" <[EMAIL PROTECTED]> wrote:
>
>> Hi, just thought dropping a note here so you'd know: the troubles reported
>> for
>> wine+fedora 9, now also affect fedora 8. Last saturday i did a 'yum update',
>> and
>> after that about all wine-a
I sent a patch to removed these test earlier.
>
>> So why are you adding the check that is not present on windows? What are
> th reasoning to have this if it clearly absent in native implementation?
That's why I removed it form wined3d. I set the check in ddraw, since only
ddraw checks it.
Dav
On Tue, Jun 10, 2008 at 10:24 PM, Jeff Zaroyko <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 8:49 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
>>> Descent FreeSpace: The Great War and Descent FreeSpace 2 fail to detect
>>> hardware acceleration through Direct3D when enumerating devices, th
26 matches
Mail list logo