Felix Nawothnig wrote:
Dimi Paun wrote:
We need to get rid of that seperation - either the DIB should be
stored fully on X side (which would require to add some features to
X) or fully on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since you ne
To the PC reporters and journalists that this email gets sent to, this
should probably be sent to people on your lists, pending further
research on your part. I got this from the EFF (for those that dont
know, thats the Electronic Frontires Foundation, the guys that monitor
your privacy), and
On Sat, 23 Jul 2005, Felix Nawothnig wrote:
Dimi Paun wrote:
Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
I'd think that apps directly accessing the surface memory are either games or
do some other kind of realtime graphics so network transpare
Dimi Paun wrote:
Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
I'd think that apps directly accessing the surface memory are either
games or do some other kind of realtime graphics so network transparency
isn't worth anything there (since we'd ha
> The "real" DIB, used for GDI calls, is stored on X side but the DIB
> surface, used for direct access, is stored on Wine side and we need to
> keep them in sync by catching reads / writes to the DIB surface.
> We need to get rid of that seperation - either the DIB should be stored
> fully on X s
From: "Felix Nawothnig" <[EMAIL PROTECTED]>
> > You can't have it fully on the X side, since you need direct memory
access
>
> Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
> > (non-synchronized I might add) to the DIB data.
>
> MSDN says:
>
> Windows
Dimi Paun wrote:
We need to get rid of that seperation - either the DIB should be stored
fully on X side (which would require to add some features to X) or fully
on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since you need direct memory access
D
On Fri, 22 Jul 2005 16:32:17 -0400
"Dimi Paun" <[EMAIL PROTECTED]> wrote:
> From: "Phil Krylov" <[EMAIL PROTECTED]>
> > Added EM_GETZOOM and EM_SETZOOM RichEdit message handlers.
>
> > + case EM_GETZOOM:
> > +if (!wParam || !lParam)
> > + return FALSE;
> > +*(int *)wParam = editor->
From: "Phil Krylov" <[EMAIL PROTECTED]>
> Added EM_GETZOOM and EM_SETZOOM RichEdit message handlers.
> + case EM_GETZOOM:
> +if (!wParam || !lParam)
> + return FALSE;
> +*(int *)wParam = editor->nZoomNumerator;
> +*(int *)lParam = editor->nZoomDenominator;
> +return TRUE;
I
From: "Felix Nawothnig" <[EMAIL PROTECTED]>
> We need to get rid of that seperation - either the DIB should be stored
> fully on X side (which would require to add some features to X) or fully
> on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since y
Glenn Wurster wrote:
Our current DIB implementation is an ugly hack. We need a real DIB
implementation, either as a complete GDI engine in Wine or as an X11
extension.
But is it the DIB implementation that is really at fault here or is it
the fact that we are adding extra exceptions and can't b
On Friday 22 July 2005 19:34, Francois Gouget wrote:
@ cdecl ldap_search_s(ptr str long str ptr long) ldap_search_sA
-@ cdecl ldap_search_sA(ptr str long str ptr long)
-@ cdecl ldap_search_sW(ptr wstr long wstr ptr long)
+@ cdecl ldap_search_sA(ptr str long str ptr long ptr)
+@ cdecl ldap_search_
> Our current DIB implementation is an ugly hack. We need a real DIB
> implementation, either as a complete GDI engine in Wine or as an X11
> extension.
But is it the DIB implementation that is really at fault here or is it
the fact that we are adding extra exceptions and can't be sure what
the
Glenn Wurster wrote:
Comments? Suggestions?
Our current DIB implementation is an ugly hack. We need a real DIB
implementation, either as a complete GDI engine in Wine or as an X11
extension.
Some work has been done on a GDI engine in Wine by Transgaming a couple
of years ago but it wasn't
--- Dimi Paun <[EMAIL PROTECTED]> wrote:
> > > Also, accessing the magic strided, data, element, stride
> > > directly is very weird, and problematic. The casual user
> > > wouldn't know what hit him :)
> >
> > It's less problematic since if forces the code into a strict layout, why
> have extra
James Hawkins <[EMAIL PROTECTED]> writes:
> Hey,
>
> Is there anything wrong with this?
>
> Changelog
> * Add the WebBrowser implementation.
Yes, it doesn't build because of some missing header (hhctrl.h
IIRC). Also, splitting patches is good, but don't overdo it, if you
have a C file and its a
After looking at glibc nss code for a while, and also
trying to understand how wined3d/device.c code
updates pp* variables (it constructs the varname
from a string pattern, and updates it), it is my opinion
that macros are pure evil, and inline functions should
be used everywhere instead.
..that'
From: "Oliver Stieber" <[EMAIL PROTECTED]>
> Well, when the #if 0's are removed the whole lot should fit on a screen so
you can see the macro
> and it's usage quite clearly and it no longer looks like magic.
No, the _usage_ will always look like magic. It will magically use and
modify
var from the
I've been doing some debugging of the exception handler and have come
across a problem for which I'm not sure what the best solution is. It
involves an application using the ESP for something other than the
stack.
The current DIB code uses protection to detect when the application
modifies the DI
Oops, let me take back some of my advice:
> I think accepting both CRYPT_E_ASN1_LARGE and CRYPT_E_ASN1_EOD,
> along with a value that results in CRYPT_E_ASN1_EOD, would be a
> useful fix.
I should read my own comments. If it returns CRYPT_E_ASN1_EOD on WinME,
that means the test is just wrong on
Hi Dmitry,
On Sat, 23 Jul 2005 00:41:42 +0900
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
> What kind of hyphenation richedit needs? Would an automatic, not
> dictionary based algorithm suffice?
Actually I'm unsure if the original RichEdit implements any hyphenation
algorithm itself. However,
"Phil Krylov" <[EMAIL PROTECTED]> wrote:
Added some missing but useful items to the RichEdit TODO list.
+ * - full justification
+ * - hyphenation
+ * - tables
What kind of hyphenation richedit needs? Would an automatic, not
dictionary based algorithm suffice?
In 1996-97 I've developed and
On Fri, 2005-07-22 at 16:06, Felix Nawothnig wrote:
> Paul Vriens wrote:
> > every now and then one of the tests failed. Probably because a process is
> > not longer there.
>
> You could spawn a child-process in the test which would be more reliable
> (or you could query the current process - tha
--- Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> Hmm. I don't understand the code, but if I change (+) BYTE tooBig
> definition, then exceptions are gone, but return codes still differs in
> the output (|):
(snip)
> I thought if there may be some sense in tuning tooBig value, then could
> it b
* The log message from [1] says:
>
> By-pass the RPC runtime if possible when calling an STA by posting a
> message directly to the apartment window for it to process. Fixes a
> deadlock in InstallShield caused by having to create a thread when
> freeing an object that come
On Fri, Jul 22, 2005 at 12:08:58PM +0200, Alexandre Julliard wrote:
> Marcus Meissner <[EMAIL PROTECTED]> writes:
>
> > In 2001 when windows/property.c moved to dlls/user/property.c additionaly
> > EnumProps16 gained the ability to enumerate non-string atoms.
> >
> > This brings a 16 bit applicat
* On Fri, 22 Jul 2005, Juan Lang wrote:
>
> > But the bad thing is that after running small code chunk another calls
> > to CryptEncodeObjectEx() starts generating exceptions here.
>
> the error handling on Win9x wasn't as good as on XP.
Hmm. I don't understand the code, but if I change (+)
I'm still looking for someone to take over winrash development. It's
a sourceforge project written in c under visual studio 6. I can give
developer access and help to anyone interested.
Chris
On 7/22/05, Paul Walker <[EMAIL PROTECTED]> wrote:
> I just joined this list and noticed the nt servic
Paul Vriens wrote:
every now and then one of the tests failed. Probably because a process is
not longer there.
You could spawn a child-process in the test which would be more reliable
(or you could query the current process - that's what I do in the psapi
tests)...
Felix
Hi Saulius,
> But the bad thing is that after running small code chunk another calls
> to CryptEncodeObjectEx() starts generating exceptions here.
Hm, that's what I was afraid of, that the error handling on Win9x wasn't
as good as on XP. I'll probably just have to remove those tests, as I was
tr
On Fri, 2005-07-22 at 11:45 +0200, Alexandre Julliard wrote:
> Alexandre Julliard <[EMAIL PROTECTED]> writes:
>
> > It looks like the bug is with quotes in the middle of tokens then.
>
> Does this work for you?
Yep, that works.
--
Matthew Davison <[EMAIL PROTECTED]>
On Fri, 2005-07-22 at 09:36 +0200, Alexandre Julliard wrote:
> Matthew Davison <[EMAIL PROTECTED]> writes:
>
> > Without this patch, the INF parser in setupapi will strip any spaces
> > which are not inside quotes from an INF file. Windows will only strip
> > spaces at the start and end of each fi
I'm currently seeing the following, new warnings for
dlls/wined3d/drawprim.c:
drawprim.c: In function `primitiveConvertToStridedData':
drawprim.c:540: warning: unused variable `canDoViaGLPointers'
drawprim.c: At top level:
drawprim.c:702: warning: `draw_vertex' defined but not used
The f
> > Might not be easy.
> >
> > You have to add yourself to dlls/ntdll/file.c
> >
> > NtCreateFile, NtWriteFile, NtReadFile ...
>
> Last time I suggested that people were not happy, to
> say the least.
>
> What I had in mind is writing my own implementation of
> CreateFile and the like, that de
Brian Vincent wrote:
On 7/21/05, Paul Vriens <[EMAIL PROTECTED]> wrote:
Nothing better than reading the code. I've added a key
HKCU\Wine\Fonts\Replacements and a String Value "Marlett" with "Wine
Marlett" as the data. Now the buttons show up nicely.
Does that need to go in wine.inf?
* Log message from [1]:
>
> Juan Lang <[EMAIL PROTECTED]>
> - fix decoding of long-form data lengths
> - use exception handling in decoding
> - tests for these changes
One of added tests in the patch fails on winME:
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE
--- Marcus Meissner <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 19, 2005 at 05:06:47AM -0700, Damjan
> Jovanovic wrote:
> >
> >
> > --- Marcus Meissner <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Jul 19, 2005 at 01:14:20AM -0700, Damjan
> > > Jovanovic wrote:
> > > > I'd like to know if there a
Marcus Meissner <[EMAIL PROTECTED]> writes:
> In 2001 when windows/property.c moved to dlls/user/property.c additionaly
> EnumProps16 gained the ability to enumerate non-string atoms.
>
> This brings a 16 bit application I have here to crash in
> repne scansb es:(di), so it clearly expects get on
Alexandre Julliard <[EMAIL PROTECTED]> writes:
> It looks like the bug is with quotes in the middle of tokens then.
Does this work for you?
Index: dlls/setupapi/parser.c
===
RCS file: /opt/cvs-commit/wine/dlls/setupapi/parser.c,v
re
Matthew Davison <[EMAIL PROTECTED]> writes:
> The Trailing Spaces state strips ALL spaces outside of quotes, which is
> wrong and leads to a space being wrongly stripped from several
> (non-vital) lines in the IE6 installer.
No, the trailing spaces state doesn't strip anything if it's not the
end
Matthew Davison <[EMAIL PROTECTED]> writes:
> Without this patch, the INF parser in setupapi will strip any spaces
> which are not inside quotes from an INF file. Windows will only strip
> spaces at the start and end of each field/line.
This is supposed to be handled by the TRAILING_SPACES state
A tried to run Morrowind (it fails loading the outdoors).
I saw a message of unsupported D3DCMPFUNC. So I looked up MSDN and it
mentioned defaults, so I've added them. Not sure if they also need to be
in the d3d8/ directory too?
It didn't fix my problem, but it is probably still useful to have.
In
42 matches
Mail list logo