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

edit control bug - EM_LIMITTEXT does not work
by Felipe W Damasio 14 Feb '03

14 Feb '03

Hi, When you try to limit the maximum chars accepted in an edit control by doing something like this: SendMessage(hwndEdit, EM_LIMITTEXT, 10, 0); Wine simply ignores it, and let the user type more than 10 (in this example) characters. This looks bad, because the user could eventually overflow the allocated memory for the dialog, making the program crash. Cesar Mello (mello(a)elipse.com.br) coded a little program to show this limitation: ftp://ftp.elipse.com.br/pub/about1/about1-src.tar.gz I just created a bug entry on bugs.winehq: http://bugs.winehq.com/show_bug.cgi?id=1280 Could someone help me with this? Thanks a lot and kind regards, Felipe

1 0

Re: For your consideration, here's a preview of some new seh_try_macros-type
by Rolf Kalbermatter 14 Feb '03

14 Feb '03

Dan Kegel <dank(a)kegel.com> wrote: >Alexandre Julliard wrote: >> There are people building Wine with the Sun compiler. Also it makes >> sense for at least some dlls to allow building them with MSVC to test >> them under Windows. And in general using different compilers is a good >> way to shake out bugs from the code. > >I always build my conformance tests both in the normal way >and standalone with msvc. >IMHO every executable and DLL we do should run on Windows, too, >if it doesn't absolutely have to make Unix system calls. I regularly compile some of the DLLs under MSVC. The current state of DLLs is so that the non core DLLs compile usually almost fine but linking is a quite big issue I haven't fully tackled. If I link with the MSCV libs I get often undefined imports and linking with MSVC generated import libs from Wine source requires some hand work, as the MSVC IDE only generates the import lib AFTER the entire DLL has been successfully created, so you get sort of a catch 22 situation. Another issue is that most of the DLLs are not yet in a state where they can possibly be put into a current Windows installation, without causing all sorts of crashes and weird problems. The interdependencies between DLLs in a W2K installation is really enormous and a lot of functions in the Wine DLLs are not yet implemented or not fully complient. Rolf Kalbermatter

2 1

DirectSound problems
by Matthieu Foillard 14 Feb '03

14 Feb '03

It seems that there is a bug with DirectSound. Using Half-life, when i start the console, it goes into un infinite loop : $ /usr/bin/wine --debugmsg +dsound Program\ Files/Half-Life/hl.exe -- -opengl -game cstrike -windowed -console -noipx 2> /tmp/log it says : ... warn:dsound:DSOUND_MixCancelAt (0x403f6318, 0), buf_mixpos=25296 trace:dsound:IDirectSoundBufferImpl_Unlock (0x403f6318,0x403f6410,65536,(nil),0):stub trace:dsound:IDirectSoundBufferImpl_Lock (0x403f6318,0,65536,0x40760064,0x40760054,0x4076005c,0x40760058,0x00000000) at 60129 trace:dsound:IDirectSoundBufferImpl_Lock ->65536.0 trace:dsound:IDirectSoundBufferImpl_Lock locking prebuffered region, ouch warn:dsound:DSOUND_MixCancelAt (0x403f6318, 0), buf_mixpos=25296 trace:dsound:IDirectSoundBufferImpl_Unlock (0x403f6318,0x403f6410,65536,(nil),0):stub trace:dsound:IDirectSoundBufferImpl_Lock (0x403f6318,0,65536,0x40760064,0x40760054,0x4076005c,0x40760058,0x00000000) at 60129 trace:dsound:IDirectSoundBufferImpl_Lock ->65536.0 trace:dsound:IDirectSoundBufferImpl_Lock locking prebuffered region, ouch ... Over and over and the game console is "lock". If I disable sound (by comment out oss driver in ~/.wine/config) it works fine. I have this problem using both oss and arts driver. Sometimes after some times, it works and the game console unlocks and all goes fine. Sometimes i wait for a long time and it never works. i have an es1370 sound card, kernel 2.4.20, /dev/dsp0 and /dev/dsp1 are both working. It seems that the game menu use /dev/dsp1 and the game itself (e.g. the console) uses /dev/dsp0. I can't explain this. Thanks for your help mgf -- Matthieu Foillard <m.foillard(a)taktile.com> tel : 0146090496 - gsm : 0686574170 pgp : 0x1609654F

1 0

Re: wine/dlls/comctl32 listview.c
by Rein Klazes 14 Feb '03

14 Feb '03

On Tue, 11 Feb 2003 16:17:31 -0600, you wrote: > Modified files: > dlls/comctl32 : listview.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Compute matrix of first paint when we actually have some items > (problem first spotted & debugged by Duane Clark). This causes a rgeression in newsbin. The listview with the headers do not update during a "retrieve all headers". Until something else triggers a redraw, eg uncover window pane. From then everything works as expected. Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 3

named pipes still broken?
by Dan Kegel 14 Feb '03

14 Feb '03

Is it just me, or are named pipes broken for other people, too? In my tests, Wine can create named pipes, but the reading side can't open them. (Even without my recent changes to sync.c which added filename checking.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: 2GB visible partition size
by Duane Clark 14 Feb '03

14 Feb '03

Tony Lambregts wrote: > Alexandre Julliard wrote: >> >>Well, yes, if we really need to change the fstype it should be a >>generic option that allows all types to be specified, not just >>NTFS. And it shouldn't overload the existing "type" parameter, it >>should be a separate entry. >> > OK. I guess my biggest problem with this is that the most obvious name > for this entry is "Filesytem" which is already used <g>. Since the parameter of interest is specifically named "fsname" rather than "fstype" or "Filesystem", perhaps that should be the configurable parameter name. I would think that would eliminate any confusion.

2 1

For your consideration, here's a preview of some new seh_try_macros-type stuff...
by Gregory M. Turner 14 Feb '03

14 Feb '03

Let me know what you think of these. So far, I like them better than the original versions, although in solving some limitations of the old macros, I've created some new ones. This version avoids ({ }) entirely, in favor of Ove's original thought, which was to use __LINE__; therefore, putting multiple __(finally|except) clauses in the same line probably breaks. Otherwise, these are better macros. They are slightly more easily understood (although still pretty darn confusing, especially in the debugger), probably more resiliant against compiler optimizations, and have much less awful performance. Best of all, they ought to properly re-raise exceptions after executing finally clauses. There is some cruft in there, btw, which will be fixed before I submit anything to patches. They still break break/continue, of course, since they still rely on __TRY / __EXCEPT blocks to do the dirty-work. You can run the original seh_macros.c test against these successfully, except for the "absurdly nested" ones which use macros and presumably would fail quite dramatically due to __LINE__ duplications. FWIW, compared to the degree of "pressing need" for these macros, I have already spent way too much time on them... But the old ones kind of sucked, and, frankly, it's a fun semantic puzzle that requires pusing the limits of good old cpp just a _bit_ further than may have been intended ... so, here it is. Note that I'm declaring a variable in the header file here. I guess, I should fix this by creating an internal API in ntdll? I never quite figured out whether global non-static variables in a dll are thread-local, or what... (same for lexically scoped static ones -- real clueless here, and building a new system so I don't have much doco's at my fingertips ATM) Sooo.... Anyone want to help me decide what's the best way to get a thread-local global variable instantiated? Probably, my previous attempt with TlsAlloc was semantically correct, but that was /way/ too fat a solution, I'd like something much quicker if its at all possible. Otherwise this won't be threadsafe, which seems like a bad call, esp. since such code will probably end up being used to guard against unacceptable resource leakage.. warning, cut-and-pasted this patch in chunks so it might be bugged... should be clear enough how to duplicate, however, if it fails... --- ../wine.vanilla/include/wine/exception.h 2003-01-29 21:50:14.000000000 -0600 +++ ./include/wine/exception.h 2003-02-09 01:33:45.000000000 -0600 @@ -21,8 +21,12 @@ #ifndef __WINE_WINE_EXCEPTION_H #define __WINE_WINE_EXCEPTION_H +/* WRC can't find setjmp.h. Does it not check /usr/include? */ +#if (!(defined(__WRC__))) + #include <setjmp.h> #include "windef.h" +#include "excpt.h" /* The following definitions allow using exceptions in Wine and Winelib code * @@ -59,6 +63,16 @@ * You can use them to leave a __EXCEPT block though. * * -- AJ + * + * Now we can implement the __try/__except/__finally magic of VC++ as standard (?) macros. + * this is a "good enough" implementation, it's incomplete, but should suffice for most uses. + * + * The macros require some symbols to be found in ntdll.dll.so, so link with that DLL if you + * use them. + * + * If you are using VC++ and this header, #define USE_COMPILER_EXCEPTIONS before you include it. + * + * -gmt */ /* Define this if you want to use your compiler built-in __try/__except support. @@ -146,8 +160,90 @@ extern DWORD __wine_finally_handler( PEXCEPTION_RECORD record, EXCEPTION_FRAME *frame, CONTEXT *context, LPVOID pdispatcher ); + +#if (!defined(NO_VC_SEH_MACROS)) + +#ifndef _WINE_ALREADY_DEFINED_SEH_MACROS__ +#define _WINE_ALREADY_DEFINED_SEH_MACROS__ + +/* fixme: should be renamed since these are used for except too */ +typedef void (*__p_seh_finally_executer) (); +typedef void (*__p_seh_dotry_executer) (__p_seh_finally_executer); +__p_seh_finally_executer __thread_outermost_handler_ptr; + +#define __SEH_LINEUNIQ_CAT2(x,y) __SEH_LINEUNIQ_ ## y ## x +#define __SEH_LINEUNIQ_CAT1(x,y) __SEH_LINEUNIQ_CAT2(x,y) + +#define __SEH_LINEUNIQ_NULLMACRO(x) x +#define __SEH_LINEUNIQ_MAGIC_LINE __SEH_LINEUNIQ_NULLMACRO( __LINE__ ) + +#define __SEH_LINEUNIQ_ID(x) __SEH_LINEUNIQ_CAT1( __SEH_LINEUNIQ_MAGIC_LINE , x ) + +#define __try \ + do { \ + void dotry(__p_seh_finally_executer fin) { \ + __label__ __seh_macro_exit_spot; \ + auto WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler); \ + __TRY { \ + { \ + +#define __finally \ + } \ + __seh_macro_exit_spot: \ + if (0) goto __seh_macro_exit_spot; \ + } __EXCEPT( __wine_seh_macro_exception_handler ) { \ + } __ENDTRY \ + (*fin)(); \ + WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler) { \ + (*fin)(); \ + return EXCEPTION_CONTINUE_SEARCH; \ + } \ + } \ + goto __SEH_LINEUNIQ_ID(DETOUR); \ + __SEH_LINEUNIQ_ID(RETOUR): \ + dotry( __thread_outermost_handler_ptr ); \ + } while (0); \ + goto __SEH_LINEUNIQ_ID(AFTERFINALLY); \ + auto void __SEH_LINEUNIQ_ID(Finally_Executer) (); \ + __SEH_LINEUNIQ_ID(DETOUR): \ + __thread_outermost_handler_ptr = & __SEH_LINEUNIQ_ID(Finally_Executer); \ + goto __SEH_LINEUNIQ_ID(RETOUR); \ + __SEH_LINEUNIQ_ID(AFTERFINALLY): ; \ + void __SEH_LINEUNIQ_ID(Finally_Executer) () + +#define __except(...) \ + } \ + __seh_macro_exit_spot: \ + if (0) goto __seh_macro_exit_spot; \ + } __EXCEPT( __wine_seh_macro_exception_handler ) { \ + (*fin)(); \ + } __ENDTRY \ + WINE_EXCEPTION_FILTER(__wine_seh_macro_exception_handler) { \ + return ( __VA_ARGS__ ); \ + } \ + } \ + goto __SEH_LINEUNIQ_ID(DETOUR); \ + __SEH_LINEUNIQ_ID(RETOUR): \ + dotry( __thread_outermost_handler_ptr ); \ + } while (0); \ + goto __SEH_LINEUNIQ_ID(AFTEREXCEPT); \ + auto void __SEH_LINEUNIQ_ID(Except_Executer) (); \ + __SEH_LINEUNIQ_ID(DETOUR): \ + __thread_outermost_handler_ptr = & __SEH_LINEUNIQ_ID(Except_Executer); \ + goto __SEH_LINEUNIQ_ID(RETOUR); \ + __SEH_LINEUNIQ_ID(AFTEREXCEPT): ; \ + void __SEH_LINEUNIQ_ID(Except_Executer) () + +#define __leave goto __seh_macro_exit_spot + +#endif /* _WINE_ALREADY_DEFINED_SEH_MACROS__ */ + +#endif /* NO_VC_SEH_MACROS */ + #endif /* USE_COMPILER_EXCEPTIONS */ +#endif /* __WRC__ */ + static inline EXCEPTION_FRAME * WINE_UNUSED __wine_push_frame( EXCEPTION_FRAME *frame ) { #if defined(__GNUC__) && defined(__i386__) -- gmt

4 6

wcmd autoexec.bat?
by J. Grant 14 Feb '03

14 Feb '03

Hello I have been testing wcmd to automate some process I used to use on win98. However I can not find the autoexec.bat for wcmd? Currently the wcmd shell starts up with no prompt, this has to be corrected in my batch files. prompt $p$g etc. Wine seems to have 2 autoexec.bat's but does not seem to ever use them. /var/lib/wine/autoexec.bat never seems to be executed. Neither is the one I created in my fake c drive (/home/now3d/.wine/c/autoexec.bat) Is this issue known? are their any workarounds? Regards JG

3 4

Keyboard shortcut to disable DXGrab?
by Matthew Toseland 14 Feb '03

14 Feb '03

What would be involved in implementing a keyboard shortcut (ideally configurable) to temporarily disable DXGrab, when playing a game in a window? If such a thing was done, would it be accepted into the source? -- Matthew Toseland toad(a)amphibian.dyndns.org/amphibian(a)users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/ahNdJC6opVw/ ICTHUS.

1 0

Re: popupmenu itemsize
by Uwe Bonnes 14 Feb '03

14 Feb '03

>>>>> "Christian" == Christian Kristukat <semmel(a)hoc.net> writes: Christian> Hi, I suspect that this again is a dirty patch but it helps Christian> in working with Microcal Origin. Maybe a more skilled person Christian> than me finds the real origin of this problem. At one point Christian> in the program a popup menu opens but only the items' width Christian> is calculated correctly, the height is not, in fact it is Christian> equal zero. For that case I added an arbitrarily chosen Christian> height of 12 points and it works fine. Here's the patch: ... Christian> lpitem->rect.bottom += 12; + Nagic constants mostly are evil? It the "12" perhaps related to some SYSPARAMS? ... Christian> PS: By the way: every cvs operation (update, diff) hangs Christian> after processing the last directory. However it seems to be Christian> complete and pressing CTRL-C seems not to corrupt Christian> anything. Any ideas? Are you using rhlx01.fht-esslingen.de? Andi works on that problem then. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2