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

Re: OpenGL Visual Management
by lawson_whitney＠juno.com April 16, 2001

April 16, 2001

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.

2 11

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard April 9, 2001

April 9, 2001

"James Hatheway" <james(a)macadamian.com> writes: > I implemented the callback in a very similar way as the Wave out callback > is implemented. You can see this in the functions wodOpen(), wodOpenHelper(), > and WAVEMAP_DstCallback() , look at the data passed in the wom structure > (in dlls/winmm/wavemap/wavemap.c). I don't see any other way that I will > be able to callback into the app when the WineOSS layer notifies the wavemap > layer. The way it is now (wineoss directly calling the app) > causes my app to crash, and doesn't work that way on waveout. But these other functions are not using the WINE_MLD internal winmm structure, so why do you need it in widOpen()? Couldn't you instead do exactly what wodOpen() does? -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: Nasty Wine/kernel bug, anyone?
by Ulrich Weigand April 6, 2001

April 6, 2001

> 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

2 1

Re: [PATCH] deferred trace
by gerard patel April 6, 2001

April 6, 2001

At 03:00 PM 14/03/2001 -0800, you wrote: <snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed. Expressed ? What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time. I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people. And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it. So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-) Gerard

2 1

RegSetValueEx problem?
by davep March 31, 2001

March 31, 2001

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

1 0

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 29, 2001

March 29, 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 29, 2001

March 29, 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

Some ideas/bugs that turned out while playing Fallout
by Jukka Heinonen March 26, 2001

March 26, 2001

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

1 0

Re: building wine-20010305
by furlan＠telocity.com March 26, 2001

March 26, 2001

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

2 1

building wine-20010305
by Igor March 25, 2001

March 25, 2001

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

2 1

Printing documentation not built
by Ian Pilcher March 25, 2001

March 25, 2001

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

2 1

Re: Nasty Wine/kernel bug, anyone?
by gerard patel March 25, 2001

March 25, 2001

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 :-/) Btw, since Borland released Kylix they talk of a glibc bug in dlopen : http://community.borland.com/article/0,1410,26998,00.html do you know if it's a concern for Wine too ? Gerard

3 2

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard March 24, 2001

March 24, 2001

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

1 0

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Guy L. Albertelli March 24, 2001

March 24, 2001

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

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard March 24, 2001

March 24, 2001

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

1 0

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard March 24, 2001

March 24, 2001

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

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard March 24, 2001

March 24, 2001

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

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Andreas Mohr March 23, 2001

March 23, 2001

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

1 0

Re: Handling overlapping buffers in wcstombs_sbcs
by Alexandre Julliard March 23, 2001

March 23, 2001

Fran=E7ois Gouget <fgouget(a)codeweavers.com> writes: > Actually the documentation specifies that WideCharToMultiByte (cal= led > by ConvertVersionInfo32To16) fails if the source and destination > pointers are the same. But it does not specify what happens if the > buffers merelyt overlap. And of course in the ConvertVersionInfo32To16 > case there's a 2 byte difference between them! Then ConvertVersionInfo32To16 is broken; WideCharToMultiByte does not support overlapping buffers. > I'm not really convinced by the loop unrolling but I tried to keep= it > anyway. I just modified it a bit. If someone's interested in doing > actual performance tests, wants to look at the assembly or knows how > manual loop unrolling must be done, go ahead. You know, I did exactly that (looking at the assembly and running performance tests) when implementing it; it may be possible to improve it more by optimizing CPU pipelines usage, which is something I don't know too much about. But I strongly doubt you can improve it by only looking at the C source... --=20 Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard March 22, 2001

March 22, 2001

"James Hatheway" <james(a)macadamian.com> writes: > Changelog: > James Hatheway - james(a)macadamian.com > widOpen in the wavemapper should use a callback. It doesn't seem right to use winmm internal structures here. Are you sure this is the right way to do it? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Nasty Wine/kernel bug, anyone?
by Alexandre Julliard March 22, 2001

March 22, 2001

lawson_whitney(a)juno.com writes: > Or is this a different glibc bug? Yes, it's apparently a bug in reference counting when freeing libraries; since we never free our libraries at the moment, we haven't run into this one yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

problems compiling mfc with winelib
by Doug Alcorn March 22, 2001

March 22, 2001

I have a small apps with only about half a dozen dialogs. It was originally developed in MS-DevStudio. Our desire is to use the same code between MS-Windows and Linux/Unix using the winelib. This app is derived from CWinApp and uses mfc for all the widgets. I'm told it would take too much effort to redo the app without mfc (I'm not a windows programmer, and don't know much about all that). So, my assumption based on reading winehq.com is that I need to compile the mfc using winelib. I got all the code over to my linux box and converted all the files/directories to lowercase only. I got the mfc, atl, and some other include directory that was under "Program Files/Visual Studio/VC98" (or something similar). I ran winemaker on the mfc directory and successfully got the configure script built. The problem is getting the make files built. I had to define both CFLAGS and CPPFLAGS "-D_WIN32 -DWIN32 -D_WINDOWS -D_MBSC" in the environment. Here's my configure line: $ ./configure --with-win=/path/to/wine/sources --with-atl-includes=/path/to/atl/includes --with-mfc-includes=/path/to/parent/of/mfc/includes It goes allong pretty well until it checks for afx.h. That's when it bombs majorly. I get pages and pages of compile time errors in the config.log. Lots of parse errors, syntax errors, scoping errors, redifinitions... lots of stuff. Am I right that I have to compile mfc? Is this something that most developers using winelib to compile windows programs do? Are there instructions for doing so? At this point I'm totally stumped. I'm not about to start debugging mfc. I'll re-write the app before I do that. What is the suggested course of action? -- (__) Doug Alcorn <doug(a)lathi.net> http://www.lathi.net oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.

2 1

Re: Port to OS/390 mainframe USS?
by James Hatheway March 22, 2001

March 22, 2001

Hello James, > I am not real clear about the difference between the PE loader and the > WINELIB, but then, I am also unclear as to why my user would want to run a > Windows app on the mainframe in the first place. Sorry, I should have been a bit more descriptive with my answer. The PE loader is used to run executable files that were compiled to be executed in Windows/intel environment (standard windows apps). It handles the 'magic' of loading a windows executable including the necessary dependecy checking, dynamic link library loading, etc. Once the executable is loaded and all dependecies to DLLs resolved and loaded the program is started and runs with the same intel code that would have executed in windows. Whenever the app makes a call to a Windows API function, the code actually is handled by WINE code (or the native windows DLLs if that is the user's configuration) That is why WINE is not an 'emulator' rather a reimplementation of the Windows API. That is also why it is tied to the intel platform, since it is still directly executing intel code. Since WINE is comprised mainly of a reimplementation of the Windows API, it can also be used as a porting library for application developers. WineLib allows a developer to recompile his Windows source so that it will run on other unix platforms (including other CPU architectures than intel). The problem is that not as much work goes into the WineLib side of WINE than does go into the mainstream WINE side of things. My understanding is that WineLib has been built on Solaris/Sparc, powerpc, and s390 with varying degrees of success. Also I don't know if the patches that got these platforms to build are actually in the main CVS tree. Searches through past WineHQ discussions can bring up the names of those who worked on this stuff. So, unless your user has access to the source code to his app, he can't use WINE to run his app on the S390. I'm not sure if WineLib has advanced enough to support his app on the S390, and in fact Wine itself might not support his app on intel either, that is a case by case thing. (although WINE works quite well for a lot of apps) Finally I have no idea why a user would want to run a windows app on a s390. ^_^ > Is there someone at Ulrich that I should be talking to? Ulrich is a person: Ulrich Weigand. He subscribes to the mailing list so I am sure he saw your message. You can get his email address from the mail list archives. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

2 2

Re: Nasty Wine/kernel bug, anyone?
by Steve Fox March 21, 2001

March 21, 2001

> Could you check in which kernel routine the process is blocked? > (e.g. using ps -Ao pid,wchan) Running 'ps -Ao pid,wchan' shows that all the processes in uninterruptible sleep are in the do_exit routine. >> Because the process is already gone, I can't strace or gdb it. > > What do you mean 'the process is already gone'? Could it be that > ptrace doesn't work because the Wine server has already attached > to that client process? I am unable to attach to it with gdb either. I get the error: Attaching to program: /opt/notes5/wine/bin/wine, Pid 22018 ptrace: Operation not permitted. > Steve, is VFAT also involved in your case? Only ext2 here. Steve Fox IBM Linux Technology Center http://oss.software.ibm.com/developerworks/opensource/linux http://stevefx.rchland.ibm.com (IBM Intranet)

1 0

Port to Sparc64
by Jutta Wrage March 21, 2001

March 21, 2001

Hi! What about the suggested port to Sparc? Did anybody work on that again? There was a question in the Wine-HOWTO mailing list. cu Jutta -- http://www.witch.westfalen.de/ Wine-HOWTO http://www.la-sorciere.de/wine/

2 1

any questions?
by Natanael Copa March 21, 2001

March 21, 2001

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

1 0

Port to OS/390 mainframe USS?
by James.Robinson＠crowley.com March 21, 2001

March 21, 2001

Will there be a port of WINE to OS/390 mainframe USS? LINUX runs fine under USS, so it would seem that WINE should run there as well. Has anyone done this yet? Thanks James Robinson james.robinson(a)crowley.com

4 3

any questions?
by Natanael Copa March 21, 2001

March 21, 2001

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard March 20, 2001

March 20, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Does the attached patch look as applicable? Yep, looks good. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: x11drv patch
by lawson_whitney＠juno.com March 20, 2001

March 20, 2001

On Mon, 19 Mar 2001, Ove Kaaven wrote: > Here's some more x11drv code... in addition to the HAL bits, it adds some > gamma control stuff, so we can implement Get/SetDeviceGammaRamp (in GDI). > > Log: > Ove Kaaven <ovek(a)transgaming.com> > Added gamma ramp code to the XVidMode interface. Good day! I think this misses x11ddraw.h. At least, I don't have it. xvidmode.c:16: x11ddraw.h: No such file or directory I will find it though. Lawson ________________________________________________________________ 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.

2 2

wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed
by Dmitry Timoshkov March 20, 2001

March 20, 2001

Hello all. I have this very strange situation: Debugging with +relay,+win,+region,+message has revealed: ... Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] WM_GETDLGCODE sent from self wp=00000000 lp=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] WM_GETDLGCODE returned 00000100 wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - info->output)' failed. err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) fs=0287 It seemed to be as libc bug and I have upgraded my stock rh 6.2 from ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. Any suggestions?

2 1

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard March 20, 2001

March 20, 2001

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set. I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. It's unlikely we are ever going to support proper LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard March 19, 2001

March 19, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of > undesirable LOAD_LIBRARY_AS_DATAFILE? Not necessarily, it may be considered a feature to load version info from the native dll, even though the actual code will run from the builtin. This may help programs believe they got the exact version they wanted (since presumably the app installed the dll in the first place). > Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future? Unlikely; the problem is that we cannot prevent constructors from running, and we need to resolve imports before running constructors. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard March 19, 2001

March 19, 2001

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > But here is a problem. This doesn't honor a load order. If load order > of a requested dll explicitly specified as 'builin' but 'native' library > there is somewhere in the path, then we will get unexpected result. > How to cope with it? I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. -- Alexandre Julliard julliard(a)winehq.com

2 1

fixme:win32:DeviceIoControl Unimplemented control 104 for VxD device SECPROV
by Achilleas Mantzios March 19, 2001

March 19, 2001

Does anyone have a clue??? P.S. You have done serious job :) i wanna say. -- Á÷éëëÝáò ÌÜíôæéïò Application Developer Eurisko A.E. ÐéíäÜñïõ 9 106 71 ÁèÞíá Ôçë: +301 3633362 Öáî: +301 3633074 e-mail: achilleas.mantzios(a)eurisko.gr

1 0

Re: RFC: client side implementation of async I/O
by Mike McCormack March 18, 2001

March 18, 2001

Hi All, WWW reported that my client side async patch relies on the service thread... sorry for not clearly explaining, but it doesn't. It works by multiplexing the server's wait reponse fd with pending i/o operation fds using poll. When i have time, i'll try to clean it up a bit. Currently i'm working on a kernel patch to help implement other WaitCommEvent flags. i hope Alexandre considers applying the client side async patch in some form. Mike ------------------------------------------ mailto:Mike_McCormack(a)looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

Re: Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel March 18, 2001

March 18, 2001

At 11:44 PM 17/03/2001 -0500, you wrote: >Strange but true. I reverted the patch, and alt-b beeps but does not >cause a crash. With the patch in, wine crashes without a beep. > >Now I guess I'll put it back in. It doesn't cripple me if wine crashes >when I fat-finger the GUI. I guess wine-devel doesn't want to see a >trace, and maybe you don't either, but if you do it will save time to >send it. I had left out some cases in my first try :/, but maybe it's better to understand firsst what the app is doing. Could you send me a complete (from start) +relay,+menu trace of your app crashing with current Wine (no copy to wine-devel is best in this case) If you can apply the following patch to enhance trace first : --- menu.c.orig Sun Mar 18 10:18:31 2001 +++ menu.c Sun Mar 18 11:28:29 2001 @@ -1852,6 +1852,7 @@ LPWSTR prevText = IS_STRING_ITEM(item->fType) ? item->text : NULL; debug_print_menuitem("MENU_SetItemData from: ", item, ""); + TRACE("flags=%x str=%p\n", flags, str); if (IS_STRING_ITEM(flags)) { @@ -4511,6 +4512,9 @@ { if (!menu) return FALSE; + debug_print_menuitem("MENU_SetItemInfo_common from: ", menu, ""); + TRACE("mask=%x type=%x text=%p\n", lpmii->fMask, lpmii->fType, lpmii->dwTypeData); + if (lpmii->fMask & MIIM_TYPE ) { /* Get rid of old string. */ if ( IS_STRING_ITEM(menu->fType) && menu->text) { @@ -4589,7 +4603,7 @@ if (lpmii->fMask & MIIM_DATA) menu->dwItemData = lpmii->dwItemData; - debug_print_menuitem("SetMenuItemInfo_common: ", menu, ""); + debug_print_menuitem("SetMenuItemInfo_common to : ", menu, ""); return TRUE; } Thanks. Gerard

2 1

Menu crash - was : Re: [PATCH] Version info for comctl32.dll
by gerard patel March 17, 2001

March 17, 2001

At 10:26 PM 16/03/2001 -0500, you wrote: > >On a related note, I provoked that crash in menu.c again, this time by >hitting an accelerator key (?) for a button that was not enabled at the >time. First thanks for the bug report. The trace is not difficult to read, the menu item is a text item and the text pointer is NULL. MENU_CalcItemSize is not handling this case. What is strange is this problem appears only with my patch. Maybe your app is really initializing the menu when receiving the WM_INITMENU message, but *only* when there is need to display the menu. I can't see how it could find out about it, though. Anyway, could you try the following patch ? It tries to remove the main case I saw where the app can set a menu item to text type with a null text pointer. It is a legitimate patch by itself, even if it does not fix your problem. Maybe it could have nasty side effects. If it avoids the systematic crash, try to find if the other is really gone for good too. I have found a strangeness in the HEAP_strdup macros - WARNING - this is of interest to anyone dabbling with Wine code. While HEAP_strdupW and HEAP_strdupAtoW appear very similar, the specs are not the same; one returns a null pointer when called with a null pointer, the other allocates 2 bytes of memory and returns a pointer to it. Nice trap :-) Gerard --- menu.c.orig Wed Mar 14 20:19:46 2001 +++ menu.c Sat Mar 17 14:47:30 2001 @@ -4524,11 +4524,15 @@ menu->text = lpmii->dwTypeData; - if (IS_STRING_ITEM(menu->fType) && menu->text) { - if (unicode) - menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); - else - menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + if (IS_STRING_ITEM(menu->fType)) { + if (menu->text) { + if (unicode) + menu->text = HEAP_strdupW(GetProcessHeap(), 0, lpmii->dwTypeData); + else + menu->text = HEAP_strdupAtoW(GetProcessHeap(), 0, (LPSTR)lpmii->dwTypeData); + } + else + menu->fType |= MF_SEPARATOR; } }

2 2

Re: [PATCH] Version info for comctl32.dll
by gerard patel March 17, 2001

March 17, 2001

At 10:10 AM 15/03/2001 +0800, you wrote: >I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable >defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls >in ONE place. Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly. Unless the version number of winsock.dll, richedit.dll, version.dll, or unrelated dlls like that is always identical to the version number of common controls ? I did not check but that seems unlikely. >1. I believe that version numbers should be equal in both numerical field and >in the string value (0.01 != 4.72 and 1.00 != 4.72). >2. There is no need for excessive \000 at the end of the string value. >3. All well behaving programs do read "VarFileInfo"/"Translation" before >retrieving other version information. LANGUAGE does nothing here. >4. Did you try to use my sample application showing version info? >5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve >as an example of adding version resources into built-in dlls. Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-) I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource. Gerard

3 23

Re: [PATCH] Version info for comctl32.dll
by gerard patel March 16, 2001

March 16, 2001

At 08:54 PM 15/03/2001 -0500, you wrote: <snip> >for its version info and gets the builtin. The ver trace looks a little >strange to me - maybe it will make sense to you? Do you mean a strangeness that could go away with the following patch : --- info.c.orig Fri Feb 23 21:37:15 2001 +++ info.c Fri Mar 16 10:14:19 2001 @@ -503,8 +503,15 @@ && !VersionInfoIs16( data ) ) { /* convert resource from PE format to NE format */ - ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, - (VS_VERSION_INFO_STRUCT16 *)data ); + BYTE *ptemp = HeapAlloc(GetProcessHeap(), 0, datasize); + if (ptemp) + { + ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)data, + (VS_VERSION_INFO_STRUCT16 *)ptemp ); + memcpy(data, ptemp, datasize); + HeapFree(GetProcessHeap(), 0, ptemp); + + } } return TRUE; I don't think this will fix your problem, though. Gerard

2 1

Re: [PATCH] Recalculate menus after WM_INITMENU
by lawson_whitney＠juno.com March 16, 2001

March 16, 2001

On Mon, 12 Mar 2001, gerard patel wrote: > StatView (www.statview.com) menus don't work at all. > It seems that this app recreates all submenus of the > main menu in the WM_INITMENU handling. > > ChangeLog: > > * controls/menu.c > Recalculate menu sizes if WM_INITMENU has recreated/changed something > > Good day, Gerard! I have noticed a couple of crashes at controls/menu.c 872 since I applied this - when I fatfinger something in the wm (icewm) and keyboard input gets directed to a different window, but the event comes to wine, I think, but I haven't looked into it too closely and I'm not sure I can reproduce it. /* If we get here, then it must be a text item */ if (IS_STRING_ITEM( lpitem->fType )) { SIZE size; GetTextExtentPoint32W(hdc, lpitem->text, strlenW(lpitem->text), &size); and in this case lpitem is NULL and the strlen crashes. Would you be interested to see traces if I can reproduce it (if so which traces)? I think maybe it is a wm bug, but maybe wine should protect itself if it is not too expensive to do so? 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.

1 0

Re: Eliminate excessive retries in GetFileVersionInfo(Size)
by lawson_whitney＠juno.com March 15, 2001

March 15, 2001

Good day! Maybe it takes a Man from Mars to think that a windose function might ought to sort of do what its name implies, but the more I think about it, wouldn't it be simpler? It is right and proper for the functions of oleaut32.dll to be performed by liboleaut32.so and friends (if the Wine administrator so directs), but if the app asks for the version info for oleaut32.dll, and the named file exists (because the app's installer _put_ that file there, in this case) how about we give it the version info from that bloody file? If the file doesn't exist, we give it a builtin construct, say. IOW, disconnect file version from dll. I don't think it is any business of the app what does its work, so I don't see why it should be able to tell by GetFileVersionInfo whether the working blah.dll is builtin or native. I guess you could make a case for a [VersionOverrides] section in the config, but I am not going to. That way lies madness. I would be willing to take a shot at writing the code if that's what we decide we want, and if no one is in a great hurry for it, but... Regards, Lawson << Sardines of the world unite! << >> You have nothing to lose but your cans. >> ---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.

1 0

Re: Eliminate excessive retries in GetFileVersionInfo(Size) (fwd)
by lawson_whitney＠juno.com March 15, 2001

March 15, 2001

Oops, I misdirected this to wine-patches before. Sorry. On Thu, 15 Mar 2001, Dmitry Timoshkov wrote: > Hello. > > This patch helps eliminate excessive retries in GetFileVersionInfo(Size). > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Return from GetFileVersionInfo(Size) if specified file found, > but VS_VERSION_INFO resource not. > Good day! Here we go again. This breaks my app (juno 2.0.11) with builtin ole32/oleaut32. Native ole32/oleaut32 are so full of deadbeef they sort of stink. I guess we don't need to panic yet. I can revert it locally until so I can get and send mail until I see if I (or someone) can make some builtin version resources that will satisfy this app. It installs its own oleaut32.dll and with this patch in it thinks the install is busted. Regards, Lawson It is better to be lucky than good. - J. A. Soucy ---

1 0

Re: winedefault patch
by Andreas Mohr March 15, 2001

March 15, 2001

On Wed, Mar 14, 2001 at 09:35:17PM +0100, Ove Kaaven wrote: > Wine won't load builtin dlls if a full path to a nonexistent file is > specified, so the default registry should probably not have a full path to > dplayx.dll. Some guy managed to start Settlers 3 after this was fixed... > > Log: > Removed path from dplayx registry entry, so that the builtin dplayx can be > loaded. Alexandre, please add a comment to winedefault.reg reminding people of this problem for future entries. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 15, 2001

March 15, 2001

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > I am not exactly sure what you mean by this. Do you mean to put the > code that would be in the dll, into the debugger, or to extend the > debugger in such a way that it can load dll's to enhance its > functionality, or something else? I mean that the code that would have been in the dll and loaded into Wine should be in the debugger instead. So for instance, instead of having a magic key (or X message) to switch tracing on, you'd have a debugger command 'set tracing on' that would poke into the Wine address space to do it. Since you can read/write memory, call functions (I think it's broken now but should be easy to fix), etc. from the debugger you can do everything from here and avoid the need to have any debugging code running inside the Wine process. > This would bypass the objection of intercepting a key, like F12, and > using it to generate a window list dump, and replace it with a > mechanism that uses the debugger own builtin functions to do that. Yes, exactly. > I think it is desirable to use as much of the existing debugger > functionality as possible, and to add an "elaborate mechanism in the > debugger" that allows it to be dynamically extended in > functionality. It would certainly be possible to load dlls inside the debugger itself to extend it; though maybe simply loading a batch file containing debugger commands may allow to do a lot of things already without requiring compiling new code. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] Version info for comctl32.dll
by Dmitry Timoshkov March 14, 2001

March 14, 2001

"gerard patel" <gerard.patel(a)asi.fr> wrote: > ChangeLog: > > * dlls/comctl32/rsrc.rc > Add version info. [...] > LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +1 VERSIONINFO > +FILEVERSION 4, 72, 0, 0 > +PRODUCTVERSION 4, 72, 0, 0 > +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > +FILEOS VOS_DOS_WINDOWS16 [...] > + VALUE "FileVersion", "0.01\000" [...] > + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > My current design is to have yet another dll that would register > itself as the handler for this XClientMessage, so that on reciept of > the XClientMessage, it is simply passed to this new dll. This dll > would implement whatever application specific debugging tools I > need, with only the bare minimum of support from wine needed. Since > the wine debugger already has quite a bit of the functionality that > is needed, it might be interesting if this method could be used to > effectively open a pipe and drive the wine debugger externally. What you should rather do IMO is to put your dll inside the debugger, and have the debugger drive Wine instead of the other way around. Then you can add all kinds of elaborate mechanisms in the debugger, and do anything you want without needing any cooperation from the running Wine process. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: Problems with WM_NCHITTEST and HTTRANSPARENT
by Patrik Stridvall March 14, 2001

March 14, 2001

> I'm currently having problems with this situation: > > Thread 1 owns some controls (modeless dialog box, actually) > > Thread 2 owns a window that covers the dialog (let's say it's like a > "skin" or something...) > > The window procedure for thread 2's window return HTTRANSPARENT in its > WM_NCHITTEST handler, so in theory mouse messages should get > passed down > to thread 1's controls. Now, what happens is this... [snip] > Any ideas on how to solve this, or whether it's supposed to work at all? I > think I could fix some games if this worked... otherwise I'll have to > think of some other way... >From MSDN: < HTTRANSPARENT < In a window currently covered by another window in the same thread < (the message will be sent to underlying windows in the same thread < until one of them returns a code that is not HTTRANSPARENT). Note "window in the same thread". So it seems that you (Wine) shouldn't pass down mouse messages to thread 1 in your example.

1 0

Problems with WM_NCHITTEST and HTTRANSPARENT
by Ove Kaaven March 14, 2001

March 14, 2001

I'm currently having problems with this situation: Thread 1 owns some controls (modeless dialog box, actually) Thread 2 owns a window that covers the dialog (let's say it's like a "skin" or something...) The window procedure for thread 2's window return HTTRANSPARENT in its WM_NCHITTEST handler, so in theory mouse messages should get passed down to thread 1's controls. Now, what happens is this... -Mouse message arrives at thread 2 -TranslateMouseMsg calls WINPOS_WindowFromPoint -WINPOS_WindowFromPoint sends a WM_NCHITTEST to window -Window procedure returns HTTRANSPARENT -WINPOS_WindowFromPoint finds the controls, and returns that -TranslateMouseMsg wakes owner of controls (thread 1) -Mouse message arrives at thread 1 -TranslateMouseMsg calls WINPOS_WindowFromPoint -Since the transparent window is not owned by the current thread, WINPOS_WindowFromPoint doesn't bother to send it a message, but rather returns HTCLIENT directly -WINPOS_WindowFromPoint returns the transparent window -TranslateMouseMsg wakes thread 2 Repeat. This blocks all further mouse input processing, by the way... Any ideas on how to solve this, or whether it's supposed to work at all? I think I could fix some games if this worked... otherwise I'll have to think of some other way...

1 0

Re: [PATCH] deferred trace
by gerard patel March 14, 2001

March 14, 2001

At 12:04 PM 14/03/2001 -0500, you wrote: >I remember wishing fondly for something like this when we were working >on WordPerfect, but never having the time to do it myself. FYI someone at Codeweavers has something much more sophistificated than my simple patch but from my understanding it's not ready for general use :-/ Gerard

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

Gavriel State <gav(a)transgaming.com> writes: > I disagree - many of the bugs I encounter can happen well into the run > of a program. For example, debugging a dialog box in an app that comes > up only after a specific set of occurances. Having the ability to turn > on -debugmsg +all at will would make this kind of debugging much easier. My reply was more targeted at the dumping of the window handles; I don't deny switching tracing on or off would be useful, but it needs to be done in a more generic way. Also this can be done externally to Wine, so that we don't need to burden the core dlls with extra command-line options or magic key sequences. There are many ways of doing that; an output filter is very easy to do and would work in many situations; if you need more complex stuff you could do it from the debugger, or write a small app that uses the debug API to manipulate the tracing state. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard March 14, 2001

March 14, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > 2) I don't see how I will get the window list I generate with > WIN_WalkWindows if there is no change at all in Wine - I should > have said that to cut in the trace size in not a goal per se, but a > mean to make debugging easier. > If I have to make a first run with full trace that I have to browse to see > what is the meaning of the window handles appearing in the trace, I lose > a lot of time. Having immediately a view of all existing windows is *very* > handy. I don't doubt it's very useful for the specific problem you are tracking; but it's hardly generic enough to be included in the main tree. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Heroes 3
by Andreas Mohr March 13, 2001

March 13, 2001

On Mon, Mar 12, 2001 at 07:06:03PM +0100, Rustan Rosen rustan(a)lysator.liu.se [AndiM/Usenet 01/2001] wrote: > I found this on wine-users, and have the same problem. I did as you said, > and have attatched the file. Good ! > I have tried to test different setups, and seem to have problems with > directx, it wants to install 6.1, which doesnt work, and then says my > system doesnt have directx ('failed' in a checklist). I use the latest > wine in debian unstable, from 5/3 2001. After checking for directx, it > seems to install fine, but then just hangs. After killing it, and running > wine HEROES3.EXE > from the installed directory, it gives the above message. Can you help? > Shall I ask someone else? > Shall I supply more data? Call kernel32.192: CreateFileA(418c1a11 "C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod",c0000000,00000003,405e6ce4,00000003,00000080,00000000) ret=00599971 fs=008f trace:string:lstrcpynA (0x405e6400, "/kul/musik/wine/fake_windows", 1024) Ret kernel32.192: CreateFileA() retval=ffffffff ret=00599971 fs=008f . . . Call user32.425: MessageBoxA(00000000,005dd4fc "Unable to initialize resources - possible disk problem.",005dd628 "Unexpected Program Termination",00000010) ret=004cef94 fs=008f Hmm. Does C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod exist ? Or maybe this should be DATA\\h3sprite.lod ?? Hmm. Let me check this. I smell some Wine problem... BTW, have you tried running http://home.germany.net/100-30936/download/winecheck ? Probably doesn't help here, though... ARGL: Call kernel32.414: GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,405e6cdc,405e6ccc) ret=00599630 fs=008f trace:string:lstrcpynA (0x405e63d0, "/kul/musik/wine/fake_windows", 1024) trace:string:lstrcpynA (0x405e63ed, "Program Files/3DO/Heroes3", 995) trace:string:lstrcpynA (0x405e67d3, "PROG~FBU\\3DO\\HEROES3", 1021) trace:string:lstrcpynA (0x405e67d2, "/Program Files/3DO/Heroes3", 1021) trace:string:lstrcpynA (0x405e67ed, ".\\DATA\\", 995) trace:string:lstrcpynA (0x405e6cdc, "C:\\Program Files\\3DO\\Heroes3\\DATA", 260) Ret kernel32.414: GetFullPathNameA() retval=00000021 ret=00599630 fs=008f THAT's it !! GetFullPathNameA() is broken (clips trailing '\\'). Latest Wine release, BTW ? Or which one ? Oh well, something needs to be fixed then, I guess... ;-) Andreas Mohr

2 1

RE: The PEACE Project
by Patrik Stridvall March 13, 2001

March 13, 2001

> I don't know if you know about The PEACE Project: > > http://chiharu.haun.org/peace/ Now I do. :-) > What is PEACE? > > PEACE is a set of programs to run Win32 apps on NetBSD/i386 > (and other ports > in the future?) box. I see. > What is the difference from other Win32 emulators? > > Actually, PEACE is éWin32-compatible package' rather than > éemulator' because > different from Wine and WABI, And Wine isn't a "Win32-compatible package"? > PEACE does not have éemulator > executable'. > EXE files are directly executed from sh or csh. The above is IMHO a rather clintonesque use of the words emulator and executable. They hide the comparable code in NetBSD's dynamic linker instead. Not impressed, eventhough we could and probably should do that in the future. However if we hide the fact Wine is run, many user will not realize that it really is Wine's fault that their Win32 application crashes and say to their friends that Linux is unstable which gives Linux a bad reputation. We don't want that do we? So we probably shouldn't make it transparent at least not as long Wine still is alpha. > PEACE consists of the following 3 components: > > 1.In-kernel *.EXE loader Can't find the source but can't imagine it is very complicated. Probably somthing similar to what David Howells did for Linux. > 2.Dynamic linker for Windows *.DLLs Hmm, 233 lines of code including comments. Not very revolutionary. > 3.Win32 API implementation (i.e. core DLLs) This is supposed to do exact what Wine (Winelib) does. However it currently only implements a very small part of what Wine currently does as they admit... > How many Win32 API functions are implemented? > > Currentry, most APIs are NOT implemented. ... here In short this is just some Japanese guys trying to reinvent the wheel. I really can't understand why they don't cooperate with us in the Wine project instead.

6 5

Re: [PATCH] deferred trace
by gerard patel March 12, 2001

March 12, 2001

At 11:24 AM 10/03/2001 -0800, you wrote: >gerard patel <gerard.patel(a)asi.fr> writes: > >> This implements a way to not output the debug trace to disk until the >> user hits Alf + F12. The goal is to avoid too big trace files. > >I think it would be much better to do that with a small external >program that you pipe the debug output into. This way you can have >much more flexibility I don't see why. 2 other points : 1) I wonder if I will not lose in speed with this approach; it seems to be more efficient to stop the output ASAP, than to filter data after it has passed through a pipe. I have timed Bcb4 loading with Wine on my computer (K6-350) - without any trace : 48 seconds With a simple -debugmsg +win,+relay : - with my patch : 70 seconds -> 22 seconds overhead - with a redirection to /dev/null : 95 seconds -> 47 seconds overhead I don't know if a pipe would be more efficient that a redirection, though. 2) I don't see how I will get the window list I generate with WIN_WalkWindows if there is no change at all in Wine - I should have said that to cut in the trace size in not a goal per se, but a mean to make debugging easier. If I have to make a first run with full trace that I have to browse to see what is the meaning of the window handles appearing in the trace, I lose a lot of time. Having immediately a view of all existing windows is *very* handy. >, and you don't need to hardcode a specific key >that some apps may need. But my patch does not use the Alt+F12 key if the -dt command line option is not used. It's true that some apps use this key, but in this case it's only debugging that is affected because the app does something when I use this key. It has never been a problem until now. Maybe a signal could be used instead. Gerard

2 1

RE: The PEACE Project
by Patrik Stridvall March 12, 2001

March 12, 2001

> > > What is the difference from other Win32 emulators? > > > > > > Actually, PEACE is éWin32-compatible package' rather than > > > éemulator' because > > > different from Wine and WABI, > > > > And Wine isn't a "Win32-compatible package"? > > > > > PEACE does not have éemulator > > > executable'. > > > EXE files are directly executed from sh or csh. > > > > The above is IMHO a rather clintonesque use of the words > > emulator and executable. They hide the comparable code > > in NetBSD's dynamic linker instead. > > > > Clintonesque?? HAHAHAHAHAHAHAHAHAHAHA That's really good > dude! I guess it > follows in the tradition of words like "nasty". It follows the same tradition as the word quisling which means "A traitor that serves as the puppet of the enemy occuping his or her country." after Vidkun Quisling the notorius Norwegian traitor. Being clintonesque means "Deliberately distorting the meaning of a word or words in order to make somebody believe something that is not true." Compare Bill Clinton saying "I did not have sex with that woman" using a rather non standard definition of the word sex. In the case PEACE this might not have been deliberate, but because of ignorance, so perhaps the use of the word clintonesque was too harsh. > > Not impressed, eventhough we could and probably > > should do that in the future. > > > > I thought there was another kernel module running around that > loaded wine > for exe files. Used BINFMT_MISC or something? See Chad's mail. > > However if we hide the fact Wine is run, many user > > will not realize that it really is Wine's fault > > that their Win32 application crashes and say to > > their friends that Linux is unstable which gives > > Linux a bad reputation. We don't want that do we? > > > > So we probably shouldn't make it transparent at > > least not as long Wine still is alpha. > > > > Should there ever be a kernel module exe loader? The advantage of a kernel module loader is that you can do relocation on demand as well as having the ability to just discard such pages when memory is low instead of swapping them out. > Codeweavers is on the right track here, allowing users to > launch Windows > apps from gnome by creating a file association. Agreed. > > > PEACE consists of the following 3 components: > > > > > > 1.In-kernel *.EXE loader > > > > Can't find the source but can't imagine it is very complicated. > > Probably somthing similar to what David Howells did for Linux. > > > > I thought David's module was implementing the Wine in kernel > space (e.g. > part 3 of this). This part can be done with or without > having Wine in the > kernel. Not quite he is trying to implement the Wine _server_ in kernel space. ie approximately thoses things that requires some sort of intra-process communication. > > I really can't understand why they don't cooperate > > with us in the Wine project instead. > > I cannot either. I know that there is this whole thing about > wanting to > write your own code for stuff, but that is usually a waste of time. > Furthermore, the Wine project is developed in an extremely > open way by a lot > of very talented developers. It is a real shame to see > someone who could > obviously help out the Wine project going out and doing their > own program. > > Anyone can join the wine development team. Simply subscribe > to wine-devel > and wine-patches and start hacking. Because all patches go through > Alexandre before going into CVS every developer has basically > equal chances > of getting their patch into the tree (assuming that it is > following the > overall architecture goals of Wine). Indeed and if they prefer not to communicate in english, setting up a wine-devel-jp mailing list shouldn't be a problem. Most of the patches they send in will "speak" for itself without any or at least only a very short explaination. > Actually, I would say wine is an > extremely good example of the open source development process. > > There is also no licensing issue with Wine, it's under such a liberal > license that anyone can use it! Agreed.

1 0

RE: The PEACE Project
by Patrik Stridvall March 12, 2001

March 12, 2001

> > I really can't understand why they don't cooperate > > with us in the Wine project instead. > > That's exactly what I thought several weeks ago when I first > heard of it. > > Licensing issues might be the reason (I did not look at their > license !). They use the BSD license, unfortunately the one with the advertisment clause. However I don't imagine it will be a problem since there is very little if anything that they have implemented that we haven't implemented I long time ago already. Additional problem is that they use C++. :-) In short they have wasted a lot of effort for little or no gain. > Other than that I'm tired of YAW (Yet Another Windows, which is > the name of yet another windows package, coincidentally ;-) Indeed. I can understand people that start working with a project has a lot of ideas and the project leader rejects them and they grow tired and decide to do it themselves. However for a project like Wine most things really can't be done that many ways since it must be compatible with Windows so this shouldn't really be a very large problem. In this case perhaps they, being Japanse, felt uncomfortable with cooperating with english speaking people. I noticed that they have a Japanese only mailing list. Anyway we could always create a wine-devel-jp or whatever if that was a problem.

1 0

The PEACE Project
by Damjan Lango March 12, 2001

March 12, 2001

Hi, I don't know if you know about The PEACE Project: http://chiharu.haun.org/peace/ What is PEACE? PEACE is a set of programs to run Win32 apps on NetBSD/i386 (and other ports in the future?) box. What is the difference from other Win32 emulators? Actually, PEACE is `Win32-compatible package' rather than `emulator' because different from Wine and WABI, PEACE does not have `emulator executable'. EXE files are directly executed from sh or csh. Requirements More information PEACE consists of the following 3 components: 1.In-kernel *.EXE loader 2.Dynamic linker for Windows *.DLLs 3.Win32 API implementation (i.e. core DLLs) How many Win32 API functions are implemented? Currentry, most APIs are NOT implemented. (I'm not involved in that project, just found it on the web) ciao Damjan Lango

1 0

Re: RFC: client side implementation of async I/O
by Alexandre Julliard March 10, 2001

March 10, 2001

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > The patch can be further optimised, for example by keeping active asyncs in a > seperate list from inactive asyncs. i think it is more efficient because the > number of server calls and context switches is reduced. Reducing the number of server calls but making them more expensive is not necessarily a gain. Show me the numbers... > What i'm more interested in is whether having waiting clients running > concurrently with wineserver and those clients waking themselves from wait is > a good idea. I'm not sure it's a good idea, particularly if we want to support signals (which I think would be a good thing since it allows getting rid of the service thread). > Similarly, we could create a client side file handle cache that is alerted by > the wineserver when it becomes invalid. Before each fd is used, the cache > implementation would poll on the wineserver communication fd to confirm the > cache is valid, which would further improve the speed of file I/O. (a single > poll vs. a full server call) You'll probably still need a server call to find out about file locks at some point. And again you'll get in trouble if you want to support signals. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard March 10, 2001

March 10, 2001

gerard patel <gerard.patel(a)asi.fr> writes: > This implements a way to not output the debug trace to disk until the > user hits Alf + F12. The goal is to avoid too big trace files. I think it would be much better to do that with a small external program that you pipe the debug output into. This way you can have much more flexibility, and you don't need to hardcode a specific key that some apps may need. -- Alexandre Julliard julliard(a)winehq.com

1 0

Palette managing
by kenon＠go2.pl March 9, 2001

March 9, 2001

Hi In file windows/painting.c in function RealizePalette16 I found that line 1713: if (hWnd) SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); broke some applications . When I comment it out - every things work well, but when I leave it some child-windows are displayed in improper place. I think this message should be sent only when used entry in COLOR_sysPal is replaced by new one (function X11DRV_PALETTE_SetMapping in line 907 when index == -1). Maciek Kaliszewski

1 0

Re: Edit control notification fix
by Andreas Mohr March 9, 2001

March 9, 2001

On Fri, Mar 09, 2001 at 03:52:56PM +0800, Dmitry Timoshkov wrote: > Hello. > > Andreas Mohr privately reported that some old 16-bit installer > started to not update its edit control after my patch entitled > "Do not notify parent of the Edit control on WM_SETTEXT when Edit > is part of the ComboBox." Investigation has shown that installer > has its main dialog window defined in resources, and DIALOG_GetControl16() > gets edit control with style ES_COMBO (0x200) defined there. > My first attempt to fix the trouble was to simply mask out not > allowed styles in the DIALOG_GetControl16(): i.e. for edit control > do style &= ~ES_COMBO. That hack cured the application, but Andreas Well, that's not exactly true. You did not do it "for edit control". You did it for *all* controls in DIALOG_GetControl16() (at least in the patch you sent me). That's why I objected. I just had to :) > didn't like that approach. After some thinking, I added yet another > test into my "Edit Control Test Suit". And here is the result of it. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Do not send notification to parent of an edit control, > if parent is a child window. Remove old and not correct patch. OK. I can't really judge whether that's correct, as I'm not too much into these kinds of things. Hopefully it's correct :) Thanks again, Andreas Mohr

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > Not so... The file offset must also be page aligned! OK, this has apparently changed in kernel 2.4; in kernel 2.2 block size alignment is enough. That's unfortunate, but I guess it was necessary to support large files or memory sizes. Then yes, in 2.4 your patch will be more useful. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > My main gripe is the slow speed of access to files... Every Read/WriteFile > goes to the wineserver to convert the handle into a file descriptor and to > check for locking. The FD is then passed back over a UNIX domain socket, used > once and then closed. Note that we are no longer doing that in the latest versions; the file descriptor is only transferred once, and all further requests are done on a pipe which is faster than a socket. > Gavriel State <gav(a)transgaming.com> wrote: > > In my experience Alexandre far prefers incremental change to kind of > > approach you're taking. Using that kind of approach will improve the > > chances that your code will make it into Wine at some point. > > Hmmm... It's difficult to determine how to do it incrementally without making > for even more work, but I think I know what you mean. The kernel module itself may be hard to do incrementally, but you should really consider reusing the existing server API so that your module can be plugged in easily. For instance your module entry points should be the same as the server requests, and use the same request structures. > Context switching is the main element of it. Going to the wineserver and back > again just for a ReadFile() call or a Wait*() function incurs a fairly serious > penalty (particularly on an X86, I think). Plus there's no requirement for the > kernel to pass the remains of your timeslice to the wineserver and back > again. I still think that it should be possible to improve that by a small kernel hack. It will never be as fast as doing everything in the kernel of course, but it may just be fast enough to avoid the need to reimplement the whole server. > Look at the VM size of something like MS Word, and think of not having to > allocate buffers to store all those DLLs, thus eating a massive chunk out of > your machines total VM. Have you measured how many dirty pages you can avoid with your change? It seems to me that in most cases, when the dll is loaded at its preferred address, the number of pages made dirty by the fixups should be quite small anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 8, 2001

March 8, 2001

Gavriel State <gav(a)transgaming.com> writes: > Looking at the kernel sources, it appears to be page-alignment, not > filesystem block size that mmap needs to match. Rereading old wine-devel > archives, it appears that the notion that the filesystem block size is > involved is either from a very old kernel, or a misreading of some kernel > comments. Page alignment is needed for the address in memory, not for the offset inside the file on disk; since section virtual addresses in PE files are always page-aligned the memory address is never a problem. The only problem comes from the alignment of the data inside the PE file, and this is where we only need block-size alignment to make mmap possible. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by Alexandre Julliard March 7, 2001

March 7, 2001

David Howells <dhowells(a)cambridge.redhat.com> writes: > So this saves you the cost of the fd transfer net packet. Though you still > have to do the two context switches, which is my main contention. I suspect we are doing more than two switches (though I haven't proved it), which is why I think there is a margin for improvement. You'll obviously always have the context switch cost unless everything is in the kernel. > True, but I'd have thought that the context switches involved are still a cost > you can't get rid of so easily. Out of interest, how do you plan on doing the > locking stuff for Read/WriteFile? Cache it locally? It is unfortunate, but you > can't really make use of UNIX file locking, since this is mostly advisory and > as such doesn't actively stop read/write calls. Yes, we'll need to store the locks in the server and check them before each read/write (and probably also release them afterwards if necessary). There may be some optimisations possible, but we should probably do it the easy way first. > Seriously, though, whilst this'd be a lot easier in many ways (and it would > allow you to avoid the context-switch penalties), you wouldn't be able to take > full advantage of the available support in the kernel, which is more capable > than the standard UNIX userspace API suggests. I don't see why. I'm not suggesting keeping the current socket stuff, just reusing the structures. So basically instead of passing the address of the stack arguments (which is really ugly IMO) to your ioctl, you pass one of the server request structures. This allows your changes to be localized to wine_server_call and doesn't require changing any of the routines that make server calls. Obviously you'd need some more changes for a few calls like ReadFile/WriteFile, but most operations could switch to your mechanism without needing any change. You simply cannot require people to recompile all of Wine to use your module. > > I still think that it should be possible to improve that by a small > > kernel hack. It will never be as fast as doing everything in the > > kernel of course, but it may just be fast enough to avoid the need to > > reimplement the whole server. > > If you want to suggest exactly what you'd like to see as a hack... I don't know exactly, there are many ways of doing it; you can have a specialized fifo, a network protocol, an ioctl, etc. Basically any mechanism that ensures that we do the strict mimimum number of context switches and schedule() calls for a server call. And probably also a way to transfer chunks of memory from the client address space so that we don't need the shared memory area. > As far as I've observed (I've got Win2000 available), most Windows DLL's have > 512-byte (sector) alignment internally, _not_ 4096-byte (page) alignment for > the sections. This means that the separate sections can't be mmap'd (or else > they'd lose their required relative relationships): Actually the file alignment doesn't need to be 4096, it needs to match the filesystem block size. On a FAT filesystem the block size is 512 so Linux will happily mmap every section. On a 1k-block ext2 fs it will be able to mmap about 50% of them. > Also, since DLLs and EXEs are not compiled as PIC (the MSDEV compiler not > having such an option as far as I can recall), the fixup tables usually seem > to apply to just about every page in the code section. Only if the dll cannot be loaded at the preferred address, which shouldn't happen too often. I'm not saying your patch is useless, but I doubt the gain is as large as you seem to think. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Wineserver semantics
by Alexandre Julliard March 6, 2001

March 6, 2001

Ryan Cumming <bodnar42(a)bodnar42.dhs.org> writes: > What about having the file descriptor cache explictly invaildated? Like, > the server keeps track of which file descriptors the various wine > processes have cached, and if a process closes or performs some locking > operation on a file descriptor, all the other wine proceses that are using > that file descriptor are explictly notified. This way processes can assume > a file descriptor is valid unless told otherwise... would this be any > better performance-wise? Does it fit in to the wineserver architecture > nicely? ;) Not really; you'd either need to callback into the client, which creates a lot of synchronisation issues, or use a shared memory area which implies locking. Either way doesn't really fit in the current model. And as mentioned already we'll probably still need a server call on each file access to implement file locking. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Wineserver semantics
by Alexandre Julliard March 6, 2001

March 6, 2001

Waldek Hebisch <hebisch(a)math.uni.wroc.pl> writes: > There is ongoing disscusion on how to seed up the wineserver. > So I have question concerning correctness of corrent implementation. > Namely, for reading or writing files I have not found any locking in > wineserver when issuing file descriptor to clients. On the other > hand the client closes file descriptor just after use, and also > disscusion in the group suggests that client is supposed to have > exclusive acces to file. So I would like to know what is the case: > 1) client is allowd to cache the descriptor > 2) current implementation depends on winning a race > 3) I missed locking in wineserver I'm not sure what you mean by 'exclusive access to the file'. If you mean file locking then this is not implemented, so there cannot be any race ;-) Currently the client is allowed to cache the descriptor, but before each read/write it checks with the server that the cache is still valid. There is a race that the handle can be modified between the check and the actual read, this will cause either a bad handle error or a read from the wrong file; but this is no different from what happens under Windows if the client is manipulating handles concurrently with a ReadFile. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winelauncher patch
by Jeremy White March 6, 2001

March 6, 2001

Ove, I have in fact determined why I did not use which: On Suse (and Caldera, I believe), which /usr/bin/wine returns an error string, making the whole script go straight down the drain. What was wrong with the previous implemenation? Are you getting a $0 value that doesn't include the path? In all of the test cases I have, invoking wine seems to bring in a $0 that includes enough of the path for the find logic to work. Jer > Hunk 2: > real_name=`find $0` don't find anything if the user typed "wine" or > something, wine is in /usr/bin, which is in PATH, but the cwd is ~... > rather run it through `which $0` first. Also, the symlink it's reading > don't have to be absolute (my symlinks are relative), deal with that. > > -real_name=`find $0 -type l -printf "%l\n"` > +argv0_path=`which $0` > +if [ -z $argv0_path ] ; then > + argv0_path=$0 > +fi > + > +real_name=`find $argv0_path -type l -printf "%l\n"` > if [ ! $real_name ]; then > - real_name=$0; > + real_name=$argv0_path > +elif [ ! -x $real_name ]; then > + real_name=`find $argv0_path -printf "%h\n"`/$real_name > fi > + > argv0_dir=`find $real_name -printf "%h\n"` > > if [ -z $argv0_dir ] ; then > @@ -130,7 +138,7 @@ > WINESERVER=$WINEBIN/server/wineserver > fi

2 1

Wineserver semantics
by Waldek Hebisch March 6, 2001

March 6, 2001

There is ongoing disscusion on how to seed up the wineserver. So I have question concerning correctness of corrent implementation. Namely, for reading or writing files I have not found any locking in wineserver when issuing file descriptor to clients. On the other hand the client closes file descriptor just after use, and also disscusion in the group suggests that client is supposed to have exclusive acces to file. So I would like to know what is the case: 1) client is allowd to cache the descriptor 2) current implementation depends on winning a race 3) I missed locking in wineserver -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

WinCE/PocketWindows?
by Robert & Jennifer Hartley March 6, 2001

March 6, 2001

Hi, (Please forgive me if this has already been examined, as this is my first post.) I am curious to know if a version of WINE has been considered that would be made to run WinCE (CE) and PocketWindows (PW) applications on Linux PDAs. I have been working with the Agenda VR3 PDA from www.agendacomputing that runs Linux very well on a MIPS processor. I also received a free set of Embedded Tools CDs from MicroSoft that have VC++ and VB on them for building CE and PW applications. The platforms it supports are X86, MIPS, ARM, and SH3, and I believe there are others. There is a compatability layer that runs on WinNT to test before deploying. If we had that emulated in Linux, then we would be most of the way towards being done. (Or so I would imagine.) Naturally, since I am a Linux/Unix guy, I was thinking that it would be neat to have these CE/PW apps running on my X86 Linux box, my NetWinder, my venerable old Indy, and finally, once debugged, on this Agenda Linux PDA. The WINE community has already done a huge amount of great work, so I thought that maybe a cut down version of WINE would work on the CE/PW subsets of Windows. Being an outsider, could someone let me know if I am totally out there in LaLa Land? Thanks, Rob (here around Ottawa, ON) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Robert Hartley Mail: 201 Broadway = = Central Region Systems Engineer Cambridge, MA 02139 = = Integrated Computer Email: rhartley(a)ics.com = = Solutions, Inc. Web Site: www.ics.com = = Tech Support: support(a)ics.com Phone: 800-800-4271 = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the MotifZone (www.motifzone.org) for info on Motif!

1 0

Re: Perl/Wine extension for perusal
by Niki Spahiev March 6, 2001

March 6, 2001

Hello, Two small suggestions: 1. python has very good WIN32 bindings and also generic DLL interface CALLDLL. 2. VNC has alpha of macro recorder which can be used for interactive tests. Regards, Niki Spahiev

1 0

Re: RFC: client side implementation of async I/O
by Alexandre Julliard March 6, 2001

March 6, 2001

Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > This patch moves responsibility for asynchronous I/O to the client process. > i'm posting it to wine-devel because i want to know what other developers here > think about the technique i've used to make this work... Your approach is not going to work with the latest changes I made to the server. The good news is that the changes I'm making are in part to allow making server calls in signal handlers, so when this works you should be able to use SIGIO to do async IO. > i think this implementation is more efficient, as it makes fewer server calls > and duplicates fewer file descriptors, while maintaining correctness. It's not clear to me that it is more efficient; it seems it will do a lot more work on every single server call if an async IO is pending. Of course the only way to tell is to run benchmarks. -- Alexandre Julliard julliard(a)winehq.com

3 2

TCP/IP networking and registry keys
by Alan Chandler March 6, 2001

March 6, 2001

I spent most of the weekend trying to get Grand Prix Legends GPL to work. I achieved my first goal of getting it to run in server mode. One of the things I needed to get the game to do, was to recognise that there where some interfaces it could talk TCP/IP out of. It took me some time to realise that under windows it was doing this by looking for the key [System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then enumerating the keys under it to establish an IP address ie the following [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] "IPAddress"="10.0.10.100" The thought occurred to me that maybe the tool the builds the registry during wine install could actually create these keys - since it is essentially a key part of the system (and other similar keys are also built in the same way). I don't think I have the skills to do it myself yet. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

3 2

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells March 5, 2001

March 5, 2001

Gavriel State <gav(a)transgaming.com> wrote: > As it stands, your approach won't be useful for general Wine usage until > you've got *everything* done. True. But I think there are valid reasons for doing it this way. One major problem is handles. Either the kernel must allocate all handles, or userspace must allocate all handles. Take something like the implementation of DuplicateHandle() - dead easy really in kernel space, including duplication to another process. If userspace tells the kernel to use handle X for a mutex, say, and handle Y for a semaphore, then userspace still has to go to atomic management code to (a) allocate a handle, and (b) access a handle. And to implement cross-process duplication, you either need some sort of interrupt & IPC mechanism, or an external process (the wineserver). This being the case, you lose any gains by putting the stuff in-kernel. Alternatively, if userspace is allowed to implement arbitrary handles that are allocated by the kernel, then the kernel waiting mechanism can get a little tricky. However, that said, for non-waitable objects, this might not be so bad. In fact, I'm planning on implementing the registry access handles this way and may well do some of the process and thread control this way too. Furthermore, the kernel would have to be given object handles not object pointers, otherwise you have a gaping security hole. And another major problem is context switches... they are horribly expensive really. They currently make Wine with at least 20 times the system call latency that the kernel method is capable of. > And then there will be boatloads of debugging to do. Perhaps not as much as you think... I'm doing as much debugging as I can as I go along, just making sure the kernel objects work as I'd expect (not necessarily the same thing, true, as having "compatible" behaviour). > If there's any way that you can implement your kernel module more within the > context of the existing server architecture - replacing objects on a piece > by piece fashion rather than all at once - that might make it easier to > adopt. See above for why the piece-by-piece method is difficult. One alternative would be to invent a new network protocol (say AF_WINE), but that again requires a complete implementation before it is really useful. > For example, you might try implementing the core object/handle management > and waiting code in the kernel module, and have the wine server rely on the > kernel module for that low-level functionality. By this, do you mean actually having the wineserver process talk to the kernel module on behalf of the Wine application? > Waiting for objects would be implemented on the client side through a call > to the kernel module. That's what I'm currently doing, though it's not fully implemented yet. > When something needs to be done with an object, we would call either the > wineserver or the kernel module, depending on how that object is > implemented. > For example, you could do mutexes entirely within the kernel module, but > leave file objects on the wine-server side initially. My main gripe is the slow speed of access to files... Every Read/WriteFile goes to the wineserver to convert the handle into a file descriptor and to check for locking. The FD is then passed back over a UNIX domain socket, used once and then closed. I suspect it can't really be done otherwise, particularly if ZwCloseObject (or whatever it is called) is implemented, since this allows handles in another process to be closed. Actually, I've done a fair amount of the file object stuff... Most of it involves mapping down to a "struct file *", which is how the kernel views files, and then invoking appropriate kernel method. > In my experience Alexandre far prefers incremental change to kind of > approach you're taking. Using that kind of approach will improve the > chances that your code will make it into Wine at some point. Hmmm... It's difficult to determine how to do it incrementally without making for even more work, but I think I know what you mean. > One thing I've been wondering that you might be able to answer is this: > exactly why is the current Wine Server architecture so slow? Is it just the > context switching? Context switching is the main element of it. Going to the wineserver and back again just for a ReadFile() call or a Wait*() function incurs a fairly serious penalty (particularly on an X86, I think). Plus there's no requirement for the kernel to pass the remains of your timeslice to the wineserver and back again. Also, you have to bundle lots of data through AF_UNIX network packets and/or copy lots of data into and out of _shared_ memory without killing other threads. One of the problems with the context switch is that you have to flush all the CPU caches, muck around with the MMU and execute scheduling algorithms. > Is it that the kernel isn't giving the wineserver a high enough priority > once the client blocks after having written to the socket? I don't think priority has anything much to do with it. A more convenient scheduling algorithm might help a little, though. > Is it other socket overhead (routing, perhaps)? Simply speeding up the > communications path between the clients and the server would remove the need > for most of the kernel level services. I don't think so... To communicate with the wineserver you have to use some sort of waitable UNIX object (ie: a socket, a pipe, or a SYSV semaphore or message), do busy waiting (& kill your CPU), or send signals (context switch _and_ signal overhead). To do it without a wineserver (ie: using shared memory) is also tricky... You have to be able to, for instance, recover from processes going away without releasing mutexes. > Also, just FYI, the PE image mapping work is nice, but isn't likely to affect > speed all that much, since Wine can just mmap in most PE images created with > recent compilers. WordPerfect, for example, launches in around 10-12 seconds > on my machine (down from 45-60 seconds before the mmaping). I can't imagine > that doing the fixups when paging instead would do too much better. Look at the VM size of something like MS Word, and think of not having to allocate buffers to store all those DLLs, thus eating a massive chunk out of your machines total VM. Plus, it should be even quicker launching because fixups don't have to be done unless they're necessary. You certainly don't have to go through an fixup a few tens of megs of DLL. Cheers, David

1 0

Wine Press
by Eric Pouech March 5, 2001

March 5, 2001

http://linux.cnet.com/linux/0-2136864-7-4961586.html worth the reading, even if Wine gets the lowest ranking my reading of it is that Wine is not yet a product (compared to the two others). I definitively think we should focus more on a release target. It of course means that we have to make choices (do not include some functionnalities), spend pretty much more time on testing... but that's the way to go if we want to have Wine 1.0 around on of these days A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

3 2

Re: RESUBMIT: afm
by Gavriel State March 5, 2001

March 5, 2001

Back in Febuary, Marcus Meissner wrote: > > Changelog: > fixed one NULL ptr problem > added loading of .afm files from several common locations > (ghostscript, a2ps, enscript, (teTeX), X11) > > Index: afm.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/afm.c,v > retrieving revision 1.4 > diff -u -r1.4 afm.c > --- afm.c 2001/01/02 20:30:16 1.4 > +++ afm.c 2001/02/03 18:50:42 > BOOL PSDRV_GetFontMetrics(void) > { > int idx = 0; > char key[256]; > char value[256]; > + char *path; > + DIR *dir; > + > + /* some packages with afm files in that directory */ > + PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/"); > + PSDRV_ReadAFMDir("/usr/share/a2ps/afm/"); > + PSDRV_ReadAFMDir("/usr/share/enscript/"); > + PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/"); We just did an integration with WineHQ, and this code has started to grate on me (mostly because of the fact that the AFM parser spits out a bunch of error messages while trying to parse my AFM files. Rather than hardcoding the paths into the code, could we do this instead: while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value, sizeof(value))) PSDRV_ReadAFMDir(value); This has the added benefit of allowing the user to specify only those AFM directories that their rasterizer knows about too. With the above, I get a whole bunch of printer fonts listed as available in wine that I can't actually print if Ghostscript isn't configured to find the font files. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

[RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8
by Vedran Rodic March 4, 2001

March 4, 2001

On Sun, Mar 04, 2001 at 01:51:16PM +0100, Ove Kaaven wrote: > > > Since this is a 32-bit move (movl), you should use %%eax, not %%ax. The > assembler doesn't complain about this now, but technically it should, and > might someday. > > Since you're converting to 32bpp, not 16bpp, you should multiply "left" by > 4, not by 2, or strange things may happen in some apps. Thanks. Fixed patch attached. I did change left multiplicator from 2 to 4 in my earlier patches, but I forgot to include it in my final patch being 3 AM and so... I'll try to be more careful next time. Vedran

1 1

Re: for loop fixes
by Francois Gouget March 4, 2001

March 4, 2001

On Sat, 3 Mar 2001, Andreas Mohr wrote: [...] > - changed all terminating ";" of isolated for loops to " ;" to indicate the > loop's isolation. IMHO, for such loops the following would be much clearer: <init_expression>; while (<test_condition>) { <update_expression>; } (ok, you can also put '{' on the next line) > Please do the same for these for loops in the future. ??? > Somebody might want to write a Wine coding guidelines article... $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l 96 (wg is my recursive source grep script) Maybe we should ask people to put the for and the instruction it applies to on separate lines. Combined with the suggestion above this would make it easier to check for this kind of bug. > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > too ;-) Yep, I should have done that myself (if you find a generic bug, always check for other similar bugs). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

4 4

RFC: client side implementation of async I/O
by Michael McCormack March 4, 2001

March 4, 2001

Hi all, This patch moves responsibility for asynchronous I/O to the client process. i'm posting it to wine-devel because i want to know what other developers here think about the technique i've used to make this work... i've relaxed some of the assumptions wineserver makes about client processes. i think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. Mike -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

1 0

Re: Add explicit WM_CLOSE processing in the edit control
by Alexandre Julliard March 3, 2001

March 3, 2001

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Since handler of WM_CLOSE in DefWindowProc calls DestroyWindow, > which eventually sends WM_DESTROY, EDITSTATE gets destroyed before > call to EDIT_UnlockBuffer in the end of processing of WM_CLOSE, > therefore EDIT_UnlockBuffer gets confused. This is not specific to WM_CLOSE, it can happen with other messages too; any time we transfer control back to the application the window can be destroyed. I think it would be better to either unlock the buffer before calling DefWindowProc, or make EDIT_UnlockBuffer cope with a destroyed window. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: erase bkgnd on page scroller control
by Alexandre Julliard March 3, 2001

March 3, 2001

Susan Farley <susan(a)codeweavers.com> writes: > @@ -720,7 +721,8 @@ > PAGER_INFO *infoPtr; > DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); > > - dwStyle |= WS_CLIPCHILDREN; > + /* background color of the child should be the same as the pager */ > + dwStyle &= ~WS_CLIPCHILDREN; Shouldn't we simply leave WS_CLIPCHILDREN alone and use whatever the app specified when creating the window, instead of forcing it one way or another? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ListView fix
by François Gouget March 3, 2001

March 3, 2001

Ok, so now that I've got the patch out, there's a weird problem that I've been having with this piece of code. Apply the following on top of my previous patch and you'll get the weirdest traces: --- cut here --- Index: dlls/comctl32/listview.c =================================================================== RCS file: /home/cvs/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.99 diff -u -r1.99 listview.c --- dlls/comctl32/listview.c 2001/02/28 05:31:02 1.99 +++ dlls/comctl32/listview.c 2001/03/02 23:45:09 @@ -1542,10 +1545,22 @@ item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + TRACE("nSelectionMark=%d nItem=%d nFirst=%d nLast=%d\n",infoPtr->nSelectionMark,nItem,nFirst,nLast); +#if 0 + i = nFirst; + while (i <= nLast) + { + TRACE("i=%d\n",i); + LISTVIEW_SetItemState(hwnd,i,&item); + i++; + } +#else for (i = nFirst; i <= nLast; i++); { + TRACE("i=%d\n",i); LISTVIEW_SetItemState(hwnd,i,&item); } +#endif LISTVIEW_SetItemFocus(hwnd, nItem); infoPtr->nSelectionMark = nItem; --- cut here --- Now if I click on item 3 I get the following trace: ... trace:listview:LISTVIEW_AddGroupSelection nSelectionMark=-1 nItem=3 nFirst=3 nLast=3 trace:listview:LISTVIEW_AddGroupSelection i=4 trace:listview:LISTVIEW_WindowProc hwnd=1908 uMsg=1006 wParam=0 lParam=405b6c30 trace:listview:LISTVIEW_AddSelectionRange Add range 4 - 4 ... Now, last I checked (i.e. a few minutes a go), 'for (i=3;i<=3;i++) printf("%d\n",i);' prints 3 and certainly not 4. Also, if I'm not mistaken this code is strictly equivalent to the while loop in the '#if 0' branch. Yet the while loop works fine but not the for loop. In a word this looks like a gcc bug to me! $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) How do we normally deal with those? -- François Gouget fgouget(a)codeweavers.com

2 1

WinMM/MMSystem & registry
by Eric Pouech March 2, 2001

March 2, 2001

I'm currently investigating moving all multimedia setup into the registry as current WINMM/MMSYSTEM implementation is rather close to the WIN3.x/9x model, I started looking at their native implementation. The main goal is to use no longer the hard coded drivers name, but rather get them from the registry basically, it goes like this: /* * The Windows registry settings are as follows: * - the drivers are defined by sets, each set has an index * - the sets are loaded in the set index increasing order * - a set is divided by classes (wave, midi...), and several drivers can be * defined in each class * - the keys are spread into two locations: * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\MEDIA\%idx%\Drivers\%class%\%name% * where %idx% is the set index, * %class% is the class (midi, wave...) * %name% is the name of the device (which can be different from * the actual name of a the driver's filename (even if, * in lots of cases it's the same)) * these keys mainly describe what to load, and in which order * This key shall also contain some configuration options for the driver (if * needed...) * - each entry under the Services\Class has a corresponding entry in another part * of the registry * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\%class%\%namen%<%idx%> * Under this location is stored information regarding how to load the * driver (like if it's enabled, PnP information...) */ there are some other keys (like the PnP devices enumeration) which use the index to refer to the driver implementing this under Wine is not too difficult. The hairy part is the configuration (setting up the keys in the registry) since the first step of the configuration (for this scheme) is to get the first unused index, this can be a bit tricky (especially when a registry exists, and has been copied from a native one) the possible solutions are: A/ implement this mechanism and provide an ad hoc tool for this purpose. The hard part is, in some cases, that the data to add to the registry have to be determined at installation time: the number of DSP available for the wave output, or the list of MIDI playback devices (synthesizer, midi out...) - current WineOSS implementation gets its name from the kernel -. A1/ create a specific (winelib) tool to take care of it A2/ make use of Windows installation capabilities (setup API) and provide a .INF file for each. I'm not quite sure that's feasible with the semantics of the API (mainly for the naming issue described above) B/ do not implement this mechanism B1/ provide a Wine specific easy set of keys B2/ same as above, but upon startup, Wine (or winmm/mmsystem) partially recreates the native keys as needed I'd rather go the A1 or B1. As of today, the only drawback of B1 is that some native DLLs (multimedia control panel, the midi mapper) will not work. I haven't (yet) run against a program using this poorly undocumented set of features (which, of course, will not work on Win2k with WDM in place). any comment is welcome. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

file descriptor problems
by Rein Klazes March 2, 2001

March 2, 2001

Hi, With today's CVS I get problems with the Agent newsreader after 0.5 to 1 hour of use. Sometimes I get this: > wine client error:0x8063890: no fd received for handle 264 and the wine service tread has exited. In other cases the program shows a message box showing: cannor write <filename>. DOS error 4. and the program goes crazy. Dos error 4 means "too many files open", which seems related to the first message. Rein. -- Rein Klazes rklazes(a)casema.net

1 0

Protocol error
by Andreas Schultz March 1, 2001

March 1, 2001

Hi, I'm getting repeatable error's with the latest CVS version: Protocol error:0x8066ae0: read : Resource temporarily unavailable The application that is causing is the Gunman Chronicles Dedicated Server. I tried to find out what is going on, but couldn't find anything usefull. Has anybody ales seen a similar behavior? Andreas -- -------------------- professional INTERNET services -------------------- EastLink GmbH Niederlassung Magdeburg voice: +49-180-5432060 Lorenzweg 42 fax: +49-371-4320626 D-39110 Magdeburg http://www.eastlink.de

1 0