June 2001 - wine-devel

Re: wine/ dlls/x11drv/winpos.c windows/x11drv/event.c
by Guy L. Albertelli 23 Jun '01

23 Jun '01

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

1 0

ChooseFont dialog problems.
by kenon＠go2.pl 23 Jun '01

23 Jun '01

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:

1 0

Re: PATCH: MSDOS VGA mode
by Alexandre Julliard 23 Jun '01

23 Jun '01

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

1 0

word wrapping in ListViews
by Bill Medland 22 Jun '01

22 Jun '01

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

1 0

server:truncated to 32768
by David Hagood 21 Jun '01

21 Jun '01

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 and one of the app threads dies. However, the main app window is still up, and four of its threads (plus the wineserver) are still alive. The app stops responding to the system, however. Where do I start on debugging this? What should I trace?

2 1

Initializing Dosvm for direct port access
by Uwe Bonnes 21 Jun '01

21 Jun '01

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. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- hertz:/spare/bon/wine-clean> cvs -d $CVSROOT diff -uw -7 wine/msdos/ioports.c Index: wine/msdos/ioports.c =================================================================== RCS file: /home/wine/wine/msdos/ioports.c,v retrieving revision 1.24 diff -u -w -7 -r1.24 ioports.c --- wine/msdos/ioports.c 2001/05/09 17:31:35 1.24 +++ wine/msdos/ioports.c 2001/06/21 08:23:57 @@ -227,14 +227,15 @@ static void IO_port_init(void) { char temp[1024]; do_direct_port_access = 0; /* Can we do that? */ + DPMI_LoadDosSystem(); if (!iopl(3)) { iopl(0); PROFILE_GetWineIniString( "ports", "read", "*", temp, sizeof(temp) ); do_IO_port_init_read_or_write(temp, IO_READ); PROFILE_GetWineIniString( "ports", "write", "*",

2 2

Press: OsOpinion: Putting a Bad API on a Good OS
by Francois Gouget 20 Jun '01

20 Jun '01

Hi, A nice article with a provocative title. What I like about it is that it addresses the main objection of Linux hardcore users to Wine (at least as seen from Slashdot): will Wine hurt Linux? But judge for yourself :-) http://www.osopinion.com/perl/story/11297.html -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 1

Re: Still more clipping issues - but getting better
by r.maurizzi＠gvs.it 20 Jun '01

20 Jun '01

I'm using Lotus Notes 4.6, and with the last updates wirtualy all clipping problems were solved. The problem now is that every time I type a character in the editor, the whole window gets repainted 8-) and sometimes I can't see the cursor or a text selection I make. How can I help? Ciao, Roberto.

1 0

Still more clipping issues - but getting better
by Guy L. Albertelli 20 Jun '01

20 Jun '01

Hi Alexandre, The latest commits (through "Clip parent client area when using the drawable from a higher level parent." julliard@wine2. 01/06/19 20:22:40) have fixed the problem mentioned in the previous email. However certain problems still exist. The attached JPG shows the results with the latest commits and the native control when the second band is deleted (band # 1). Somehow it never erases the band. This did work correctly in 6/1 CVS. Recreation instructions: Select RB_DELETEBAND and change the first zero (second line) to a 1 and send it. The second band with the ComboBoxEx should disappear. There is another issue with IE4 (one of my test programs). When a string is typed into the address line (a ComboBoxEx) and "return" pressed, the entire IE window disappears. IE is still running and by selecting the item in the GNOME taskbar, the IE window reappears correctly. Thanks a lot, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Still clipping issues
by Guy L. Albertelli 19 Jun '01

19 Jun '01

The REBAR ControlSpy (as a simple test application) still displays clipping/drawing issues since 6/1/2001 even with the native control. The enclosed JPG shows some of the problems. The method for recreation is to select the Styles menu and then select the Recreate Control button. At the end of the redraw cycle the distortion is as shown. Note the partial combobox dropdown arrow just below the word "Control_" in the center of the screen. This seems to be due to an unclipped rectangle/too large a client area during the ComboBoxEx creation. In the 6/1 CVS version, you can see the same dropdown arrow but it is within the left hand control window not beyond. Note also the badly drawn text in the two listboxes to the right. If there is anything I can supply to help fix this please let me know. Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>>

1 0

Re: PATCH: wine-config
by Alexandre Julliard 19 Jun '01

19 Jun '01

Malte Starostik <malte(a)kde.org> writes: > For example if the winelib app is only part of a project that for some reason > has its own Makefile management and/or merges its own rules with the ones for > wine. Yes, this refers to activexproxy where we currently have a self-written > configure check, but I could imagine other places where this might be of > interest... Well, of course you don't have to use the complete configure and makefile generated by winemaker, you can just take the subset you need and copy it into your makefiles. But I don't see how a wine-config could help you do that. Also I don't see why you'd necessarily want to use the same flags to compile your winelib app that have been used to compile wine itself; in fact you may not even be using the same compiler. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: wine-config
by Alexandre Julliard 19 Jun '01

19 Jun '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > to help winelib using developers, this program exports flags and directories > to /usr/bin/. > > I am not sure whether exported cflags and libs are ok. > > Hmm, we probably should also tell how to build .so libs. And specs -> .cs. > (Hmm, supply Makefile snippets?) Actually we already have winemaker that can generate a complete configure and makefile, so I'm not sure what purpose a wine-config would serve. -- Alexandre Julliard julliard(a)winehq.com

2 1

problem in create_icon_window in x11drv/window.c ?
by Adriaan Moors 19 Jun '01

19 Jun '01

hi just checked out wine from cvs today (exams are finally over ;-)), and tried to run WinMX (which ran fine, and still runs fine, using the precompiled cvs i have from june 9th), now with today's cvs i get this error: (i think it happens when the window for the tray icon is created...) <snip> trace:x11drv:create_icon_window created 280000d X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 89 Current serial number in output stream: 94 <wine exits> when i comment out the TSXCreateWindow in create_icon_window, the program starts up, but the windows keep moving about... i'm sorry if this is not the right newsgroup to post to, i hope it's not something i've done wrong regards, adriaan moors -- ADDING "JUST KIDDING" DOESN'T MAKE IT OKAY TO INSULT THE PRINCIPAL Bart Simpson on chalkboard in episode 2F09

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Trying to claim, even though you didn't, that Winelib is > > effected is absurd since it is independent of the debugger. > > Distributing the debugger with WineLib is merly an aggregation > > nothing more. > > In theory any library that the debugger uses will also fall under the > GPL. In _theory_ yes, but hardly in pratices. No sane court would claim that, not even, would I dare say, the one of Judge Kaplan of DeCSS fame. Of course Microsoft (I can't remember the link but search on Slashdot) do claim it in their FUD campaign against the GPL but that doesn't make it true. Whether the GPL:ed is designed to be a "virus" or not is one thing that I will not argue for or against, but copyright law defintely isn't, so I will be quite hard for it to spread in the real world. > And someone shipping Wine binaries may not be aware that parts of > it need to be GPLed, and they will get flamed to death on Slashdot. That is a very convincing argument, yes. :-) > I mostly agree with you that the FSF stance on dynamic linking has no > basis in copyright law, but I'm not interested in providing the test > case. So if you want to use readline you can patch your local copy, > but I won't ship this in the main distribution. I was pretty sure that would be your answer.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, you are right that that code should be revised and duplications > must be remove. But since I'm not an expert in the win32 communications code, > I can't do it without risk to break a working code. This patch was mostly > inspired by the fact, that while USER exports 16-bit comm stuff, that stuff > is not in the USER code. Instead of doing an ugly thing exporting 16-bit comm > functions from KERNEL I decided to move the code around. Please consider the > applying of the patch as it is now. Code duplication can be removed later. No, I'm afraid it won't be fixed if it is moved to a separate file. Also the split is not going to help for dll separation anyway, since the 16-bit routines use the SERVICE_* functions that aren't exported. So if you want clean dll separation the only choice is to rewrite the 16-bit routines. Any volunteer? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Trying to claim, even though you didn't, that Winelib is > effected is absurd since it is independent of the debugger. > Distributing the debugger with WineLib is merly an aggregation > nothing more. In theory any library that the debugger uses will also fall under the GPL. And someone shipping Wine binaries may not be aware that parts of it need to be GPLed, and they will get flamed to death on Slashdot. I mostly agree with you that the FSF stance on dynamic linking has no basis in copyright law, but I'm not interested in providing the test case. So if you want to use readline you can patch your local copy, but I won't ship this in the main distribution. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No, it is enough that it is GPL compatible which the Wine > license is. > > But then the code can no longer be distributed under a non GPL > compatible license, while this is allowed by the Wine license. winedbg _binaries_ compiled with --enable-readline quite possibly. As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work. In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned. Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever". Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not. The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries. As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it. > I think the benefit of using readline in the debugger is much too > small to justify the potential license issues this would cause. Only the debugger (winedbg) links with readline => only the debugger can be effected. Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Move 16-bit COMM stuff to USER, where it belongs. While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > No, it is enough that it is GPL compatible which the Wine license is. But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license. I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause. -- Alexandre Julliard julliard(a)winehq.com

1 0

Lost mail
by Alexandre Julliard 18 Jun '01

18 Jun '01

Folks, I have been forced to change ISPs over the week-end, and it seems the old and new ISP couldn't agree on when to do the switch, so any mail sent to me during the week-end probably got forwarded to /dev/null. Also could people who submitted a patch to wine-patches please send me a private copy? I know they are on the mailing list archive, but it makes my life a lot easier to have everything in my mail box. Thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

set_file_pointer and 64 bit file access
by Bill Medland 18 Jun '01

18 Jun '01

I see we are in the middle of converting set_file_pointer towards 64 bit file systems. Currently the code is confused as to when to change from unsigned to signed int for the low 32 bits. Should it happen in SetFilePointer before sending the request (which means we end up changing the request format) or should it happen within set_file_pointer (after changing the argument back to a signed int; this would also require work in SetFilePointer to get it to set up the request correctly). Any views? Bill

1 0

RE: Use the libreadline in Winedbg, if available
by Ove Kaaven 18 Jun '01

18 Jun '01

On Mon, 18 Jun 2001, Patrik Stridvall wrote: > A minor notice. Readline is GPL:ed (not LGPL:ed) which is not so good. > While it is without doubt legal for us to use and distribute, > it might cause trouble for other people. Not as long as it's optional (that patch even supported ./configure --without-readline, so no trouble, such people would just disable it).

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 18 Jun '01

18 Jun '01

> On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > > Hallo, > > > > at present, wine uses unconditionally a self supplied readline > > function. Appended patch tries to find out if libreadline > is available > > and uses libreadline if available. I configured with and without > > libreadline and successfully compiled winedbg on my system. > > libreadline is a static library on my system and winedbg > grew 90 kByte > > stripped and 110 kByte compiled with -g. > > You are not allowed to link readline aganst non GPL code to > my knowledge. No, it is enough that it is GPL compatible which the Wine license is. Whether we should is another matter though. Just linking it to the debugger is rather harmless IMHO though.

2 1

Re: Use the libreadline in Winedbg, if available
by Marcus Meissner 18 Jun '01

18 Jun '01

On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > Hallo, > > at present, wine uses unconditionally a self supplied readline > function. Appended patch tries to find out if libreadline is available > and uses libreadline if available. I configured with and without > libreadline and successfully compiled winedbg on my system. > libreadline is a static library on my system and winedbg grew 90 kByte > stripped and 110 kByte compiled with -g. You are not allowed to link readline aganst non GPL code to my knowledge. Ciao, Marcus

1 0

Dosvm not initialized for Direct port access
by Uwe Bonnes 18 Jun '01

18 Jun '01

Hallo, some license manager dll (lmgr327a) manages to read IOPORT 0x40 from 32-bit code. This results in an access to Dosvm.GetTimer() in line 297 in ioports.c, and as Dosvm isn't initialized this results in a crash. =>0 0x00000000 (ebp=404e4b38) 1 0x400cd595 (IO_inport+0x205(port=0x40, size=0x1) [ioports.c:297] in libntdll.so) (ebp=404e4b38, null call assumed) 2 0x400a7405 (INSTR_inport+0x25(port=0x40, size=0x1, context=0x404e4c50) [instr.c:328] in libntdll.so) (ebp=404e4b58) 3 0x400a888c (INSTR_EmulateInstruction+0x12cc(context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50, context=0x404e4c50) [instr.c:745] in libntdll.so) (ebp=404e4bc4) 4 0x400733c9 (do_segv+0x109(context=0x404e4c50, trap_code=0xd, cr2=0x0, err_code=0x0) [signal_i386.c:671] in libntdll.so) (ebp=404e4c2c) 5 0x4007368d (segv_handler+0x3d(__signal=0xb, __context=0x0) [signal_i386.c:787] in libntdll.so) (ebp=404e4d1c) 6 0x4029fb58 (__restore [sigaction.c] in libc.so.6) (ebp=405f57a0) 7 0x1c0b0004 (LMGR327A.DLL..reloc+0xbfe2004) (ebp=04007242) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2001