- Wine-Devel - list.winehq.org

Linking with winelib
by Nikolay A. Liber Sept. 10, 2004

Sept. 10, 2004

Hello I am using winelib with Mono hack to load windows DLL into python module. There is a dummy function wine_pthread_init_thread in libwine.so. wine_pthread_init_thread implemented in winelib.so.exe from mono shared winelib. I link module. gcc -shared mymodule.so module_code.o -lwine ./winelib.so.exe But when I load module init_thread from ntdll calls dummy wine_pthread_init_thread. How to override that dumy function? Thank you Nikolay

2 1

RE: modal dialog: Wait until message queue runs dry before calling ShowWindow()
by Zach Gorman Sept. 9, 2004

Sept. 9, 2004

Yes, the test code is on its way. These patches are all from a few weeks ago, but Alexandre asked me to break them up into multiple smaller patches. I tested them with the latest tree and they seem to still work fine. Zach -----Original Message----- From: Mike McCormack [mailto:mike(a)codeweavers.com] Sent: Thursday, September 09, 2004 2:37 PM To: zach(a)archetypeauction.com Subject: Re: modal dialog: Wait until message queue runs dry before calling ShowWindow() Zach Gorman wrote: > My tests show that Windows behaves this way. If you could submit your test as a patch including it in the wine test suite, that would be great. If not, just posting it with a LGPL compatible license so others can adapt it to the test suite would be appreciated too. Mike

1 0

Re: edit control
by Robert Shearman Sept. 9, 2004

Sept. 9, 2004

Ulrich Czekalla wrote: >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Allow copying selection when control is read only > > >------------------------------------------------------------------------ > >Index: dlls/user/edit.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/edit.c,v >retrieving revision 1.1 >diff -u -r1.1 edit.c >--- dlls/user/edit.c 31 Aug 2004 01:10:08 -0000 1.1 >+++ dlls/user/edit.c 9 Sep 2004 13:01:26 -0000 >@@ -3604,7 +3604,8 @@ > > /* Protect read-only edit control from modification */ > if(es->style & ES_READONLY) >- return; >+ if (c != 0x03) /* Allow copying selection */ >+ return; > > control = GetKeyState(VK_CONTROL) & 0x8000; > > That read-only check looks completely bogus to me as the code below already checks for ES_READONLY. Rob

2 1

Settlers 3: bug in NTDLL_get_server_timeout??
by Stefan Dösinger Sept. 9, 2004

Sept. 9, 2004

Hello list, I am trying to get Settlers 3(Siedler 3) working. This game crashes with a Integer divide by 0 exception very early. Wine version: cvs from September 7. 2004 Settlers 3 version: 1.60 with WinXp-patch. s3.exe produces a nice crash dump(attached errorlog.txt) and with a little debugging I found out that the crash occurs in RtlEnlargedUnsignedDivide(), file dlls/ntdll/large_int.c This is what I think is going on: *)s3.exe calls SetWaitableTimer() in dlls/kernel/sync.c *)NtSetTimer() in dlls/ntdll/sync.c is called, and this is where the problem beginns. NtSetTimer() calls NTDLL_get_server_timeout from time.c *)The 2nd case occurs(the else if) and RtlEnlargedUnsignedDivide is called. The interesting thing is that TICKSPERSEC is a constant(10000000) and this shouldn't give a divide by zero. But RtlEnlargedUnsignedDivide takes an UINT as 2nd arguemt, and 10000000 is too big for an UINT. For testing I enabled the C version of RtlEnlargedUnsignedDivide, and this time the exception didn't occur but wineserver blocked(kill -9 was necessary) The same thing happens if I move the divison to NTDLL_get_server_timeout(and do not call RtlEnlargedUnsignedDivide). I commented the call to NTDLL_get_server_timeout, and s3.exe starts successfully, but I don't think that's the correct way to solve this problem. I attached the output with normal debug options and a few TRACEs changed to ERRs. NTDLL_get_server_timeout is called quite often. The SetWaitableTimer call: err:ntdll:SetWaitableTimer called err:ntdll:NtSetTimer (0xf4,0x46d32104,(nil),(nil),00000000,0x000001f4,(nil)) stub err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called ... fixme:dialog:MSGBOX_OnInit system modal msgbox ! Not modal yet. -- The crash message err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called Greetings, Stefan Dösinger

4 5

RE: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades Sept. 9, 2004

Sept. 9, 2004

Hiya, Just an fyi - I installed it and gave it a try. The first problem (the one you mentioned) is easily solved by commenting out the hide and show calls around the setwindowpos. This may be the real fix - The problem is the app has a default window proc which is receiving a window activated message on the show, and assumes it had lost full screen and got it back. It then tries to reset everything but it never completed initialization! Anyway it then goes on to die on something I think is sound related, but might be my machines problem (sound on my test box is seriously screwed up). Note the game writes into a sub dir 'Logs' (from memory) a log of how far it gets. Try taking those 2 lines out and see if you get any further. I'll have another go at the 2nd trap I am seeing, but it would be interesting to see if you get any further. Jason

1 0

UltimaOnLine: X11DRV_CritSection deadlock
by Diego 'Flameeyes' Pettenò Sept. 9, 2004

Sept. 9, 2004

Hi, I'm playing Ultima OnLine using wine in the last times, it works fine, except that wine processes eat all the cpu time and sometimes I have this fixme on stderr: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIBcopy But the true problem is that if I'm idle for some time, I get this error, and kde stops responding at mouse (and sometimes also keyboard) events: err:ntdll:RtlpWaitForCriticalSection section 0x41bd6220 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Seems like a deadlock, but I don't know what can generate this problem, so I can't reproduce it after launching winedbg. Also when I close the client, wine remains open until I ctrl-c it. Trying to tracing this is quite impossible, because it's already heavy when launched directly, I don't think it's possible to have a +all with it without using the delayed debug, but I'm not able to find out the patch into wine-patches, if someone can point a link for it, I'll try to do that. If no one has idea of what problem is this, I'll report it as a bug, but maybe it's only an application's problem. TIA, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

5 7

Re: Drowning in FIXMEs...
by Jukka Heinonen Sept. 9, 2004

Sept. 9, 2004

Chris Rankin: > OK, here's a first draft at a patch. Created with > reference to my old copies of Ralph Brown's Interrupt > List. Well, under DOS VGA text mode, mouse cursor is like "gpm" mouse cursor, a character cell which gets inverted or otherwise highlighted in order to show where mouse is currently located at. As far as I know, neither Wine nor Windows supports this and SetConsoleCursorInfo really has no effect on mouse cursor, anyway. So, under text mode, hide/show functions should do nothing. However, under VGA graphics mode, show/hide cursor really should call ShowCursor. And, if mouse driver is reset, hide count must be reset to one and cursor must be hidden. I have some more or less untested patch for show/hide somewhere but the last time I tried to get that working I had to fix IRQ handling, again, and after that I was too bored and too busy for doing DOS stuff. Anyway, it will take probably about half a week until I have time for digging out the patch, which I will do if this thing is not fixed before that. I guess I should also dig my other DOS related patches and submit them as well, I don't know if they really help much but at least I would not have pending stuff in my computer. -- Jukka Heinonen <http://www.iki.fi/jhei>

4 3

Re: Re: test.winehq.org site
by Chris Morgan Sept. 9, 2004

Sept. 9, 2004

>From what I can tell on my xp machine it looks like winrash is running correctly, no errors downloading the winetest are reported. Maybe winetest is failing prematurely or the reporting of the results isn't occuring correctly? Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/09/08 Wed PM 12:06:04 EDT > To: Saulius Krasuckas <saulius2(a)ar.fi.lt> > CC: wine-devel(a)winehq.org > Subject: Re: test.winehq.org site > > On Wed, Sep 08, 2004 at 06:32:31PM +0200, Saulius Krasuckas wrote: > > When can we expect it to be up and running? > > It is up and running, we're just missing an index page. > Until that gets created, use this link instead: > > http://test.winehq.org/data/ > > Unfortunately, the testing process has been broken lately, > for unknown reasons. > > -- > Dimi. > >

3 2

The solution for the Delphi menu bug
by Michael Kaufmann Sept. 9, 2004

Sept. 9, 2004

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 is as simple as updating the menu bar's hWnd member every time the user clicks on a menu bar. This is even necessary if the menu is displayed in multiple windows, so it's not a "Delphi-only" fix. Thank you for the intensive discussion we had on the subject! My patch is here: http://www.winehq.org/hypermail/wine-patches/2004/09/0154.html Regards Michael

1 0

DirectInput suggestion
by Jonathan Wilson Sept. 8, 2004

Sept. 8, 2004

I dont know how this stuff works on linux so my suggestion may be wrong but here goes. Basicly, my suggestion is that any joystick that is visible to linux apps be made visible to windows apps via DirectInput joystick APIs. This eliminates the need for WINE to care about USB and such.

2 1