On 9/26/06, Paul Chitescu <[EMAIL PROTECTED]> wrote:
On Tue, 26 Sep 2006, Dan Kegel wrote:
> >The new /O[peration] command line option allows to specify a shell
> >operation other than "open".
> Hmm. I don't see that option in the Win XP documentation:
>
http://www.microsoft.com/resources/docum
On Tuesday 26 September 2006 08:47, you wrote:
> The problem is that a version check is not reliable. For instance in case
> of a remote X session the version number for instance in case of the nvidia
> drivers can be 2.0 while most extensions aren't supported. For reasons like
> this we can't use
On 9/26/06, Paul Chitescu <[EMAIL PROTECTED]> wrote:
Changelog: start.exe: Implement /D option, add new wine specific feature
allowing to specify the shell operation name.
The new /O[peration] command line option allows to specify a shell operation
other than "open". This is very valuable for te
On 9/26/06, Tom Spear <[EMAIL PROTECTED]> wrote:
On 9/26/06, James Hawkins <[EMAIL PROTECTED]> wrote:
> On 9/26/06, Tom Spear <[EMAIL PROTECTED]> wrote:
> >
> > Just a quick side.. We have a component for MSI, why not make ones for
other
> > installer types as well, such as (at the very least) In
On 9/26/06, James Hawkins <[EMAIL PROTECTED]> wrote:
On 9/26/06, Tom Spear <[EMAIL PROTECTED]> wrote:>> Just a quick side.. We have a component for MSI, why not make ones for other> installer types as well, such as (at the very least) InstallShield, and
> possibly WISE?>MSI is a component of Window
On Tue, 26 Sep 2006, Dan Kegel wrote:
> >The new /O[peration] command line option allows to specify a shell
> >operation other than "open".
> > This is very valuable for testing or implementing actions from shell
> > scripts.
>
> Hmm. I don't see that option in the Win XP documentation:
> http:/
On 9/26/06, Tom Spear <[EMAIL PROTECTED]> wrote:
Just a quick side.. We have a component for MSI, why not make ones for other
installer types as well, such as (at the very least) InstallShield, and
possibly WISE?
MSI is a component of Windows and thus Wine. Installshield and WISE
are proprie
On 9/26/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
I think the new 'installer' keyword is on every bug that needs it now.
http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keywords=installer%2C+download&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
The new /O[peration] command line option allows to specify a shell
operation other than "open".
This is very valuable for testing or implementing actions from shell scripts.
Hmm. I don't see that option in the Win XP documentation:
http://www.microsoft.com/resources/documentation/windows/xp/all
Miko?aj Zalewski wrote:
> I'm afraid this is worse than it was - if a separator will happen to
> be longer than 7 characters plus NUL you will write part the end of the
> buffer (the buffers in FormatInt and FormatDouble are 8 characters
> long). If you really want to support strings of any leng
On Tuesday 26 September 2006 22:55, Jeremy White wrote:
> 1. We can write a utility that lets us compare a winehq commit
> message to a wine-patches email and see if there is a 'match'.
> 100% isn't required, but some nice non zero number is.
>
> A key requirement is t
Andrew Talbot wrote:
I am about to submit another try, to see what people think. This time I'm
using GetLocaleInfoW() twice for each buffer: once, to determine the size
needed, and again, to actually get the locale info.
I'm afraid this is worse than it was - if a separator will happen to
b
I wil be looking msxml.
On 9/26/06, Dan Kegel <[EMAIL PROTECTED]> wrote:
I think the new 'installer' keyword is on every bug that needs it now.
http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keywords=installer%2C+download&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=
Miko?aj Zalewski wrote:
> Andrew Talbot wrote:
> I've wrote that code and forgot that sizeof(parameter array) is the
> size of a pointer. The current code will actually work as in current
> wine there is no locale that has more than one character (plus the NUL
> terminator) for the decimal or th
I think the new 'installer' keyword is on every bug that needs it now.
http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keywords=installer%2C+download&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
shows 94 downloadable apps with keyword 'insta
Andrew Talbot wrote:
Dan Kegel wrote:
BTW the way you define the new size, as a magic constant, seems
bad. Can you use 4 * sizeof(WCHAR), or whatever, instead of 8?
And even then, the '4' seems almost as bad.
- Dan
Yes, I did feel uneasy about using a magic constant, I must admit. A
> This last check is pointless. If perf is NULL, we bail out and return
> NULL a few lines up. Also, please add a test showing that native does
> not crash if a NULL perf is sent in. It's weird, but we need to be
> consistent with native, as some apps depend on such a crash.
>
Whoops! Thanks,
On Tue, Sep 26, 2006 at 03:04:47PM -0500, Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 9ae4e8d98efc952918bcdae86b2f640c4b062a3b
> URL:
> http://source.winehq.org/git/?p=wine.git;a=commit;h=9ae4e8d98efc952918bcdae86b2f640c4b062a3b
>
> Author: Alexandre Julliard <[EMAIL PR
On 9/26/06, Andrew Talbot <[EMAIL PROTECTED]> wrote:
Changelog:
cabinet: Fix NULL pointer dereference (Coverity).
diff -urN a/dlls/cabinet/fci.c b/dlls/cabinet/fci.c
--- a/dlls/cabinet/fci.c2006-09-12 23:59:28.0 +0100
+++ b/dlls/cabinet/fci.c2006-09-26 18:27:03.00
Eric Pouech wrote:
I don't end up with a gdb prompt. It is just stuck there.
yeah, that's a bug. I'm working on it
it should be fixed in current CVS
A+
Hi,
throught a problem in winedbg i found out that NtReadVirtualMemory has a
problem, when reading into a invalid local buffer.
it uses wine_server_set_reply( req, buffer, size ); to read the data supplied
by the server directly into application memory of unknown state.
when the read call hits ba
"James Hawkins" <[EMAIL PROTECTED]> writes:
> +static const WCHAR insert_fmts[][100] =
> +{
> +{'I','N','S','E','R','T',' ','I','N','T','O',' ','`','%','s','`','
> ','(',' ',0},
> +{'`','%','s','`',',',' ',0},
> +{' ',')',' ','V','A','L','U','E','S',' ','(',' ',0},
> +{'\'','%','s
Am Dienstag 26 September 2006 18:03 schrieb H. Verbeet:
> On 26/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > I think we should switch to NP2 repacking by default(and fix it if it is
> > broken), with that we can offer the correct pitch without the NPOT
> > extension too.
>
> Hmm. Personall
On 26/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
I think we should switch to NP2 repacking by default(and fix it if it is
broken), with that we can offer the correct pitch without the NPOT extension
too.
Hmm. Personally I consider repacking a hack for broken games. I'm not
sure if those e
Accepted patches will appear in the wine-cvs mailing list.
Patches with obvious problems may receive a response on wine-devel.
Some patches may not receive any response. In this case, your patch
maybe considered 'Not Obviously Correct', and you can:
* check the patch over yourself, and thin
On 26/09/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
...but this is really a theoretical argument. This is a framework mostly
written by me to begin with, so the chances of breaking it are
essentially zero. If it does get broken, the damage factor will be very
low - it won't test as well as it u
I didn't respond to Alexandre's point earlier, but wanted to now:
> To the private email issues, Alexandre replied:
>
> There are a fair number of such cases, yes. Not so much the bad
> patches but the corrupted/mangled/doesn't apply patches; I don't want
> to fill wine-devel with "this patch is
> Shouldn't the test be about alignment, rather than the exact size?
> I that case the power-of-two stuff shouldn't matter either, as long as
> it's properly aligned. I do have an initial patch for native NPOT
> support, but it will (of course) only work on cards that support the
> relevant extensi
H. Verbeet wrote:
On 26/09/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
change I'm interested in. However, I'm not sure why that would be better
- it would accomplish the exact same thing in twice the amount of time.
Well, there are two things I can think of right away:
- It makes thing easier
Robert Lunnon <[EMAIL PROTECTED]> writes:
> Well thats at least a reasoned response, even if I don't agree with the
> reasoning. But again you simply miss the point. I don't care that Alexandre
> doesn't move my patches (because its not true that he doesn't) and since I
> now have a patch mana
The problem is that a version check is not reliable. For instance in case of a
remote X session the version number for instance in case of the nvidia drivers
can be 2.0 while most extensions aren't supported. For reasons like this we
can't use version checks and should only detect extensions.
R
On 26/09/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
change I'm interested in. However, I'm not sure why that would be better
- it would accomplish the exact same thing in twice the amount of time.
Well, there are two things I can think of right away:
- It makes thing easier to review
- It he
Troy Rollo wrote:
> As I speculated, the reason the PPC64 Patchwork example was so out of date
> was
> that the PPC64 list had been folded into the vanilla PPC list, however the
> big problem right now is that Patchwork is "extra work" for maintainers, so
> right now they don't want to use it.
Hi,
> > Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does
> > the spec. I don't know what exactly uses the min_max form. Is this a
> > typo?
> Apart from the blend_minmax typo, it appears to be me this patch has
> some other problems.
>
> >> This patch changes the detecti
Alexandre Julliard wrote:
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
Changelog:
==
1) Abandon central memory allocation, and the tracking that involves.
Write a setup() and teardown() handler for each test, and use heap
allocation.
2) Make the main test function configure test argu
On Tuesday 26 September 2006 03:21, Roderick Colenbrander wrote:
> Vendors should still
> advertise GL_ARB_imaging for backwards compatibility if they do support 1.4
> or higher but ATI and friends don't :(
Compliant implementations are not required to advertise an extension if they
report a vers
On Tuesday 26 September 2006 19:35, Mike McCormack wrote:
> >>Since you know better, how about maintaining your own Wine tree and
> >>showing us how it's done?
> >
> > Self evidently thats what I have to do until some core functionality
> > patches find their way into WineHQ wine. It's not particul
Since you know better, how about maintaining your own Wine tree and
showing us how it's done?
Self evidently thats what I have to do until some core functionality patches
find their way into WineHQ wine. It's not particularly hard, but it is time
consuming to manage merge conflicts.
It's v
Jan Zerebecki <[EMAIL PROTECTED]> writes:
> diff --git a/dlls/user/winpos.c b/dlls/user/winpos.c
> index 6bc9056..e78f484 100644
> --- a/dlls/user/winpos.c
> +++ b/dlls/user/winpos.c
> @@ -152,7 +152,20 @@ UINT WINAPI ArrangeIconicWindows( HWND p
> */
> void WINAPI SwitchToThisWindow( HWND hwnd
Ivan Gyurdiev <[EMAIL PROTECTED]> writes:
> Changelog:
> ==
> 1) Abandon central memory allocation, and the tracking that involves.
> Write a setup() and teardown() handler for each test, and use heap
> allocation.
>
> 2) Make the main test function configure test arguments.
> Replace
On 9/26/06, Troy Rollo <[EMAIL PROTECTED]> wrote:
And add "|hi link cCommentL cError" to have C++ comments hilighted as errors,
giving:
autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8 softtabstop=4
shiftwidth=4|hi link cCommentL cError
Thanks! I put that up on the Wiki too.
F
On 9/26/06, Troy Rollo <[EMAIL PROTECTED]> wrote:
On Monday 25 September 2006 19:47, n0dalus wrote:
> At the bottom of my ~/.vimrc (create it if it doesn't exist):
> if !exists("loaded_vimrc_autocmd")
> let loaded_vimrc_autocmd=1
> autocmd BufNewFile,BufRead /data/wine/* set expandtab tab
On 26/09/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
To verify that the 32 bit alignment is true for 1x1 textures too.
+/* test is deactivated until out np2 support doesn't report
the full power of 2 pitch to the app */
+todo_wine ok(lockedRect.Pitch == 4, "Got pitch %d, exp
On Tuesday 26 September 2006 09:34, Troy Rollo wrote:
> On Monday 25 September 2006 19:47, n0dalus wrote:
> > At the bottom of my ~/.vimrc (create it if it doesn't exist):
> > if !exists("loaded_vimrc_autocmd")
> > let loaded_vimrc_autocmd=1
> > autocmd BufNewFile,BufRead /data/wine/* set e
44 matches
Mail list logo
