October 2003 - Wine-devel - list.winehq.org

Status of HeapAlloc Cleanup in shell32
by Steven Edwards 28 Oct '03

28 Oct '03

Is the HeapAlloc/ReAlloc stuff being tracked anywhere? I think it is the cause of a lot of problems I have with shell32 under Windows and ReactOS. Applications linked to wine shell32.dll under Windows2000 run fine but when you exit they get illigal op's where the memory could not be "read" kind of like the bug I had in uninstaller.exe that started the HeapAlloc cleanup. Thanks Steven __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/

2 1

Re: wine/ tools/winebuild/relay.c dlls/ntdll/signa ...
by Robert Shearman 28 Oct '03

28 Oct '03

This has fixed the problem slightly (see message titled "Bug in cxx_frame_handler") - the program now displays: err:seh:setup_exception stack overflow 592 bytes in thread 000e eip 401c425a esp 40640db0 stack 0x40540000-0x40750000 And then exits. I still believe there is a problem in dlls/msvcrt/cppexcept.c with the following lines (359-364): if (!exc_type) /* nested exception, fetch info from original exception */ { rec = msvcrt_get_thread_data()->exc_record; exc_type = (cxx_exception_type *)rec->ExceptionInformation[2]; } The problem is that msvcrt_get_thead_data()->exc_record returns NULL (probably because there is no nested exception?). Should there just be a check there for a NULL pointer or is it part of a bigger problem? Rob On Tuesday 28 October 2003 12:30 am, you wrote: > ChangeSet ID: 9891 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/10/27 18:30:55 > > Modified files: > tools/winebuild: relay.c > dlls/ntdll : signal_i386.c > > Log message: > Switch back to the main process stack before calling exception > handlers. > > Patch: http://cvs.winehq.com/patch.py?id=9891 > > Old revision New revision Changes Path > 1.31 1.32 +27 -28 wine/tools/winebuild/relay.c > 1.73 1.74 +297 -165 wine/dlls/ntdll/signal_i386.c

1 0

Improper Focus handling
by Cogman 28 Oct '03

28 Oct '03

I have noticed this bug in wine for some time, (winex has corrected it btw). It seems that new windows, child windows, and message boxes are incorrectly handled in wine, when created they are often put at the bottem of the stack of wine windows and not given focus. This is bad expecialy in Install shield programs that bring the messages and windows up one after the other, but you cant see the others or move them because the first is covering them. Also Keyboard focus does not seem to be working properly all the time (sometimes a window gets keyboardfocus and sometimes it doesnt) One thing I would like to point out is the fact that if you click on a window in windows it gets both keyboard and mouse focus. A few examples of where the focus issue becomes a problem are in Cstike and Pharaoh. In Cstrike (or any HL game for that matter) if you loose focus on the main window (alt-tab or something else happens) you loose keyboardfocus, but not always mouse focus, So you endup stuck in a game with the keyboard focused on some other window (usually on a konsole so killall is the only way to get out other then changing virtual windows) In pharaoh the problem is when a new window pops up. The keyboard does not send messages to it, and you can click on it and everything but not be able to type anything (save game window). Now if you run games in desktop mode it will sometimes work. but I dont think that you should have to run games in desktop just to get proper focus handling. I really would love to see this bug smushed :)

1 0

wine msvcrt on Library initialization
by Boaz Harrosh 28 Oct '03

28 Oct '03

I have only managed to compile and link MFC with the msvcrt.dll the std way would not work. Now the MFC has lots of: <somefoo.cpp> void CleanFoo() { } int init = atexit( CleanFoo ) ; </somefoo.cpp> The call to atexit will in-turn call _lock if we look at _lock.c : <lock.c> ... /* If the lock doesn't exist yet, create it */ if( lock_table[ locknum ].bInit == FALSE ) { /* Lock while we're changing the lock table */ _lock( _LOCKTAB_LOCK ); .... </lock.c> Since we are calling on library initialization, (global variable) it might happen that the call is made before the initialization of the _LOCKTAB_LOCK (before a call to lock.c::msvcrt_init_mt_locks) and therefor I get an endless recursion. Now this is why we have the -wrap option with the delayed load of winelib apps. [Q}Should I submit a patch to protect that endless recursion in msvcrt. or should it be noted that all DLL s used by the winelib-application should be also linked to the wrapper (to have a chance to initialize) and submit a patch to winemaker? P.S Some similar problem occurs with native msvcrt.dll. That one is hard to pinpoint exactly. In any way making the wrapper link to msvcrt will solve the problem in both cases. Free Life Boaz

1 0

Proposal to resolve the issue of the broken wine-users gateway
by Jeremy White 28 Oct '03

28 Oct '03

Hi Folks, Say, Just chatting on IRC today, and ShadowHawk pointed out that a host of other sites (Franks corner, etc) have sprung up almost entirely because there are no user based forums on winehq.org. This is, in part, due to the fact that the gateway between the newsgroup and wine-users is busted. And it is that way, because the gateway we were using is a dead project, and Jer hasn't been able to wrestle it back into working (and doesn't really want to). Further, I think it may be time to recognize that cool looking forums are what users expect; that mailing lists and newsgroups are really becoming the 'old' way of doing things. Further, there is a PHP based forum system that Jer would be happy to put up on winehq.org. This would neatly side step the whole problem and perhaps provide a nice upgrade for winehq.org. What do others think? Cheers, Jeremy

5 6

Re: DMUSIC: fix in dmloader's behavior
by Jerry Jenkins 28 Oct '03

28 Oct '03

Rok Mandeljc wrote: > + /* OK, MSDN says that search order is the following: > + - current directory (DONE) > + - windows search path (FIXME: how do I get that?) Try this : DWORD GetEnvironmentVariable( LPCTSTR lpName, // environment variable name LPTSTR lpBuffer, // buffer for variable value DWORD nSize // size of buffer ); or NTSTATUS WINAPI RtlQueryEnvironmentVariable_U( PWSTR env, PUNICODE_STRING name, PUNICODE_STRING value ); > + - loader's search path (DONE) > + */

2 1

Re: Fix comctl32 conformance test
by Jakob Eriksson 28 Oct '03

28 Oct '03

Why is this not applied? Would be nice to have when cross compiling works. Hans Leidekker wrote: >Hi, > >It appears that the comctl32 conformance test calls functions by name >that are exported by ordinal only on Windows. Still the test runs (and >thus run-time links) on Wine. Is this wanted behavior? > >When I run it as a cross compiled test on my W2kSP4 machine or on Wine(!) >it bombs with linking errors. To fix this I made this patch that uses >GetProcAddress to get at the functions via their ordinals. > > -Hans > >Changelog: > Don't call functions by name. They are exported by ordinal only. > > >Index: dlls/comctl32/tests/dpa.c >=================================================================== >RCS file: /home/wine/wine/dlls/comctl32/tests/dpa.c,v >retrieving revision 1.2 >diff -u -r1.2 dpa.c >--- dlls/comctl32/tests/dpa.c 5 Sep 2003 23:08:42 -0000 1.2 >+++ dlls/comctl32/tests/dpa.c 19 Oct 2003 16:24:49 -0000 >@@ -29,6 +29,9 @@ > > #include "wine/test.h" > >+static HDPA (WINAPI *pDPA_Create)(INT)=NULL; >+static INT (WINAPI *pDPA_Search)(HDPA,LPVOID,INT,PFNDPACOMPARE,LPARAM,UINT)=NULL; >+ > static INT CALLBACK dpa_strcmp(LPVOID pvstr1, LPVOID pvstr2, LPARAM flags) > { > LPCSTR str1 = (LPCSTR)pvstr1; >@@ -42,14 +45,18 @@ > HDPA dpa_ret; > INT int_ret; > CHAR test_str0[]="test0"; >- >- dpa_ret = DPA_Create(0); >+ >+ HMODULE hcomctl32=LoadLibraryA("comctl32.dll"); >+ pDPA_Create=(void*)GetProcAddress(hcomctl32, (LPSTR)328); >+ pDPA_Search=(void*)GetProcAddress(hcomctl32, (LPSTR)339); >+ >+ dpa_ret = pDPA_Create(0); > ok((dpa_ret !=0), "DPA_Create failed"); >- int_ret = DPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED); >+ int_ret = pDPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED); > ok((int_ret == -1), "DPA_Search found invalid item"); >- int_ret = DPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED|DPAS_INSERTBEFORE); >+ int_ret = pDPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED|DPAS_INSERTBEFORE); > ok((int_ret == 0), "DPA_Search proposed bad item"); >- int_ret = DPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED|DPAS_INSERTAFTER); >+ int_ret = pDPA_Search(dpa_ret,test_str0,0, dpa_strcmp,0, DPAS_SORTED|DPAS_INSERTAFTER); > ok((int_ret == 0), "DPA_Search proposed bad item"); > } > > > > >

2 2

Longhorn info
by Mike Hearn 28 Oct '03

28 Oct '03

Of course, as we don't actually implement the "new" XP APIs yet, this is all rather academic. Still, why not take a look at what we'll be reimplementing in 2010 ;) SDK: http://longhorn.msdn.microsoft.com/ Articles/Info: http://msdn.microsoft.com/longhorn thanks -mike

1 0

Segmentation fault
by flyker 28 Oct '03

28 Oct '03

Under Windows my program exe file is about 6Mb. Under Linux and Wine it is about 50Mb (.so file). It is normal ? And Wine makes Segmentation fault on initialising global variables of my program. #1 0x40bb0116 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at main.cpp:681 #2 0x40bb0176 in _GLOBAL__I_oldfCentury () at main.cpp:3809 #3 0x40bcc151 in __do_global_ctors_aux () from /home/mc/PRJ/main.exe.so #4 0x40872dc6 in _init () from /home/mc/PRJ/main.exe.so #5 0x4000c4b1 in _dl_init_internal () from /lib/ld-linux.so.2 #6 0x40154f42 in dl_open_worker () from /lib/libc.so.6 #7 0x4000c266 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #8 0x401549af in _dl_open () from /lib/libc.so.6 #9 0x4017bf6b in dlopen_doit () from /lib/libdl.so.2 #10 0x4000c266 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #11 0x4017c316 in _dlerror_run () from /lib/libdl.so.2 #12 0x4017bf14 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 #13 0x4002ea32 in wine_dlopen (filename=0xbfffc5f8 "/home/mc/PRJ/main.exe.so", flag=2, error=0xbfffd628 "\200.", errorsize=1024) at loader.c:454 #14 0x4049e920 in __wine_kernel_init () at process.c:841 #15 0x401d8947 in __wine_process_init (argc=0, argv=0xbfffda84) at loader.c:1954 #16 0x4002e9fd in wine_init (argc=2, argv=0xbfffded4, error=0xbfffda84 "", error_size=1024) at loader.c:431 #17 0x3c001771 in main (argc=2, argv=0xbfffded4) at main.c:33 #18 0x40057917 in __libc_start_main () from /lib/libc.so.6 Any ideas ?

2 1

New compiler warnings
by Gerald Pfeifer 28 Oct '03

28 Oct '03

My nightly autobuilder on FreeBSD 5.1 noticed the following warning introduced yesterday: signal_i386.c:524: warning: `save_context' defined but not used signal_i386.c:602: warning: `restore_context' defined but not used Also, there are two OpenGL warnings left, after most have been fixed a few months ago: directx.c:852: warning: implicit declaration of function `glXGetProcAddressARB' drawprim.c:829: warning: implicit declaration of function `glMultiTexCoord4fARB' Could you please have a look? Thanks! Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0