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

RegSetValueEx problem?

by davep

I've been trying to track down why WineMine does not save my best scores ;-( On exit, WineMine saves the current user settings to the registry with code like this: char data[16]; wsprintf( data, "%d", p_board->pos.x ); RegSetValueEx( hkey, "Xpos", 0, REG_SZ, (LPBYTE) data, sizeof( data )); The problem here is that the 'count' parameter passed to RegSetValueEx is not the string length but the size of the entire buffer. Wine dutifully writes into the registry the entire buffer including the trailing garbage, and also adds a null to the end if there isn't one there. When WineMine tries to read the value back it is now 17 characters long and too big to fit in the 16-byte buffer. Compiling and running Winemine under Windows 95 this problem doesn't occur. Win95 truncates the value at the first null. So RegSetValueEx needs fixing. However there are already comments in there about the differences between 95 and NT in the handling of REG_SZ values, and I don't have an NT system to carry out checks. Can someone with experience propose a solution? -- Dave Pickles

March 31, 2001

Sendmessage fix..

by crazney

Hey, im writing cause i presently use Andreas Mohr's sendmessage fix (titled TEB fix, because it stop the TEB errors).. basically, what the patch does, is clean up after a killed SendMessage if it didnt clean itsself up.. (well something like that, iirc).. anyway, i run the LHL howto page, and this patch is very useful to running Half-Life and several other games/programs.. so itd be nice to have it in CVS.. which it isnt presently.. when Andreas Mohr first wrote the patch, he told me that alexandre denied it, and neither him, ove or myself can work out why.. so yer, i'd just like to know a) why was it refused.. and b) can you put it in now, or write something which does just this now.. thanks in advance ps, can you please email me about this, because im not subscribed to this list. cheers David -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Hammerton aka crazney Victoria, Australia http://crazney.net/ HOWTO maintainer and Linux Half-Life http://lhl.linuxgames.com/ email: http://crazney.net/contact.html -> Note: this email address expires after one week.

March 31, 2001

Re: [PATCH] HOOK_CallHook

by Michael Stefaniuc

On Fri, Mar 30, 2001 at 12:54:06AM -0500, James Juran wrote: > James Juran wrote: > > > > Ulrich Weigand wrote: > > [...] > > > I've managed to reduce the problem to a simple testcase, which is > > > appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... > > > > Running this program with Red Hat's gcc-2.96-74 still produces the > > error. I'm downloading -79 now and will test that. Has this been > > reported to Red Hat's Bugzilla? I'll submit it if you don't want to. > > Same results with -79. It fails with -O2, but passes with -O2 > -fno-gcse. Tested also the very last version -80, same problem. I've forwarded yesterday Francois email to Jakub Jelinek and I'm making now the bugzilla entry. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

March 30, 2001

Re: OpenGL Visual Management ... continued.

by lawson_whitney＠juno.com

On Fri, 30 Mar 2001, Gavriel State wrote: > > Ok - this is what I'll explore further then. It may be a few more days > before I can get to it though, since it looks like I'm going to be a daddy > in a few hours. 8-) > > -Gav > Don't let me stop you. :-) I lived with local patches for about 3 months while file handles were getting sorted out, I guess I can give you a few days - hell, take a week if you need it. I just hope the wine-users don't catch us. Lawson ---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.

March 30, 2001

Re: [PATCH] HOOK_CallHook

by James Juran

James Juran wrote: > > Ulrich Weigand wrote: > [...] > > I've managed to reduce the problem to a simple testcase, which is > > appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... > > Running this program with Red Hat's gcc-2.96-74 still produces the > error. I'm downloading -79 now and will test that. Has this been > reported to Red Hat's Bugzilla? I'll submit it if you don't want to. Same results with -79. It fails with -O2, but passes with -O2 -fno-gcse. -- James Juran jamesjuran(a)alumni.psu.edu

March 30, 2001

Re: [PATCH] HOOK_CallHook

by Michael Veksler

I tested this with 2 newer gcc versions: gcc version 3.0 20010305 (prerelease) gcc version 2.97 20010122 (experimental) Both print PASS, when compiling with -O2. Michael

March 30, 2001

Re: OpenGL Visual Management ... continued.

by Gavriel State

lawson_whitney(a)juno.com wrote: > > At a guess - the privately created ColorMaps need to take their initial colors > > from the Default Color Map? > > That sounds about right. Oh, at one point I reverted only wnd.c - no > difference - then palette.c. Colors seemed better with the pointer off > the window IIRC, but it still went to black and white withe the pointer > on the desktop. Ok - this is what I'll explore further then. It may be a few more days before I can get to it though, since it looks like I'm going to be a daddy in a few hours. 8-) -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 30, 2001

Re: [PATCH] HOOK_CallHook

by James Juran

Ulrich Weigand wrote: [...] > I've managed to reduce the problem to a simple testcase, which is > appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... Running this program with Red Hat's gcc-2.96-74 still produces the error. I'm downloading -79 now and will test that. Has this been reported to Red Hat's Bugzilla? I'll submit it if you don't want to. james[1]%gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.0) james[2]%rpm -qi gcc Name : gcc Relocations: (not relocateable) Version : 2.96 Vendor: Red Hat, Inc. Release : 74 Build Date: Sat 03 Feb 2001 06:49:13 PM EST Install date: Mon 12 Feb 2001 12:02:51 AM EST Build Host: porky.devel.redhat.com Group : Development/Languages Source RPM: gcc-2.96-74.src.rpm Size : 8444185 License: GPL Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://gcc.gnu.org Summary : Various compilers (C, C++, Objective-C, Chill, ...) Description : The gcc package contains the GNU Compiler Collection: cc and gcc. You'll need this package in order to compile C/C++ code. james[3]%gcc -O2 test.c james[4]%./a.out FAIL james[6]%gcc -O2 -fno-gcse test.c james[7]%./a.out PASS james[8]%exit Script done on Fri Mar 30 00:09:36 2001 -- James Juran jamesjuran(a)alumni.psu.edu

March 30, 2001

Re: [PATCH] HOOK_CallHook

by François Jacques

>OK, I must have misunderstood you then. Sorry ... It's ok :) >I've managed to reduce the problem to a simple testcase, which is >appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... > >Culprit *appears* to be the global common subexpression elimination, >although this is not quite definite. I haven't tracked the problem >down yet. Are you thinking of doing more investigation on that? >However, when switching off GCSE (-fno-gcse), correct code is produced. >I'm not sure I'd like to do a complete Wine build without GCSE though; >this might significantly reduce code quality ... Oh the runtime behavior should not change that much but it's still non-negligeable. I like the "disable-gcse-if-you-probe-that-gcc-version" approach. >I'll write a configure check to switch off gcse, using the testcase >below. We should probably contact RedHat (I think Jacub Jelinek >handles 2.96 bugs ...) to confirm that GCSE is really at fault. If you want to post it with the test program, go ahead :) I never posted to gcc bug list so I'm not sure how much attention would be given to the bug. I think the mailing list should be cc'ed on the postings so everybody can follow up how it turns out. Ciao! Francois

March 30, 2001

Re: [PATCH] HOOK_CallHook

by François Jacques

>To be honest, I didn't read the patch and simply assumed this was a simple case >of forgetting to add volatile and getting bitten by a compiler that optimizes >more agressively. > >Either way it still is a valid point to be concerned about not only compiler >bugs but also new compiler features. 100% agree on this point. The community needs some ways to keep up to date with those new compiler versions. I know it's hard since we work on different projects which usually needs some kind of stability (in the product and in the development process) so we tend to stick with a reference compiler that we know works. However, if we don't keep up to date with those new compiler version, well fall in some intensive bug chasing session... and debugging at the assembly level is not that fun. And it's a cycle, we test the new compiler version, we find bugs, we get an improved compiler which, with a nice side-effect, may solve other bugs. >That would be a good idea. Of course I don't think the volatile keyword in >this case is hurting anything except maybe speed (negligble). Hopefully this >can get fixed soon in gcc. Looking at the gcc project page, it seems that 3.0 >is very close to be done. 3.0 ? That's good news in terms of technology advance... however I fear some late nites chasing bugs generated from that new version :) Cheers! Francois

March 30, 2001

Re: [PATCH] HOOK_CallHook

by David Elliott

Francois Jacques wrote: > > > > > IMHO, performing code review of the whole tree for missing volatile > keywords > > > would be a waste of time compared to do it on a case by case basis. > Simply > > > keep in mind that those bugs may happen - especially with "aggressive" > > > compilers such as gcc 2.96. If a bug didn't happen with the previous > > > compiler and does show up with the latest release, it might be a good > > > candidate. > > > > But the point is, this is *not* a Wine bug that was just exposed by a > > new compiler -- this is a compiler bug, plain and simple. > > Did I write it was a WINE bug? No. It is very clear for me that it *is* a > compiler issue. > > I had three choices > > a) find a workaround and have people comment on it; > b) disable the optimize phase for gcc 2.96 and have the whole community on > my back; > c) fix gcc. > > I went for the easy one. > > > Making these variables 'volatile' is not required at all -- 'volatile' > > tells the compiler that the variables might be changed behind the > > compiler's back, e.g. due to being asynchroneously modified by a signal > > handler or something like that. In this particular case, however, the > > variables are not only not changed behind the compiler's back, they > > are *never* changed at all! > > 100% agree. Again, it's a quick-yet-efficient workaround to the compiler > problem that just happened to work. While volatile is for variables that are > modified by external factors, it was a good way to prevent all the > optimization - which was just what I wanted. > To be honest, I didn't read the patch and simply assumed this was a simple case of forgetting to add volatile and getting bitten by a compiler that optimizes more agressively. Either way it still is a valid point to be concerned about not only compiler bugs but also new compiler features. > > > Instead of circumventing the compiler bug in this particular case, > > it might be preferable to find out which optimization phase contains > > the bug, and write a configure check that switches that phase off > > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). > > We'll do some research on the optimization phase. Once we found it, can > anybody help us with that autoconf kungfu? > That would be a good idea. Of course I don't think the volatile keyword in this case is hurting anything except maybe speed (negligble). Hopefully this can get fixed soon in gcc. Looking at the gcc project page, it seems that 3.0 is very close to be done. -Dave

March 30, 2001

Re: [PATCH] HOOK_CallHook

by Ulrich Weigand

> Did I write it was a WINE bug? No. It is very clear for me that it *is* a > compiler issue. OK, I must have misunderstood you then. Sorry ... > > Instead of circumventing the compiler bug in this particular case, > > it might be preferable to find out which optimization phase contains > > the bug, and write a configure check that switches that phase off > > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). > > We'll do some research on the optimization phase. Once we found it, can > anybody help us with that autoconf kungfu? I've managed to reduce the problem to a simple testcase, which is appended below. It fails on RedHat gcc-2.96-69 (as of 12/2000) ... Culprit *appears* to be the global common subexpression elimination, although this is not quite definite. I haven't tracked the problem down yet. However, when switching off GCSE (-fno-gcse), correct code is produced. I'm not sure I'd like to do a complete Wine build without GCSE though; this might significantly reduce code quality ... I'll write a configure check to switch off gcse, using the testcase below. We should probably contact RedHat (I think Jacub Jelinek handles 2.96 bugs ...) to confirm that GCSE is really at fault. Bye, Ulrich void clobber(int *); void compare(int, int); void use(int); int global; void test(int trigger, int param) { int data = trigger? global : 0; int orig_param = param; clobber(&param); compare(orig_param, param); use(data); } void clobber(int *param) { (*param)++; } void compare(int orig_param, int param) { if (orig_param != param) printf( "PASS\n" ); else printf( "FAIL\n" ); } void use(int data) { } int main(void) { test(0, 0); } -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 29, 2001

Re: controls/edit.c

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Ulrich Czekalla wrote: > I forgot to plug a region leak before I sent the patch in. I have > attached an updated patch. > > /Ulrich > Good day! This message comes to you from Juno-2.0.11 without benefit of junopine: I am composing it with Juno's GUI composer using the new edit.c. Much less flicker. I still can't answer a letter this way: Juno chokes on a SendMessageCallback as soon as it gets anything in its inbox, but that is nothing to do with edit.c It is hot and heavy with ads now and I get some sluggishness because I am contending with the ad engine for the 47 bogoMIPS of the mighty p-120, but really it seems much better. I still don't like GUI though, and Juno might get annoyed if I delete all its ads, which I would have to do to really use this composer, so I will go back to Pine now, but it does seem much better nor it was. Lawson ---cut here Well, not quite without junopine. I hit alt-s meaning to send it, and saved it to the draft folder instead, and tripped on another SendMessageCallback trying to get it out, but I did compose it with a GUI editor. The first patch moved the cursor for each character of the password, but showed no character, but with the revised patch I see the xxxx strikover I am accustomed to see. I think it is an improvement, but I am hardly a GUI guru. First soldier into the minefield, maybe, and still alive. Regards, Lawson ---cut here. Really. "The Rest is Spam." ________________________________________________________________ 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.

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Francois Jacques

> > > IMHO, performing code review of the whole tree for missing volatile keywords > > would be a waste of time compared to do it on a case by case basis. Simply > > keep in mind that those bugs may happen - especially with "aggressive" > > compilers such as gcc 2.96. If a bug didn't happen with the previous > > compiler and does show up with the latest release, it might be a good > > candidate. > > But the point is, this is *not* a Wine bug that was just exposed by a > new compiler -- this is a compiler bug, plain and simple. Did I write it was a WINE bug? No. It is very clear for me that it *is* a compiler issue. I had three choices a) find a workaround and have people comment on it; b) disable the optimize phase for gcc 2.96 and have the whole community on my back; c) fix gcc. I went for the easy one. > Making these variables 'volatile' is not required at all -- 'volatile' > tells the compiler that the variables might be changed behind the > compiler's back, e.g. due to being asynchroneously modified by a signal > handler or something like that. In this particular case, however, the > variables are not only not changed behind the compiler's back, they > are *never* changed at all! 100% agree. Again, it's a quick-yet-efficient workaround to the compiler problem that just happened to work. While volatile is for variables that are modified by external factors, it was a good way to prevent all the optimization - which was just what I wanted. > Instead of circumventing the compiler bug in this particular case, > it might be preferable to find out which optimization phase contains > the bug, and write a configure check that switches that phase off > if it detects the bug (like we did with the 2.95.2 strength-reduce bug). We'll do some research on the optimization phase. Once we found it, can anybody help us with that autoconf kungfu? Ciao! Francois

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Ulrich Weigand

> IMHO, performing code review of the whole tree for missing volatile keywords > would be a waste of time compared to do it on a case by case basis. Simply > keep in mind that those bugs may happen - especially with "aggressive" > compilers such as gcc 2.96. If a bug didn't happen with the previous > compiler and does show up with the latest release, it might be a good > candidate. But the point is, this is *not* a Wine bug that was just exposed by a new compiler -- this is a compiler bug, plain and simple. Making these variables 'volatile' is not required at all -- 'volatile' tells the compiler that the variables might be changed behind the compiler's back, e.g. due to being asynchroneously modified by a signal handler or something like that. In this particular case, however, the variables are not only not changed behind the compiler's back, they are *never* changed at all! If the compiler generates incorrect code here, this is just a bug, probably somewhere in the common subexpression elimination (or maybe reload) code. Now if the compiler has this bug, it might manifest itself also at different places -- which we *cannot* find by a code review, as the code itself is completely correct ... Instead of circumventing the compiler bug in this particular case, it might be preferable to find out which optimization phase contains the bug, and write a configure check that switches that phase off if it detects the bug (like we did with the 2.95.2 strength-reduce bug). Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 29, 2001

Re: [PATCH] HOOK_CallHook

by Francois Jacques

> This kind of begs the question: how many more places in Wine should the > volatile keyword be used? I find it hard to believe that this is the only > spot in a large very low-level project like Wine. You're comment is absolutely right. The thing is, those bugs are especially hard to find out and require very careful code examination. IMHO, performing code review of the whole tree for missing volatile keywords would be a waste of time compared to do it on a case by case basis. Simply keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate. Now try to don't go paranoid about compiler issues when WINE crashes with your new Linux installations ;) Francois

March 29, 2001

Re: controls/edit.c

by Ulrich Czekalla

I forgot to plug a region leak before I sent the patch in. I have attached an updated patch. /Ulrich Ulrich Czekalla wrote: > > This patch modifies the edit control to keep the line format data > and simply update it as changes occur. It also uses the line data > to calculate a proper update region. The result is a significant > reduction in flicker. Since this is a big change to the format > engine of the edit control it should be tested for a while before > committing. > > Changelog: > Ulrich Czekalla <uczekalla(a)codeweavers.com> > Update format engine to reduce flicker > Index: controls/edit.c =================================================================== RCS file: /home/wine/wine/controls/edit.c,v retrieving revision 1.75 diff -u -w -r1.75 edit.c --- controls/edit.c 2001/03/13 23:31:08 1.75 +++ controls/edit.c 2001/03/29 17:31:36 @@ -63,6 +63,7 @@ INT net_length; /* netto length of a line in visible characters */ LINE_END ending; INT width; /* width of the line in pixels */ + INT index; /* line index into the buffer */ struct tagLINEDEF *next; } LINEDEF; @@ -172,7 +173,7 @@ /* * Helper functions only valid for one type of control */ -static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es); +static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es, INT iStart, INT iEnd, INT delta, HRGN hrgn); static void EDIT_CalcLineWidth_SL(WND *wnd, EDITSTATE *es); static LPWSTR EDIT_GetPasswordPointer_SL(EDITSTATE *es); static void EDIT_MoveDown_ML(WND *wnd, EDITSTATE *es, BOOL extend); @@ -263,6 +264,7 @@ static void EDIT_WM_Timer(WND *wnd, EDITSTATE *es); static LRESULT EDIT_WM_VScroll(WND *wnd, EDITSTATE *es, INT action, INT pos); static void EDIT_UpdateText(WND *wnd, LPRECT rc, BOOL bErase); +static void EDIT_UpdateTextRegion(WND *wnd, HRGN hrgn, BOOL bErase); LRESULT WINAPI EditWndProcA(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); LRESULT WINAPI EditWndProcW(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); @@ -1132,100 +1134,250 @@ * a soft return '\r\r\n' or a hard return '\r\n' * */ -static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es) +static void EDIT_BuildLineDefs_ML(WND *wnd, EDITSTATE *es, INT istart, INT iend, INT delta, HRGN hrgn) { HDC dc; HFONT old_font = 0; - LPWSTR start, cp; + LPWSTR current_position, cp; INT fw; - LINEDEF *current_def; - LINEDEF **previous_next; + LINEDEF *current_line; + LINEDEF *previous_line; + LINEDEF *start_line; + INT line_index = 0, nstart_line = 0, nstart_index = 0; + INT line_count = es->line_count; + INT orig_net_length; + RECT rc; - current_def = es->first_line_def; - do { - LINEDEF *next_def = current_def->next; - HeapFree(GetProcessHeap(), 0, current_def); - current_def = next_def; - } while (current_def); - es->line_count = 0; - es->text_width = 0; + if (istart == iend && delta == 0) + return; dc = GetDC(wnd->hwndSelf); if (es->font) old_font = SelectObject(dc, es->font); + previous_line = NULL; + current_line = es->first_line_def; + + /* Find starting line. istart must lie inside an existing line or + * at the end of buffer */ + do { + if (istart < current_line->index + current_line->length || + current_line->ending == END_0) + break; + + previous_line = current_line; + current_line = current_line->next; + line_index++; + } while (current_line); + + if (!current_line) /* Error occurred start is not inside previous buffer */ + { + FIXME(" modification occurred outside buffer\n"); + return; + } + + /* Remember start of modifications in order to calculate update region */ + nstart_line = line_index; + nstart_index = current_line->index; + + /* We must start to reformat from the previous line since the modifications + * may have caused the line to wrap upwards. */ + if (!(es->style & ES_AUTOHSCROLL) && line_index > 0) + { + line_index--; + current_line = previous_line; + } + start_line = current_line; + fw = es->format_rect.right - es->format_rect.left; - start = es->text; - previous_next = &es->first_line_def; + current_position = es->text + current_line->index; do { - current_def = HeapAlloc(GetProcessHeap(), 0, sizeof(LINEDEF)); - current_def->next = NULL; - cp = start; + if (current_line != start_line) + { + if (!current_line || current_line->index + delta > current_position - es->text) + { + /* The buffer has been expanded, create a new line and + insert it into the link list */ + LINEDEF *new_line = HeapAlloc(GetProcessHeap(), 0, sizeof(LINEDEF)); + new_line->next = previous_line->next; + previous_line->next = new_line; + current_line = new_line; + es->line_count++; + } + else if (current_line->index + delta < current_position - es->text) + { + /* The previous line merged with this line so we delete this extra entry */ + previous_line->next = current_line->next; + HeapFree(GetProcessHeap(), 0, current_line); + current_line = previous_line->next; + es->line_count--; + continue; + } + else /* current_line->index + delta == current_position */ + { + if (current_position - es->text > iend) + break; /* We reached end of line modifications */ + /* else recalulate this line */ + } + } + + current_line->index = current_position - es->text; + orig_net_length = current_line->net_length; + + /* Find end of line */ + cp = current_position; while (*cp) { if ((*cp == '\r') && (*(cp + 1) == '\n')) break; cp++; } + + /* Mark type of line termination */ if (!(*cp)) { - current_def->ending = END_0; - current_def->net_length = strlenW(start); - } else if ((cp > start) && (*(cp - 1) == '\r')) { - current_def->ending = END_SOFT; - current_def->net_length = cp - start - 1; + current_line->ending = END_0; + current_line->net_length = strlenW(current_position); + } else if ((cp > current_position) && (*(cp - 1) == '\r')) { + current_line->ending = END_SOFT; + current_line->net_length = cp - current_position - 1; } else { - current_def->ending = END_HARD; - current_def->net_length = cp - start; + current_line->ending = END_HARD; + current_line->net_length = cp - current_position; } - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, current_def->net_length, + + /* Calculate line width */ + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, current_line->net_length, es->tabs_count, es->tabs)); + /* FIXME: check here for lines that are too wide even in AUTOHSCROLL (> 32767 ???) */ - if ((!(es->style & ES_AUTOHSCROLL)) && (current_def->width > fw)) { + if ((!(es->style & ES_AUTOHSCROLL)) && (current_line->width > fw)) { INT next = 0; INT prev; do { prev = next; - next = EDIT_CallWordBreakProc(es, start - es->text, - prev + 1, current_def->net_length, WB_RIGHT); - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, next, es->tabs_count, es->tabs)); - } while (current_def->width <= fw); - if (!prev) { + next = EDIT_CallWordBreakProc(es, current_position - es->text, + prev + 1, current_line->net_length, WB_RIGHT); + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, next, es->tabs_count, es->tabs)); + } while (current_line->width <= fw); + if (!prev) { /* Didn't find a line break so force a break */ next = 0; do { prev = next; next++; - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, - start, next, es->tabs_count, es->tabs)); - } while (current_def->width <= fw); + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, + current_position, next, es->tabs_count, es->tabs)); + } while (current_line->width <= fw); if (!prev) prev = 1; } - current_def->net_length = prev; - current_def->ending = END_WRAP; - current_def->width = (INT)LOWORD(GetTabbedTextExtentW(dc, start, - current_def->net_length, es->tabs_count, es->tabs)); + + /* If the first line we are calculating, wrapped before istart, we must + * adjust istart in order for this to be reflected in the update region. */ + if (current_line->index == nstart_index && istart > current_line->index + prev) + istart = current_line->index + prev; + /* else if we are updating the previous line before the first line we + * are re-caulculating and it expanded */ + else if (current_line == start_line && + current_line->index != nstart_index && orig_net_length < prev) + { + /* Line expanded due to an upwards line wrap so we must partially include + * previous line in update region */ + nstart_line = line_index; + nstart_index = current_line->index; + istart = current_line->index + orig_net_length; + } + + current_line->net_length = prev; + current_line->ending = END_WRAP; + current_line->width = (INT)LOWORD(GetTabbedTextExtentW(dc, current_position, + current_line->net_length, es->tabs_count, es->tabs)); } - switch (current_def->ending) { + + + /* Adjust length to include line termination */ + switch (current_line->ending) { case END_SOFT: - current_def->length = current_def->net_length + 3; + current_line->length = current_line->net_length + 3; break; case END_HARD: - current_def->length = current_def->net_length + 2; + current_line->length = current_line->net_length + 2; break; case END_WRAP: case END_0: - current_def->length = current_def->net_length; + current_line->length = current_line->net_length; break; } - es->text_width = max(es->text_width, current_def->width); - start += current_def->length; - *previous_next = current_def; - previous_next = &current_def->next; - es->line_count++; - } while (current_def->ending != END_0); + es->text_width = max(es->text_width, current_line->width); + current_position += current_line->length; + previous_line = current_line; + current_line = current_line->next; + line_index++; + } while (previous_line->ending != END_0); + + /* Finish adjusting line index's by delta or remove hanging lines */ + if (previous_line->ending == END_0) + { + LINEDEF *pnext = NULL; + + previous_line->next = NULL; + while (current_line) + { + pnext = current_line->next; + HeapFree(GetProcessHeap(), 0, current_line); + current_line = pnext; + es->line_count--; + } + } + else + { + while (current_line) + { + current_line->index += delta; + current_line = current_line->next; + } + } + + /* Calculate rest of modification rectangle */ + if (hrgn) + { + HRGN tmphrgn; + /* + * We calculate two rectangles. One for the first line which may have + * an indent with respect to the format rect. The other is a format-width + * rectangle that spans the rest of the lines that changed or moved. + */ + rc.top = es->format_rect.top + nstart_line * es->line_height - + (es->y_offset * es->line_height); /* Adjust for vertical scrollbar */ + rc.bottom = rc.top + es->line_height; + rc.left = es->format_rect.left + (INT)LOWORD(GetTabbedTextExtentW(dc, + es->text + nstart_index, istart - nstart_index, + es->tabs_count, es->tabs)) - es->x_offset; /* Adjust for horz scroll */ + rc.right = es->format_rect.right; + SetRectRgn(hrgn, rc.left, rc.top, rc.right, rc.bottom); + + rc.top = rc.bottom; + rc.left = es->format_rect.left; + rc.right = es->format_rect.right; + /* + * If lines were added or removed we must re-paint the remainder of the + * lines since the remaining lines were either shifted up or down. + */ + if (line_count < es->line_count) /* We added lines */ + rc.bottom = es->line_count * es->line_height; + else if (line_count > es->line_count) /* We removed lines */ + rc.bottom = line_count * es->line_height; + else + rc.bottom = line_index * es->line_height; + rc.bottom -= (es->y_offset * es->line_height); /* Adjust for vertical scrollbar */ + tmphrgn = CreateRectRgn(rc.left, rc.top, rc.right, rc.bottom); + CombineRgn(hrgn, hrgn, tmphrgn, RGN_OR); + DeleteObject(tmphrgn); + } + if (es->font) SelectObject(dc, old_font); + ReleaseDC(wnd->hwndSelf, dc); } @@ -2140,7 +2292,7 @@ es->format_rect.bottom = es->format_rect.top + es->line_height; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); } @@ -2836,6 +2988,7 @@ UINT e; UINT i; LPWSTR p; + HRGN hrgn = 0; TRACE("%s, can_undo %d, send_update %d\n", debugstr_w(lpsz_replace), can_undo, send_update); @@ -2916,9 +3069,14 @@ CharLowerBuffW(p, strl); s += strl; } - /* FIXME: really inefficient */ if (es->style & ES_MULTILINE) - EDIT_BuildLineDefs_ML(wnd, es); + { + INT s = min(es->selection_start, es->selection_end); + + hrgn = CreateRectRgn(0, 0, 0, 0); + EDIT_BuildLineDefs_ML(wnd, es, s, s + strl, + strl - (es->selection_end - es->selection_start), hrgn); + } else EDIT_CalcLineWidth_SL(wnd, es); @@ -2930,7 +3088,12 @@ /* force scroll info update */ EDIT_UpdateScrollInfo(wnd, es); - /* FIXME: really inefficient */ + if (hrgn) + { + EDIT_UpdateTextRegion(wnd, hrgn, TRUE); + DeleteObject(hrgn); + } + else EDIT_UpdateText(wnd, NULL, TRUE); if(es->flags & EF_UPDATE) @@ -3134,7 +3297,7 @@ EDIT_EM_EmptyUndoBuffer(es); es->flags &= ~EF_MODIFIED; es->flags &= ~EF_UPDATE; - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); EDIT_EM_ScrollCaret(wnd, es); /* force scroll info update */ @@ -3200,7 +3363,7 @@ EDIT_EM_EmptyUndoBuffer(es); es->flags &= ~EF_MODIFIED; es->flags &= ~EF_UPDATE; - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); EDIT_EM_ScrollCaret(wnd, es); /* force scroll info update */ @@ -3403,7 +3566,7 @@ es->word_break_proc16 = NULL; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) { - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); } } @@ -3422,7 +3585,7 @@ es->word_break_proc = NULL; es->word_break_proc16 = wbp; if ((es->style & ES_MULTILINE) && !(es->style & ES_AUTOHSCROLL)) { - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); EDIT_UpdateText(wnd, NULL, TRUE); } } @@ -3683,6 +3846,8 @@ */ static void EDIT_WM_Destroy(WND *wnd, EDITSTATE *es) { + LINEDEF *pc, *pp; + if (es->hloc32W) { while (LocalUnlock(es->hloc32W)) ; LocalFree(es->hloc32W); @@ -3695,6 +3860,15 @@ while (LOCAL_Unlock(wnd->hInstance, es->hloc16)) ; LOCAL_Free(wnd->hInstance, es->hloc16); } + + pc = es->first_line_def; + while (pc) + { + pp = pc->next; + HeapFree(GetProcessHeap(), 0, pc); + pc = pp; + } + HeapFree(GetProcessHeap(), 0, es); *(EDITSTATE **)wnd->wExtra = NULL; } @@ -4447,7 +4621,7 @@ EDIT_SetRectNP(wnd, es, &r); if (es->style & ES_MULTILINE) - EDIT_BuildLineDefs_ML(wnd, es); + EDIT_BuildLineDefs_ML(wnd, es, 0, strlenW(es->text), 0, (HRGN)0); else EDIT_CalcLineWidth_SL(wnd, es); @@ -4678,6 +4852,21 @@ if (dy) EDIT_EM_LineScroll(wnd, es, 0, dy); return 0; +} + +/********************************************************************* + * + * EDIT_UpdateText + * + */ +static void EDIT_UpdateTextRegion(WND *wnd, HRGN hrgn, BOOL bErase) +{ + EDITSTATE *es = *(EDITSTATE **)((wnd)->wExtra); + + if (es->flags & EF_UPDATE) + EDIT_NOTIFY_PARENT(es, EN_UPDATE, "EN_UPDATE"); + + InvalidateRgn(wnd->hwndSelf, hrgn, bErase); }

March 29, 2001

Re: OpenGL Visual Management ... continued.

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Gavriel State wrote: > Can you tell me: > - What video card you're using > - What bit depth and resolution you've got > - Whether the behaviour continues if you turn off the setup_opengl_visual() > call in dlls/x11drv/x11drv_main.c No. To be precise, I did exactly: diff -ur /gp/gav/was/dlls/x11drv/x11drv_main.c dlls/x11drv/x11drv_main.c --- /gp/gav/was/dlls/x11drv/x11drv_main.c Wed Mar 28 22:31:00 2001 +++ dlls/x11drv/x11drv_main.c Thu Mar 29 10:23:03 2001 @@ -379,7 +379,8 @@ /* If OpenGL is available, change the default visual, etc as necessary */ #ifdef HAVE_OPENGL - setup_opengl_visual(); +/* setup_opengl_visual(); +*/ #endif /* HAVE_OPENGL */ /* tell the libX11 that we will do input method handling ourselves and everything works fine. > - Whether notepad.exe exhibits the same behaviour (that's the only non > game app I run on a regular basis for testing). How about winemine?? (didn't have notepad.exe handy.) winemine does it, so does programs/notepad. I pulled a 1993 notepad.exe from a tar.bz2 - that would be from wfw3.11, I think. It does it too. > > At a guess - the privately created ColorMaps need to take their initial colors > from the Default Color Map? That sounds about right. Oh, at one point I reverted only wnd.c - no difference - then palette.c. Colors seemed better with the pointer off the window IIRC, but it still went to black and white withe the pointer on the desktop. > > I'll try to have a further look into it tomorrow. Sorry for any wasted time. > > -Gav > > -- > Gavriel State, CEO > TransGaming Technologies Inc. > http://www.transgaming.com > gav(a)transgaming.com > Lawson ---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.

March 29, 2001

Re: OpenGL Visual Management

by lawson_whitney＠juno.com

On Thu, 29 Mar 2001, Gavriel State wrote: > Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I > don't remember getting it when testing the 3dfx card I just loaned out to > someone. Maybe I flubbed the 8-bit testing there... > > Can you tell me: > - What video card you're using (**) Mach64: Graphics device ID: "ATI Mach64 CT (264CT)" > - What bit depth and resolution you've got (--) Mach64: PCI: Mach64 CT rev 9, Aperture @ 0xfe000000, Block I/O @ 0xfc00 (--) Mach64: Card type: PCI (--) Mach64: Memory type: DRAM (1) (--) Mach64: Clock type: Internal (--) Mach64: Maximum allowed dot-clock: 135.000 MHz (**) Mach64: Mode "640x480": mode clock = 45.800 (**) Mach64: Mode "800x600": mode clock = 69.650 (**) Mach64: Mode "1024x768": mode clock = 85.000 (**) Mach64: Mode "1280x1024": mode clock = 110.000 (--) Mach64: Virtual resolution: 1280x1024 (--) Mach64: Video RAM: 2048k (--) Mach64: Using hardware cursor (--) Mach64: Using 16 MB aperture @ 0xfe000000 (--) Mach64: Ramdac is Internal (--) Mach64: Ramdac speed: 135 MHz (--) Mach64: Using 8 bits per RGB value What is bit depth? :-) can you tell from that? That is interesting. At 16 bpp, the symptoms I reported don't occur, and all is well. I guess you suspected that, but it didn't occur to me to check before. I might be the only wine user who habitually uses 8bpp: I can't see any difference between 8 and 16 bpp. Well, with your patch in I can. > - Whether the behaviour continues if you turn off the setup_opengl_visual() > call in dlls/x11drv/x11drv_main.c > - Whether notepad.exe exhibits the same behaviour (that's the only non > game app I run on a regular basis for testing). > > > No doubt I am not well set up for DGA: > > DGA shouldn't matter for this stuff at all. > > > I haven't really looked into it much yet...maybe you will see right off > > what you or I have done wrong? > > At a guess - the privately created ColorMaps need to take their initial colors > from the Default Color Map? > > I'll try to have a further look into it tomorrow. Sorry for any wasted time. > > -Gav > > -- > Gavriel State, CEO > TransGaming Technologies Inc. > http://www.transgaming.com > gav(a)transgaming.com > I'll get on with some more tests now, but I want to give you that to start with. Lawson ---cut here Dammit, my winelib sendmail program won't work unless X is running. Try again. ---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.

March 29, 2001

Re: OpenGL Visual Management

by Gavriel State

lawson_whitney(a)juno.com wrote: > > On Mon, 26 Mar 2001, Gavriel State wrote: > > > This patch fixes several issues with the way OpenGL manages visuals: > > Something is not right, I think. Ordinary apps (Dmitry's About.exe, > say) look as if they were using a vga16 server - unless the pointer is > over the desktop: then the entire X display is black and white. > Without a desktop with managed moving the pointer over the app's window > radically changes the palette for the whole screen, but not to black and > white. With neither managed nor desktop, the pointer has no effect on > the palette. Argh. I'm getting the same behaviour in 8-bit mode on my NVidia card. I don't remember getting it when testing the 3dfx card I just loaned out to someone. Maybe I flubbed the 8-bit testing there... Can you tell me: - What video card you're using - What bit depth and resolution you've got - Whether the behaviour continues if you turn off the setup_opengl_visual() call in dlls/x11drv/x11drv_main.c - Whether notepad.exe exhibits the same behaviour (that's the only non game app I run on a regular basis for testing). > No doubt I am not well set up for DGA: DGA shouldn't matter for this stuff at all. > I haven't really looked into it much yet...maybe you will see right off > what you or I have done wrong? At a guess - the privately created ColorMaps need to take their initial colors from the Default Color Map? I'll try to have a further look into it tomorrow. Sorry for any wasted time. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 29, 2001

Re: OpenGL Visual Management

by lawson_whitney＠juno.com

On Mon, 26 Mar 2001, Gavriel State wrote: > This patch fixes several issues with the way OpenGL manages visuals: > > - It always uses a double-buffered visual if one is available, even when > not running Wine in --desktop mode. Previously, we just hoped that the > default visual was double buffered, which is isn't in some DRI GL drivers. > > - It ensures that all colormaps created use the double-buffered visual if > it exists. This prevents problems where DRI GL implementations fail > to work unless the colormap visual matches the window visual matches the > glX visual. > > - It gets around similar visual issue with the default GL context created for > apps that don't create their own contexts before trying to use GL functions. > > Note that we are not able to support the wgl ChoosePixelFormat/DescribePixelFormat > APIs properly. Some of the infrastructure for this exists in graphics/x11drv/opengl.c > so that it can be done when the time comes. This patch explicitly removes the wgl > code that tries to match the OpenGL visual to a requested pixel format, because > that won't work until we can dynamically remap HWNDs to new X11 Windows with > a new visual. > > -Gav > Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette. No doubt I am not well set up for DGA: grep -i dga config.cache ac_cv_header_X11_extensions_xf86dga_h=${ac_cv_header_X11_extensions_xf86dga_h=yes} ac_cv_lib_Xxf86dga_XDGAQueryExtension=${ac_cv_lib_Xxf86dga_XDGAQueryExtension=no} ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=${ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=yes} but I don't see why DGA support should disturb things so. I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong? Regards, Lawson ---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.

March 29, 2001

Re: [PATCH] HOOK_CallHook

by David Elliott

Francois Jacques wrote: > Group, This patch comes from investigation of a bug that was observed in > RedHat 7.0 and not observed in RedHat 6.1. After a debugging session that > involved Stephane and I, we found out that it was a compiler issue (which > I feared from the start, but wasn't considering it seriously... > arghhh). The RedHat 6.1 installation has gcc version 2.91.66 and the > RedHat 7.0 installation has gcc version 2.96-20000731 (RedHat Linux 7.0) > with latest updates from RedHat. What's happening : 1) HOOK_CallHook is > being called (notice wParam and lParam arguments)2) Local variables > wParamOrig and lParamOrig are set to wParam and lParam values3) Mapping > function is called (MapFunc) with the *addresses* of wParam and lParam so > those get changed before we call the hook4) After MapFunc is called, > wParamOrig and lParamOrig values also changed to the new values of wParam > and lParam (!) Explanation : Down to the assembly level code, the compiler > doesn't create wParamOrig and lParamOrig on the stack. Instead, it > directly use wParam and lParam. Fix : add volatile to wParamOrig and > lParamOrig to prevent optimizations on those variables (aka. force their > presence on the stack) This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. -Dave

March 29, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

> If I were going to make more WAGs (Wild Assed guesses), > I'd hazard a guess that this was due to my Alsa sound system > (running on the AC97 codec on my Asus motherboard). > > I tried to walk the stack back, but didn't get very far > (after the first time of wrongly computing the hex offset > from a .s file, I gave off, stomped off to look > for a better disassembler and gave up). If you have the 'vmlinux' file, try objdump --disassemble vmlinux > My best guess is that we're coming through dentry_open > (xc012e7fe)/ chrdev_open (0xc012f66c) > /soundcore_open (0xc01bbf71). However, I wasn't > seeing a familiar EBP/EIP pattern, so I'm possibly just > pulling random symbols out of the air. Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule [I am assuming that you have 256MB main memory. Correct?] Now, the question is still, who is sleeping on that semaphore and why? >From the call trace, it would seem that some sound-related module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...) We can continue to track in two directions. First, we can try to locate the point within the Wine application where the open() syscall is performed. >From the trace we see that the system call instruction is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY ) [The stack pointer value is rather weird, I'd say ...] This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis. The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ... The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this: Call Trace: [<d0826a42>] [<d087ce3e>] to a file and pipe the file through ksymoops. In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 28, 2001

[CHECKER] Stanford enhanced gcc found 741 errors in wine source

by Dan Kegel

... just kidding. Has anyone else been watching the success of the Stanford MC team in finding linux kernel bugs using an enhanced version of gcc? See http://www.lwn.net/2001/0322/kernel.php3 and scroll down to 'Global Kernel Analysis'. They've done a fabulous job. This and the Kernel Janitor project promise to help keep the linux kernel stable even in those funny corner cases that don't get exercised enough to make the bugs easy to track down. Would Wine be another possible application of the MC work? - Dan

March 27, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

> Process 1503 found at c2cd8000, esp c2cd9e04 > Call Trace: [<c010794f>] [<c2cd8000>] Hmpf, this is not quite what I expected :-/ (Maybe the kernel is compiled with -fomit-frame-pointer?) Could you try using a modified version of dump that will at least dump out the complete kernel stack so that we can analyse it manually? --- dump/dump.c Mon Mar 26 23:47:18 2001 +++ dump.new/dump.c Tue Mar 27 21:55:11 2001 @@ -95,6 +95,18 @@ printf( " [<%08x>]", eip ); } printf( "\n" ); + +{ + unsigned int stack[2048]; + unsigned int start = esp & -16; + unsigned int i, len = addr + 8192 - start; + read_kernel( stack, start, len ); + + printf( "Stack Dump:\n" ); + for ( i = 0; i < len/16; i++ ) + printf( "0x%08x: %08x %08x %08x %08x\n", + start + 16*i, stack[4*i], stack[4*i + 1], stack[4*i + 2], stack[4*i + 3] ); +} } int main( int argc, char *argv[] ) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 27, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

Just spent 30 minutes trying to reproduce with Outlook, and now, of course, I can't. I may well have pressed ^C at some point; I'm learning that Outlook does, eventually (2-3 minutes) come up (but promptly crashes). However, whilst trying something else, I had another winelib program crash. So, I grabbed what info from it I could in the attached file. Jer Stuck Process: jwhite 1503 0.5 2.6 32956 6684 pts/2 D 20:07 0:02 testapp -debugmsg +relay ps -p 1503 -o pid,wchan PID WCHAN 1503 down dump 1503 Process 1503 found at c2cd8000, esp c2cd9e04 Call Trace: [<c010794f>] [<c2cd8000>] /usr/src/linux-2.4.0/System.map fragment: c01078f8 T __down c0107994 T __down_interruptible c0107a60 T __down_trylock c0107a9c T __down_failed . . . c02f6c14 A _end I have the feeling there is something more I could have gotten you here, but I'm not sure what. Last 21 lines or so of a relay log: ebp=405b679c esp=405b6788 ds=002b es=002b gs=0000 flags=00000202 Ret kernel32.4: VxDCall3() retval=00000002 ret=bfe819e3 fs=008f eax=00000002 ebx=417c4188 ecx=00000001 edx=405b67cc esi=0000006c edi=405b67cc ebp=405b679c esp=405b6794 ds=002b es=002b gs=0000 flags=00000202 Call kernel32.455: GetPrivateProfileStringA(417bb8e7 "mci",00000000,417bb80a "",403d5b48,00000800,417bc626 "SYSTEM.INI") ret=4178b025 fs=008f Ret kernel32.455: GetPrivateProfileStringA() retval=00000051 ret=4178b025 fs=008f Call kernel32.2: VxDCall1(00010013) ret=bfe8165f fs=008f eax=00000001 ebx=417c4188 ecx=fffffffe edx=417c20e4 esi=0000006c edi=403d5b9a ebp=405b67d4 esp=405b67a0 ds=002b es=002b gs=0000 flags=00000202 Ret kernel32.2: VxDCall1() retval=00000000 ret=bfe8165f fs=008f eax=00000000 ebx=417c4188 ecx=fffffffe edx=417c20e4 esi=0000006c edi=403d5b9a ebp=405b67d4 esp=405b67a4 ds=002b es=002b gs=0000 flags=00000202 Call kernel32.947: lstrcpynA(405b668c,417bb4a7 "wineoss.drv",00000080) ret=4177f8db fs=008f Ret kernel32.947: lstrcpynA() retval=405b668c ret=4177f8db fs=008f Call kernel32.553: HeapAlloc(40360000,00000000,0000001c) ret=4177f666 fs=008f Ret kernel32.553: HeapAlloc() retval=403d8774 ret=4177f666 fs=008f Call kernel32.601: LoadLibraryA(405b668c "wineoss.drv") ret=4177f680 fs=008f Ret kernel32.601: LoadLibraryA() retval=417c8000 ret=4177f680 fs=008f Call kernel32.459: GetProcAddress(417c8000,417ba14b "DriverProc") ret=4177f6a0 fs=008f Ret kernel32.459: GetProcAddress() retval=417d8e90 ret=4177f6a0 fs=008f Call wineoss.1: DriverProc(00000000,403d8774,00000001,00000000,00000000) ret=4177f3e2 fs=008f

March 27, 2001

TransGaming & SourceForge

by Gavriel State

Hi everyone, Just wanted to let everyone know that the TransGaming DirectX development is now being hosted at SourceForge. You can get updates from our live CVS tree, discuss DirectX specific issues on the 'WineX-devel' mailing list, etc. The SourceForge project page is at: http://sourceforge.net/project/winex The CVSROOT for CVS is: :pserver:anonymous(a)cvs.winex.sourceforge.net:/cvsroot/winex We're doing WineHQ merge-ins every week or two, so things should stay relatively up to date. Currently, we're undertaking a rearchitecture of the Direct3D work, along the lines of the DDraw HAL work we've been contributing to the WineHQ tree. Basically, we're seperating the glX code into the x11drv for device independance. We're also redoing the front end interfaces to start supporting D3D APIs both older and newer than D3D 7. On the OpenGL front, we've done some work on the visual management code that solves some problems we were seeing where you couldn't get a double-buffered visual on some cards without using -desktop mode. I should be posting a patch for this back to wine-patches very soon. There are still some kinks to be worked out... -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 26, 2001

Re: WineX-Transgaming

by Gavriel State

"Gottfried F. Zojer" wrote: > > Hi, > > I m new to this list.So I hope that a little bit of feedback is coming > to my > first posting.Is somebody on this list who is working on DirectX APi s > into WINE.I heart from the WineX Api from Transgaming Tech. > It s hosted on SourgeForge.Unfortuntely this server must be a very slow > because it was impossible for me to get access to the CVS-Tree. > Thanks in advance If you have technical questions specific to the new DirectX code, you're best off directing them to the new WineX-devel list we've created on SourceForge. If you can't reach SourceForge at all, give it another go later in the day, it occasionally has load issues. If you are having persistant problems with SourceForge CVS, you can apply one of the earlier patches from the TransGaming website to the WineHQ tree. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

Hi Jeremy, > > Great :-( Now the interesting thing would be to know *which* > > semaphore this is waiting on ... > > > > I'd really like to see a kernel stack backtrace on this. However, > > there doesn't appear to be an easy way to do so ... > > I was pretty sure this was going to be a fun one... OK, I've hacked together a silly tool that generates a kernel stack backtrace from userspace. Note that this doesn't do much error checking; please compile against kernel sources that match the running kernel, and don't try to use the tool for *running* processes ... To generate the dump, just run 'dump <pid>'. The result is suitable for piping through 'ksymoops' for symbol lookup. Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

> > > > PID WCHAN > > 2531 down > > Great :-( Now the interesting thing would be to know *which* > semaphore this is waiting on ... > > I'd really like to see a kernel stack backtrace on this. However, > there doesn't appear to be an easy way to do so ... I was pretty sure this was going to be a fun one... > > > > Hmm. Could you try getting a Wine trace (especially the server/ > > > client interaction)? > > > > ftp://wine.codeweavers.com/pub/other/outlook-server.out.gz > > (about 160K). > > Is this from the same run as above? I.e. is the process > with pid 2531 part of this trace? Yes. > > B.t.w. the trace appears to show that you pressed ^C to > terminate the process. Does the symptom (processes in state D) > show *before* you press ^C or only afterwards? > I'm nearly certain that I see the process show up as run state 'D' prior to pressing ^C, but I may be wrong. I tend to notice this problem, of course, only after pressing ^C and trying to do a killall. I'll poke around a bit more (sorry for not reproducing this more quickly; since it tends to cost me a reboot and a lengthy fsck to repair, I'm a little slow to iterate the test cycles <g>). Jer

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

Hi Jeremy, > > Could you check in which kernel routine the process is blocked? > > (e.g. using ps -Ao pid,wchan) > > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > jwhite 2531 2.3 14.8 86144 38016 pts/0 D 16:02 0:05 wine > --debugmsg +server msimn.exe > > PID WCHAN > 2531 down Great :-( Now the interesting thing would be to know *which* semaphore this is waiting on ... I'd really like to see a kernel stack backtrace on this. However, there doesn't appear to be an easy way to do so ... > > Hmm. Could you try getting a Wine trace (especially the server/ > > client interaction)? > > ftp://wine.codeweavers.com/pub/other/outlook-server.out.gz > (about 160K). Is this from the same run as above? I.e. is the process with pid 2531 part of this trace? B.t.w. the trace appears to show that you pressed ^C to terminate the process. Does the symptom (processes in state D) show *before* you press ^C or only afterwards? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 26, 2001

WineX-Transgaming

by Gottfried F. Zojer

Hi, I m new to this list.So I hope that a little bit of feedback is coming to my first posting.Is somebody on this list who is working on DirectX APi s into WINE.I heart from the WineX Api from Transgaming Tech. It s hosted on SourgeForge.Unfortuntely this server must be a very slow because it was impossible for me to get access to the CVS-Tree. Thanks in advance Gottfried

March 26, 2001

Some ideas/bugs that turned out while playing Fallout

by Jukka Heinonen

I installed latest Wine snapshot and got Fallout running. However, after I played with Fallout for some time, I found out that there are certain issues with Wine that make playing Fallout a bit irritating. Since these issues likely affect lots of games and also many other applications, I decided to make some bug reports and suggestions. I *might* be interested to do some work on these myself, but before doing anything, I want to get some feedback on these issues: 1. Lost keyboard/mouse events. When typing something to text dialogs, I noticed that if I type too fast Wine ignores some of the typed letters. Similarly, I sometimes have to press mouse buttons multiple times in order to get the Wine window to recognize mouse clicks. These are definitely bugs. 2. Sound quality was usually good but sometimes there were short pauses at regular intervals in the playback. I guess this was because hardware buffers got empty and soundcard stopped playing for a short time. Another problem was that if Fallout had music enabled it was possible that music playback took so much CPU time that the whole machine got very sluggish and Wine window stopped receiving mouse/keyboard input. It is likely that both of these problems were due to too slow a machine (Pentium MMX 200) but they still are annoying. What I would suggest would be to add to Wine configuration options like this: * No sound. Even though Linux might have working sound drivers it might be that sound just does not work in Wine. Better to be able to disable sound from Wine applications in this case. Also good for really slow machines. * Reduced quality sound. Use sound hardware as if it was only able to do something like mono/8 bits/8000 Hz. Doesn't sound terribly good, but hopefully CPU load is reduced. Haven't looked at Wine code to see if this would be the case. * Full quality sound. This should be the default. 3. Running full screen mode applications was not easy. First of all, if I did not use desktop-in-window mode and the full screen window lost focus then I had no way of getting focus back to Wine window. Also, Fallout only run few seconds before freezing in this mode. On the other hand, desktop-in-window mode worked. However, this window had the annoying property that if I accidentally gave it focus, it took lots of effort to get focus out of this window. Ok, I should be using click-to-focus instead of focus to window under mouse but I think having to change window manager configuration to get Wine work is not right. On the other hand, it was way too easy to get focus out of the Wine window. Fallout and many other full screen games scroll when you move mouse to the edge of the Wine window and this quite often resulted in Wine losing focus. This is not a good thing if you use CTRL-ALT-PLUS/MINUS to change resolution to 640x400 since this causes nasty scrolling. So, I have the following suggestion for full-screen mode. When application requests full-screen mode, open big black window on top of all other windows and draw application window in center of that. If there is some way to get X server to keep viewport centered when resolution is manually changed this would work quite well, otherwise it might be necessary to put the Wine window to some corner. If would be really great if Wine could ask X server to change resolution. Perhaps an extension to X server (or just reading X server manuals) would be needed... Moving mouse out of this window should not work. This would keep lots of games (and players) happy. If this window lost focus (window managers usually have keys to move focus to other windows) then the full-screen Wine window should be replaced by a miniature window of the full-screen application. Clicking this miniature would naturally reopen the big fullscreen window. In order to keep users happy, there should some key to miniaturize the full-screen application. If window manager did not already use ALT-TAB then that might be a good candidate. Also, you should be able to miniaturize the window using mouse. This could be done Windows-like by moving the mouse to the edge of the screen (or maybe corner?) and keeping it there for several seconds. After this time, a bar would appear. Clicking this bar would miniaturize the window. This might still look funny if an application scrolls when mouse is moved to the edge of the screen, but it would otherwise not cause problems with the scrolling itself. Finally, in order to keep users not too surprised, it might be good idea to show for a few seconds some text on top of the full-screen window when the window "steals" the display. Something like: "Wine / xyz.exe / Use alt-tab or move mouse to edge of screen to hide" 4. There should be some documentation on using Wine with Linux kernel automounter. Like whether it works or not and does it make using games with multiple CDs easier etc. And I was just wondering should Wine try to manually mount/unmount CDROMs if you don't use automounter. -- Jukka Heinonen <http://www.iki.fi/jhei/>

March 26, 2001

Re: building wine-20010305

by Andreas Mohr

On Sun, Mar 25, 2001 at 05:54:17PM -0800, furlan(a)telocity.com wrote: > On Sun, 25 March 2001, "Dmitry Timoshkov" wrote: > > > > > "Igor" <furlan(a)telocity.com> wrote: > > > > > ../include/winbase.h:1917: parse error before `!' > > > make[3]: *** [loadorder.o] Error 1 > > > > Did you look at that place? What is there? > > everything is fine there > > > > > For me, there is only single '!' sign in the include/winbase.h at line 1759: > > #define HasOverlappedCompleted(lpOverlapped) ((lpOverlapped)->Internal != STATUS_PENDING) > > > > Are you sure, that you have downloaded not broken archive? > > Prior to my post to the wine-devel I dovnoladed wine 3 times... and I got always different build errors.. > > Finally I succeeded by continously repeating "make".. > After every "make" I came further... > > so..the conclusion is: I have some problems > with hard disk, RAM or "something_else"... Ouch !! That surely sounds like big trouble to me... Install the memtest package/program and run it ! And make sure that you don´t have any DMA problems or similar with your IO chipset !! (check your hdparm configuration just in case !) > WINE is just fine !! :-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 26, 2001

Re: building wine-20010305

by Dmitry Timoshkov

"Igor" <furlan(a)telocity.com> wrote: > ../include/winbase.h:1917: parse error before `!' > make[3]: *** [loadorder.o] Error 1 Did you look at that place? What is there? For me, there is only single '!' sign in the include/winbase.h at line 1759: #define HasOverlappedCompleted(lpOverlapped) ((lpOverlapped)->Internal != STATUS_PENDING) Are you sure, that you have downloaded not broken archive?

March 26, 2001

Re: building wine-20010305

by furlan＠telocity.com

On Sun, 25 March 2001, "Dmitry Timoshkov" wrote: > > "Igor" <furlan(a)telocity.com> wrote: > > > ../include/winbase.h:1917: parse error before `!' > > make[3]: *** [loadorder.o] Error 1 > > Did you look at that place? What is there? everything is fine there > > For me, there is only single '!' sign in the include/winbase.h at line 1759: > #define HasOverlappedCompleted(lpOverlapped) ((lpOverlapped)->Internal != STATUS_PENDING) > > Are you sure, that you have downloaded not broken archive? Prior to my post to the wine-devel I dovnoladed wine 3 times... and I got always different build errors.. Finally I succeeded by continously repeating "make".. After every "make" I came further... so..the conclusion is: I have some problems with hard disk, RAM or "something_else"... WINE is just fine !!

March 26, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

> Could you check in which kernel routine the process is blocked? > (e.g. using ps -Ao pid,wchan) USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jwhite 2531 2.3 14.8 86144 38016 pts/0 D 16:02 0:05 wine --debugmsg +server msimn.exe PID WCHAN 2531 down > > Hmm. Could you try getting a Wine trace (especially the server/ > client interaction)? ftp://wine.codeweavers.com/pub/other/outlook-server.out.gz (about 160K). Thanks, Jer

March 25, 2001

Re: Printing documentation not built

by Francois Gouget

On Sun, 25 Mar 2001, Ian Pilcher wrote: > It looks like the contents of documentation/printing.sgml are not being > included in either the HTML or PostScript/PDF documentation. Anyone > know how to fix this? I propose the following. Does everyone agree with the placement in the wine-user/configuration section? (I'm not quite sure about the rationale behind the order of things in the configuration section) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

March 25, 2001

Re: Nasty Wine/kernel bug, anyone?

by Jeremy White

gerard patel wrote: > At 12:14 PM 20/03/2001 -0600, you wrote: > > <snip> > >I saw at least other user report on this (Steve Fox reported this > >with Lotus Notes). > > > >My best guess is that this is a bug in the vfat driver, > >but that's just a hunch. > > Where did this Notes bug turn up ? I never saw it on the news group, > and it's not in your bug database. I'm curious because I would like to > know how to reproduce it (I don't want not install Win98 and Outlook to > test this :-/) I think it was in the newsgroup; I found it by doing a google search on dead threads. Ulrich, I haven't been able to reproduce it in the few simple attempts I've made, but I'll take a more focused try at it tomorrow. Jer

March 25, 2001

building wine-20010305

by Igor

Hi to ALL, This is the first time I am writing to the WINE-DEVEL list. First of all, I have to congratulate all the developers for their outstanding job. Then I have to say that I have downloaded, more or less, ALL the versions of WINE back to March 1999. The sequence "configure-->make_depend-->make" worked flawlessly ..... UNTIL today This is the first time I am not able to compile WINE source code on my system. my system is: REHAT Linux 2.2.14-5.0 i686 gcc compiler is gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) glibc libray is: glibc-2.1.3-15 ./configure goes through without a glitch make depend does not cause any problem at all but when I start "make" I do get on the screen the following ld -r builtin.o relay.o snoop.o thunk.o asmrelay.o thunk.glue.o -o if1632.o make[3]: Leaving directory `/usr/local/downloads/tarballs/wine-20010305/wine-20010305/if1632' make[3]: Entering directory `/usr/local/downloads/tarballs/wine-20010305/wine-20010305/loader' gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o elf.o elf.c gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o loadorder.o loadorder.c In file included from ../include/heap.h:13, from loadorder.c:15: ../include/winbase.h:1917: parse error before `!' make[3]: *** [loadorder.o] Error 1 If out there is a good soul to help me out , I would really appreciate it Thanks In advance Igor Furlan

March 25, 2001

Printing documentation not built

by Ian Pilcher

It looks like the contents of documentation/printing.sgml are not being included in either the HTML or PostScript/PDF documentation. Anyone know how to fix this? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

March 25, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > Exactly. > > I think a compromise would be to create a wrapper script that modifies > the config file first to use appropriate settings and then calls the main > Wine binary. That's certainly a possibility. If you want a more temporary change you could also use regapi to change the config branch in the registry. Yet another possibility would be to add a "fast" mode to the debugger where it wouldn't load symbols or anything, simply setup the environment and launch an application. This could be the first step towards making it change debugmsg options during execution too. And all these solutions are potentially much more generic than the few existing options, since you could use the same mechanism to change just about anything in the configuration. -- Alexandre Julliard julliard(a)winehq.com

March 25, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Andreas Mohr

On Sat, Mar 24, 2001 at 04:07:33PM -0500, Guy L. Albertelli wrote: > > -----Original Message----- > From: Alexandre Julliard <julliard(a)winehq.com> > To: andi(a)rhlx01.fht-esslingen.de <andi(a)rhlx01.fht-esslingen.de> > Cc: Wine Devel <wine-devel(a)winehq.com> > Date: Saturday, March 24, 2001 2:34 PM > Subject: Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ... > > > >There are tons of settings that can only be set through the config > >file; why are the few remaining options so much different that you > >need to set them on the command line? and how do you pass options > >when an app is not launched from the command-line (like from another > >Windows app, or from a desktop icon)? > > > > > As a developer, I find the ability to > change -desktop/-managed, -debugmsg, -dll options on every run from the > command line invaluable. If I had to edit config every time I wanted to > change -debugmsg or -dll options, my progress would be at least cut in half. Exactly. I think a compromise would be to create a wrapper script that modifies the config file first to use appropriate settings and then calls the main Wine binary. Ugh, yet another wrapper hack... ;-) But that should actually be usable. After all you'd have to change the Codeweavers Preview/Debian package wrapper script to support that, too. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Guy L. Albertelli

-----Original Message----- From: Alexandre Julliard <julliard(a)winehq.com> To: andi(a)rhlx01.fht-esslingen.de <andi(a)rhlx01.fht-esslingen.de> Cc: Wine Devel <wine-devel(a)winehq.com> Date: Saturday, March 24, 2001 2:34 PM Subject: Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ... >There are tons of settings that can only be set through the config >file; why are the few remaining options so much different that you >need to set them on the command line? and how do you pass options >when an app is not launched from the command-line (like from another >Windows app, or from a desktop icon)? > As a developer, I find the ability to change -desktop/-managed, -debugmsg, -dll options on every run from the command line invaluable. If I had to edit config every time I wanted to change -debugmsg or -dll options, my progress would be at least cut in half. Guy

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > There are some options, like the --desktop/--managed option, that the user > may want to change quite often. Having to edit the config file is painfull > in that case. It will soon be possible to specify them per-application in the config file, so this should address the main reason for changing them often. If people really want more flexibility there are many ways of doing that; but hard-coding the options in kernel32 isn't one of them. -- Alexandre Julliard julliard(a)winehq.com

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> There are tons of settings that can only be set through the Alexandre> config file; why are the few remaining options so much Alexandre> different that you need to set them on the command line? and Alexandre> how do you pass options when an app is not launched from the Alexandre> command-line (like from another Windows app, or from a Alexandre> desktop icon)? There are some options, like the --desktop/--managed option, that the user may want to change quite often. Having to edit the config file is painfull in that case. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > IMHO --desktop is *very* important. > > This will inevitably lead to tons of very confused questions, just like > with the sudden config file change. Yep, and there will still be other changes that will break everything and confuse users (think window management for instance); that the reason we are not at 1.0 yet. > And why don't you get rid of --managed then either ? It will happen, don't worry... > And how exactly does this break dll separation ? Because with these command-line options kernel32 must know about and export information specific to x11drv. Also there's a larger issue of mechanism vs. policy; if we want to be able to use the same set of Wine libraries for multiple usage (wine loader, Winelib apps, mp3 players loading Windows dlls, etc.) we need to move all policy decisions to the higher layers. We cannot have kernel32 enforce a specific command-line usage, since this doesn't apply in all cases. For another instance of the same issue, see the discussion about the deferred debug trace a couple of weeks ago: we need the Wine libraries to provide the *mechanism* to display tracing and other informations, but the *policy* of when and how to switch tracing on or off must be moved to higher layers (like the debugger) instead of hardcoding a magic key sequence in user32. > Can't we solve this in another way ? > (i.e. maybe keep cmdline options for Wine, but don't use them for Winelib > apps) > Getting rid of all command-line options is not really an option IMHO. > They are just way too useful. There are tons of settings that can only be set through the config file; why are the few remaining options so much different that you need to set them on the command line? and how do you pass options when an app is not launched from the command-line (like from another Windows app, or from a desktop icon)? -- Alexandre Julliard julliard(a)winehq.com

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Andreas Mohr

On Fri, Mar 23, 2001 at 04:25:09PM -0800, Alexandre Julliard wrote: > Andreas Mohr <a.mohr(a)mailto.de> writes: > > > Huh ?? > > > > Why would you consider --desktop to be "obsolete" ? > > It's not obsolete, it just has to be specified in the config file > instead. All command-line options are going to disappear at some > point, first because they are problematic for some Winelib apps, and > second because they break dll separation. Hmmmm. IMHO --desktop is *very* important. This will inevitably lead to tons of very confused questions, just like with the sudden config file change. You could really have announced this change in advance. And why don't you get rid of --managed then either ? And how exactly does this break dll separation ? (sorry, /me is just being dumb here again) There are already dozens of things handled globally without any problem, so why would this one be special ? The Winelib argument should be sort of valid, though. Can't we solve this in another way ? (i.e. maybe keep cmdline options for Wine, but don't use them for Winelib apps) Getting rid of all command-line options is not really an option IMHO. They are just way too useful. (think about --debugmsg, too !) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Alexandre Julliard

Andreas Mohr <a.mohr(a)mailto.de> writes: > Huh ?? > > Why would you consider --desktop to be "obsolete" ? It's not obsolete, it just has to be specified in the config file instead. All command-line options are going to disappear at some point, first because they are problematic for some Winelib apps, and second because they break dll separation. -- Alexandre Julliard julliard(a)winehq.com

March 24, 2001

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...

by Andreas Mohr

On Fri, Mar 23, 2001 at 06:45:46PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 98539114690732747875154 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/03/23 18:45:46 > > Modified files: > dlls/x11drv : x11drv_main.c > documentation : wine.man.in > documentation/samples: config > graphics/x11drv: xfont.c > include : options.h x11drv.h > misc : options.c > windows : dce.c win.c > windows/x11drv : event.c wnd.c > > Log message: > Cleanup properly on x11drv unloading. > Moved --synchronous option into config file. > Removed --desktop, --display and --language command-line options. Huh ?? Why would you consider --desktop to be "obsolete" ? Andreas Mohr

March 24, 2001