- Wine-Devel - list.winehq.org

Sendmessage fix..
by crazney March 31, 2001

March 31, 2001

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.

1 0

Re: [PATCH] HOOK_CallHook
by David Elliott March 30, 2001

March 30, 2001

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

6 9

Re: [PATCH] HOOK_CallHook
by François Jacques March 30, 2001

March 30, 2001

>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

1 0

Re: [PATCH] HOOK_CallHook
by François Jacques March 30, 2001

March 30, 2001

>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

1 0

Re: controls/edit.c
by lawson_whitney＠juno.com March 29, 2001

March 29, 2001

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.

1 0

Re: controls/edit.c
by Ulrich Czekalla March 29, 2001

March 29, 2001

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); }

1 0

[CHECKER] Stanford enhanced gcc found 741 errors in wine source
by Dan Kegel March 27, 2001

March 27, 2001

... 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

1 0

Nasty Wine/kernel bug, anyone?
by Jeremy White March 27, 2001

March 27, 2001

I'm able to consistently reproduce a kernel bug whilst running Wine (both 0305 and todays CVS) and the version of Outlook Express that comes with Win98. That is, if I use a pretty stock Wine config, and launch msimn.exe, we get the splash screen, and then a process stuck in 'D' (uninterruptible sleep). At this point, AFAIK, the only solution is to wait for the IO to timeout (I haven't been patient enough to see if it does), or to reboot. Because the process is already gone, I can't strace or gdb it. Anyone a) Want to take this on? b) Have advice on how I can generate enough debug info that we can feed it to the Kernel guys to get it fixed? And yes, this happens both on a 2.2 system and a 2.4 system. 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. Jer

2 7

TransGaming & SourceForge
by Gavriel State March 26, 2001

March 26, 2001

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

1 0

WineX-Transgaming
by Gottfried F. Zojer March 26, 2001

March 26, 2001

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

2 1