Re: GetDIBits(): Handle Bitfields properly

+if (bpp > 0 && compr == BI_BITFIELDS) +{ +/* Windows ignores the input bitfields and overwrites them */ + +if (bpp == 16) +{ +/* With these bitfields, the color data is the same as for BI_RGB */ +((PDWORD)info->bmiColors)[0] = 0x7c00; +

Re: ntdll: Heap implementation has a performance bottleneck

Alexandre Julliard wrote: A quick fix is to add more free list entries, and in particular an entry for very small blocks since your test case seems to create a lot of them. Something like this seems to work well: Thank you Alexandre, this patch speeds up HomeSite a lot. It's still not as fast

ntdll: Heap implementation has a performance bottleneck

Hi, I have discovered that Wine's heap implementation (HeapAlloc(), HeapFree(), etc. in dlls/ntdll/heap.c) is very slow if many small memory blocks are allocated and freed. Somebody has reported this before: http://www.winehq.org/pipermail/wine-devel/2005-February/034095.html HomeSite's synt

Re: GetDIBits() with a bitmap that is selected in a device context

I have submitted new tests to wine-patches. @Dmitry: One of your bitmap tests triggers an assertion on Windows 9x. Look here: http://test.winehq.org/data/200605161000/ Regards, Michael Dmitry Timoshkov wrote: The application "Fritz 5.32" calls GetDIBits() with a bitmap that is still selected

GetDIBits() with a bitmap that is selected in a device context

The application "Fritz 5.32" calls GetDIBits() with a bitmap that is still selected in a device context (see bug 3893). The bitmap has a color table. GetDIBits() creates a memory DC, selects the bitmap into this DC, and calls GetDIBColorTable(). But this fails, because Wine can't select this bi

Re: Static control [10/10]: Support the Windows XP mode of the static control

An even better summary is in WWN 243: http://www.winehq.org/site?issue=243#Button%20Code%20Audit

Re: Static control [10/10]: Support the Windows XP mode of the static control

Hi Filip, This doesn't seem right. User32 shouldn't be checking manifests, I would expect the STATIC control to be subclassed in COMCTL32 and the WinXP functionality implemented there. You're right, but it's not easy to implement it in the same way as Windows does. Windows has two impleme

Re: Static control [06/10]: STN_ENABLE and STN_DISABLE notifications

Hi, it's already in the subject, but here's a better changelog: Static control: - Support STN_ENABLE and STN_DISABLE notifications - Repaint immediately upon WM_ENABLE Regards, Michael On 1/11/06, Michael Kaufmann <[EMAIL PROTECTED]> wrote: --- static-old.c

Re: [user] static.c: PaintIcon fix background colour

Hi, The current functionality is not correct either then. It works ok for a normal SS_ICON, but if you use SS_CENTERIMAGE with it, it paints the background around the icon where there should be no background. I will experiment with transparent icons and improve my patch. Thankyou for the info.

Re: [user] static.c: PaintIcon fix background colour

Hi Kieran, Icons can have transparent and inverted pixels! This patch is not correct, the background has to be painted always. * dlls/user/static.c: Kieran Clancy > Only set background for icon control when the icon is invalid. Regards, Mi

Re: NSIS problem?

It seems that NSIS installers have regressed in Wine 0.9 - at least, the PE Explorer setup which looks and feels like an NSIS based installer won't install with a "The folder name is invalid" error message. I poked at this a bit but got nowhere. The installer of PE Explorer has been created

Re: MS Office 95/97 needs native odbccp32.dll

The MS Office 95/97 setup program fails when using the built-in odbccp32.dll. A native version of this dll is on the installation media. Since 2005-07-08, Wine doesn't use this file because of this patch: http://cvs.winehq.org/patch.py?id=18748 Does Office 95/97 ship a version of odbccp32.d

MS Office 95/97 needs native odbccp32.dll

Hi, The MS Office 95/97 setup program fails when using the built-in odbccp32.dll. A native version of this dll is on the installation media. Since 2005-07-08, Wine doesn't use this file because of this patch: http://cvs.winehq.org/patch.py?id=18748 I think that we have three options: - Chang

Re: Delphi edit control created in Unicode instead of ANSI mode

But apart from that, why is the patch not CVS-worthy? Due how the WM_GETTEXT is "dispatched" (ie calling the proc) - but that would be solved with SendMessageW(). I've found another problem: Reading the window proc address with GetWindowLong won't work for subclassed windows. We nee

Re: Delphi edit control created in Unicode instead of ANSI mode

Hi, Does Windows XP use Unicode controls too if theming is on? Because the Delphi edit controls are now in Unicode mode, the messages sent to them have to be translated from ANSI to Unicode and back. When a program reads the "Text" property of a TEdit control, Delphi sends a WM_GETTEXTLENGTH me

Delphi edit control created in Unicode instead of ANSI mode

Hi Frank, One of your theming patches ( http://www.winehq.org/hypermail/wine-cvs/2005/08/0313.html ) has caused a problem in many Delphi applications. The edit controls of Delphi applications are now created in Unicode mode. I hope you have an idea why this happens... Of course Delphi applica

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

Hi Michael, 2) Did other people see this bug already? TextPad 4.5 broke just around the time when you checked in the patch. It crashes at startup, the crash location is strange and has already changed a few times when I updated the WINE source tree. You can get TextPad 4.5 here: ftp://ft

UpdateWindow doesn't call XFlush

Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that Up

Re: X11: Problems with ConfigureNotify events that are received/processed too late

Hi all, Some other propositions on how to fix this: 1. Don't handle X events in MsgWaitForMultipleObjectsEx, just wait for them. 2. Don't cache the X11 window rectangle and always use XGetGeometry to get the current window rectangle. That will surely solve the problem, but also calls like Get

X11: Problems with ConfigureNotify events that are received/processed too late

Hi all, I'm trying to get the dialog boxes of Word 95 working. They often appear with the minimal window size (about 70x50 pixels), so they're unusable. With KDE's window manager (KWin) this happens very often. With Enlightenment and GNOME's window manager (Metacity), it only happens from tim

UpdateWindow vs. WM_PAINT

Hi, I've noticed that many Windows controls don't wait for a WM_PAINT message. They redraw themselves immediately (with GetDC/ReleaseDC, UpdateWindow or RedrawWindow). This is necessary if a program is carrying out a lengthy operation without fetching messages. TextPad is such a program: Its pr

Re: CreateDIBitmap fix

st bitmaps have a BITMAPINFOHEADER. Unfortunately, I had to duplicate an internal function (DIB_GetBitmapInfo) in my new patch. Regards Michael Am Montag, 13. September 2004 13:12 schrieb Huw D M Davies: Michael Kaufmann <[EMAIL PROTECTED]> Huw Davies &

The solution for the Delphi menu bug

Hi all, I found a different approach to make the menus of Delphi applications work in WINE. I was working on a different bug (allow a single menu to be used in multiple windows), and found that my fix for this problem also fixes the Delphi menu bug. So we don't have to break a testcase! The fix

Re: Revised menu patch

Hi Alexandre The only explanation was "it breaks the testcase X", where X is a testcase that doesn't even pass on Windows 9x. I think the patch won't break any real application. Famous last words. There have been a number of similar hacks done in the menu code already, but they all had to be r

Re: Revised menu patch

Hi Dmitry How do you define the "real behavior" ? That's a behaviour of an existing product that could be tested and confirmed. So is there an existing third-party program that depends on the "real behavior" ? Have you checked that Windows 2003 still passes this test? No, I don't.

Re: Revised menu patch

Hi Uwe Micheal, can we perhaps create a test case, that mimics the Delphi behaviour and succeeds on WinXX but fails on Wine? Then the behaviour is well documented and there is less reason to not fix it while breaking another test. Yes, that's a good idea! I've attached a test case that fails onl

Re: Revised menu patch

Hi Dmitry My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. That's a very bad idea, then you need to comment out half of the test cases in Wine. The tests show *the real* behaviour, it doesn't really matter whether it's docu

Revised menu patch

Hi all My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out. I've also added mo

Re: DestroyMenu: Check if the menu is still used (fix for bug 1486)

Hi, I've searched for other patches on this subject. I was very surprised to see that Andreas Mohr submitted a patch for the same problem about two years ago: Oh, me? :-) True, I've been bitten by that issue at that time (and several applications failed on it, e.g. FilZip 2.01(?)), so I atte

Re: DestroyMenu: Check if the menu is still used (fix for bug 1486)

Hi Dmitry There is a test case in Wine (dlls/user/tests/win.c,test_SetMenu) which shows that your patch is wrong. This test case also fails on Win9x, as you can see in the code of the test case: ok(DestroyMenu(hMenu), "DestroyMenu error %ld\n", GetLastError()); ok(!IsMenu(hMenu), "menu handle

Re: Wine bug with delphi Menus

Hi Robert This bug is a duplicate of bug 1486 which I've just fixed! :-) http://bugs.winehq.org/show_bug.cgi?id=1486 Regards Michael Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working

Re: Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)

Hi! Could you integrate the DIB-Testcase program with the conformance framework? It seems like it would be a valuable addition and a good complement to your patch. Currently I don't have the time to do this, but I'll try it eventually. By the way: I've found some more incompatibilities: - Create

Re: Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)

Hi all, I finally managed to create a patch that fixes the bug in CreateDIBitmap and also changes all the WINE code that was relying on the wrong behavior. I'll send the patch to wine-patches in a couple of minutes. So if you intended to help, it's too late ;-) Test Program (DIB-Testcase.zip):