Re: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
"Rein Klazes" <[EMAIL PROTECTED]> wrote: I attach it here now (bzip2'ed for once because of its size). Before submitting to wine-patches, I need some time to review the code once more for remnants of old way of thinking and to get rid of the IS__ITEM macro's ( or rename them to reflect the true intention). Well done Rein, your patch looks straightforward and really simple. Thanks. -- Dmitry.
exception.o - Undefined reference to NtCurrentTeb in CVS?
I just got back from being on vacation for a week or so, and found I can't compile the current CVS on either of my systems - even after checking out everything from scratch and making clean. Is anyone else having this problem, or is is specific to my machines? ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole atom.o env.o error.o exception.o generated.o info.o large_int.o path.o om.o reg.o rtl.o rtlbitmap.o rtlstr.o string.o time.o testlist.o -o ntdll_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/kernel32 -L../../../libs -lkernel32 exception.o(.text+0x267): In function `test_prot_fault': /home/evil/install/wine/dlls/ntdll/tests/exception.c:202: undefined reference to `NtCurrentTeb' exception.o(.text+0x271):/home/evil/install/wine/dlls/ntdll/tests/exception.c:203: undefined reference to `NtCurrentTeb' exception.o(.text+0x32b):/home/evil/install/wine/dlls/ntdll/tests/exception.c:213: undefined reference to `NtCurrentTeb' collect2: ld returned 1 exit status winegcc: gcc failed. make[3]: *** [ntdll_test.exe.so] Error 2 Thanks in advance, J
RE: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
>I attach it here now (bzip2'ed for once because of its size). Before
>submitting to wine-patches, I need some time to review the code once
>more for remnants of old way of thinking and to get rid of the
>IS__ITEM macro's ( or rename them to reflect the true intention).
Glancing through the patch, I see what you are trying to do, and some
comments (and remember this is just from a glance so far)
1. I'm not sure the MENU_SetItemData for the ownerdraw case is correct as it
doesn't actually take a copy of the data, it saves the pointer. I'm pretty
sure Windows would take a copy (It does when inserting). In fact the
ownerdraw code doesn't set text, just dwitemdata in this routine
2. SetMenuItemInfo_common, In the MIIM_TYPE case for ownerdraw - You would
lose the dwtypedata value for ownerdraw with text
3. Unrelated but just spotted, GetMenuItemInfo_common doesn't return
dwTypeData for ownerdraw what TYPE is used, can we add a test to confirm
that?
>You tests from 4004.patch2 are included. I just removed the todo_wine{}
>which is a probably a good sign.
Yeah, the todo was a condition I didn't really care about at the time, but
fixing it is good :-)
Thanks
Jason
Re: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
On Mon, 26 Dec 2005 10:57:04 -, you wrote:
>>You are correct. The real problem is that the text field should not be
>>used anymore for bitmaps handles after the hbmpItem field was added just
>>for that. This is proven by the fact that strings cannot only be
>>combined with owner draw menu, but also with bitmaps and even
>>separators.
>
>Hmmm... As was found from the tests once I checked the rc, you cant convert
>a string type to a bitmap type directly, although I didn't test adding a
>valid bitmap handle. My tests haven't proved (or attempted to prove) whether
>you can have a string attached to a bitmap type, but reading the MSDN it
>states that a menuitem which is a bitmap has the low-order word of the
>dwTypeData member as the bitmap handle, and hence implies you couldn't have
>an associated text (as that is normally pointed to via the same field).
>However, since Windows also copies the value, they too may have the
>equivalent of the internal 'text' field which may or may not get cleared, so
>perhaps this is wrong. It was outside the scope of what I was trying to fix.
This what I think that is happening, also including a MF_BITMAP flag to
the fFlags field if for backward compatibility it is needed.
>>I am too busy celebrating vacation atm, but I hope to send in a patch
>>with extensive tests somewhere tomorrow or so.
>
>Sure, thanks - I'll watch out for it.
I attach it here now (bzip2'ed for once because of its size). Before
submitting to wine-patches, I need some time to review the code once
more for remnants of old way of thinking and to get rid of the
IS__ITEM macro's ( or rename them to reflect the true intention).
> Can you make sure you incorporate the
>specific tests for the bug report in it too please.
You tests from 4004.patch2 are included. I just removed the todo_wine{}
which is a probably a good sign.
Rein.
menu-textistext.diff.bz2
Description: Binary data
Re: Problem with WineD3D Surface Locking
> That program works fine for me with > OpenGL vendor string: NVIDIA Corporation > OpenGL renderer string: GeForce4 Ti 4400/AGP/3DNOW! > OpenGL version string: 1.5.2 NVIDIA 66.29 I don't think it's ATI specific: Try with Mesa Software rendering or any other X11 3D driver. With fglrx it works partially: 24 Bit color depth works nice, 16 bit fails. I'll try it with my brothers mach64 card, but I don't expect it to work. Thanks for the testing, Stefan pgpoJsbC63MQk.pgp Description: PGP signature
Re: Problem with WineD3D Surface Locking
> I have written a small D3D9 test app which shows this behavior: Compile it > with "winemaker .", followed by make, and run it. Pressing ESC will cause it > to quit, pressing any other keys makes IDirect3DDevice9::Clear call on the > back buffer, with a color value based on the pressed keys. A click anywhere > will LockRect() the whole backbuffer, write 0xff into the whole locked > memory, and UnlockRect() it. > > The screen should become completely white, but instead it goes black. With the > fglrx driver and 24 bit color depth it shows the correct behavior, but with > any other driver(radeon, software rendering) or 16 bit color depth, it > doesn't work. The bug is somehow related to some GL calls in > UnlockRect(glPixelZoom and glOrtho), but I couldn't find anything specific. That program works fine for me with OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce4 Ti 4400/AGP/3DNOW! OpenGL version string: 1.5.2 NVIDIA 66.29 Perhaps it's ATI specific? I wonder if you can reproduce it by calling the relevant OpenGL functions directly.
Re: Should wordpad run yet? It's crashing for me...
On 12/26/05, Tom Wickline <[EMAIL PROTECTED]> wrote: > On 12/26/05, Dan Kegel <[EMAIL PROTECTED]> wrote: > > [ winme's wordpad crashes with wine-0.9.4 ] > > http://bugs.winehq.org/show_bug.cgi?id=4160 I'm unstuck now; the patch for bug 4128 got me going. > > Is there a better way to test riched20.dll interactively? > > Performance test has a number of test that really stress riched20.dll > the 2D section test Drawing lines, bitmaps, fonts, text, and GUI elements > You can compare results against builtin and native riched and see > visual glitches in the test window. > > They have a 30 day demo here: > http://www.passmark.com/products/pt.htm Hey, thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Should wordpad run yet? It's crashing for me...
On 12/26/05, Dan Kegel <[EMAIL PROTECTED]> wrote: > I'm trying to narrow down some riched20 problems > so I can file bug reports about them. Thinking that > perhaps winme's wordpad would be a good test program > for this, I tried it out with wine-0.9.4... only to discover > it crashes right after displaying its main window. > So I filed > http://bugs.winehq.org/show_bug.cgi?id=4160 > > Is there a better way to test riched20.dll interactively? Performance test has a number of test that really stress riched20.dll the 2D section test Drawing lines, bitmaps, fonts, text, and GUI elements You can compare results against builtin and native riched and see visual glitches in the test window. They have a 30 day demo here: http://www.passmark.com/products/pt.htm Tom > Thanks, > Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > >
Re: continuosly calling the function from winelib failing - stackoverflow
Hi All
Thank you for the responce
I am able to solve the problem and the problem is due to the calling convention .
Thank you all once again
On 12/26/05, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
Ananth M <[EMAIL PROTECTED]> wrote:> - Stub function is declared in X_dll.h as> long __stdcall STUB_Add(long, long);> -Stub function is defined in X_main.c as
> long __stdcall STUB_Add(long x, long y)> {> printf
("stub function is called \n");> return
0;> }>> In one Application , I used> LoadLibrary("X.dll.so")
- to load the dll> GetProcAddress("")
- to get the function pointer>and
if I call the function continuously in a loop of for 1000> times, first 2 calls are success 3rd call is crashedHow do you define a function pointer? Does it have proper number of arguments/calling convention? If it looks OK to you but still crashes, perhaps you could
create a sample project which shows the problem and post an url for it here?--Dmitry.
Re: (no subject)
> 1. When wine changes screen resolution, it changes resolution of desktop > and that move my icons and i must arrange it manually after game exit and > that is the problem. Please make that resolution switching like "cedega". > Cedega changes the screen resolution, but desktop dimensions are unchanged. That's a Xrandr issue: Wine uses Xrandr to change the screen resulution: Both the virtual Desktop and the Screen resolution are changed. Cedega only changes the Screen resolution just as if you typed Ctrl + alt + "+". The reason why Wine so is a mouse locking issue: dinput.dll fails to lock the mouse inside the Wine window often, and if the Desktop is bigger than the screen, one can accidentally move the mouse outside the game window. The solution to this one is to fix dinput and avoid the use of Xrandr. There's a registy key to force the cedega behavior I think it's HKCU\Software\Wine\X11 Driver\UseXrandr, but I am not sure. > 2. Where is the config? Implementation of "winecfg" isn't good choice. > Config file was good so why you have removed it? Existence of that config > file will be welcomed for many users, which wants to edit some options, > which they can't edit now. You can still edit them in the registry files. Have a look at HKCU/Software/Wine/ This path is stored in ~/.wine/user.reg, which can be edited with any text editor. > 3. The "-workdir" option. When i try to run some programs or when i try to > install something, sometimes wine can't find files needed by installer or > installed game. Cedega uses "-workdir" parameter which sets the directory, > where are that files. I couldn't install or run many games and programs > because of Wine can't find that files, which are needed. (e.g. wine > -workdir "/root/.wine/drive_c/warcraft III/" "C:/warcraft III/Frozen > Throne.exe") I don't think such an option is needed - You can simply cd into the needed directory. If you want to run the app from a GUI menu, you can set a working path for that menu entry. pgpLWkudcT0bB.pgp Description: PGP signature
Re: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote: PS While I think about it, I've also fixed another menu issue as well (bug 3095), and have attached a sample patch to the bug report which includes this and the changes to fix and test that one, and if you have an interest in the menu code you might want to check that out as well. I was going to submit it once this one got into cvs. The proposed fix doesn't look right. I'd suggest just submit the test case showing the bug with appropriate todo_wine statements to wine-patches, then we could try to make it pass under Wine. -- Dmitry.
RE: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
>>The fact that you need to intorduce the txtWasAllocated flag suggests that >>something is wrong. Also MF_OWNERDRAW certainly does not qualify as a MF_STRING >>alias. I'll try to play with your test case and see if I can find a better fix. The particular problem in the bug report was that the ownerdraw can indeed have an associated string value (which is converted to Unicode if necessary) which is kept across the menu item being converted to a String or Ownerdraw type, and our code wouldn't allow returning the string value nor did it save a copy of it in the ownerdraw case. It also highlighted problems with the code where we wouldn't free up the allocated storage in one of the cases even for the string type, and once you added the ownerdraw type into the decision making about freeing then it was a lot simpler and cleaner to save whether the memory was allocated or not. I don't doubt you could do it without the flag, but it would also be more complex checks in each case. >You are correct. The real problem is that the text field should not be >used anymore for bitmaps handles after the hbmpItem field was added just >for that. This is proven by the fact that strings cannot only be >combined with owner draw menu, but also with bitmaps and even >separators. Hmmm... As was found from the tests once I checked the rc, you cant convert a string type to a bitmap type directly, although I didn't test adding a valid bitmap handle. My tests haven't proved (or attempted to prove) whether you can have a string attached to a bitmap type, but reading the MSDN it states that a menuitem which is a bitmap has the low-order word of the dwTypeData member as the bitmap handle, and hence implies you couldn't have an associated text (as that is normally pointed to via the same field). However, since Windows also copies the value, they too may have the equivalent of the internal 'text' field which may or may not get cleared, so perhaps this is wrong. It was outside the scope of what I was trying to fix. >I am too busy celebrating vacation atm, but I hope to send in a patch >with extensive tests somewhere tomorrow or so. Sure, thanks - I'll watch out for it. Can you make sure you incorporate the specific tests for the bug report in it too please. Jason PS While I think about it, I've also fixed another menu issue as well (bug 3095), and have attached a sample patch to the bug report which includes this and the changes to fix and test that one, and if you have an interest in the menu code you might want to check that out as well. I was going to submit it once this one got into cvs.
Re: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
On Mon, 26 Dec 2005 16:13:10 +0800, you wrote: > >The fact that you need to intorduce the txtWasAllocated flag suggests that >something is wrong. Also MF_OWNERDRAW certainly does not qualify as a MF_STRING >alias. I'll try to play with your test case and see if I can find a better fix. You are correct. The real problem is that the text field should not be used anymore for bitmaps handles after the hbmpItem field was added just for that. This is proven by the fact that strings cannot only be combined with owner draw menu, but also with bitmaps and even separators. I am too busy celebrating vacation atm, but I hope to send in a patch with extensive tests somewhere tomorrow or so. Rein.
Re: debugging help
Robert Reif wrote: I'm trying to help someone on wine-bugs (http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game. The problem is that the game is catching and displaying the exception. It also appears that the game won't run in winedbg. Does anyone have any ideas on how to proceed from here. from what I see in the debug log (from winedbg), the game runs under winedbg. IMO, you should use 'pass' instead of 'cont' to get further (this would pass the exception back to program instead of pretending it's fixed). A+ -- Eric Pouech
Re: continuosly calling the function from winelib failing - stackoverflow
Ananth M <[EMAIL PROTECTED]> wrote:
- Stub function is declared in X_dll.h as
long __stdcall STUB_Add(long, long);
-Stub function is defined in X_main.c as
long __stdcall STUB_Add(long x, long y)
{
printf ("stub function is called \n");
return 0;
}
In one Application , I used
LoadLibrary("X.dll.so") - to load the dll
GetProcAddress("") - to get the function pointer
and if I call the function continuously in a loop of for 1000
times, first 2 calls are success 3rd call is crashed
How do you define a function pointer? Does it have proper number of arguments/
calling convention? If it looks OK to you but still crashes, perhaps you could
create a sample project which shows the problem and post an url for it here?
--
Dmitry.
Re: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote: In the case of ownerdraw -> string -> ownerdraw, the calls do indeed work and keep the saved string. Debugging on windows seems to show the string is copied and saved as well, which concurs with the rest of the patch. The fix (rather than the tests) is still accurate for this as far as I can tell. Attached is new patch, which checks the rc of the SetMenuItemInfo (and InsertMenuItem) calls... The fact that you need to intorduce the txtWasAllocated flag suggests that something is wrong. Also MF_OWNERDRAW certainly does not qualify as a MF_STRING alias. I'll try to play with your test case and see if I can find a better fix. -- Dmitry.
