I want to make sure that this problem is well understood. Also to make it clear
that Wine differs from windows in this really important aspect.
For more details, you can refer to the following thread:
http://www.winehq.org/hypermail/wine-devel/2005/04/0426.html
It needs to be fixed at least on th
Peter Beutner wrote:
Yupp most of the code maybe already in ntdll.
But imo it is quite as ugly, from a design point of view, to call ntdll
functions from inside the ntoskrnl.
It should be the other way around, shouldn't it?
Sure, you just have to convince Alexandre that it's a good idea to move
Hi!
I have problems with writing files from wine (today's CVS). Typical example
is word95, which always writes something like:
Cannot access folder "F:\filename.doc
": unaccessible or protected by password
(in my local language, so it may be inaccurate).
There is a small problem with this stran
Juan Lang wrote:
What this misses is the most common status that causes us all to argue:
uncomitted, because Alexandre's not sure about it. Perhaps he has a gut
feeling that the approach is not right, but hasn't taken the time to
identify any particular flaw. Perhaps it merits additional though
Alexandre Julliard schrieb:
Peter Beutner <[EMAIL PROTECTED]> writes:
Any reasons given?
Stability is the obvious reason. And also of course the fact that we
have most of the code we need in ntdll already and none of it in
wineserver.
Yupp most of the code maybe already in ntdll.
But imo i
This of course points to another problem with the existing system - if a patch
has been rejected, it should be a necessary consequence that the submitter is
informed with reasons - they shouldn't have to be chasing up Alexandre to
find out if the patch was rejected or merely missed (which happen
> This of course points to another problem with the existing system -
> if a patch has been rejected, it should be a necessary consequence
> that the submitter is informed with reasons - they shouldn't have to
> be chasing up Alexandre to find out if the patch was rejected or
> merely missed (which
> This of course points to another problem with the existing system - if a
> patch
> has been rejected, it should be a necessary consequence that the submitter is
> informed with reasons - they shouldn't have to be chasing up Alexandre to
> find out if the patch was rejected or merely missed (w
Alexandre Julliard wrote:
You should provide your own handling of stubs inside ntoskrnl, like
ntdll does.
ntosknrl? And who's talking about ntoskrnl? This is an attempt to add
generic support for native nt applications, it's not a ntoskrnl specific
thing, and not all native nt apps do the
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "Hiji" <[EMAIL PROTECTED]> wrote:
>
> > As a user, I've been particularly happy about how
> Wine
> > has progressed. However, what is of GRAVE concern
> to
> > me is when patches that fix serious bugs aren't
> > applied; specifically, bug 3148.
"Hiji" <[EMAIL PROTECTED]> wrote:
> As a user, I've been particularly happy about how Wine
> has progressed. However, what is of GRAVE concern to
> me is when patches that fix serious bugs aren't
> applied; specifically, bug 3148. Even the patch
> submitter had to plead with this alias for someo
Detlef Riekenberg wrote:
dlls/msi/tests : package.c
... i Suggest that:
- all directories and files for tests should be created in
"%TEMP%\winetest"
- we modify "wine/tests.h" to get this path and
check for path and name overflows (MAX_PATH and nesting level).
"c:" could be readonl
--- Steven Edwards <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> wrote:
> > I'll grant you that we could possibly setup a TinderBox type of system
> > but I feel that would be very overkill right now and even TinderBox can
> > only detect problems after p
The only reason I had not made some of these comments earlier was that I knew
that they would not be well received, and that there would be at least some
unconstructive responses. A prerequisite for having a productive discussion
of this kind is being able to recognise the possible validity of a
Hello,
On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> wrote:
> I'll grant you that we could possibly setup a TinderBox type of system
> but I feel that would be very overkill right now and even TinderBox can
> only detect problems after patches get committed.
I don't know if everyone follows wine
> [...]
> > I suspect the current model is either at or near
> its limits. It would
> > certainly not cope with a significant number of
> commercial outfits putting in
> > a serious level of contribution, nor does it
> encourage them to make the
> > attempt.
>
> I can assure you that there are man
--- James Liggett <[EMAIL PROTECTED]> wrote:
> This is some excellent news! Kudos and keep up the
> great work :)
>
> James
I agree. This is freakin' awesome!
Hiji
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection arou
This is some excellent news! Kudos and keep up the great work :)
James
On Tue, 2005-09-06 at 21:21 +0100, Oliver Stieber wrote:
> I though it was about time I gave a status update on DirectX9/wined3d, so
> here goes.
>
> Short of a couple of bug fixes (one to shaders, and another that cause
On 9/2/05, Stefan Leichter <[EMAIL PROTECTED]> wrote:
> Is it possible to get the timestamps back into the mailing list archive? It is
> useful e.g. for regression testing to see when patches were committed to cvs.
Yeah, it's actually a showstopper for me too and I asked the same
thing. It's exac
I though it was about time I gave a status update on DirectX9/wined3d, so here
goes.
Short of a couple of bug fixes (one to shaders, and another that causes
some games to crash)
and a couple of patches that need resending (support for non-power2 textures in
warhammer 40k)
wined3d and d3d9 i
No, it is not possible.
On Fri, 2005-09-02 at 23:22 +0200, Stefan Leichter wrote:
> Am Mittwoch, 31. August 2005 01:30 schrieb Jeremy Newman:
> > The webserver is back online. There are still plenty of quirks to fix.
> > Feel free to bug me here on wine-devel about any issues that crop up.
> >
> H
Hi
After reading reading this commit,
> ChangeSet ID: 20009
> Added files:
> dlls/msi/tests : package.c
> Test creating a package.
> Patch: http://cvs.winehq.org/patch.py?id=20009
... i Suggest that:
- all directories and files for tests should be created in
"%TEMP%\winetes
Am Samstag, 3. September 2005 21:22 schrieb Jacek Caban:
> Changelog:
> Added file protocol implementation
Hello,
this patch breaks the cross compiling of the tests with mingw. Which is the
correct location of the class id?
Bye Stefan
make[3]: Entering directory `/usr/src/wine/wine-mingw/d
On Tue, 06 Sep 2005 18:19:08 +0200, Jean Magnan de Bornier
<[EMAIL PROTECTED]> wrote:
| Again I think this was covered in earlier posts but I seem to recall
wine
| not being able to control the recording level. I set it to a suitable
| level before starting NS IIRC and it got through to the
Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote:
> On Tue, 6 Sep 2005, Alexandre Julliard wrote:
>> Peter Beutner <[EMAIL PROTECTED]> writes:
>>
>>> Any reasons given?
>>
>> Stability is the obvious reason. And also of course the fact that we
>> have most of the code we need in ntdll
Le 05 septembre à 23:40:10 [EMAIL PROTECTED] écrit notamment:
| On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier
| <[EMAIL PROTECTED]> wrote:
>
[...]
>
| Again I think this was covered in earlier posts but I seem to recall wine
| not being able to control the recording level. I se
Le 06 septembre à 17:28:53 Francois Gouget <[EMAIL PROTECTED]> écrit notamment:
| On Tue, 6 Sep 2005, Jean Magnan de Bornier wrote:
| [...]
| > Sure these are quicker, thanks wino and François; actually I was pointing
| > at the fact that the need to kill all those wine-preloader in order to
| > w
On Tue, 6 Sep 2005, Jean Magnan de Bornier wrote:
[...]
Sure these are quicker, thanks wino and François; actually I was pointing
at the fact that the need to kill all those wine-preloader in order to
wineboot is very poorly documented, either in man wine or in the docs at
wineqh, so I had to fin
On Tuesday 06 September 2005 10:27, you wrote:
> Kuba Ober wrote:
> >On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote:
> >>Peter Beutner <[EMAIL PROTECTED]> writes:
> >>>Any reasons given?
> >>
> >>Stability is the obvious reason.
> >
> >Stability? It'd still be at most as unstable as a
Le 06 septembre à 16:26:24 Francois Gouget <[EMAIL PROTECTED]> écrit notamment:
| On Mon, 5 Sep 2005, [EMAIL PROTECTED] wrote:
>
| > On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier
| > <[EMAIL PROTECTED]> wrote:
| >
| >> As root, "ps ax | grep wine", and then looking at pid numbers, kil
Kuba Ober wrote:
On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote:
Peter Beutner <[EMAIL PROTECTED]> writes:
Any reasons given?
Stability is the obvious reason.
Stability? It'd still be at most as unstable as a native windows session, so I
don't see a big de
On Mon, 5 Sep 2005, [EMAIL PROTECTED] wrote:
On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier <[EMAIL PROTECTED]>
wrote:
As root, "ps ax | grep wine", and then looking at pid numbers, kill all of
the /usr/bin/wine-preloader processes (there were four or five of them),
one after the
Ivan Gyurdiev wrote:
Thanks for reporting this. In order for the logs of these types of
programs to make sense, you really need to give me one with
+ole,+olerelay,+seh,+tid options. I suspect it is the following bug
though:
I've attached the necessary logs to:
http://bugs.winehq.org/sh
Marcus Meissner wrote:
On Sun, Sep 04, 2005 at 02:17:06AM -0500, Robert Shearman wrote:
In newer InstallShields, there is a marshaled object that contains a
function with a VT_PTR -> VT_USERDEFINED( TKIND_ENUM ). This should be
treated as "int *", but is actually treated as "int". This is d
Ivan Leo Puoti <[EMAIL PROTECTED]> writes:
> @@ -469,8 +469,10 @@
> /* get the default entry point for a given spec file */
> static const char *get_default_entry_point( const DLLSPEC *spec )
> {
> +if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE && spec->characteristics &
> IMAGE_FILE_DLL)
On Tue, 6 Sep 2005, Alexandre Julliard wrote:
Peter Beutner <[EMAIL PROTECTED]> writes:
Any reasons given?
Stability is the obvious reason. And also of course the fact that we
have most of the code we need in ntdll already and none of it in
wineserver.
Just trying to move things forward an
On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier
<[EMAIL PROTECTED]> wrote:
As root, "ps ax | grep wine", and then looking at pid numbers, kill all
of
the /usr/bin/wine-preloader processes (there were four or five of them),
one after the other. Then as user, wineboot worked. Wonder
On Tue, 6 Sep 2005, Robert Lunnon wrote:
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote:
[...]
Having to pipe all the changes through one person limits scalability.
[...]
I must disagree, the LOTM (Lord Of The Manor) governance model may wor
--- Karsten Elfenbein <[EMAIL PROTECTED]> wrote:
That looks fine, thanks.
> Added A2R10G10B10 and D3DFMT_D24FS8 modes to all other functions.
>
> Karsten
>
> > -Ursprüngliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Stieber
> > Gesendet
Marcus Meissner wrote:
Personally I consider the WINE project fair in its patch acceptance policies.
IMHO it's also fair to call it Wine and not WINE, IIRC this was agreed on
before.
Ivan.
On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote:
> Peter Beutner <[EMAIL PROTECTED]> writes:
> > Any reasons given?
>
> Stability is the obvious reason.
Stability? It'd still be at most as unstable as a native windows session, so I
don't see a big deal with that. If wineserver and/or
On Tue, Sep 06, 2005 at 09:58:03PM +1000, Robert Lunnon wrote:
...
> I must disagree, the LOTM (Lord Of The Manor) governance model may work for
> an small outfit but wine has already outgrown it. I have two or three
> withheld patches which are absolute show stoppers for running wine under
> S
On Tue, Sep 06, 2005 at 01:46:21PM +0200, Andreas Mohr wrote:
> Hi,
>
> On Tue, Sep 06, 2005 at 11:32:05AM +0100, Ivan Leo Puoti wrote:
> > Peter Beutner wrote:
> >
> > >Any reasons given?
> >
> > Yes, he doesn't want driver in the wineserver.
>
> Well, that reasoning cannot remain without furt
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
> On Tue, 6 Sep 2005, Troy Rollo wrote:
> [...]
>
> > Having to pipe all the changes through one person limits scalability.
>
> This is far from being an issue with the current number of patches. By
> the time it becomes an issue I'm sure w
Hi,
On Tue, Sep 06, 2005 at 11:32:05AM +0100, Ivan Leo Puoti wrote:
> Peter Beutner wrote:
>
> >Any reasons given?
>
> Yes, he doesn't want driver in the wineserver.
Well, that reasoning cannot remain without further discussion if there
truly is a need for such a feature.
Either having a techn
Peter Beutner <[EMAIL PROTECTED]> writes:
> Any reasons given?
Stability is the obvious reason. And also of course the fact that we
have most of the code we need in ntdll already and none of it in
wineserver.
--
Alexandre Julliard
[EMAIL PROTECTED]
Huw D M Davies <[EMAIL PROTECTED]> writes:
> On Sun, Aug 28, 2005 at 12:04:41PM +0100, Huw D M Davies wrote:
>> Huw Davies <[EMAIL PROTECTED]>
>> Don't call LineTo while holding the gdi lock
>
> Is this one better?
I think it would be better to release the DC earlier on and then j
Peter Beutner wrote:
Any reasons given?
Yes, he doesn't want driver in the wineserver.
Ivan.
Uwe Bonnes wrote:
Was this discussed on wine-devel?
No, but you're welcome to try and convince him, even if I don't really think
it's possible.
Ivan.
Ivan Leo Puoti schrieb:
Peter Beutner wrote:
Why implement ntoskrnl as a seperate process plus inventing a new IPC
protocol to talk to it? As you said: "ntoskrnl for windows _is_ what
wineserver for wine.". So why not implement the needed ntoskrnl stuff
into wineserver?
Great idea, but Ale
> "Ivan" == Ivan Leo Puoti <[EMAIL PROTECTED]> writes:
Ivan> Peter Beutner wrote:
>> Why implement ntoskrnl as a seperate process plus inventing a new IPC
>> protocol to talk to it? As you said: "ntoskrnl for windows _is_ what
>> wineserver for wine.". So why not implement the
Peter Beutner wrote:
Why implement ntoskrnl as a seperate process plus inventing a new IPC
protocol to talk to it? As you said: "ntoskrnl for windows _is_ what
wineserver for wine.". So why not implement the needed ntoskrnl stuff
into wineserver?
Great idea, but Alexadre doesn't want drivers
Vitaliy Margolen schrieb:
We need ntoskrnl to run some subset of drivers on wine. Notably cd protection
drivers. They are not a hardware drivers, but a means to access something that
is not accessible from user space. So in a sense ntoskrnl is just a process to
run those drivers in, and send/rece
On Tue, 6 Sep 2005, Troy Rollo wrote:
[...]
Having to pipe all the changes through one person limits scalability.
This is far from being an issue with the current number of patches. By
the time it becomes an issue I'm sure we'll have switched to a
distributed repository model with different m
Hi,
On Tue, Sep 06, 2005 at 05:28:06PM +0900, Mike McCormack wrote:
>
> Andreas Mohr wrote:
>
> >Hmm, something seems to be missing here...
>
> The purpose of the test is only to prove that we can make a package. I
> have other tests that I will submit later that build on
> create_package_db
Andreas Mohr wrote:
Hmm, something seems to be missing here...
The purpose of the test is only to prove that we can make a package. I
have other tests that I will submit later that build on
create_package_db and package_from_db, but this test does something
useful as it is.
Mike
http://www.winehq.com/pipermail/wine-devel/2030-March/000355.html
Well, now we all know wineserver will still be around in 2030...
Seriously, this should be fixed (not wineserver, the list archive)
Ivan.
As Dmitry rightly pointed out, wine-devel is a good place to post stuff for help/comments/review, so
here is an (almost) full diff of my tree against cvs. Without going as far as making wineserver a
user mode ntoskrnl like mike_m suggested, this code allows kernel mode drivers to work decently in
Hi,
On Tue, Sep 06, 2005 at 03:21:55PM +0900, Mike McCormack wrote:
> ChangeLog:
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> * test creating a package
+res = MsiCloseHandle( suminfo);
+ok( res == ERROR_SUCCESS , "Failed to close suminfo" );
+
+
+res = MsiCloseHandle( hPackage);
+
On Mon, Sep 05, 2005 at 10:21:17PM +0400, Vitaly Lipatov wrote:
> Can anyone test PHP Expert Editor for install? It uses InstallShield
> and install loop at message "File access denied."
>
> http://www.ankord.com/download/phpxedit_33.zip
Installs fine here (except dialogbox at the end and that it
60 matches
Mail list logo
