June 2001 - Wine-Devel - list.winehq.org

Re: wine/ ./configure ./configure.in documentation ...

by lawson_whitney＠juno.com

On Fri, 29 Jun 2001, Uwe Bonnes wrote: > >>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: > Alexandre> ... > Alexandre> +0 -0 wine/msdos/ppdev.c > ^^^^^ > Hallo Alexandre, > > oops, this is not enough. The patch I submitted was > --- /dev/null Tue Feb 20 18:39:20 2001 > +++ wine/msdos/ppdev.c Thu Jun 21 14:32:14 2001 > @@ -0,0 +1,283 @@ > ^^^^ > > Did I choose wrong arguments to diff? > > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > I don't think so. I have all 283 lines, by sending www4mail after the URL in the wine-cvs entry. That way it comes as an added file, flagged with &&&, not a patch exactly, but I have a little program to take care of those. I think that is just the way the wine-cvs list handles added files. Lawson ---ICBW, of course, IC always BW--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

June 29, 2001

Re: wine/ ./configure ./configure.in documentation ...

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ... Alexandre> +0 -0 wine/msdos/ppdev.c ^^^^^ Hallo Alexandre, oops, this is not enough. The patch I submitted was --- /dev/null Tue Feb 20 18:39:20 2001 +++ wine/msdos/ppdev.c Thu Jun 21 14:32:14 2001 @@ -0,0 +1,283 @@ ^^^^ Did I choose wrong arguments to diff? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 29, 2001

rebar trouble with WinZip 8.0

by Mike McCormack

Hi, WinZip 8.0 has a toolbar. It used to show all the toolbar buttons, but it seems to have a problem now, since only the LHS button is shown. Some debug output below. Mike mike(a)linux:~/c > wine Program\ Files/WinZip/WINZIP32.EXE Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file .. trace:rebar:REBAR_AdjustBands start=0, end=0, max x=550, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 trace:rebar:REBAR_AdjustBands start=0, end=0, max x=561, max y=61 trace:rebar:REBAR_AdjustBands Phase 1 band 0, (0,0)-(69,61), orig x=0, xsep=0 trace:rebar:REBAR_AdjustBands Phase 2 band 0, (0,0)-(69,61), orig x=0, xsep=0 err:rebar:REBAR_AdjustBands Serious problem adjusting row 1, start band 0, end band 0 .. fixme:shell:SHGetFileInfoA set icon to shell size, stub fixme:listview:LISTVIEW_SetColumnOrderArray iCount 9 lpiArray 0x405a6a74 mike(a)linux:~/c ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

June 29, 2001

Re: Support Ordinal forwarding in Dll loading

by Alexandre Julliard

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > In attempting to use Specmaker to create a forwarding DLL to do testing of > the Rebar and ComboBoxEx controls, I ran into a problem where pe_image.c did > not support forwarding an ordinal only reference. This patch allows that > function to work. The ordinal forward is of the form: > dllname.DLLNAME_nnnn. I don't think Windows supports something like this. I would suggest instead to fix specmaker to not generate a forward in this case. -- Alexandre Julliard julliard(a)winehq.com

June 29, 2001

CreateWindow issue?

by Bill Medland

Can anyone shed any light on this? 1. If I take Petzold's POPPAD1 project and slightly modify it so that the style is WS_CHILD | WS_BORDER | WS_VISIBLE | ES_AUTOHSCROLL and then spy on the WM_NCCREATE and WM_CREATE it tells me that the style passed in is WS_OVERLAPPEDWINDOW | WS_CHILDWINDOW | WS_VISIBLE | ES_AUTOHSCROLL which is not the same thing. Does anyone know if a. The Windows Spy++ is telling fibs b. (Win95) CreateWindow patches them up in some way. 2. (Why I was even looking at 1) In the application I am working on we open Edit controls almost as above inside dialogs and they appear with a single pixel solid frame under Windows whereas under Wine they appear with a 2-pixel sunken frame. There are several changes I can make in the controls/edit.c to get the same behaviour under Wine but so far they all "mess up" normal sunken ones. (Under windows the resulting windows end up with zero extended style and 50000088 style.) Any thoughts would be appreciated. Bill

June 28, 2001

Re: Proper detection of VM86 support

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Proper detection of VM86 support > on FreeBSD, Linux and Solaris added. I don't think that's useful. Even if we someday support vm86 on other platforms, this is one of these cases where a simple platform check (#ifdef linux) is preferable to complex configure magic IMO. This is how we do the LDT check too, because there simply isn't enough similarity between platforms to justify configure tests. -- Alexandre Julliard julliard(a)winehq.com

June 28, 2001

[Problem report] Messages cooked too much ?

by Gerard Patel

This is a problem of intermittents hangings, when moving the mouse or closing a window (not obvious). I finally realized that the traces in the hanging of Eudora 4 looked very similar, but Eudora 4 hangs reliably ;-) I have found this Eudora crash an infinite loop generated by a mouse move message, cooked to generate a WM_NCMOUSEMOVE, then this last message is obtained repeatedly from the server without being ever removed. It does not seem right to peek a cooked message off the server, not find anything useful to do with it, and just ignore it and asking the server again. The following patch removes the problem, and *seems* to cure the intermittent hangings of other apps. Gerard --- message.c.orig Wed Jun 27 22:14:07 2001 +++ message.c Wed Jun 27 22:13:57 2001 @@ -790,7 +790,11 @@ if (qmsg.kind == RAW_HW_MESSAGE || qmsg.kind == COOKED_HW_MESSAGE) { if (!process_hardware_message( &qmsg, hwnd, first, last, flags & PM_REMOVE )) + { + if (qmsg.kind == COOKED_HW_MESSAGE) + if (!(flags & PM_REMOVE)) QUEUE_FindMsg( hwnd, first, last, TRUE, &qmsg ); goto retry; + } } else {

June 27, 2001

Re: docu patch

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > diff -u -r1.9 DEVELOPERS-HINTS > --- DEVELOPERS-HINTS 2001/01/10 23:59:25 1.9 > +++ DEVELOPERS-HINTS 2001/06/26 23:02:00 > @@ -23,6 +23,7 @@ > > GDI: > > + console/ - handling of text consoles > graphics/ - graphics drivers > x11drv/ - X11 display driver > win16drv/ -> see below > @@ -58,7 +59,7 @@ > msnet/ > msvcrt/ - C runtime library > msvideo/ - 16 bit video manager > - ole32/ - 32 bit OLE 2.0 librairies > + ole32/ - 32 bit OLE 2.0 libraries > oleaut32/ - 32 bit OLE 2.0 automation > olecli/ - 16 bit OLE client > oledlg/ - OLE 2.0 user interface support > @@ -86,12 +87,13 @@ > > Miscellaneous: > > - misc/ - shell, registry, winsock, etc. > + misc/ - misc. wine management, registry, etc. > ipc/ - SysV IPC based interprocess communication > - win32/ - misc Win32 functions > ole/ - OLE code > - nls/ - National Language Support > + nls/ - National Language Support > configuration files > + unicode/ - Unicode (character) support > + win32/ - misc Win32 functions > I have nothing against updating the doc, but I don't think adding wrong information is going to help <g>. console/ is not a GDI directory, and there is no top level nls/ directory. -- Alexandre Julliard julliard(a)winehq.com

June 26, 2001

Re: configure.in patch

by Andreas Mohr

On Tue, Jun 26, 2001 at 08:43:22PM +0900, Bang Jun-Young wrote: > On Tue, Jun 26, 2001 at 11:42:07AM +0200, Marcus Meissner wrote: > > The reason we check for 'flex' again is that the standard check sets LEX > > to 'lex' even if none is found, which lead to confusion during compile. > > > > Our check is similar, but it finds out if 'lex' is present and aborts > > configure if not. > > Another question: why doesn't it doublecheck for yacc? There may > be a system that doesn't have any parser installed by default and > at least one of yacc, byacc, and bison should be installed to > compile. Just for reference - I had this very problem just yesterday with some guy. Nearly nothing installed: checking for bison... no checking for byacc... no checking for flex... (cached) flex configure didn't abort, and compile "crashed" at wrc: make[2]: Entering directory `/home/daniel/tmp/wine/tools/wrc' yacc -bppy -ppp -d -t ./ppy.y make[2]: yacc: Command not found make[2]: *** [ppy.tab.c] Error 127 make[2]: Leaving directory `/home/daniel/tmp/wine/tools/wrc' make[1]: *** [wrc/__depend__] Error 2 make[1]: Leaving directory `/home/daniel/tmp/wine/tools' make: *** [tools/__depend__] Error 2 Command exited with non-zero status 2 -> not good. --> good if this patch fixes it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

June 26, 2001

change of style in the edit control

by Bill Medland

Is anyone working on the edit control's handling of WM_STYLE_CHANGED? Does anyone have any useful information? I intend adding handling of WM_STYLE_CHANGING/ED to controls/edit.c for our application (which uses SetWindowLong to modify the style after creation). 1. Does anyone know why the EDITSTATE.style is not fed back to the pWnd->dwStyle after being modified. 2. Does anyone know of any documentation of the interaction within windows when the styles are incompatible? Bill

June 26, 2001

Re: configure.in patch

by Bang Jun-Young

On Tue, Jun 26, 2001 at 11:42:07AM +0200, Marcus Meissner wrote: > On Tue, Jun 26, 2001 at 05:43:55PM +0900, Bang Jun-Young wrote: > > Why does configure check for flex twice? On NetBSD I get: > > > > checking for bison... no > > checking for byacc... no > > checking for flex... flex > > checking for yywrap in -lfl... yes > > checking for flex... flex > > > > (as seen above, autoconf doesn't search for `yacc' for > > AC_PROG_YACC -- should be fixed) > > It will use it as default if neither byacc nor flex are found. > > The reason we check for 'flex' again is that the standard check sets LEX > to 'lex' even if none is found, which lead to confusion during compile. > > Our check is similar, but it finds out if 'lex' is present and aborts > configure if not. Another question: why doesn't it doublecheck for yacc? There may be a system that doesn't have any parser installed by default and at least one of yacc, byacc, and bison should be installed to compile. I have made another patch: diff -u -r1.209 configure.in --- configure.in 2001/06/19 03:30:14 1.209 +++ configure.in 2001/06/26 11:26:50 @@ -54,6 +54,13 @@ AC_PROG_CPP AC_PATH_XTRA AC_PROG_YACC +AC_CHECK_PROGS(XYACC,$YACC yacc byacc bison,none) +if test "$XYACC" = "none" +then + echo "*** Error: No suitable parser found. ***" + echo " Please install 'yacc', 'byacc', or 'bison' package." + exit 1 +fi AC_PROG_LEX AC_CHECK_PROGS(XLEX,$LEX flex lex,none) if test "$XLEX" = "none" Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

June 26, 2001

Re: configure.in patch

by Andreas Mohr

On Tue, Jun 26, 2001 at 11:42:07AM +0200, Marcus Meissner wrote: > On Tue, Jun 26, 2001 at 05:43:55PM +0900, Bang Jun-Young wrote: > > Why does configure check for flex twice? On NetBSD I get: > > > > checking for bison... no > > checking for byacc... no > > checking for flex... flex > > checking for yywrap in -lfl... yes > > checking for flex... flex > > > > (as seen above, autoconf doesn't search for `yacc' for > > AC_PROG_YACC -- should be fixed) > > It will use it as default if neither byacc nor flex are found. > > The reason we check for 'flex' again is that the standard check sets LEX > to 'lex' even if none is found, which lead to confusion during compile. > > Our check is similar, but it finds out if 'lex' is present and aborts > configure if not. > > This has reduced compiling support queries :) That's all fine and dandy :), but I think we should add a comment to this configure.in line, given the pretty confusing doubled configure output. I'm about 150% sure other people will want to submit the same "fixes" otherwise. -- Andreas Mohr

June 26, 2001

Re: configure.in patch

by Marcus Meissner

On Tue, Jun 26, 2001 at 05:43:55PM +0900, Bang Jun-Young wrote: > On Tue, Jun 26, 2001 at 08:44:50AM +0200, Marcus Meissner wrote: > > On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > > > * configure.in: > > > Remove a redundant check for flex. > > > > It is not redundant! AC_PROG_LEX does more than just look for the 'lex' > > binary. > > > > Please do not apply. > > Why does configure check for flex twice? On NetBSD I get: > > checking for bison... no > checking for byacc... no > checking for flex... flex > checking for yywrap in -lfl... yes > checking for flex... flex > > (as seen above, autoconf doesn't search for `yacc' for > AC_PROG_YACC -- should be fixed) It will use it as default if neither byacc nor flex are found. The reason we check for 'flex' again is that the standard check sets LEX to 'lex' even if none is found, which lead to confusion during compile. Our check is similar, but it finds out if 'lex' is present and aborts configure if not. This has reduced compiling support queries :) Ciao, Marcus

June 26, 2001

Re: Apps DB round 2

by G.LeeJ

James Hatheway wrote: > > > Proposals: > > > * Currently the screenshot is in its own column. That's quite bad > > > sometimes: > > > > I'll play with this some more. I'm assuming a web design that the average > > user is going to be at 1024x768. Does anyone really use less than that > > anymore? (save for web devices of course). > > Yes, unfortunately... Many public places like libraries,etc. still > have terminals with 15 inch monitors at 800x600. agreed......alot of people are simply in a upper crust minority with screens as large as 1024x768 and able to read that res without "squinting" terribly......ie:at "least" a 19" monitor and those aren't cheap for average consumer...although Ihaven't checked prices recently my 21" hitachi is totally adequate ....... I NEVER design without taking into consideration 15"/800X600......because the outcome can be plain nasty. signed minority member <g>

June 26, 2001

Re: configure.in patch

by Bang Jun-Young

On Tue, Jun 26, 2001 at 08:44:50AM +0200, Marcus Meissner wrote: > On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > > * configure.in: > > Remove a redundant check for flex. > > It is not redundant! AC_PROG_LEX does more than just look for the 'lex' > binary. > > Please do not apply. Why does configure check for flex twice? On NetBSD I get: checking for bison... no checking for byacc... no checking for flex... flex checking for yywrap in -lfl... yes checking for flex... flex (as seen above, autoconf doesn't search for `yacc' for AC_PROG_YACC -- should be fixed) Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

June 26, 2001

Re: configure.in patch

by Marcus Meissner

On Tue, Jun 26, 2001 at 03:34:23PM +0900, Bang Jun-Young wrote: > * configure.in: > Remove a redundant check for flex. It is not redundant! AC_PROG_LEX does more than just look for the 'lex' binary. Please do not apply. Ciao, Marcus > -AC_PROG_LEX > AC_CHECK_PROGS(XLEX,$LEX flex lex,none) > if test "$XLEX" = "none" > then

June 26, 2001

RE: undefined reference to main in _start

by lawson_whitney＠juno.com

On Mon, 25 Jun 2001, Gilroy Billard wrote: > No, it is not. > > Basically, I want to use wine_main and link the WINE source libraries into > my project, for example, libmsvfw32.so, libwine.so, etc. > This is what I did in the past and it worked fairly well. However, 20001202 > and greater versions of WINE also require libntdll.so. This is fine too, but > now I get an error "crt1.o undefined reference to main in _start". > > > -----Original Message----- > From: Francois Gouget [mailto:fgouget(a)free.fr] > Sent: Monday, June 25, 2001 3:12 PM > To: Gilroy Billard > Cc: Uwe Bonnes; Wine-Devel(a)Winehq.Com > Subject: RE: undefined reference to main in _start > > > On Mon, 25 Jun 2001, Gilroy Billard wrote: > > > winemaker? no I didn't know there was such a thing. I will take a look at > > it though. thanks > > Winemaker generates Makefiles to compile windows source with Winelib. > But I don't think this is what you want to do, is it? > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > We are Pentium of Borg. You will be approximated. Division is futile. > Maybe I am misunderstanding something, but that sounds like a winelib application you are working on, and that is what winemaker does best, in my experience. Don't be mislead by "windows source", think rather "c-like code you have the source to that wants to make some calls to the windows API" (it can also call any other API you care to give it the headers and libraries for, including libc). Winelib programs changed radically some time in December 2000 - I think for the better - in that you can now simply import a dll in the .spec file and the wine toolchain starting with winemaker takes care of LoadLibrary/GetProcAddress, but they build, start and link differently too. I'd say give winemaker a try. Maybe you will have to hand-hack the Makefile a bit, but winemaker understands beter than I can explain how to make winelib apps. I guess you could take winedbg as an example winelib app. Lawson --- Just because it works for me, doesn't mean I know what I'm doing. ---cut here--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

June 25, 2001

Re: Win16 calls by Win32 functions

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Sure Win32 calls to Win16 should be eliminated that is > without question. This is how Windows NT does it and > Alexandre has a policy that Wine should doing like > Windows NT does. I fully agree. > > However I'm not positive that replacing Win16 calls to > Win16 with Win32 calls is always good idea. See below. As a rule it is a good idea, but there are of course exceptions. Basically the rule should be that wherever you can choose between a Win16 or Win32 function to do something, you should pick the Win32 function. But in the cases where the Win16 and Win32 functions have different semantics, then of course you have to use the correct one, even if in some cases it means calling Win16 functions from Win32 (like for the GlobalAlloc stuff). -- Alexandre Julliard julliard(a)winehq.com

June 25, 2001

RE: undefined reference to main in _start

by Gilroy Billard

No, it is not. Basically, I want to use wine_main and link the WINE source libraries into my project, for example, libmsvfw32.so, libwine.so, etc. This is what I did in the past and it worked fairly well. However, 20001202 and greater versions of WINE also require libntdll.so. This is fine too, but now I get an error "crt1.o undefined reference to main in _start". -----Original Message----- From: Francois Gouget [mailto:fgouget(a)free.fr] Sent: Monday, June 25, 2001 3:12 PM To: Gilroy Billard Cc: Uwe Bonnes; Wine-Devel(a)Winehq.Com Subject: RE: undefined reference to main in _start On Mon, 25 Jun 2001, Gilroy Billard wrote: > winemaker? no I didn't know there was such a thing. I will take a look at > it though. thanks Winemaker generates Makefiles to compile windows source with Winelib. But I don't think this is what you want to do, is it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

June 25, 2001

RE: undefined reference to main in _start

by Francois Gouget

On Mon, 25 Jun 2001, Gilroy Billard wrote: > winemaker? no I didn't know there was such a thing. I will take a look at > it though. thanks Winemaker generates Makefiles to compile windows source with Winelib. But I don't think this is what you want to do, is it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.

June 25, 2001

RE: undefined reference to main in _start

by Gilroy Billard

winemaker? no I didn't know there was such a thing. I will take a look at it though. thanks -----Original Message----- From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com]On Behalf Of Uwe Bonnes Sent: Monday, June 25, 2001 1:20 PM To: gilroy(a)trakonic.com Cc: Wine-Devel(a)Winehq.Com Subject: Re: undefined reference to main in _start >>>>> "Gilroy" == Gilroy Billard <gilroy(a)trakonic.com> writes: Gilroy> Hi, I can't link in any version of the WINE libraries after Gilroy> version 20001202 without getting a linker error: undefined Gilroy> reference to main in function _start. Gilroy> I compile WINE with these options: ./configure --without-x Gilroy> --without-curses --disable-debug --disable-trace. Gilroy> Any ideas??? Did you try with winemaker? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 25, 2001

Re: undefined reference to main in _start

by Uwe Bonnes

>>>>> "Gilroy" == Gilroy Billard <gilroy(a)trakonic.com> writes: Gilroy> Hi, I can't link in any version of the WINE libraries after Gilroy> version 20001202 without getting a linker error: undefined Gilroy> reference to main in function _start. Gilroy> I compile WINE with these options: ./configure --without-x Gilroy> --without-curses --disable-debug --disable-trace. Gilroy> Any ideas??? Did you try with winemaker? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 25, 2001

undefined reference to main in _start

by Gilroy Billard

Hi, I can't link in any version of the WINE libraries after version 20001202 without getting a linker error: undefined reference to main in function _start. I compile WINE with these options: ./configure --without-x --without-curses --disable-debug --disable-trace. Any ideas??? thanks, Gilroy Billard mailto:gilroy(a)trakonic.com Software Developer Trakonic Inc. PH: 1-902-450-0922 FX: 1-902-450-0939 1-877-419-3887 http://www.trakonic.com

June 25, 2001

RE: Win16 calls by Win32 functions

by Patrik Stridvall

> "Patrik Stridvall" <ps(a)leissner.se> wrote: > > > Noticing that you (Dimitry) have send in a few patch > > replacing Win16 calls by Win32 ones, I wish to > > point out that winapi_check can detect "illegal" > > calls from Win32 to Win16. > > > > Just do > > winapi_check --cross-call-win32-win16 > > Great! Why didn't you just make a patch and submit it? Well. Because I don't want to blindly do search and replace I haven't got around to do it since it will take some time to analyze each case for correctness. It is on my list of things to do but it has very low priority. But since you seems to be doing it, I might just as well tell you how to easily find many of them. > > Note that some of the fixes in your (Dimitry's) > > patches is not included in the result below > > because they are Win16 functions calling Win16 > > functions. > > > > I do not say this is nessary wrong, but are > > you (Dimitry) really sure this is how it should be? > > Well, as Alexandre already has pointed out, Win16 should be > mostly implemented by using Win32. I agree with him that use > of the 16-bit code should be eliminated as much as possible. > Moreover, until now I just have replaced only obvious places: > 16-bit functions which just thunk up to win32 without any > argument processing. Sure Win32 calls to Win16 should be eliminated that is without question. This is how Windows NT does it and Alexandre has a policy that Wine should doing like Windows NT does. I fully agree. However I'm not positive that replacing Win16 calls to Win16 with Win32 calls is always good idea. See below. > > Sure it probably runs a little faster, but then Win16 > > applications on a modern computer are likely to be > > _very_ fast, so it is really worth risking potential > > compabillity errors because of some probably irrelavant > > speed differences. > > > > Not that functions like DeleteObject are likely to > > have such problems but still... > > I'm not going to blindly replace 16-bit calls by 32-bit. > I look into the code and do think twice before submitting > a patch. Of course you are not, but there might be subtle issues that break the code in the future then the full Win32 semantics is implemented. That requires much more thinking than just casually browsing the code and reading the documentation. Actually just thinking and reading documentation is not enough either Win32 or Win16 might have undocumentation features on Windows not implement by Wine yet. Note that I'm not convinced is a large problem if any at all. I'm just worried and think we need to think this through carefully. So what should we do? Correct me if I'm wrong but because of the DLL separation Win16 to Win16 calls between different DLL:s (or rather different .so files) must not take place. I notice that, for example, user32.spec contains the following lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallNextHookEx16(long long long long) CallNextHookEx16 @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall SetWindowsHookEx16(long long long long) SetWindowsHookEx16 @ stdcall UserYield16() UserYield16 and gdi32.spec contains these lines: ################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CreateMetaFile16(str) CreateMetaFile16 @ stdcall CloseMetaFile16(long) CloseMetaFile16 This is what is guess Alexandre wants eliminated not calls like the call in SetDCState16 (Win16 GDI) to DeleteObject16 (Win16 GDI) that you "fixed" in one of your patches. Of course Win32 to Win16 calls should be fixed even within a DLL but that is because of possible different semantics not because of the DLL separation. In short I suggest the following policy 1. No Win32 to Win16 calls: This is because of semantic and speed reasons. 2. No Win16 to Win16 calls between different DLL:s: This is because of the DLL separation. 3. No Win16 to Win32 calls within a DLL (with the exception a function's Win32 counterpart or replacement in the case of obsolete function): This is because of semantic reasons but I'm not sure how hard we must enforce point, because if the the Win32 function generates a non Win16 message or some other non Win16 related stuff I guess we can quite easily can (and perhaps even now does) ignore or filter such things in more fundamental part of the code like in the message dispatching code.

June 25, 2001

Re: Win16 calls by Win32 functions

by Dmitry Timoshkov

"Patrik Stridvall" <ps(a)leissner.se> wrote: > Noticing that you (Dimitry) have send in a few patch > replacing Win16 calls by Win32 ones, I wish to > point out that winapi_check can detect "illegal" > calls from Win32 to Win16. > > Just do > winapi_check --cross-call-win32-win16 Great! Why didn't you just make a patch and submit it? > Unfortunately there is a bug in the CVS version > of winapi_check (fixed in my tree) that makes this > option output too many messages. However until > it is updated just do "grep 'illegal call'" on > the output. > > The result this is included below. > Note that some of the fixes in your (Dimitry's) > patches is not included in the result below > because they are Win16 functions calling Win16 > functions. > > I do not say this is nessary wrong, but are > you (Dimitry) really sure this is how it should be? Well, as Alexandre already has pointed out, Win16 should be mostly implemented by using Win32. I agree with him that use of the 16-bit code should be eliminated as much as possible. Moreover, until now I just have replaced only obvious places: 16-bit functions which just thunk up to win32 without any argument processing. > Sure it probably runs a little faster, but then Win16 > applications on a modern computer are likely to be > _very_ fast, so it is really worth risking potential > compabillity errors because of some probably irrelavant > speed differences. > > Not that functions like DeleteObject are likely to > have such problems but still... I'm not going to blindly replace 16-bit calls by 32-bit. I look into the code and do think twice before submitting a patch. Anyway, thanks for your comments. -- Dmitry.

June 25, 2001

Win16 calls by Win32 functions

by Patrik Stridvall

Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect "illegal" calls from Win32 to Win16. Just do winapi_check --cross-call-win32-win16 Unfortunately there is a bug in the CVS version of winapi_check (fixed in my tree) that makes this option output too many messages. However until it is updated just do "grep 'illegal call'" on the output. The result this is included below. Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions. I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be? Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences. Not that functions like DeleteObject are likely to have such problems but still... ---8<--- controls/menu.c: user32: GetSystemMenu: illegal call to GetSubMenu16 (Win32 -> Win16) dlls/kernel/comm.c: kernel32: BuildCommDCBAndTimeoutsA: illegal call to BuildCommDCB16 (Win32 -> Win16) dlls/msvideo/msvideo_main.c: msvfw32: ICClose: illegal call to ICSendMessage16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32: CLSIDFromProgID: illegal call to CLSIDFromProgID16 (Win32 -> Win16) dlls/ole32/compobj.c: ole32 & ole32: CLSIDFromString: illegal call to CLSIDFromString16 (Win32 -> Win16) dlls/ole32/storage.c: ole32: StgIsStorageFile: illegal call to StgIsStorageFile16 (Win32 -> Win16) dlls/shell32/shell.c: shell32: ExtractAssociatedIconA: illegal call to ExtractAssociatedIcon16 (Win32 -> Win16) dlls/winmm/mci.c: mmsystem & winmm: mciExecute: illegal call to mciSendString16 (Win32 -> Win16) dlls/winmm/mci.c: winmm: mciFreeCommandResource: illegal call to mciFreeCommandResource16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mciGetErrorStringA: illegal call to mciGetErrorString16 (Win32 -> Win16) dlls/winmm/mmsystem.c: winmm: mmsystemGetVersion: illegal call to mmsystemGetVersion16 (Win32 -> Win16) files/profile.c: kernel32: GetPrivateProfileSectionNamesW: illegal call to GetPrivateProfileSectionNames16 (Win32 -> Win16) graphics/escape.c: gdi32: ExtEscape: illegal call to Escape16 (Win32 -> Win16) loader/module.c: kernel32: WIN32_GetProcAddress16: illegal call to GetProcAddress16 (Win32 -> Win16) loader/ne/module.c: kernel & kernel32: FreeLibrary16: illegal call to FreeModule16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalFix16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalReAlloc16: illegal call to GlobalHandleToSel16 (Win32 -> Win16) memory/global.c: kernel & kernel32: GlobalWire16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) memory/global.c: kernel32: K32WOWGlobalLock16: illegal call to WIN16_GlobalLock16 (Win32 -> Win16) objects/clipping.c: gdi32: RectVisible: illegal call to RectVisible16 (Win32 -> Win16) objects/dc.c: gdi32: RestoreDC: illegal call to SetDCState16 (Win32 -> Win16) objects/metafile.c: gdi32: PlayMetaFileRecord: illegal call to PlayMetaFileRecord16 (Win32 -> Win16) objects/palette.c: gdi32: UpdateColors: illegal call to UpdateColors16 (Win32 -> Win16) windows/clipboard.c: user32: RegisterClipboardFormatA: illegal call to RegisterClipboardFormat16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateCursor: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: CreateIcon: illegal call to CreateCursorIconIndirect16 (Win32 -> Win16) windows/cursoricon.c: user32: DestroyCursor: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: DestroyIcon: illegal call to CURSORICON_Destroy (Win32 -> Win16) windows/cursoricon.c: user32: LookupIconIdFromDirectoryEx: illegal call to LookupIconIdFromDirectoryEx16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcA: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefFrameProcW: illegal call to DefFrameProc16 (Win32 -> Win16) windows/mdi.c: user32: DefMDIChildProcA: illegal call to DefMDIChildProc16 (Win32 -> Win16) windows/mdi.c: user32: ScrollChildren: illegal call to CalcChildScroll16 (Win32 -> Win16) windows/painting.c: user32: UserRealizePalette: illegal call to RealizePalette16 (Win32 -> Win16)

June 25, 2001

Re: undefined reference to main in _start

by G.LeeJ

Francois Gouget wrote: > On Mon, 25 Jun 2001, Gilroy Billard wrote: > > > winemaker? no I didn't know there was such a thing. I will take a look at > > it though. thanks > > Winemaker generates Makefiles to compile windows source with Winelib. > But I don't think this is what you want to do, is it? > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > We are Pentium of Borg. You will be approximated. Division is futile. i'm very surprised by how much wine is running for me....I do NOT know if it was RH ( as I'm trying Debian unstable at moment ) or just me...but i'm running things I don't recall working before &/or mabye the latest /greateste is just better than earlier ones I'd tried..... anyway goldisk works flawlessly so far in wine which is very nice....can't get sonic foundryes acid music yet but oh well not critical.....I tried to install flash 5.0....the installer 'tried' to start but bomber....plus ill check database ..... many things worked i was pleasantly surprised......very nice! thanks wine team this is great stuff..... tres merci lee -====

June 25, 2001

wine core dump

by Heiko Nardmann

I am not sure whether this mail reached the mailing list already partly. Due to some problem with KMail here is the full mail. Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #33 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #34 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a2114, context=0x404a2188) at exception.c:195 #35 0x40062509 in do_segv (context=0x404a2188, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #36 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078600924, sc_esi = 1074775150, sc_ebp = 1078600548, sc_esp = 1078600500, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078600500, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #37 <signal handler called> #38 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #39 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #40 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a24dc, context=0x404a2410) at exception.c:195 ---Type <return> to continue, or q <return> to quit--- #41 0x400629c4 in int_handler (__signal=2, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1074113920, sc_esi = 0, sc_ebp = 1078608284, sc_esp = 1078601232, sc_ebx = 1078608268, sc_edx = 810345475, sc_ecx = 17152, sc_eax = 1078601394, sc_trapno = 14, sc_err = 4, sc_eip = 2356908743, sc_cs = 35, __csh = 0, sc_eflags = 646, esp_at_signal = 1078601232, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 1078620009}) at signal_i386.c:893 #42 <signal handler called> #43 0x8c7b92c7 in ?? () #44 0xe in ?? () Cannot access memory at address 0x1 -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50

June 25, 2001

wine core dump

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Using CVS version from 23.6. I was able to produce a core dump trying to use Word97. Here is the session from gdb. I might provide the core file to anyone interested. snsrv053:nardmann[Word]>gdb /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/wine core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Core was generated by `/opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-200106'. Program terminated with signal 11, Speicherzugriffsfehler. Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_unicode.so Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libkernel32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libuser32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libgdi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libadvapi32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libole32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/librpcrt4.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshell32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libshlwapi.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libcomctl32.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwinspool.drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libx11drv.so Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/libwine_tsx11.so Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXxf86dga.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86dga.so.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.1 Reading symbols from /usr/lib/libGL.so.1...done. Loaded symbols for /usr/lib/libGL.so.1 Reading symbols from /usr/lib/libGLU.so.1...done. Loaded symbols for /usr/lib/libGLU.so.1 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so...done. Loaded symbols for /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libwineps.so #0 thread_errno_location () at thread.c:214 214 return &NtCurrentTeb()->thread_errno; (gdb) bt #0 thread_errno_location () at thread.c:214 #1 0x40292a15 in __sigprocmask (how=0, set=0x40114340, oset=0x404a1058) at ../sysdeps/unix/sysv/linux/sigprocmask.c:48 #2 0x400c99c6 in wine_server_call (req=0x404a1158, size=20) at client.c:196 #3 0x4005af51 in send_debug_event (rec=0x404a123c, first_chance=1, context=0x404a12b0) at exception.c:124 #4 0x4005b19f in EXC_RtlRaiseException (rec=0x404a123c, context=0x404a12b0) at exception.c:177 #5 0x40062509 in do_segv (context=0x404a12b0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #6 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078596916, sc_esi = 1074775150, sc_ebp = 1078596752, sc_esp = 1078596704, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078596704, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #7 <signal handler called> #8 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #9 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #10 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1534, context=0x404a15a8) at exception.c:195 #11 0x40062509 in do_segv (context=0x404a15a8, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #12 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078597676, sc_esi = 1074775150, sc_ebp = 1078597512, sc_esp = 1078597464, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078597464, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #13 <signal handler called> #14 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #15 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #16 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a182c, context=0x404a18a0) at exception.c:195 #17 0x40062509 in do_segv (context=0x404a18a0, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #18 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078598436, sc_esi = 1074775150, sc_ebp = 1078598272, sc_esp = 1078598224, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598224, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #19 <signal handler called> #20 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #21 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #22 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1b24, context=0x404a1b98) at exception.c:195 #23 0x40062509 in do_segv (context=0x404a1b98, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #24 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599196, sc_esi = 1074775150, sc_ebp = 1078599032, sc_esp = 1078598984, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078598984, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #25 <signal handler called> #26 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #27 0x400ff684 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine-CVS-20010623/dlls/libntdll.so #28 0x4005b1ea in EXC_RtlRaiseException (rec=0x404a1e1c, context=0x404a1e90) at exception.c:195 #29 0x40062509 in do_segv (context=0x404a1e90, trap_code=14, cr2=0xe1a253e4, err_code=6) at signal_i386.c:707 #30 0x4006285d in segv_handler (__signal=11, __context={sc_gs = 0, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1078599956, sc_esi = 1074775150, sc_ebp = 1078599792, sc_esp = 1078599744, sc_ebx = 1074787972, sc_edx = 1074787972, sc_ecx = 1074795488, sc_eax = 128, sc_trapno = 14, sc_err = 6, sc_eip = 1074788000, sc_cs = 35, __csh = 0, sc_eflags = 68226, esp_at_signal = 1078599744, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 0, cr2 = 3785511908}) at signal_i386.c:842 #31 <signal handler called> #32 0x400ff6a0 in __DTOR_END__ () from /opt/Source-Archive/mirrors/CompilationDir/i686-whatever-linux2/wine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Nu3bpm53PRScYygRAuYLAKDR49a+j/JDCirOmLCC48N1ql1rXgCg10Ah aOiXiUWyz02czaQc4jG1i8k= =W1KY -----END PGP SIGNATURE-----

June 25, 2001

Fallout Tactics problems

by Tim Oertel

Hi all, I sent this to wine-users, but got no response... so I'll assume I've hit a bug or three. I've successfully installed FT, and it sorta runs. Specifically: o It installed without problems. o It runs the intro animations and training walkthroughs, but the anims alternately play audio or video, pausing the other while one plays. o Character creation works, although the keyboard occasionally fails to work... not sure why. o Screen redraw is hosed when scrolling left or up. A ~64 pixel strip gets replicated across the screen... Clicking directly on the map redraws fine. I'm wondering if anyone knows what is going on or can suggest how to start debugging the scrolling problem. (I have plenty of debug experience and can figure things out, but I'm not familiar with wine, so am not sure where to start.) I'm using the latest CVS build as of 2001/06/20. Tim -- ////// toertel(a)rpa.net ///////////// // "Why should I be content to simply // / live in this world, when I, as a // human being, can CREATE it?" //

June 25, 2001

A pointer to some undoc functions

by Uwe Bonnes

Hallo, http://www.geocities.com/SiliconValley/4942/contents.html contains some explications about those undocumented functions in the win32 API mostly used bi explorer, iexplorer and friends. I took a look at the comctl32 MRU functions... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 24, 2001

[Problem report] X11DRV_GetDC

by Gerard Patel

This problem I see with Eudora (1.5 or 3.06 - I can't see it with Eudora 4 because it crashes before :-)). Using the option dialog box, everytime there is a checkbox or an option button, these buttons appear 2 times when switching from a page to another, one time at the correct place, one time off to the left. I think that the problem comes from the fact that the app paints outside of a WM_PAINT event. What happens is that when switching from a dialog 'page' to another, Eudora creates a hidden dialog with buttons on it, initialize the controls with the correct values from its config file, then reparent all the controls to the main dialog box. The hidden dialog box is a child of the main dialog box (but on this hidden dialog box, the controls are not at the place where they are supposed to be on the real dialog box). To be clearer, we have windows as follow (in the order parent->child) A : main dialog, style visible + clipsiblings B : work dialog, not visible + not clipsiblings C : a checkbox X11DRV_GetDC finds B as top window that is not clipsibling, then Wine use as drawable the parent of B : A. Then the checkbox is displayed somewhere on A. The following patch works around this particular problem, but I doubt that it's the best place to change. And, BTW, there are many other problems in current Cvs with my toy test suite :-/, problems that were not here a month ago, of course. To be fair the new code has removed *some* long standing problems, too. But on the balance it's still very bad. Gerard Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.10 diff -u -r1.10 winpos.c --- dlls/x11drv/winpos.c 2001/06/22 03:42:27 1.10 +++ dlls/x11drv/winpos.c 2001/06/24 10:50:45 @@ -387,8 +387,11 @@ /* find the top parent in the hierarchy that isn't clipping siblings */ top = NULL; - for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) - if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + if (IsWindowVisible(win->hwndSelf)) + { + for (ptr = win->parent; ptr && ptr->parent; ptr = ptr->parent) + if (!(ptr->dwStyle & WS_CLIPSIBLINGS)) top = ptr; + } if (!top && !(flags & DCX_CLIPSIBLINGS)) top = win;

June 24, 2001

Re: PATCH: MSDOS VGA mode

by Marcus Meissner

On Fri, Jun 22, 2001 at 02:44:06PM +0200, Ove Kaaven wrote: > > On Fri, 22 Jun 2001, Marcus Meissner wrote: > > > Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn > > doing inb(0x60) and the +io debugging giving back the correct scancode > > (0x1c on press and 0x9c on release). > > After reading the scancode, however, it determintes that it was not a > cursor key, so it passes it on to the DOS int9 handler for default > processing there. Then it expects the keypress to appear in the BIOS > keyboard buffer. I forgot I am also using the following additional patch (probably slightly incorrect for special keys): Index: dosvm.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/dosvm.c,v retrieving revision 1.6 diff -u -r1.6 dosvm.c --- dosvm.c 2001/05/14 20:09:38 1.6 +++ dosvm.c 2001/06/23 06:49:02 @@ -388,6 +388,7 @@ static void DOSVM_ProcessMessage(MSG *msg) { BYTE scan = 0; + BYTE xchar; TRACE_(int)("got message %04x, wparam=%08x, lparam=%08lx\n",msg->message,msg->wParam,msg->lParam); if ((msg->message>=WM_MOUSEFIRST)&& @@ -408,7 +409,8 @@ * should check for them */ INT_Int09SendScan(0xE0,0); } - INT_Int09SendScan(scan,0); + xchar = msg->wParam & 0xff; + INT_Int09SendScan(scan,xchar); break; } } This code is putting 0x0d/0x1c pairs into the keyboard buffer. > (You might have seen that if you also ran --debugmsg +int) I see those, and I see it appended to the keyboard buffer (even looking directly at the DOS image under /tmp/filexxxxx). However, monkey1.exe does not seem to read out this buffer, some keypresses later it is full. The BIOS data structures appear all ok. Trace snippet: trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x1c ) 0x60 < 1c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=1c fixme:int16:INT_Int16AddChar (0d,1c) fixme:int16:INT_Int16AddChar (0d,1c) at offset 30 trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing trace:int:DOSVM_PIC_ioport_out another event pending, signalling dosmod trace:int:DOSVM_Process DOS module caught signal 12 trace:int:DOSVM_Process setting Pending flag, interrupts are currently enabled trace:int:DOSVM_SendQueuedEvent dispatching IRQ 1 trace:int:DOSVM_SendQueuedEvent clearing Pending flag trace:int:IO_inport 1-byte value from port 0x60 trace:int:IO_inport returning ( 0x9c ) 0x60 < 9c @ 201a:1632 trace:int:DOSVM_SimulateInt builtin interrupt 09 has been branched to trace:int:INT_Int09Handler scan=9c trace:int:DOSVM_PIC_ioport_out received EOI for current IRQ, clearing Very puzzling. > I think we managed to get monkey island to start by fixing that keyboard > code. However, because of that annoying wineserver assertion failure, no > DOS apps like this run with my code anymore, so I can't check. Unless you > want to fix the wineserver assertion at server/console.c line 194, so > CONSOLE_make_complex can run in one thread while another winedos thread > keeps waiting for input? I do not get that assertion? I get keyboard input directly from the DirectDraw window with above message loop. Ciao, Marcus

June 23, 2001

Re: wrc error

by Francois Gouget

On Sat, 23 Jun 2001, Bang Jun-Young wrote: [...] > I added a line to parser.y (r1.26) as follows: > > --- parser.y 2001/06/06 21:04:08 1.26 > +++ parser.y 2001/06/23 04:28:52 > @@ -423,6 +423,7 @@ > want_id = 1; > dont_want_id = 0; > } > + | resources tNL > ; > > After doing that, I could build Wine successfully again. I'll > send a complete patch including above comment to wine-patches > soon. Great. I must admit I did not have time to look into this. I tested your patch on my machine and Wine still compiles fine with bison, so you can probably post it to wine-patches. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

June 23, 2001

Re: Word97 problems

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 23 June 2001 12:46, Heiko Nardmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > I am still trying to get Word97 up and running. > > Now I found out that Word tries to LoadLibrary() some MSO7DEU.DLL which > seems to be the language DLL. I saw that after failing to find it it tries > to find MSO7ENU.DLL. When failing with that, too, some kind of exception is > happening according to the log files and the message box described in > former mails appears. > > So I took this DLL from my Windows/Word installation and copied it into the > same folder as Word. Now I have the following Word files in one directory: > > - - winword.exe > - - wwintl32.dll > - - mso97.dll > - - mso7deu.dll > > No other Windows files are on my Linux machine except on the NT partition > which is NOT used during this tests. > > After starting it again I now get a different message box saying that my > registry is corrupt and I should rerun Word setup. I will further analyze > the logfiles to see which registry entries are needed ... > > This analyze has been done with todays CVS ... > Hmm ... the new message box has a Ok button but I can't click on it. Nothing happens. No visual feedback. Okay then I tried to close it using the KDE close button. The message box disappears and Word appears after a few seconds. The first time seeing the message box I interrupted the whole thing with Ctrl-C. Some debug messages appear on the screen although I did not specify anything (see below). I was able to type a few characters. Selecting items in the menus worked fine, too. Trying to open a file results in some message box saying that I have not enough memory. Hmm ... Where is this L"HP2200" stuff coming from? Is wine somehow parsing the printcap? fixme:dc:GetDeviceCaps (0088,94): DeviceCaps param CAPS1 is UNIMPLEMENTED, will yield 0! fixme:dc:GetDeviceCaps (0088,94): unsupported DeviceCaps capability, will yield 0! fixme:dialog:MSGBOX_OnInit system modal msgbox ! Not modal yet. err:psdrv:PSDRV_AFMGetCharMetrics missing ;, failed. [C 0 ; WX 600 ; N null] err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:psdrv:PSDRV_DeviceCapabilities16 no printerinfo for HP2200, return 0! err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:psdrv:PSDRV_DeviceCapabilities16 no printerinfo for HP2200, return 0! err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 87 err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry err:winspool:OpenPrinterW Can't find printer L"HP2200" in registry fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0031,0031,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0032,0032,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,00dc,00dc,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0033,0033,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0053,0053,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0064,0064,0x405b54f0), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0041,0041,0x405b54e4), returns slightly bogus values. fixme:font:GetCharABCWidthsW (0a3c,0074,0074,0x405b54f0), returns slightly bogus values. fixme:ole:CoRegisterMessageFilter stub fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL err:mmsys:MMDRV_InitHardcoded You didn't setup properly the config file for the Wine multimedia modules. Will use the hard-coded setup, but this will disapear soon. Please add a WinMM section to your Wine config file. fixme:string:EnumDateFormatsW (0x3013e860, 1031, 2): stub fixme:string:EnumDateFormatsW (0x3013e860, 7, 2): stub fixme:string:EnumDateFormatsW (0x3013e860, 1031, 2): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 1031, 1): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 7, 1): stub fixme:string:EnumDateFormatsW (0x3013e8ab, 1031, 1): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,1031,0): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,7,0): stub fixme:string:EnumTimeFormatsW (0x3013e8c7,1031,0): stub Created not existing system directory 'C:\My Documents' fixme:listview:LISTVIEW_Create ANSI notify format is NOT used fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:listview:LISTVIEW_Create ANSI notify format is NOT used server:truncated to 512 server:truncated to 1536 server:truncated to 2048 server:truncated to 2560 server:truncated to 3072 server:truncated to 3584 server:truncated to 4096 server:truncated to 4608 server:truncated to 5120 server:truncated to 5632 server:truncated to 6144 server:truncated to 6656 server:truncated to 10752 server:truncated to 11264 server:truncated to 15360 fixme:storage:StorageImpl_Commit (4): stub! fixme:storage:StorageImpl_Commit (4): stub! fixme:ole:WriteFmtUserTypeStg (0x403be1c0,c00e,L"Microsoft Word-Dokument") stub! fixme:storage:StorageImpl_SetElementTimes not implemented! fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL fixme:icon:DrawIconEx no flags set? setting to DI_NORMAL - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7NI8vpm53PRScYygRAqEZAJ9sR0w1caE5M1Tk0TB2vLGWxdvGcgCg5pnZ z1iSvwUEGrsVFkP24F4ioYU= =Y5ao -----END PGP SIGNATURE-----

June 23, 2001

Re: Problems loading mingw32 binaries (latest CVS)

by Vedran Rodic

On Sat, Jun 23, 2001 at 01:18:35PM +0200, Vedran Rodic wrote: > Hello > > It seems that some recent change (post 20010510) prevents binaries made with > mingw32 (at least with my mingw32 linux cross-compiler) to load. > > The error message is: > err:module:map_image Could not map section .text, file probably truncated > wine: can't exec 'a.exe': error=21 > > I've put one such binary and the source at: > http://quark.fsb.hr/vedran/wine > > Debian wine version 0.0.20010510-3 loads the binary fine. Found the problem: unaligned_mmap() in memory/virtual.c It seems that this is one more problem that happens when using gcc -O3. gcc -O2 produces code that loads a.exe without problems. Strangely, gcc-3.0 -O3 works just fine too. So it just might be a bug in gcc 2.95.4. But, another thing, that program should make circle shaped window, but it makes a circle shaped window with upper and left edges cut a bit. I guess more bugs to chase:) Vedran

June 23, 2001

Re: Initializing Dosvm for direct port access

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> What about checking if Dosvm.GetTimer is initialized and if it isn't >> initialized do give back the dummy value? At least the spde doesn't >> seem to care... Alexandre> How does the app behave under NT? Or with -winver nt40? With --winver nt40 the application tells about some unavailable VXDs. However I didn't bother to install the application with --winver nt40 ... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 23, 2001

Problems loading mingw32 binaries (latest CVS)

by Vedran Rodic

Hello It seems that some recent change (post 20010510) prevents binaries made with mingw32 (at least with my mingw32 linux cross-compiler) to load. The error message is: err:module:map_image Could not map section .text, file probably truncated wine: can't exec 'a.exe': error=21 I've put one such binary and the source at: http://quark.fsb.hr/vedran/wine Debian wine version 0.0.20010510-3 loads the binary fine. Vedran Rodic

June 23, 2001

Word97 problems

by Heiko Nardmann

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I am still trying to get Word97 up and running. Now I found out that Word tries to LoadLibrary() some MSO7DEU.DLL which seems to be the language DLL. I saw that after failing to find it it tries to find MSO7ENU.DLL. When failing with that, too, some kind of exception is happening according to the log files and the message box described in former mails appears. So I took this DLL from my Windows/Word installation and copied it into the same folder as Word. Now I have the following Word files in one directory: - - winword.exe - - wwintl32.dll - - mso97.dll - - mso7deu.dll No other Windows files are on my Linux machine except on the NT partition which is NOT used during this tests. After starting it again I now get a different message box saying that my registry is corrupt and I should rerun Word setup. I will further analyze the logfiles to see which registry entries are needed ... This analyze has been done with todays CVS ... - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7NHOhpm53PRScYygRAq7CAJ0YjojtnRdiX5OthOvPEkN4MUY1ugCbB+3e b3QaEHg3OaBl8c0yn0cRKpg= =nMdS -----END PGP SIGNATURE-----

June 23, 2001

Re: wrc error

by Bang Jun-Young

On Fri, Jun 15, 2001 at 08:09:54AM -0700, Francois Gouget wrote: > I wanted a preprocessed version of the user32.rc file. But Bang > Jun-Young sent me the files generated by flex/bison which allowed me to > reproduce the problem. I have not yet found a fix but the problem is in > the y.tab.c file. > > Bang Jun-Young is using byacc while I'm using bison so the files are > quite different and about impossible to compare. When I compile > parser.y I get: > > bison -y -d -t ./parser.y > conflicts: 2 shift/reduce I get the same warning with byacc. > Maybe that's the source of the problem: byacc resolves the conflicts > differently from bison which causes tehe parse to fail. Now I think I have found the reason. It was due to a bug in byacc. From parser.y of revision 1.25: | tNL /* * This newline rule will never get reduced because we never * get the tNL token, unless we explicitely set the 'want_nl' * flag, which we don't. * The *ONLY* reason for this to be here is because Berkeley * yacc (byacc), at least version 1.9, has a bug. * (identified in the generated parser on the second * line with: * static char yysccsid[] = "@(#)yaccpar 1.9 (Berkeley) 02/21/93"; * ) * This extra rule fixes it. * The problem is that the expression handling rule "expr: xpr" * is not reduced on non-terminal tokens, defined above in the * %token declarations. Token tNL is the only non-terminal that * can occur. The error becomes visible in the language parsing * rule below, which looks at the look-ahead token and tests it * for tNL. However, byacc already generates an error upon reading * the token instead of keeping it as a lookahead. The reason * lies in the lack of a $default transition in the "expr : xpr . " * state (currently state 25). It is probably ommitted because tNL * is a non-terminal and the state contains 2 s/r conflicts. The * state enumerates all possible transitions instead of using a * $default transition. * All in all, it is a bug in byacc. (period) */ I added a line to parser.y (r1.26) as follows: --- parser.y 2001/06/06 21:04:08 1.26 +++ parser.y 2001/06/23 04:28:52 @@ -423,6 +423,7 @@ want_id = 1; dont_want_id = 0; } + | resources tNL ; After doing that, I could build Wine successfully again. I'll send a complete patch including above comment to wine-patches soon. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

June 23, 2001

Re: Readconsole, was libreadline for winedbg

by eric pouech

> investigating further, I found that winedbg uses ReadConsole to get what the > debug-user typed in, however ReadConsole by far doesn't behave as > expected, namely to give back the VT100 codes for what the user typed in. At > present arrow key presses are never delivered to winedbg well I tested it on NT2000, and arrows are not given back to the app using ReadConsole. So, it's winedbg which is at fault and should use ReadConsoleInput instead, but it would mean that the line editing should be heavily revisited to switch from a VT100 to a input_record style of input... a nicer fix would be to implement the ENABLE_LINE_INPUT mode for the console (so that the line edition would be done in the Wine code). we would lost the emacs-like keys usage (unless we had a Wine specific ENABLE_EMACS_LINE_INPUT mode to the console) > and if winedbg runs > on the staring console, input is only delivered to winedbg after the user > entered "Enter". yes. this is because, when the console is allocated on a current term, stdin is not set to raw mode. here again, it means another rewrite (the underlying stdin must be set to raw (at least resetting ICANON), and all the line editing logic must be taken care of by wine (including echoing the input characters) so, not to restart the discussion, but the libreadline inclusion (if any) would be more appropriate in the wine core code rather than in winedbg :-( A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

June 23, 2001

Re: wine/ dlls/x11drv/winpos.c windows/x11drv/event.c

by Guy L. Albertelli

With the patch "Don't rely on X to expose windows covered by a sibling, do it manually. (6/21)" installed, it seems that most (possibly all) of the painting problems have been fixed. Great job!! There are two other outstanding problems remaining: 1. With ControlSpy (REBAR.EXE), WinRAR, and IE4 and native controls (commctrl, comctl32): The 01/03/15 cvs, when the mouse moves over the gripper, the cursor changes to linked left & right arrows. When the left button is pressed, the cursor is changed to a small double gripper with left & right arrows. The selected band can then be dragged. At the 01/06/01 cvs, the cursor is not changed either before the left button push or after. However the selected band can still be dragged. With the current cvs (01/06/22), the cursor is changed to the linked left & right arrows, but the area where the change occurs is much smaller. The cursor goes back to the normal arrow after the left button is pressed. The selected band can then be dragged, but is less responsive that the other two cases by about 50%. 2. This is with -managed mode and both examples involve the X-window being minimized (current cvs 6/22): With IE4 and native controls (commctrl, comctl32), when typing in the address box and "enter" is hit, the Xwindow is minimized and the data is processed. With our code, the enter is ignored. With WinRAR and native controls (commctrl, comctl32), selecting the settings dialog and replying OK results in the main window being mimimized. Selecting cancel (or other dialog boxes) do not cause mimimization. Guy

June 23, 2001

ChooseFont dialog problems.

by kenon＠go2.pl

Hello, I'm trying to make choosefont dialog working. (I'm not sending this patch to wine-patches because it is incomplete ,and I rather need some ideas ) First hunk of the patch allows changing font colors in 16-bit apps , and it seems to work properly. Second and third hunk affects both 16 and 32 bit apps ,and my intention is to fix CF_INITTOLOGFONTSTRUCT style handling. It almost works ,but code in dlls/commdlg/fontdlg.c is very cryptic (was it based on original Micro$oft code ? :-) ) . Should it be wrtitten from beginning :-( ? Trying to patch this file resemble hard patchwork :-) or else I spent too little time on trying to understand the file. Maciek --- /home/mkalisz/wine/dlls/commdlg/fontdlg.c Tue Jun 19 05:34:07 2001 +++ dlls/commdlg/fontdlg.c Sat Jun 23 01:27:57 2001 @@ -220,6 +220,7 @@ } lpChFont->lpTemplateName=lpTemplateName; + lpChFont->rgbColors=cf32a.rgbColors; font16 = MapSL(lpChFont->lpLogFont); font16->lfHeight = cf32a.lpLogFont->lfHeight; @@ -782,7 +783,7 @@ j=SendDlgItemMessageA(hDlg, cmb3, CB_GETCOUNT, 0, 0); for (i=0;i<j;i++) { - if (lpxx->lfHeight==(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) + if (lpxx->lfHeight==-(int)SendDlgItemMessageA(hDlg,cmb3, CB_GETITEMDATA,i,0)) SendDlgItemMessageA(hDlg,cmb3,CB_SETCURSEL,i,0); } } @@ -1000,6 +1001,7 @@ return TRUE; } } + break; case chx1: case chx2: case cmb2:

June 23, 2001

Re: Initializing Dosvm for direct port access

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > What about checking if Dosvm.GetTimer is initialized and if it isn't > initialized do give back the dummy value? At least the spde doesn't seem to > care... How does the app behave under NT? Or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

June 23, 2001

Re: PATCH: MSDOS VGA mode

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I think we managed to get monkey island to start by fixing that keyboard > code. However, because of that annoying wineserver assertion failure, no > DOS apps like this run with my code anymore, so I can't check. Unless you > want to fix the wineserver assertion at server/console.c line 194, so > CONSOLE_make_complex can run in one thread while another winedos thread > keeps waiting for input? Did you try to simply remove the assert? I think the way the select is done now, it should actually work fine, and the assert should no longer be necessary. -- Alexandre Julliard julliard(a)winehq.com

June 23, 2001

word wrapping in ListViews

by Bill Medland

Does anyone know where the word-wrapping occurs in CListView objects? In the MFC code or lower down? One of the issues we face with our app is that on Windows when icons are displayed in a CListView and the label is significantly wider than the icon then I note that the label is written on two lines whereas under Wine it is displayed truncated on a single line. I am trying to figure out where the fault is. Does anyone know? Bill

June 22, 2001

Re: PATCH: MSDOS VGA mode

by Ove Kaaven

On Fri, 22 Jun 2001, Marcus Meissner wrote: > Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn > doing inb(0x60) and the +io debugging giving back the correct scancode > (0x1c on press and 0x9c on release). After reading the scancode, however, it determintes that it was not a cursor key, so it passes it on to the DOS int9 handler for default processing there. Then it expects the keypress to appear in the BIOS keyboard buffer. (You might have seen that if you also ran --debugmsg +int) I think we managed to get monkey island to start by fixing that keyboard code. However, because of that annoying wineserver assertion failure, no DOS apps like this run with my code anymore, so I can't check. Unless you want to fix the wineserver assertion at server/console.c line 194, so CONSOLE_make_complex can run in one thread while another winedos thread keeps waiting for input? Hmm, but it looks like I may already have rewritten the interrupt separation for int9 enough, maybe I could submit that patch independently of the new DOS event loop (if you don't need the high performance the new event handling sustains)?

June 22, 2001

Re: PATCH: MSDOS VGA mode

by Marcus Meissner

On Sun, Jun 17, 2001 at 11:14:15PM +0200, Ove Kaaven wrote: > > On Sun, 17 Jun 2001, Marcus Meissner wrote: > > > However, Monkey Island does not appear to get <return> presses. I see > > in 60 returning scancode 0x1c (and 0x9c on release), but it never triggers > > any reaction :( > > Yes, the relevant code in msdos/int09.c is stiff #if 0-ed out in the Wine > CVS. I think I have some stuff fixing it lying around in my old Wine tree, > but it was rejected in its first form, so it might need a rewrite. > But the vm86 restructure is probably more important... Hmm. Not really, I do see int9 delivered to monkey1.exe and monkey1.exe in turn doing inb(0x60) and the +io debugging giving back the correct scancode (0x1c on press and 0x9c on release). It however does not react on it :/ Ciao, Marcus

June 22, 2001

Re: server:truncated to 32768

by Adriaan Moors

David Hagood wrote: > With a fresh build of last night's CVS pull, when I attempt to run > Delorme's AAA MapNGo V4.0, I get the following error condition: > > server:truncated to 32768 > server:truncated to 32768 > > At this point the main window of the application is up. However, if I > try to do anything non-trivial with the app, it coughs up this error: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 1 (X_CreateWindow) > Serial number of failed request: 1663 > Current serial number in output stream: 1668 maybe this is related to my problem? i get a similar error with programs that create a tray icon (but even notepad gives probs when i open help..about) (see post "problem in create_icon_window ...") regards adriaan -- But let me tell you, the slim lazy Homer you knew is dead. Now I'm a big fat dynamo. -- Homer Simpson (in "King-Size Homer")

June 21, 2001

Re: Initializing Dosvm for direct port access

by Uwe Bonnes

>>>>> "Ove" == Ove Kaaven <ovehk(a)ping.uio.no> writes: Ove> On Thu, 21 Jun 2001, Uwe Bonnes wrote: >> Hallo Ove, >> >> is something like appended patch right to get direct port access >> working for a win95 program? At least my dongle protected program >> (spde) doesn't crash any more and recognizes the license. Ove> I meant to reply sooner or later... it doesn't seem right to me to Ove> load the entire DOS subsystem for reading out the timer. Direct Ove> port access is probably not allowed for win32 apps under NT anyway? Ove> Perhaps there should be a fallback there for when the DOS subsystem Ove> is not loaded? Then again, I'm not sure how it's supposed to Ove> work... it probably can't hook the timer interrupt or set the timer Ove> rate or anything without upsetting the OS? What about checking if Dosvm.GetTimer is initialized and if it isn't initialized do give back the dummy value? At least the spde doesn't seem to care... @@ -291,7 +303,7 @@ else { dummy_ctr -= 1 + (int)(10.0 * rand() / (RAND_MAX + 1.0)); - if (chan == 0) /* System timer counter divisor */ + if ((chan == 0) && (Dosvm.GetTimer))/* System timer counter divisor */ { /* FIXME: Dosvm.GetTimer() returns quite rigid values */ tempval = dummy_ctr + (WORD)Dosvm.GetTimer(); @@ -450,8 +470,9 @@ case 0: /* latch timer */ tmr_8253[chan].latched = TRUE; dummy_ctr -= 1 + (int)(10.0 * rand() / (RAND_MAX + 1.0)); - if (chan == 0) /* System timer divisor */ - tmr_8253[chan].latch = dummy_ctr + (WORD)Dosvm.GetTimer(); + if ((chan == 0) && (Dosvm.GetTimer))/* System timer divisor */ + tmr_8253[chan].latch = dummy_ctr + + (Dosvm.GetTimer)?(WORD)Dosvm.GetTimer():0; else { /* FIXME: intelligent hardware timer emulation needed */ -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

June 21, 2001