Mike McCormack wrote:
oops. The macro functions for duplicating strings already exist, so
use them instead.
Mike
ChangeLog:
* implement ChangeServiceConfigA using ChangeServiceConfigW
Index: dlls/advapi32/service.c
Peter Riocreux [EMAIL PROTECTED] wrote:
The comment above SWP_DoOwnedPopups in dlls/x11drv/winpos.c suggests
that the only thing missing is what I *might* have fixed here,
therefore the patch also removes the FIXME and the WARN. It compiles
and doesn't break any behaviour I can test, but I am
Thorsten Kani wrote:
Nice Patch - looks good now!
i have changed the offsets and used SM_CXBORDER instead of SM_CXEDGE.
(According to MSDN, cxedge is used for 3D while cxborder is used for
Flat )
This seems to fix thedraw below issue. Visual Experience comes now
really near native.
I noticed
Dmitry Timoshkov [EMAIL PROTECTED] writes:
You have to write a test case and add it to existing ones in
dlls/user/tests/win.c to confirm that the patch is correct.
Is something that creates a tree of windows and then makes a parent
invisible and checks the visibility state of the children
On Wed, 20 Oct 2004 19:48:05 +0900, you wrote:
Hello,
Changelog:
Dmitry Timoshkov [EMAIL PROTECTED]
Tiny optimizations of bit testing operations.
Testing with gcc 3.3.5:
-BOOL min_or_max_box = (wndPtr-dwStyle WS_MAXIMIZEBOX) ||
-
Peter Riocreux [EMAIL PROTECTED] wrote:
You have to write a test case and add it to existing ones in
dlls/user/tests/win.c to confirm that the patch is correct.
Is something that creates a tree of windows and then makes a parent
invisible and checks the visibility state of the children
Rein Klazes [EMAIL PROTECTED] wrote:
From the C point of view these bit logics are identical. The compiler
finds that out easy.
Yes, I know. That's why the optimizations are tiny. I believe that
the code itself becomes more readable with my changes and makes it
not depend on the optimizations
On Wed, 20 Oct 2004 22:29:35 +0900, you wrote:
From the C point of view these bit logics are identical. The compiler
finds that out easy.
Yes, I know. That's why the optimizations are tiny. I believe that
the code itself becomes more readable with my changes and makes it
not depend on
On Wed, Oct 20, 2004 at 04:13:07PM +0200, Rein Klazes wrote:
On Wed, 20 Oct 2004 22:29:35 +0900, you wrote:
From the C point of view these bit logics are identical. The compiler
finds that out easy.
Yes, I know. That's why the optimizations are tiny. I believe that
the code itself
Hmm,
sorry- i meant SM_CYBORDER and SM_CYEDGE. (classical past_1:00am typo)
testing shows that using SM_CYBORDER instead of SM_CYEDGE affects
appearence only minimal.
if this bug only appears while using it under windows, it shouldnt be
really important.
Do you agree setting OFFSET_Y to zero is
Thorsten Kani wrote:
Hmm,
sorry- i meant SM_CYBORDER and SM_CYEDGE. (classical past_1:00am typo)
testing shows that using SM_CYBORDER instead of SM_CYEDGE affects
appearence only minimal.
if this bug only appears while using it under windows, it shouldnt be
really important.
--- Bill Medland [EMAIL PROTECTED] wrote:
In what MSDN? I presume you mean the msdn.microsoft.com site as at a certain
date.
it is stated that if nCount is 1,
Not in the MSDN CDs of January 2002; it is -1 there.
I guess you found a typo in MSDN
Oh, maybe the msdn on
Any reason this patch wasn't applied?
http://www.winehq.org/hypermail/wine-patches/2004/10/0167.html
I know it's big, but I hope the test cases help
demonstrate its correctness. Let me know if there's
anything else I can do to help a review.
Thanks,
--Juan
Juan Lang [EMAIL PROTECTED] writes:
Any reason this patch wasn't applied?
http://www.winehq.org/hypermail/wine-patches/2004/10/0167.html
It doesn't apply properly, please resend an updated version.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dmitry Timoshkov [EMAIL PROTECTED] writes:
Peter Riocreux [EMAIL PROTECTED] wrote:
You have to write a test case and add it to existing ones in
dlls/user/tests/win.c to confirm that the patch is correct.
Is something that creates a tree of windows and then makes a parent
invisible and
Walt Ogburn a écrit :
Hi,
Winedbg's watchpoints don't seem to work for me: when I try to watch a
memory location, winedbg responds that a watchpoint has been set at a
different, always constant location (I suspect this is actually in
winedbg's memory space). Nothing happens when the location I
I have been trying to make wine work properly with Solaris xlib and have been
experiencing a few stack overflow exceptions
eg
0009:Ret kernel32._LeaveSysLevel() retval= ret=7f86a7ba
0009:Ret user32.USER_Unlock() retval= ret=7f53f837
0009:Call
While looking at the WDG (and please don't count me in about arguing
whether it's WDG or WD'sG or WD'G), I came onto the Advanced Topics book
after the two big ones (Developing Wine and Wine Architecture)
I does seem very odd to me as it right now:
- it just contains random bits of information
Hi people,
I just tried to install the recent Wine-tarball (20041019) on my OpenBSD
3.6. First I had to remove kthread.c:275: the RFTHREAD flag. Then the
'make depend make' worked properly but the make install first fails
with:
/usr/bin/install -c serialui.dll.so
Hi Eric,
Thanks. That fixes the watchpoints, but introduces a couple of small
problems:
1) in dbg.y, break_add_watch_from_lvalue should take only one argument
(drop second argument)
2) in dbg.y, I have no minidump_write. Should this be replaced with
dbg_printf(%s\n, $2); ?
After
Hi again,
A better patch than previous
Changelog:
- beta implementation of HW Vertex Buffer support (using
ARB_vertex_buffer_object): locking/unlocking, creation, destruction
- some wined3d headers/interface extension
Todo
- Bind/Unbind on rendering (use exported APIs, see
I have discovered that IE6 gives a page fault, a first chance exception,
when re-creating Symptom 1 below. I have attaced the output of
winedbg. I am unable to interpret this file. As I said before, if
anyone wants me to do some troubleshooting or patch testing, I will be
more than happy to
Marcus Meissner [EMAIL PROTECTED] writes:
I think even tiny is an exaggeration. Gcc has been capable of doing
this for years and years. I'd be surprised if you could find a compiler
that could not, and still compile wine satisfactory.
I guess such changes are acceptable if it makes the
Sascha Hanse [EMAIL PROTECTED] writes:
I just tried to install the recent Wine-tarball (20041019) on my OpenBSD
3.6. First I had to remove kthread.c:275: the RFTHREAD flag. Then the
'make depend make' worked properly but the make install first fails
with:
/usr/bin/install -c
24 matches
Mail list logo
