't think either
is fine, so I come to the list for help.
Thanks!
Regards,
Felix Yan
signature.asc
Description: This is a digitally signed message part.
Kovács András wrote:
This patch is needed, because DirectX 10 is Vindows Vista only feature.
Nothing wrong with adding Vista to the list but how is this needed? You
don't want to disallow usage of dx10 unless Vista is selected, do you?
Felix
ap.c). I
don't really see the point.
want a separate physDev pointer for it, you'll need to maintain state
for DIBs too.
Well, we have a couple of DIB-dependent members in BITMAPOBJ - I'd put a
pointer to this state there. I admit this isn't really clean though.
Felix
itmap = handle;
dc->flags &= ~DC_DIRTY;
SetRectRgn( dc->hVisRgn, 0, 0, bitmap->bitmap.bmWidth, bitmap->bitmap.bmHeight);
diff --git a/dlls/gdi32/dibdrv.c b/dlls/gdi32/dibdrv.c
new file mode 100644
index 000..e4a216e
--- /dev/null
+++ b/dlls/gdi32/dibdrv.c
@@
t implementing one function at a time,
touching nothing but dibdrv.c.
So far so good. I did all those steps (except 3., I hacked around that
in my local tree) in a clean way and it works nice (for 6. I implemented
SetPixel() and tried that with a test-app).
I attached patches for the steps 1 2 and 4 so you can see where this is
going.
Comments?
Felix
Byeong-Sik Jeon wrote:
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL, error, 0,
-(LPTSTR) &lpMsgBuf, 0, NULL);
+lpMsgBuf, 0, NULL);
This patch is wrong. When FORMAT_MESSAGE_ALLOCATE_BUFFER is used
For
Stefan Dösinger wrote:
Some of them should technically be ERRs because we tell the application that
we do not support those features, so they should never be used.
Application bugs shouldn't trigger ERRs, Wine bugs should.
Felix.
Bill Medland wrote:
Can someone remind me how we used to set the debug channels back in late
2004?
wine --debugmsg +relay ...
Or maybe it was -debugmsg?
Felix
there are many nice free & libre cross-platform alternatives
to the MS office suite there is just not much incentive to get it to run
or keep it running. Games OTOH...
Felix
Felix Nawothnig wrote:
---
dlls/gdi32/tests/font.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
Anything wrong with this patch?
Duane Clark wrote:
On a Matrox G550, Win2k, crosscompiled on Linux with MingW:
I:\dlls\d3d8\tests>d3d8_crosstest texture
texture.c:122:texture caps: 0x41c7
texture.c:110:pool=0 hr=0x8876086c
texture.c:110:pool=1 hr=0x8876086c
texture.c:110:pool=2 hr=0x8876086c
texture.c:110:pool=3 hr=0x0
unning a box with an MGA and Windows installed
as I'd have to reconnect my CDROM drive, steal a HDD from my brother and
install Windows first.
Felix
Not tested under Windows (does _anyone_ besides me have a Matrox? :) -
would be nice if someone with either an MGA or an really ancient GPU
could run the test on windows (if the pool=0 trace has an hr!=0 you got
one of those ancient cards :). CCing to wine-devel for that reason.
---
dlls/d3d8/
#x27;t change GLE on success. Some do but most often the
behaviour is undocumented or changed between 9x/NT. You should check the
return value which usually is either 0 or -1 (depends on the API) on
failure.
Felix
Someone sent a patch to implement that function one or two weeks ago.
Didn't get commited though.
Felix
revising my patches...
Felix
Note that I don't change the notifications being passed or anything of
their context (with the exception of the GDI context in the postpaint
notification - but the GDI context should be saved & restored in between
anyway, see the failing test I commited a few days ago) so I can't
imagine how this could break anything.
Felix
Felix Nawothnig wrote:
Well - yes. But other controls do this too (statusbar for example) and
considering all the stuff we do during refresh this is hardly a
bottleneck. And even if it is we should optimize this codepath in gdi32
instead (by caching solid brushs for example).
...looking at
the full row and the subitems on top of it but I'd
prefer to _simplify_ the code, not add more hacks).
Felix
e compatibility
or can we just use IDL even if MS didn't?
Felix
in the manifest file? If what you say about 5.82 is
true your patch is correct though ofcourse.
Felix
Chris Morgan wrote:
What would the purpose of having untested applications in the appdb
be? Users would search for the app and find that it shows up but then
find that it doens't work.
At which point the application would qualify as been tested, no?
Felix
{
once = 1;
FIXME("MB_USEGLYPHCHARS not supported\n");
}
+#endif
If you implemented MB_USEGLYPHCHARS just remove the FIXME. Don't submit
dead code - git will remember all revisions...
Felix
e/whatever will get
you an implicit typecast which makes the compiler generate any necessary
conversion.
See http://c-faq.com/null/
Felix
Detlef Riekenberg wrote:
@@ -325,9 +328,15 @@ HRESULT DSoundRender_create(IUnknown * pUnkOuter,
LPVOID * ppv)
pDSoundRender->pClock = NULL;
pDSoundRender->init = FALSE;
pDSoundRender->started = FALSE;
... there is no need to clear it again.
However, note that NULL is not always all
Jan Zerebecki wrote:
cs is never NULL at that point.
Where should it be checked for NULL, then? Or what does it prevent to be
NULL?
cs == lParam. And this code is inside if (lParam != NULL).
amp; HIWORD(cs->lpszName))
cs is never NULL at that point.
Felix
1989
| Ty Coon, President of Vice
Felix
ract away the actually copying in a subroutine).
Felix
ml-archives would be nice (with
integrated search, no silly month-splits and... well... a somewhat
prettier design IMHO. Gmane is there but I usually end up using google
on the winehq archives though...
Felix
Francois Gouget wrote:
Someone has defaced Wine's Wiki frontpage.
Also I have either forgotten my password or the user accounts don't
work anymore. Could someone look into this?
Reverted it (no idea about the accounts, I was still logged in).
l the user32 classes,
only some were copied over to comctl32. Anyway, it works "fine" know.
Well. Actually it doesn't even initialize without some stubs but it
runs. I have a native edit control in wine for the first time since 9x
times eh? :)
Felix
to account.
I see your point. However, since the function you are implementing is in
kernel32 anyway you could abstract it away and make both functions
(CopyFile and ReplaceFile) call some internal function. That way you
would get rid of the locking completly which is argueably somewhat ugly.
Felix
ing.
I've tried to just remove registration of the classes from our user32
and use native comctl32 6 (which otherwise works nice) but no success.
So, any idea how Windows makes comctl32 register the user classes?
Felix
(CC-ing wine-devel again)
Erich Hoover wrote:
The "right" way would probably to do the copying yourself by
read/write.. but I dunno.
Except that it would ignore the permissions issues that have already
been coded into the copy routines (and any updates that may eventually
No, CreateFile (and
t bad happens? If the function which failed already set LE you
should probably keep it...
Felix
Erich Hoover wrote:
I assume you're referring to the file existence check and file delete,
followed by the actual copy and move. I implemented these checks in
this manner in order to provide error codes consistent with the
documentation. I am not incredibly familiar with the Wine internals,
Erich Hoover wrote:
Real Name:
Erich Hoover
Description:
Implements the functions ReplaceFileA and ReplaceFileW in kernel32
(Bug #7544). Also provides conformance test code to ensure proper
functionality.
Changelog:
kernel32: Implement ReplaceFileA/ReplaceFileW
Your patch seems
d there be to speed it up?
(I admit I didn't really read the code. :)
Felix
Fabian Bieler wrote:
The only way I know of to test this behavior would be to pass a NULL pointer
as callback. Naturally this results in a segfault without this patch. Is this
okay for a testcase?
Use if(0) instead of todo_wine then (and let the second patch, which
fixes the bug, remove the i
Fabian Bieler wrote:
Windows silently ignores NULL pointers supplied to SendMessageCallback as
callback function.
A testcase would be nice.
Felix
And while we're at it, there seems to be some misconfiguration of the
httpd (for quite some time), as the following URL generates an 500
Internal Server Error:
http://test.winehq.org/data/200702241000/2003_W2K3-SE-IE7/ntdll:error.txt
Hi. A new crossbuild appeared today but the site shows all tests
failing. See http://test.winehq.org/data/200702241000/
Felix
right now the
WM_PAINT/WM_NCPAINT/WM_ERASEBKGND _are_ sent - just not in between but
after WM_PAINT processing (which causes the flickering).
I agree that the "hdr" flag is kinda hackish, any idea how to properly
abstract away what I'm trying to do?
Felix
- but maybe someone will find it useful nevertheless:
http://users.holycrap.org/flexo/spy.rb
Use like:
$ WINEDEBUG="+message" wine foo.exe 2>log
$ ruby spy.rb log
Felix
Louis. Lenders wrote:
+ if( IsBadReadPtr( bits, nrsrcbytes)) return 0;
AFAIK you should never use that function since it introduces a race con.
Try using an exception handler around the memory access itself.
Felix
Linux)
syscalls as it wants.
Felix
Kovács András wrote:
+BOOL WINAPI RegisterRawInputDevices(PRAWINPUTDEVICE pRawInputDevices, UINT
uiNumDevices, UINT cbSize)
+{
+int i;
Please keep the indentation style of the original file.
Andrew Talbot wrote:
I've seen this function represented with the first two parameters
constified. Is anyone aware of a more const-correct version in the field
than the one Felix mentions?
Sorry about that, seems they changed the declaration in the new headers
- I misinterpreted your co
2/msg? Wouldn't help object size but I don't think a
shared lib would be worth it...
Felix
Andrew Talbot wrote:
-BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock,
+BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock,
This is wrong - in the PSDK headers it's LPSTR (the first parameter
should be const though).
Felix
[EMAIL PROTECTED] wrote:
This sounds almost perfect. I think the counterpoint raised by James
Hawkins would be adequately addressed by adding a winecfg option as
follows:
Since we want winecfg to be gone in the long-term a registry key alone
would probably do fine.
Felix
didn't really look at your new tests but the second of those tests you
removed failed ("got 1" IIRC) on Windows (XP) because we don't create a
parent window (and because the 21 is wrong. Should be 22 IIRC) - native
comctl32 sometimes does some strange stuff when a control doesn't have
one - so the test should create it.
Felix
Felix Nawothnig wrote:
Pierre could speak to this better than I, but my understanding is
that the Quartz driver does not need the DIB engine. Quartz (the
Mac's imaging and windowing API) is capable of drawing to offscreen
bitmaps directly, at color depths that need not match the disp
see:
http://www.winehq.org/pipermail/wine-devel/2005-July/038703.html
Now, in my opinion we shouldn't care about those apps but it's not up to
me. :)
Felix
Mikołaj Zalewski wrote:
Tab uses a mask to mark which fields are set but it new fields were set
by SetItem the mask wasn't updated.
Actually all members are always valid (for the internal structure at
least). I already sent a patch which removes the mask.
Felix
we really want to internally use undocumented functions
with unclear semantics when there is an easy (documented) way.
And besides - the comctl32 code is full of "if(p) Free(p);"...
Felix
;t make it correct and could fail if
there are undocumented flags (that gap before 0x20 looks suspicious to
me...) - and that's more likely than undocumented levels imho (and even
with 0x7 we cover another 2).
Felix
Koshelev, Misha Vladislavo wrote:
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS
somewhere set to 0xf then?
Shouldn't that be 0x7?
replacing just the while(), not the if() while().
It's mostly a matter of style though as gcc most likely will compile it
to a do {} while() anyway.
Felix
Marcus Meissner wrote:
- if(nRelPos>=0) { /* if this or preceding row */
+ if(nRelPos<=0) { /* if this or preceding row */
while(nRelPos<=0) {
Shouldn't that become a "do { ... } while()" then?
me pointers where to start solving
this problem.
See http://bugs.winehq.org/show_bug.cgi?id=5526
(at least that's what causing performance issues for Fallout 1 but IIRC
they use the same engine)
Felix
Hi. Anyone knows what happened to test.winehq.com/data? There has been
no new crossbuilds for quite some time now...
Felix
Francois Gouget wrote:
This is a NOP, it just seems a bit cleaner to me.
-hDsound = LoadLibraryA("dsound.dll");
-if (!hDsound) {
-trace("dsound.dll not found\n");
-return;
-}
-
+hDsound = GetModuleHandleA("dsound.dll");
+ok(hDsound != NULL, "dsound.dll not loa
correct again.
I uploaded a screenshot at http://hebbelabi06.de/derive.png.
Sadly I do not have the time to investigate this at the moment.
I do have fontforge installed:
# rpm -qa | grep fontforge
fontforge-20050803-2
HTH
Felix Möller
black window after clicking on "about wine".
may be linked to the external DLL required for some action here.
I will do some more investigation. At least with the default log-level
wine is not reporting any oddities.
Thanks for you help.
Felix
ore research. An easy bug is probably that the user just gets a black window
after clicking on "about wine".
Do you need any other information?
Felix
[1] - http://www.knopf.com/resources/help/winhelp2k.html
ed=N breaks focusing for everything on my box (bug #2149)... :-)
Felix
Saulius Krasuckas wrote:
I want to exclude this stuff.
Adding "97;98" to "HKEY_CURRENT_USER/Software/Wine/debug/RelayExclude"
string value doesn't help me.
Adding "_EnterSysLevel;_LeaveSysLevel;97;98" does not help either.
Suggestions?
Try "kernel32.97;kernel32.98".
Felix
ed stuff (it NUL terminates the first part, right?)
we shouldn't test for it unless we find an app which depends on it.
Felix
f the cursor being selected is
bogus that it stays the arrow pointer.
It's a regression which happenend between 20050628 and 20050725
affecting multiple applications - see
http://bugs.winehq.org/show_bug.cgi?id=3165
Felix
Marcus Meissner wrote:
Yes, but please don't use the IsBad* functions, use a proper exception
handler.
Next try, is this what you imagined.
The reason for using an exception handler is thread safety - to achieve
that you have to put it around the ATOM_AddAtomA call.
Felix
the same problem
in developing wine to support apps.
FYI, the Win98 DDK is available online (for free) at MSDN somewhere.
Felix
eated.
It's a common technique to rely on the fact that exports from kernel32
reside at the same address to use CreateRemoteThread calling LoadLibrary
for remote code injection (this is not what Vitaliy's App is doing here
but the assertions are the same).
Felix
lways the same address
on >=NT4 (in NT3 only NTDLL was at a fixed address however).
Felix
got a real world app which depends (depended, but we
don't want apps getting fixed for Wine, right?) on PeekMessage not
giving away timeslices?
Felix
t win that race as there
are zillions of methods to detect Wine and most of them can't be avoided
(the first thing that comes to my mind which can't be worked around in
userspace is doing a unix syscall for example).
Felix
I don't have the URL handy).
You mean http://test.winehq.com/data/ ?
Felix
ome from since I dunno anything about the DSound API. :-)
And shouldn't it be "%= dsb->buflen;"? I'd think that this causes
looping until new stuff is mixed in...
I tested with the particular game, and it made no difference. The
comment is there so it is evident that I tested both.
Maybe new samples are immediatly mixed in?
Felix
o we need this (both nrelay and relay16) when there
is RelayFromInclude?
RelayFromInclude doesn't follow CreateProcess, if I understand things right...
How about implementing magic values like %native% and %win16% for it
then? "option-like" debug channels seem very unintuitive to me...
Felix
o we need this (both nrelay and relay16) when there is
RelayFromInclude?
Felix
if (dsb->leadin && (dsb->startpos <= dsb->buf_mixpos))
dsb->leadin = FALSE; /* HACK: see above */
}
+ else dsb->buf_mixpos = 0; /* %= dsb->buflen; */
And shouldn't it be "%= dsb->buflen;"? I'd think that this causes
looping until new stuff is mixed in...
Felix
lf
unless the queue is put into shm).
Felix
Alexandre Julliard wrote:
since a server call is much more expensive than a Windows system call.
Would using shm fix that?
No, you don't want to put the message queue in shared memory, that's
not reliable.
shm + kernel handles for synchronization then?
Felix
system call.
Would using shm fix that?
Felix
I wrote:
So, PeekMessage always yields execution (it shouldn't) with PM_NOYIELD
specified it yields execution twice (although it shouldn't at all).
Err, that should read "and without PM_NOYIELD specified".
Felix
used to prevent the current task from halting
> and yielding system resources to another task. 32-bit Windows
> applications always run simultaneously.
Felix
#include
DWORD (WINAPI *pNtYieldExecution)(void);
static INT nIdleSlices = 0;
static DWORD WINAPI ThreadProc(LPVOID lpParam)
In theory you could roll back the stack to figure out EIP when the call
was made and then see what module is loaded at that address but that's
not what C APIs are supposed to do. And for that matter it's not what
Windows does either.
Felix
ONTPROPERTIES);
+sfp->wgBlank = 0;
+sfp->wgDefault = 0;
+sfp->wgInvalid = 0;
+sfp->wgKashida = 1;
+sfp->iKashidaWidth = 0;
+}
+
+}
You forgot the return value...
Felix
always and
this is not what MSDN says about this function anyway)
The right way is to store the HINSTANCE passed to DllMain on
DLL_PROCESS_ATTACH in a global variable and use that.
Felix
with the
families grouped afterwards).
It also implies that Wine will take over the world one day. :-)
Felix
Tom Wickline wrote:
I'm not finished, but I thought I would ask if this going in the right
direction?
http://wiki.winehq.org/BenchMark
Much better, although Windows should really be on the left side.
Felix
mon idiom...
Felix
Saulius Krasuckas wrote:
Felix, I have reverted part of your patch and tested this. Reversion is
doing fine on WinME -- zero failed tests. Didn't tested on XP or so.
Is this acceptable? If so, feel free to submit it under own name. Or
correct the code. :-)
This is not really co
This doesn't work in desktop mode (and probably non-managed mode)
though. I'd also like winecfg to fit into 640x480.
Felix
of constifying "int i" to archieve the same effects?
Felix
Johannes Koch wrote:
No, you don't. The bitwise shifting operator has a higher precedence
than the bitwise or does.
In case you didn't know...
$ man 7 operator
is your friend. :-)
Felix
r with that hints
anyway. :-)
Constifying the pointers is fine ofcourse (but rather because it helps
finding bugs than for those 1.5% performance improvements.
Felix
tches
from the last weeks it seems I'm not alone. :)
Felix
since we'd have to transfer the whole DIB
all the time anyway).
Felix
1 - 100 of 155 matches
Mail list logo
