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 :-)
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
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
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 is lack of
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
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
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 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
broken
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 won't be
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 ?
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
Actually, something else that affects quite a few games is support for
.ani cursors.
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
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 currently
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.
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
SM 3.0
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? It'd
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
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 are still rigged
with regards
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 actual
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 really
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 they
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 office apps.
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 AJ
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 what
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 is the
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 correctly
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. Then wala
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
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 steps in
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 Wine
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 recipies
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
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
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,
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
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 and
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 certain
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.
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, 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 older
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 fixes.
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
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
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
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
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
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
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
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,
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,
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
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, I'm certainly
53 matches
Mail list logo
