Hi,
On Sunday 25 March 2007 16:39:01 Dan Kegel wrote:
> Here's a try at a 1.0 wish list:
> - Safedisc support
> - OpenGL child window problem solved for most common cards at least
> - Adobe CS2/8 era apps installing and working
> - Dragon Naturally Speaking 9 working (I'm selfish, I need that one
Hans Leidekker wrote:
> On Sunday 25 March 2007 16:39:01 Dan Kegel wrote:
>
>
>> Here's a try at a 1.0 wish list:
>>
>
> I would like to see Wine 1.0 'fake' some suitable version
> of Internet Explorer, say 6.
>
We almost have it. The main missing bit that causes apps not to find our
IE
Better yet to be able to set what version it fakes.
On 3/26/07, Hans Leidekker <[EMAIL PROTECTED]> wrote:
On Sunday 25 March 2007 16:39:01 Dan Kegel wrote:
> Here's a try at a 1.0 wish list:
I would like to see Wine 1.0 'fake' some suitable version
of Internet Explorer, say 6.
-Hans
On Sunday 25 March 2007 16:39:01 Dan Kegel wrote:
> Here's a try at a 1.0 wish list:
I would like to see Wine 1.0 'fake' some suitable version
of Internet Explorer, say 6.
-Hans
Stefan Dösinger wrote:
> Am Sonntag 25 März 2007 17:33 schrieb Phil Costin:
>> Also, just out of interest, would a working safedisc implementation
>> provide the necessary underpinnings to support the hexalock copy
>> protection system? (http://hexalock.co.il/)
> I think the needed infrastructure
On 3/25/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
Clearly there will always be "office" apps that don't work, the
question for the code freeze is whether we have all the pieces we
need; I don't think there's a major feature at this point that would
prevent typical office apps from working
> Essentially, they completely broke the rendering engine by hard-coding
> assumptions about where the camera would be into the driver. Move the
> camera slightly (such as in the developer version of 3D Mark), and
> everything is a garbled mess.
OK, I take the optimizations back, I didn't know wha
>
> OpenGL: I don't really know of the windowed opengl state, and the wined3d
> ->
> wgl move. Still planned?
>
OpenGL needs to get proper windowed opengl rendering support. The best route to
that seems to be by using opengl child windows. There's a patch for it but it
needs cleanups and then
"Dan Kegel" <[EMAIL PROTECTED]> writes:
> Alexandre wrote:
>> That's still the plan, yes. I'm mostly waiting for the games
>> support to stabilize; the other main areas, office apps and
>> installers, both seem in good enough shape at this point.
>
> I suppose it depends on your definition of "off
On Sun, 2007-03-25 at 18:43 +0200, Stefan Dösinger wrote:
> > Does anyone here know if the NVIDIA Windows drivers are still rigged
> > with regards to the various 3DMark suite of benchmarks? There was a
> > scandal a while back, and the company claimed to pull their special
> > hacks out, but then
On 3/25/07, Scott Ritchie <[EMAIL PROTECTED]> wrote:
On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote:
> - Mono integration working for non-toy apps
So, when do we need to start including mono as a build/install
dependency for Wine in our packages?
Once it works better. Right now it's reall
"Rolf Kalbermatter" <[EMAIL PROTECTED]> writes:
> While the current apporach certainly works fine as far as invoking the
> DC specific functions without a lot of checking about the type of DC
> that is involved and therefore has a straightforward interface in GDI32
> I think the matching of the ac
From: Stefan Dösinger <[EMAIL PROTECTED]>
To: Scott Ritchie <[EMAIL PROTECTED]>
CC: Tom Wickline <[EMAIL PROTECTED]>, wine-devel@winehq.org
Subject: Re: Game road to 1.0
Date: Sun, 25 Mar 2007 18:43:06 +0200
> Does anyone here know if the NVIDIA Windows drivers ar
Am Sonntag 25 März 2007 17:33 schrieb Phil Costin:
> Also, just out of interest, would a working safedisc implementation provide
> the necessary underpinnings to support the hexalock copy protection system?
> (http://hexalock.co.il/)
I think the needed infrastructure is the same, but of course we w
Am Sonntag 25 März 2007 18:17 schrieb Scott Ritchie:
> On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote:
> > - Mono integration working for non-toy apps
>
> So, when do we need to start including mono as a build/install
> dependency for Wine in our packages? Or should we be doing that
> already?
> Does anyone here know if the NVIDIA Windows drivers are still rigged
> with regards to the various 3DMark suite of benchmarks? There was a
> scandal a while back, and the company claimed to pull their special
> hacks out, but then they were caught again later doing the same thing.
> It'd be a s
On Sun, 2007-03-25 at 10:17 -0400, Tom Wickline wrote:
> On 3/25/07, H. Verbeet <[EMAIL PROTECTED]> wrote:
> > On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > > So which of the following things do we want for 1.0?
> > While nice to have, I don't think d3d10 or some of the more advanced
On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote:
> - Mono integration working for non-toy apps
So, when do we need to start including mono as a build/install
dependency for Wine in our packages? Or should we be doing that
already? It'd be nice to have it all working together by default.
Th
On Sun, Mar 25, 2007 at 05:31:03PM +0300, Timo Jyrinki wrote:
> Alexandre Julliard wrote:
> >And if we delay it a bit more maybe we can slip in Safedisc
> >support too...
>
> Regarding which, does anyone have more up-to-date code and/or
> information regarding Safedisc support, than what is curre
Alexandre wrote:
That's still the plan, yes. I'm mostly waiting for the games
support to stabilize; the other main areas, office apps and
installers, both seem in good enough shape at this point.
And if we delay it a bit more
maybe we can slip in Safedisc support too...
I would consider S
Also, just out of interest, would a working safedisc implementation provide
the necessary underpinnings to support the hexalock copy protection system?
(http://hexalock.co.il/)
Timo Jyrinki wrote:
> Alexandre Julliard wrote:
>> And if we delay it a bit more maybe we can slip in Safedisc
>> sup
On Sun, Mar 25, 2007 at 07:39:01AM -0700, Dan Kegel wrote:
> Alexandre wrote:
[removed list of many features wanted for 1.0]
Not that it matters, but it doesn't seem important to me what
features go into a 1.0 release. But something like a stable
branch could be something realy usefull for many us
Actually, something else that affects quite a few games is support for
.ani cursors.
Alexandre wrote:
That's still the plan, yes. I'm mostly waiting for the games
support to stabilize; the other main areas, office apps and
installers, both seem in good enough shape at this point.
I suppose it depends on your definition of "office apps".
Adobe Acrobat Pro and Quicken don't work
Alexandre Julliard wrote:
And if we delay it a bit more maybe we can slip in Safedisc
support too...
Regarding which, does anyone have more up-to-date code and/or
information regarding Safedisc support, than what is currently
on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ?
Am Sonntag 25 März 2007 15:13 schrieb H. Verbeet:
> On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > So which of the following things do we want for 1.0?
>
> While nice to have, I don't think d3d10 or some of the more advanced
> SM 3.0 features should block 1.0.
Agreed. Those features wo
On 3/25/07, H. Verbeet <[EMAIL PROTECTED]> wrote:
On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> So which of the following things do we want for 1.0?
While nice to have, I don't think d3d10 or some of the more advanced
SM 3.0 features should block 1.0. You already know my opinion on
br
On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
Hi,
In another thread Alexandre has mentioned to wait for game stuff to stabilize
before the 1.0 freeze. I think its time for another brainstorm of what
features are still missing which we want in 1.0. The DirectX Todo has a long
list but it
Hi,
I'm actually working on DirectPlay implmentation, i'm first fixing a bit of
thing around dplayx, so that we can use native dpwsockx (the dplay service
provider) with builtin dplayx. After that i'm going to reimplement dpwsockx
from scratch using the info from Kai Blins work on the protocol.
On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
So which of the following things do we want for 1.0?
While nice to have, I don't think d3d10 or some of the more advanced
SM 3.0 features should block 1.0. You already know my opinion on
broken drivers.
Things that aren't there, but IMO sh
Hi,
In another thread Alexandre has mentioned to wait for game stuff to stabilize
before the 1.0 freeze. I think its time for another brainstorm of what
features are still missing which we want in 1.0. The DirectX Todo has a long
list but it tends to be useless to me. And I see that it can use s
Alexandre Julliard wrote:
>I'm also hoping we can make some progress on the x11drv factorisation
>before the freeze, so that we don't need to change the interface too
>much to add the quartz driver later on, we'll see how that goes.
Have you some specific ideas about what you want to do in that
Yea, I agree with what you said, I didn't mean for my message to sound like
people were doing anything blatantly wrong, the fact is though, if we like
them or hate them from a development standpoint, people love these work
arounds as users, and, it's just the evolution of the community that will
m
On Friday 23 March 2007 20:26, Alexandre Julliard wrote:
> "Tom Wickline" <[EMAIL PROTECTED]> writes:
> > I see Wine 1.0 as a set of features that AJ has decided upon, once the
> > feature set is in the tree then a feature freeze will go onto effect..
> > Then one to six months of only bug fixes. T
"Tom Wickline" <[EMAIL PROTECTED]> writes:
> I see Wine 1.0 as a set of features that AJ has decided upon, once the
> feature set is in the tree then a feature freeze will go onto effect..
> Then one to six months of only bug fixes. Then wala 1.0 is born.
>
> At the last Conf if memory serves me c
On Thu, 2007-03-22 at 23:38 -0400, Tom Wickline wrote:
> Hello all,
>
> Just thought I would through in my $.02
>
> I see Wine 1.0 as a set of features that AJ has decided upon, once the
> feature set is in the tree then a feature freeze will go onto effect..
> Then one to six months of only bug
On Thu, 2007-03-22 at 16:25 +0100, Vit Hrachovy wrote:
> However, usage scenarios for automated SW installer applications offer far
> more.
>
> First, it somehow mirrors info from AppDB. It can display application
> usability for
> range of WINE versions and also make available application on ol
I have a request of these third party tool developers
Please add a link on your front page to the WineHQ PayPal account for Donations!
Thank You!
Tom Wickline
On Thu, Mar 22, 2007 at 10:03:46PM -0600, James Hawkins wrote:
> If developers working on projects such as Wine-Doors
> contributed to Wine, then the bugs would be fixed even faster.
I think that this is not necessarily (always) true, probably not
even most of the time.
Does a developer of e.g. W
On 3/22/07, Jan Zerebecki <[EMAIL PROTECTED]> wrote:
I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the
provisions detailed here are also compatible with his views of
Wine-Doors.
Something like Winebot could possibly save me much time while
testing and developing. I reinstalled certai
On 3/22/07, Bryan Haskins <[EMAIL PROTECTED]> wrote:
>
> If you are making it extremely easy for users to run with native dlls
> and hacky workarounds, then you are hurting Wine. Wine is still beta,
That's true... and people technically should only be using wine for the pure
sake of testing an
Hello all,
Just thought I would through in my $.02
I see Wine 1.0 as a set of features that AJ has decided upon, once the
feature set is in the tree then a feature freeze will go onto effect..
Then one to six months of only bug fixes. Then wala 1.0 is born.
At the last Conf if memory serves me
I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the
provisions detailed here are also compatible with his views of
Wine-Doors.
Something like Winebot could possibly save me much time while
testing and developing. I reinstalled certain applications or
workarounds countless times, automati
If you are making it extremely easy for users to run with native dlls
and hacky workarounds, then you are hurting Wine. Wine is still beta,
That's true... and people technically should only be using wine for the pure
sake of testing and helping fix usage. LEt's be honest, very few use it fo
On 3/22/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote:
For example Ubuntu Dapper Drake (6.06) will distribute and support Wine
0.9.9 for four years from now.
I suspect they will be willing to update Drake to wine-1.0 when we release it,
since it will be far, far superior to wine-0.9.9.
Automated
On 3/22/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
> >Given list of manual steps required to install Oblivion
> >http://www.uesp.net/wiki/Oblivion:Linux
> >this can be automated easily ...
>
> The problem that wine developers have with r
On Thursday 22 March 2007 16:25, Vit Hrachovy wrote:
> First, it somehow mirrors info from AppDB. It can display application
> usability for range of WINE versions and also make available application on
> older WINE versions.
>
> For example Ubuntu Dapper Drake (6.06) will distribute and support W
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote:
> >Given list of manual steps required to install Oblivion
> >http://www.uesp.net/wiki/Oblivion:Linux
> >this can be automated easily ...
>
> The problem that wine developers have with recipies
> like the one you cite is that most of the s
On 3/20/07, Kai Blin <[EMAIL PROTECTED]> wrote:
http://code.google.com/soc/wine/about.html
Like that?
Yeah. That was me attempting something resembling humor. GSoC is
exactly what I meant.
--tim
On Wednesday 21 March 2007 00:08, Tim Schmidt wrote:
> On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote:
> > The problem that wine developers have with recipies
> > like the one you cite is that most of the steps in
> > the recipe are there to work around bugs in Wine.
> >
> > ...
> >
> > That said
On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote:
The problem that wine developers have with recipies
like the one you cite is that most of the steps in
the recipe are there to work around bugs in Wine.
...
That said, I'm certainly in favor of helping users,
as long as it's done 'right', for so
Vit wrote:
WineBot (http://winebot.sandbox.cz) is a sort of lightweight
implementation of some core thoughts, but with command line based
interface and less dependencies. Both projects share some core ideas and
data file formats. WineBot goals are much smaller in scope than
Wine-Doors ones, goin
Dan Kegel wrote:
In fact complete Wine-Doors / Winebot projects can serve for this
purpose too - as a repository of automated WINE tests.
Yes, when I heard that Wine-Doors used autohotkey, I
realized the same thing.
(I gather winebot is part of wine-doors,
http://www.wine-doors.org/trac/browser
Vit wrote:
Dan Kegel wrote:
FWIW, a couple of us have been puttering away on a scheme
to make writing application regression testers easier.
AutoHotkey (http://www.autohotkey.com) seems to do very well.
I'm using it for automated installation of lots of Windows programs into
WINE bottles as an
Dan Kegel wrote:
Rob wrote:
I think the only viable way to drive for 1.0 is feature or applications
targets, with applications compatibility driving test cases and bug
fixing.
Yes indeedy. And the only reason I haven't jumped up
and posted a proposed list of applications to support
for 1.0 i
Rob wrote:
I think the only viable way to drive for 1.0 is feature or applications
targets, with applications compatibility driving test cases and bug fixing.
Yes indeedy. And the only reason I haven't jumped up
and posted a proposed list of applications to support
for 1.0 is that real app tes
I kind of agree with him too, Since we can't really just test every single
API, obviously, the best thing to do is setup a 1.0 test quite of sorts,
where you have either a ton of little applications trying things whether
theyre known to work or not, or one big wine made ap which tests as much as
w
Dave Bialac wrote:
My personal thought is that Wine should head in the direction of 100%
compatibility with a particular version of Windows. Anything that ran
on that version should run on Wine 1.0 with no problems. Any thoughts?
That just isn't going to happen any time soon. If we were 100%
Hi All
I've been following the list for about a year now, just reading and
learning. Through this process, I've come to wonder about the
following question -- what should be the goal for Wine 1.0? I know a
lot of development is focused around getting one particular
application or anothe
59 matches
Mail list logo