- wine-devel - winehq.org

Re: Make PostScript driver less loquacious
by Dmitry Timoshkov 04 Apr '01

04 Apr '01

"Ian Pilcher" <ian.pilcher(a)home.com> wrote: > dlls/wineps/init.c, ppd.c > > Change some PS driver FIXMEs/MESSAGEs to WARNs I think it's not the time to do it. Those messages/fixme's help a lot to add missing page and bin type into psdrv: they are not complete now. And without message about missing fonts in ppd/afm it would be nightmare to track down problems with ps fonts at least for me.

3 8

Newbie question...
by Elan Feingold 04 Apr '01

04 Apr '01

Hi, I have a 3rd party x86 DLL file, that I would like to use under Linux. I have read the documentation on the specmaker tool, which would seem to provide some help. The thing that makes my case a bit different is that I would like to use the DLL within a Linux native program, not a WineLib program (its just a command line application and I need it to be very lightweight). Im pretty sure the Wine code can help me out, but Im not sure what the easiest way to proceed is, and what parts I need to use. Thanks in advance, -elan

2 1

T@x2001: Linuxport via Wine
by Joerg Mayer 04 Apr '01

04 Apr '01

Just found the following at the SuSE portal pages (German only): http://portal.suse.de/de/content/reports/tax2001.html Rough translation on the introductory paragraph: The program t@x by Buhl Data has been around for the Windows platform for some years. This year, the current version T@x2001 has been made available for the Linux OS for a first time. In order to do this the Windows emulator Wine was used. Wine allows using Windows applications running Linux. This emulator has been modified to work with t@x2001. The summary as far as Wine is concerned: The program should be more stable and faster. Does anyone know which modifications were made to wine? Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

1 0

Re: Interesting Magic # exception understood by the MS debugger...
by Alexandre Julliard 03 Apr '01

03 Apr '01

"James Hatheway" <james(a)macadamian.com> writes: > OK, I don't know too much about the internals of the WINE debugger, so > here goes. Is there a field for this already, or should I make a new > field in DBG_THREAD structure? (I think that seems like the right place > for it) Yep, you can add a field there. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Interesting Magic # exception understood by the MS debugger...
by Alexandre Julliard 03 Apr '01

03 Apr '01

"James Hatheway" <james(a)macadamian.com> writes: > For now, I put the little hack I attached to this mail in my tree to > save my sanity. My question to the list is, (A) is there a way to name > threads in Linux/Unix (I don't think so, but of course I could be wrong) No, and we don't need that. > and (B) should we support MS's hack somehow in the official tree? Yes, in the Wine debugger, which should store the name and simply continue execution, just like the MSVC debugger does. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells 03 Apr '01

03 Apr '01

Okay, I've thought about how to make the wine kernel module easier to use for Wine, and I've started adding another API to it - one that interprets Wine server messages. When I designed the module initially, I decided to make it possible to add as many API's as I liked, so in theory it's not too difficult. I'm currently performing a major rearrangement of the files that comprise the module: * Splitting the current win32 API bits out of the same files that contain the actual object class implementations. * Putting the core and the API's in separate subdirectories. * Abstracting name support, so that the internal API takes an "object name" which the user API is responsible for extracting from userspace and converting from WCS/MBS as necessary. * Fixing introduced bugs. This does not mean that I'm getting rid of the Win32 API I've already got! It will just be optional. Calling the new API will be by means of either: union generic_request msg; syscall(__NR_win32,WINESERVER_WINE_SERVER_MESSAGE,&msg); Or: union generic_request msg; int fd = open("/proc/wineserver"); struct WineserverIoctl wioc = { WINESERVER_WINE_SERVER_MESSAGE, &msg }; ioctl(fd,WINESERVER_IOCTL,&wioc); David

1 0

Interesting Magic # exception understood by the MS debugger...
by James Hatheway 02 Apr '01

02 Apr '01

Hi guys, I encountered something interesting while debugging a newer build of my application. I noticed that all of a sudden I was receiving approximately 10 new exceptions in the debugger on startup that I wasn't receiving before. After digging a little, I found out that the app coders were making use of a 'hidden' feature of MS VC that allowed you to name your threads (thus allowing for easier debugging). To do this, you call RaiseException with the code of 0x406D1388. (Search on deja.com or google.com for "0x406D1388" for details.) The windows debugger seems to be on the lookout for this code. Of course, what it does in wine is just breaking into the debugger many times and getting on my nerves. :-) For now, I put the little hack I attached to this mail in my tree to save my sanity. My question to the list is, (A) is there a way to name threads in Linux/Unix (I don't think so, but of course I could be wrong) and (B) should we support MS's hack somehow in the official tree? -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"

1 0

Re: RegSetValueEx problem?
by davep 02 Apr '01

02 Apr '01

On Sun, 01 Apr 2001, you wrote: > At 01:59 PM 31/03/2001 +0100, you wrote: > > <snip> > >Compiling and running Winemine under Windows 95 this problem doesn't occur. > >Win95 truncates the value at the first null. > > Under NT4 SP6, if I write (for example) '47' + 0 + 13 bytes of garbage, I get > exactly that when querying with the same buffer length (16). > If I use a longer buffer, one binary 0 is appended. > If I use a shorter buffer, nothing is copied and the function does not succeed > (ERROR_MORE_DATA). > > Of course under Regedit the garbage is not displayed; regedit displays only '47' > in this case. Ah, I didn't know Regedit was not giving the true value. That complicates matters even more. It seems I'll have to do some experiments. -- Dave Pickles

1 0

Re: event flags using pipes
by Alexandre Julliard 01 Apr '01

01 Apr '01

Mike McCormack <mike_mccormack(a)looksmart.com.au> writes: > Why? By changing the client side implementation of SetEvent and > ResetEvent the use file descriptors and implementing a client side > unix fd/handle cache, it should be possible to eliminate server calls > for these operations and improve the performance of wineserver. I don't see how you can get the right semantics this way, but maybe I missed something. How will you be able to wake a single thread for auto-reset events, but all of them for manual events? How are you going to implement PulseEvent? How can you do WaitForMultipleObjects for an auto-reset event without a race? -- Alexandre Julliard julliard(a)winehq.com

1 0

event flags using pipes
by Mike McCormack 01 Apr '01

01 Apr '01

Hi, i've written an implementation of windows event flags using pipes. (The modifications are confined to server/event.c for the moment.) Why? By changing the client side implementation of SetEvent and ResetEvent the use file descriptors and implementing a client side unix fd/handle cache, it should be possible to eliminate server calls for these operations and improve the performance of wineserver. Anyway, any comments are welcome. Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

RegSetValueEx problem?
by davep 31 Mar '01

31 Mar '01

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 31 Mar '01

31 Mar '01

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 30 Mar '01

30 Mar '01

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 30 Mar '01

30 Mar '01

>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 30 Mar '01

30 Mar '01

>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 29 Mar '01

29 Mar '01

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 29 Mar '01

29 Mar '01

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 27 Mar '01

27 Mar '01

... 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 27 Mar '01

27 Mar '01

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 26 Mar '01

26 Mar '01

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@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 26 Mar '01

26 Mar '01

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 26 Mar '01

26 Mar '01

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 26 Mar '01

26 Mar '01

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 26 Mar '01

26 Mar '01

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 25 Mar '01

25 Mar '01

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 25 Mar '01

25 Mar '01

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 25 Mar '01

25 Mar '01

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 24 Mar '01

24 Mar '01

-----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 24 Mar '01

24 Mar '01

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 24 Mar '01

24 Mar '01

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 24 Mar '01

24 Mar '01

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 24 Mar '01

24 Mar '01

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@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 23 Mar '01

23 Mar '01

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 22 Mar '01

22 Mar '01

"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 22 Mar '01

22 Mar '01

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 22 Mar '01

22 Mar '01

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 22 Mar '01

22 Mar '01

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 21 Mar '01

21 Mar '01

> 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 21 Mar '01

21 Mar '01

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 21 Mar '01

21 Mar '01

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 21 Mar '01

21 Mar '01

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 21 Mar '01

21 Mar '01

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 20 Mar '01

20 Mar '01

"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 20 Mar '01

20 Mar '01

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 20 Mar '01

20 Mar '01

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 20 Mar '01

20 Mar '01

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 20 Mar '01

20 Mar '01

"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 20 Mar '01

20 Mar '01

"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 19 Mar '01

19 Mar '01

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 19 Mar '01

19 Mar '01

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@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel