Hi folks,
It seems that we are getting ever so closer to 0.9. Slow, but steady.
Looking at the TODO, it looks like upgrading is one of the big
showstoppers, in that it will affect (1) the end-user experience, and
(2) how we deal with the configuration.
So this seems like a good time to start discussing this topic, as we
need to eventually reach the elusive 0.9. This seems to be a difficult
topic, so we need to approach the problem well prepared. That is,
we need to first define (and agree) on what we need to solve here.
So after a tumultuous discussion on IRC, I decided to get the ball
rolling.
Intuitively, upgrading wine is simple to understand: once a new version
is installed, we need to get users in a state where they can use it.
While simple to state, this problem is complicated by the various corner
cases that can appear in Real Life (TM):
-- native vs. builtin DLLs handling
-- multiple Wine installations on a box
-- updating only some DLLs
-- integrating into the Unix environment
-- dealing with Windows software
We can also look at some important use-cases that we need to support,
but before we do, the following must hold true in all cases:
-- administrators should be able to install a new Wine on the
system easily with "rpm -U" (or equivalent).
-- the upgrade should not erase registry settings that are
managed by the user
Let's look at the use-cases:
A. Global Install
In this case, both Wine code, as well as applications are installed
globally, for all users to access. This is the most Unix-like setup,
but unfortunately the most difficult to support, due to the fact that
Win32 apps simply expect a different environment. Since we can't
control application's code, this setup may present some limitations,
but it may be sufficient for sites that need a limited set of
applications. For this to work, it is acceptable that we ship special
scripts that know about the applications that are supported, so that
they can work around inherent limitations in the applications
themselves. Users should transparently be able to use the new version
of wine, the next time they start wine.
B. Mixed Install
Here, Wine code is installed globally, but applications are installed
in the user's account. In a way is like (A) but with some additional
applications installed directly into the user's account. Same
requirements apply to this case as well.
C. Local Install
Both Wine code, as well as applications are installed locally, into
the user's account. The Wine code is still installed globally by the
administrator (as in A & B), but it is copied locally before it's
being used. An upgrade in this case may require an explicit action
by the user, so the upgrade can happen at a controlled time, when the
user desires it.
In all of the above, there is always state in the user directory. Thus,
it is imperative that the upgrade process makes sure that after the
upgrade, the user-private state is consistent with the new code base.
Also, any solution must take into account that the registry must be
created on the fly, as it is created when registering the DLLs.
Before we go any further, I'd like to ask everybody to contribute their
thoughts/requirements/desires so that we get a conprehensive view of
the problem we are trying to solve.
Thanks for reading this far!
--
Dimi.
I'm about to implement a set of keys that lets me enable disable traces
any time. Seems to me like it's a good idea, like that I can get traces
for exactly what I need. Especially when I'm faced with weird debugger
output that's 10 minutes into the game and I can't turn traces on to
begin with.
Is there another way, possibly existing, to do this?
Is this a really bad idea?
If people are interested I can post a patch later on today or tomorrow
with it. It'll be implemented in the x11 driver and calling the existing
wine_dbg_parse_options with a new options string. It can even be made a
commandline option to enable and disable that key combination (and
possibly the key combination could be set in wineconfig) but that's if
enough people are interested in the idea.
Thanks,
Andrei
Howdy,
Someone is needed for the period June 30-July 5 to handle moderation of
the Wine lists.
If you are willing to do it, please email me off list. Thanks.
On Tue, Jun 29, 2004 at 01:27:23PM +0200, Pierre d'Herbemont wrote:
> Hi!
>
> On non-i386 we have to define MSVCRT_div_t and MSVCRT_ldiv_t.
Please also add the appropriate tests to tests/headers.c.
--
Dimi.
>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes:
Aric> Changlog: return an error if the IUnknown pointer is NULL and dont
Aric> crash tested with win2k and this is proper behavior Index:
The test is welcome in the test suite...
Thanks
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> It turns out the reason they don't work on Fedora is because they don't
> work at all
No, wine segfaulted, so it probably wasn't a packaging related problem.
> wine.inf is in /usr/share/doc/wine-20040615 which is wrong,
> it needs to be in /usr/share/wine.
This is strange because I tested both RPMs on multiple versions of Mandrake
before releasing them. Anyway, new RPMs will be up soon.
Ivan.
Hi,
Ivans comment that the Mandrake RPMs didn't work on Red Hat/Fedora
surprised me, so after encountering a stuck Mandrake user for whom the
RPMs weren't working either on IRC I decided to check them out.
It turns out the reason they don't work on Fedora is because they don't
work at all - wine.inf is in /usr/share/doc/wine-20040615 which is wrong,
it needs to be in /usr/share/wine. As this file is in the wrong place Wine
refuses to start on a new users account.
Once I manually copied the file to the right place Wine worked just fine.
Could somebody please fix the Mandrake RPMs, and maintainers of other
packages please ensure you have details like this right.
thanks -mike
> -A few other people were in favor of saving it to support a
> +A few other people were in favour of saving it to support a
"The Americans are identical to the British in all respects except, of
course, language."
- Oscar Wilde
Brian
The builtin odbc32.dll basically simply proxies the underlying unix ODBC
provider (e.g. unixODBC or iODBC).
I have just discovered that somewhere in the compilation/link phase under
Windows some standard ODBC function calls somehow actually get translated
into direct registry calls. For example the SQLGGetInstalledDrivers call
actually gets translated into an OpenKey and EnumerateKey on the
HKLM/Software/ODBC/ODBCINST.INI/ODBC Drivers
So should we have code within the registry code that recognises access to the
ODBC tree when odbc32 is builtin and redirects it to the corresponding calls
to the unix ODBC manager?
--
Bill Medland
mailto:[email protected]http://webhome.idirect.com/~kbmed
Filip Navara <xnavara(a)volny.cz> writes:
> Indeed Dimtry was right about the cause of the balloon tooltips
> drawing issue. Here is the code for FrameRgn ported from ReactOS that
> actaully does the right thing.
I don't think you should modify the source region at all, even
temporarily; it could be in use somewhere else.
--
Alexandre Julliard
julliard(a)winehq.org