wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: glibc bug mmap/malloc
by Gerard Patel 19 Jul '01

19 Jul '01

At 10:15 PM 18/07/2001 +0200, you wrote: <snip about glibc> >> > This is a BUG. While this glibc question is slightly offtopic here, I think that maybe a few people on this list could be interested in glibc, since the subject comes back on a regular basis... the following web page : http://sources.redhat.com/glibc is definitely the place to go. I feel that maybe this information could help someone, since I have wasted more than one hour searching www.gnu.org for the glibc mailing list archive :-) Also http://www.suse.de/~aj/Projects.html#glibc where it's said that Andrea Jaeger is responsible for glibc bug reports. Reading the archive gives me the impression that the whole glibc is written by no more than half a dozen programmers, btw. What's more, I have also the impression that these few are not even contributing full time to glibc :-/ Gerard

1 0

Problem with 'GetPrivateProfileString'
by Lionel Ulmer 18 Jul '01

18 Jul '01

Hi all, I have an installer crashing in 'GetPrivateProfileString' because of an NULL section pointer : 3 0x40076161 (GetPrivateProfileStringA+0x31(section=0x0, entry=0x40391efc, def_val=0x4039a394, buffer=0x403b0410, len=0x3e7, filename=0x4039a4e8) [profile.c:1232] in libntdll.so) (ebp=40586748) When looking at the code, there is the following comment (and code) : /* * undoc_feature means: * return section names string list if both section and entry are NULL. */ (...) if ((undoc_feature) && (section == NULL) && (entry == NULL)) /* undocumented; both section and entry are NULL */ But if I look at the entry for 'GetPrivateProfileString' in the MSDN, I get this : pAppName [in] Pointer to a null-terminated string that specifies the name of the section containing the key name. If this parameter is NULL, the GetPrivateProfileString function copies all section names in the file to the supplied buffer. lpKeyName [in] Pointer to the null-terminated string specifying the name of the key whose associated string is to be retrieved. If this parameter is NULL, all key names in the section specified by the lpAppName parameter are copied to the buffer specified by the lpReturnedString parameter. This is not in sync. with what Wine does.... It seems that only pAppName needs to be NULL to return a section name list. And there is another behaviour not done by Wine yet : copy all the keys of a section to the output buffer. So who is the author of this 'undocumented' feature in the Wine code ? Do you all agree that I should code it according to the (now) documented feature ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Re: glibc bug mmap/malloc
by Alexandre Julliard 18 Jul '01

18 Jul '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > You can clearly see that malloc() is able to squeeze up to 10232 bytes > into the memory range just before the mmap()ed area, but when it gets > slightly larger, it is NOT capable of switching to an entirely different > memory area, throws its arms up in desperation and simply returns a shabby > NULL. > It only uses a new memory area in case the values get *much* larger, > i.e. at least 131060 bytes. > > This is a BUG. > (IMHO) > What else should it be ? This is more a limitation of the malloc implementation than an actual bug. malloc uses brk() to allocate memory, but brk() cannot grow past an mmapped area, so malloc fails. With a standard Linux app shared libraries are mapped high in memory (usually from 0x40000000) so the malloc limit is about 1Gb; but if stuff is mapped lower, malloc capacity is reduced. The reason it works for mallocs larger than 128Kb is that glibc uses anonymous mmaps to reserve space for these instead of brk(). All in all, it's probably one more good reason for avoiding malloc in Wine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Reaktivate
by Daniel Walker 18 Jul '01

18 Jul '01

Are the reaktivate patches going to be put in the CVS eventually? Daniel Walker

3 5

Re: use GetCommState16 to save state in OpenComm16
by lawson_whitney＠juno.com 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001, Mike McCormack wrote: > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure gcc -shared -Wl,-soname,libkernel32.so kernel32.spec.o comm.spec.o kernel.spec.o stress.spec.o system.spec.o toolhelp.spec.o windebug.spec.o win87em.spec.o wprocs.spec.o comm.o debugger.o format_msg.o kernel_main.o stress.o string.o sync.o thunk.o time.o toolhelp.o utthunk.o win87em.o windebug.o wowthunk.o utthunk.glue.o -o libkernel32.so -L../../dlls -lntdll -L../../library -lwine -lm -lutil -ldl /usr/i386-slackware-linux/bin/ld: warning: type and size of dynamic symbol `CALL32_Regs' are not defined make[2]: Leaving directory `/oof/Wine-20010629/dlls/kernel' Is this right, or are my binutils getting long in the tooth? Seems to work OK though. 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 1

Re: use GetCommState16 to save state in OpenComm16
by lawson_whitney＠juno.com 18 Jul '01

18 Jul '01

On Wed, 18 Jul 2001 12:08:51 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_33334807 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > with this patch, all use of unix fds has been eliminated from the > 16bit comm code. Next step is to remove use of the service thread... > > ChangeLog: > use GetCommState16 to save state in OpenComm16 > merge comm16 globals into one structure Okay, if you get this, it does no harm to my 16 bit comms app. Does throw a little ld warning though. Well, let's see. 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: How to unsubscribe
by Antonio Augusto Todo Bom Neto 18 Jul '01

18 Jul '01

Begin forwarded message: Date: Wed, 18 Jul 2001 08:31:30 -0300 From: Antonio Augusto Todo Bom Neto <antonio(a)xultz.wox.org> To: wine-devel(a)winehq.com Subject: Re: How to unsubscribe On Wed, 18 Jul 2001 07:48:03 -0300 (ADT) tlegge(a)fundy.net wrote: > Hi > > How do I unsubscribe from this list? > > Regards > > Tim > > try it: http://www.winehq.com/mailman/options/wine-devel/tlegge%40fundy.net ;)

1 0

How to unsubscribe
by tlegge＠fundy.net 18 Jul '01

18 Jul '01

Hi How do I unsubscribe from this list? Regards Tim

1 0

Announcement : SynCE project
by Ludovic LANGE 18 Jul '01

18 Jul '01

Hello, First of all sorry for the intrusion, but I think this may be of interest for some of you. SynCE project's ambitious goal is to provide a mean of synchronising handhelds devices with a (desktop) computer. By handheld, we mean any portable / embedded / PDA.... device, that needs to synchronize its data with a less mobile computer. (An exemple would be any PDA/PocketPC running Windows CE, or any PDA running Linux, etc...) The first step of this project is to provide a full (client & server) implementation of Microsoft's RAPI protocol, which is the low-level protocol used in ActiveSync synchronisation. This will allow, when completed : - a Windows CE device to communicate with any (non-Microsoft) computer, - A Linux device to communicate with a Microsoft computer and benefits from the existing tools, - etc, etc... The second step will be to provide a set of tools to synchronize data with 'standard' open or closed source application : Mozilla, KMail, etc.... Right now, the project is in its early, early stages ( we don't even have an alpha release ! ), but yet there are some bits that allow an implementation of the client part of the RAPI protocol, to query informations (registry, filesystem, databases,...) from a WindowsCE device. One tool (DBBackup) allows a full dump of the databases of the device. I won't interfere more with the list, and I invite all people interested to have a look on the project page ( http://www.sourceforge.net/projetcs/synce & http://synce.sourceforge.net ) and to subscribe to the mailing-list. We currently are looking for developper, and for testers having mobile devices still under Windows CE (PDA, PocketPC, etc...) and an unix-like desktop environment. Best regards, Ludovic LANGE

2 1

how to add a new language wine?
by jerry.zhang 18 Jul '01

18 Jul '01

hello,everyone: I want to add a new language to wine,but I found the document about this is out of date, so,I want to know how to add a new language to the latest version of wine. In additional,I want to know how to define the value of many parameters in the file "/dlls/kernel/nls/youlanguage.nls". Best regards Jerry Zhang Redflag Software Co. Ltd E-mail: wenlongzhang(a)redflag-linux.com

2 1

glibc bug mmap/malloc
by Andreas Mohr 17 Jul '01

17 Jul '01

[yeah, it's glibc bug time AGAIN] Hello all, I just wanted to let you all know that I found what I believe to be a glibc malloc bug. (yes, this happens even with 2.4.6 and latest Debian glibc 2.2.3-6). This is the only thing I did today, BTW. When Wine loads a very large (129 MB) exe file, it does an mmap() on it. After that it tries to do some malloc()s. That fails, which causes the entirely loading/execution of that file to abort. Thus I did malloc()/free() in a for loop after that 129 MB mmap() to test the problematic behaviour. Output: trace:module:map_image mapped PE file at 0x8051000-0xfc45000 err:virtual:VIRTUAL_CreateView now that the PE file has been mmap() /dev/zero:ed, we do some other malloc()s: malloc of 4 bytes: 0x804d878 malloc of 8 bytes: 0x804d878 malloc of 12 bytes: 0x804d878 malloc of 16 bytes: 0x804d878 malloc of 20 bytes: 0x804db20 <---- (chunk size optimization algorithm) malloc of 24 bytes: 0x804db20 <---- ("") malloc of 28 bytes: 0x804e7f8 <---- ("") malloc of 32 bytes: 0x804e7f8 malloc of 36 bytes: 0x804e7f8 . . . malloc of 10224 bytes: 0x804e7f8 malloc of 10228 bytes: 0x804e7f8 malloc of 10232 bytes: 0x804e7f8 up to 0x8050fef malloc of 10236 bytes: (nil) (0x8050ff3, which probably touches mmap() management headers) malloc of 10240 bytes: (nil) . . . malloc of 131052 bytes: (nil) malloc of 131056 (0x1fff0) bytes: (nil) ... malloc of 131060 bytes: 0x404c2008 malloc of 131064 bytes: 0x404c2008 . . . You can clearly see that malloc() is able to squeeze up to 10232 bytes into the memory range just before the mmap()ed area, but when it gets slightly larger, it is NOT capable of switching to an entirely different memory area, throws its arms up in desperation and simply returns a shabby NULL. It only uses a new memory area in case the values get *much* larger, i.e. at least 131060 bytes. This is a BUG. (IMHO) What else should it be ? I already contacted Ulrich Drepper about it, and I'll hopefully get a positive reply soon. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Microsoft Windows: Made for the Internet The Internet: Made for Unix

1 0

Re: Significant change to WINEPS - please test!
by Gerard Patel 17 Jul '01

17 Jul '01

At 07:29 PM 15/07/2001 -0500, you wrote: >So please give me your feedback. I particularly want to know if it >breaks anything before I submit it. Anything ? everything is a better word. I use a 'latin' language. No unicode for me. I test with the software I use to send this mail. There is a 'preview' feature and I can preview (and print) a mail. This is working fine with current Cvs. If I use your patch, most characters in the mail body, are overlayed, printed scattered in black heaps with small lines all around , strangely evoking some insects. Pretty funny :-) If my description is not clear, I can send you a screen capture. Strangely the page header and footer are still correct, though. Gerard

2 1

Re: Small OpenGL fix
by Alexandre Julliard 17 Jul '01

17 Jul '01

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > In the current code, there seems to be two different mechanisms for driver > calling : > > - one that is 'GDI' specific with the 'dc->funcs->pFUNC_NAME' sort of calls > > - the other for 'USER' with 'USER_Driver.pFUNC_NAME' > > So which one of the two methods should I use the 'WGL' that is neither in > GDI nor in USER ? You can't really use either. The GDI one requires calling DC_GetDCPtr which you cannot do from outside GDI, and the USER one requires a reference to a global variable that isn't visible outside USER. A possible way is to use the Escape function and add a few x11drv-specific escape codes. But first it would probably be a good thing to check how opengl32 is implemented under Windows; I have no idea how it works, but it probably needs some way to communicate with the graphics driver, and we could use the same mechanism. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Small OpenGL fix
by Alexandre Julliard 17 Jul '01

17 Jul '01

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > This is more a problem of inter-dependencies of X11DRV and USER32 (as the > former should NEVER be loaded before the latter)... But as I could not fix > this problem, I prefered going 'around' the problem :-) The dependencies between x11drv and user should certainly be fixed, but the real problem is that opengl32 and ddraw import x11drv at all. x11drv is an internal driver and should never be imported by any dll. Anybody feeling like fixing that? -- Alexandre Julliard julliard(a)winehq.com

2 1

using cvs diff
by Bill Medland 17 Jul '01

17 Jul '01

I can't see it in TFM I thought I was keeping an eye on what patches had actually been applied to the wine source (especially to see if mine had) by using "cvs diff wine". It seemed to be working but I now realise it wasn't. I guess it was diffing my local code against the corresponding revisions. How do I diff my current set of code against the current cvs? Bill

3 2

ChangeDisplaySettings
by Travis Michielsen 17 Jul '01

17 Jul '01

Hi, I was planning on implementing ChangeDisplaySettingsA soon but I'm not certain on how to do it. I have been browsing the source tree and was following the methods used by DirectDraw and was considering a similar approach. While I was browsing the source, I was eventually lead to dlls/x11drv/xvidmode.c which contains most of the functions that I will probably need. But I still have a few concerns: 1) Is the x11drv used for ddraw AND the gdi or just one? 2) what is the best way to query if the video exists? without knowing syncs? 3) and if i need to know syncs how do I find them? Another question I have is about pixel depth. From what I understand, it is imposible to change the pixel format of the screen while X is running. However, it is possible to start more than one X server with different configs (and depth) which we could use if we have to but probably not a good idea. Of course another posibility is to emulate the pixel depth, but that would probably cause performance problems, especially when used by games. Anyone have any suggestions or should we just leave changing depths as unimplemented? Thanks! - Travis Michielsen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

2 1

DrawText
by Travis Michielsen 17 Jul '01

17 Jul '01

Hi all, I have put together a quick patch that SHOULD fully implement the DrawText functions. However, I have not had time to thoroughly tested most of the logic so I thought I would post it here rather than sending it directly to the patches list. I welcome any/all comments/suggestions. - Travis Michielsen Index: wine/dlls/user/text.c =================================================================== RCS file: /home/wine/wine/dlls/user/text.c,v retrieving revision 1.12 diff -u -r1.12 text.c --- wine/dlls/user/text.c 2001/07/17 00:51:00 1.12 +++ wine/dlls/user/text.c 2001/07/17 13:55:22 @@ -235,6 +235,7 @@ int prefix_x = 0; int prefix_end = 0; TEXTMETRICW tm; + int lmargin = 0, rmargin = 0; int x = rect->left, y = rect->top; int width = rect->right - rect->left; int max_width = 0; @@ -242,10 +243,8 @@ TRACE("%s, %d , [(%d,%d),(%d,%d)]\n", debugstr_wn (str, count), count, rect->left, rect->top, rect->right, rect->bottom); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n", dtp->cbSize, - dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); - } + if (dtp) TRACE("Params: iTabLength=%d, iLeftMargin=%d, iRightMargin=%d\n", + dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); if (!str) return 0; if (count == -1) count = strlenW(str); @@ -258,8 +257,17 @@ else lh = tm.tmHeight; + if (dtp) + { + lmargin = dtp->iLeftMargin * tm.tmAveCharWidth; + rmargin = dtp->iRightMargin * tm.tmAveCharWidth; + if (!(flags & (DT_CENTER | DT_RIGHT))) + x += lmargin; + dtp->uiLengthDrawn = 0; //This param RECEIVES number of chars processed + } + if (flags & DT_TABSTOP) - tabstop = flags >> 8; + tabstop = dtp ? dtp->iTabLength : flags >> 8; if (flags & DT_EXPANDTABS) { @@ -292,7 +300,7 @@ if (flags & DT_SINGLELINE) { - if (flags & DT_VCENTER) y = rect->top + + if (flags & DT_VCENTER) y = rect->top + (rect->bottom - rect->top) / 2 - size.cy / 2; else if (flags & DT_BOTTOM) y = rect->bottom - size.cy; @@ -312,7 +320,7 @@ if (flags & DT_WORD_ELLIPSIS) flags |= DT_WORDBREAK; - if (flags & DT_PATH_ELLIPSIS) + if (flags & DT_PATH_ELLIPSIS) { WCHAR* lastBkSlash = NULL; WCHAR* lastFwdSlash = NULL; @@ -320,14 +328,11 @@ line[totalLen] = '\0'; lastBkSlash = strrchrW(line, BACK_SLASHW[0]); lastFwdSlash = strrchrW(line, FORWARD_SLASHW[0]); - fnameDelim = lastFwdSlash ? lastFwdSlash : lastBkSlash; - if (lastBkSlash && lastFwdSlash) /* which is last? */ - if (lastBkSlash > lastFwdSlash) - fnameDelim = lastBkSlash; + fnameDelim = lastBkSlash > lastFwdSlash ? lastBkSlash : lastFwdSlash; if (fnameDelim) fnameLen = &line[totalLen] - fnameDelim; - else + else fnameDelim = (WCHAR*)str; strcpyW(swapStr, ELLIPSISW); @@ -343,16 +348,16 @@ } len = MAX_STATIC_BUFFER; - TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); + TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); /* if only the ELLIPSIS will fit, just let it be clipped */ len = max(3, len); GetTextExtentPointW(hdc, line, len, &size); /* FIXME: - * NextLine uses GetTextExtentPoint for each character, + * NextLine uses GetTextExtentPoint for each character, * rather than GetCharABCWidth... So the whitespace between - * characters is ignored in the width measurement, and the + * characters is ignored in the width measurement, and the * reported len is too great. To compensate, we must get * the width of the entire line and adjust len accordingly. */ @@ -365,10 +370,10 @@ if (fnameLen < len-3) /* some of the path will fit */ { /* put the ELLIPSIS between the path and filename */ - strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); + strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); swapStr[len-3-fnameLen] = '\0'; - strcatW(swapStr, ELLIPSISW); - strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); + strcatW(swapStr, ELLIPSISW); + strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); } else { @@ -382,12 +387,15 @@ line[len] = '\0'; strPtr = NULL; } + if (flags & DT_MODIFYSTRING) + strcpyW(str, swapStr); } } if (!(flags & DT_CALCRECT)) { - if (!ExtTextOutW(hdc, x, y, (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED, - rect, line, len, NULL )) return 0; + if (!ExtTextOutW( hdc, x, y, + ( (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED ) | ( (flags & DT_RTLREADING) ? 0 : ETO_RTLREADING ), + rect, line, len, NULL )) return 0; if (prefix_offset != -1) { HPEN hpen = CreatePen( PS_SOLID, 1, GetTextColor(hdc) ); @@ -410,20 +418,35 @@ break; } } + if (dtp) + dtp->uiLengthDrawn += len; } while (strPtr); + if (flags & DT_CALCRECT) { rect->right = rect->left + max_width; rect->bottom = y; + if (dtp) + rect->right += lmargin + rmargin; } return y - rect->top; } /*********************************************************************** - * DrawTextA (USER32.@) + * DrawTextW (USER32.@) */ -INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) +INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, + LPRECT rect, UINT flags ) +{ + return DrawTextExW(hdc, str, count, rect, flags, NULL); +} + +/*********************************************************************** + * DrawTextExA (USER32.@) + */ +INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, + LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) { WCHAR *wstr; INT ret = 0; @@ -437,32 +460,19 @@ { MultiByteToWideChar( CP_ACP, 0, str, count, wstr, wcount ); ret = DrawTextExW( hdc, wstr, wcount, rect, flags, NULL ); + if (flags & DT_MODIFYSTRING) + WideCharToMultiByte( CP_ACP, 0, wstr, -1, str, count, NULL, NULL ); HeapFree(GetProcessHeap(), 0, wstr); } return ret; } /*********************************************************************** - * DrawTextW (USER32.@) - */ -INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, - LPRECT rect, UINT flags ) -{ - return DrawTextExW(hdc, str, count, rect, flags, NULL); -} - -/*********************************************************************** - * DrawTextExA (USER32.@) + * DrawTextA (USER32.@) */ -INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, - LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) +INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) { - TRACE("(%d,%s,%d,%p,0x%08x,%p)\n",hdc,debugstr_an(str,count),count,rect,flags,dtp); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n",dtp->cbSize, - dtp->iTabLength,dtp->iLeftMargin,dtp->iRightMargin); - } - return DrawTextA(hdc,str,count,rect,flags); + return DrawTextExA( hdc, str, count, rect, flags, NULL ); } /*********************************************************************** __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Re: another debugstr patch
by Alexandre Julliard 17 Jul '01

17 Jul '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > BTW, Alexandre, why didn't you apply my "debugstr patch" from Jun 04 ? It got lost somewhere; I've applied it now. BTW for everybody, when you submitted a patch and didn't see it applied and didn't hear anything about it, *please* resubmit or ask me what's going on. Patches can get dropped for multiple reasons, and it's your responsibility to follow what happens to your patch, until it is either applied or you know why it wasn't. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard 17 Jul '01

17 Jul '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I did consider that, but who's going to intercept and handle that message? > It's not an operation that is or should be known outside of the x11drv, so > sending the window a custom message will either conflict with some other > message, or get the message ignored (I doubt DefWindowProc passes custom > messages back to x11drv or anything). Or did you have any particular ideas > in this area? You can set a new window procedure to intercept the message, and pass all other messages straight through to the original window procedure. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard 17 Jul '01

17 Jul '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events > are lost. I'm working on it, but have not yet thought of a way to fix it; > I need to run a procedure (GrabPointer) in the context of the thread that > owns the window that gets the grab. My latest idea was to queue an APC to > the owner of the window, but QueueUserAPC requires a thread handle, while > GetWindowThreadProcessId only returns a thread ID. I'd strongly suggest using some kind of SendMessage instead of QueueUserAPC. -- Alexandre Julliard julliard(a)winehq.com

2 1

fnt2bdf.c and font names
by Bill Medland 16 Jul '01

16 Jul '01

I've just been playing with fonts (sserife and vgasys) to get things working. In the process I notice that fnt2bdf seems to do some strange stuff about choosing a font name, pixel size etc. I don't want to submit a patch that merely demonstrates my stupidity/lack of understanding but am willing to put in my suggested fix. This will result in for example the MS Sans Serif 8 pt font getting a name of -windows-MS Sans Serif-medium-r-normal-sans-13-80-96-96-p-50-microsoft-cp1252 SIZE 8 96 96 as opposed to the current -windows-MS Sans Serif-medium-r-normal-sans-13-130-72-72-p-50-microsoft-cp1252 SIZE 13 96 96 (I don't understand why the 72 dpi is hard-coded) Do I submit it or am I misunderstanding something Bill

1 0

Re: Added sanity check to WINPROC_CallWndProc
by Uwe Bonnes 16 Jul '01

16 Jul '01

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> DeusEx causes Wine to crash (segmentation fault) because it calls Jukka> CallWindowProc and passes null in HWND parameter. While I Jukka> suspect that this is because some Wine function that should Jukka> return a valid HWND is returning a null pointer, the crashing can Jukka> be fixed simply by adding a sanity check to WINPROC_CallWndProc. How does Windows behave on those invalid arguments? Jukka> After this patch, both DeusEx installer and DeusEx dialog for Jukka> choosing rendering engine work. However, DeusEx still crashes Jukka> later because DeusEx for some reason generates a division by zero Jukka> FP exception. DeusEx handler for this exception calls Jukka> __CxxFrameHandler which is not implemented by Wine and thus Jukka> exception handling ends into infinite recursion. Luckily stack Jukka> overflow makes Wine to crash :) Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs exception facilities too. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Mouse trouble
by Daniel Bingham 16 Jul '01

16 Jul '01

Hi, I just got the latest CVS and when I tried to run starcraft my mouse won't move. I have dxgrab turned on so as not to have my mouse going off the screen when I try to move. I am not very knowledgeable about wine or programming, so I thought I'd tell someone who was. If I have something set up wrong I can't find it and don't find any documentation to address it either. Any help would be much appreciated. Please email me directly because I get the digest and tend to ignore it. Thanks. Daniel Bingham db78(a)att.net

3 2

Re: Added sanity check to WINPROC_CallWndProc
by Jon Griffiths 16 Jul '01

16 Jul '01

Hi, >Native msvcrt has __CxxFrameHandler, but I aggree that wine-msvcrt needs >exception facilities too. While I'm still on holiday, i just bought a laptop to do some wine coding on. I had improved the exception handling in builtin msvcrt but my last run of patches to it werent accepted due to using asm instead of register funcs. Once I get my old sources mailed to me I will begin hacking on it again. I'm interested in getting the konqueror/ActiveX stuff working with builtin msvcrt, since the dot.kde.org press release singled it out as non-functional (much to my shame <g>). Meanwhile I'm strolling through shlwapi and should have some patches for that soon. Its great to see the progress made since february though, very impressive. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Significant change to WINEPS - please test!
by Ian Pilcher 16 Jul '01

16 Jul '01

The attached patch makes a fundamental change to the way the PostScript driver deals with character encodings -- it ignores them. Instead, the driver now operates directly on 16-bit Unicode characters. This should be a more robust strategy for handling non-Latin, and especially multi-byte, character sets. I really have no idea, however, how the rest of Wine handles non-Latin characters. As an English speaker, I'm not well equipped to test it. So please give me your feedback. I particularly want to know if it breaks anything before I submit it. Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ======================================================================== diff -urN ../wine-20010714cvs/dlls/wineps/font.c ./dlls/wineps/font.c --- ../wine-20010714cvs/dlls/wineps/font.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/font.c Sun Jul 15 16:27:27 2001 @@ -5,6 +5,7 @@ * */ #include <string.h> +#include <stdlib.h> /* for bsearch() */ #include "winspool.h" #include "psdrv.h" #include "debugtools.h" @@ -294,6 +295,7 @@ return TRUE; } +#if 0 /*********************************************************************** * PSDRV_UnicodeToANSI */ @@ -321,9 +323,52 @@ return 0xff; } } +#endif + +/****************************************************************************** + * PSDRV_UVMetrics + * + * Find the AFMMETRICS for a given UV. Returns first glyph in the font + * (space?) if the font does not have a glyph for the given UV. + */ +static int MetricsByUV(const void *a, const void *b) +{ + return (int)(((const AFMMETRICS *)a)->UV - ((const AFMMETRICS *)b)->UV); +} + +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev) +{ + AFMMETRICS key; + const AFMMETRICS *needle; + + /* + * Ugly work-around for symbol fonts. Wine is sending characters which + * belong in the Unicode private use range (U+F020 - U+F0FF) as ASCII + * characters (U+0020 - U+00FF). + */ + + if ((physDev->font.afm->Metrics->UV & 0xff00) == 0xf000 && UV < 0x100) + UV |= 0xf000; + + key.UV = UV; + + needle = bsearch(&key, physDev->font.afm->Metrics, + physDev->font.afm->NumofMetrics, sizeof(AFMMETRICS), + MetricsByUV); + + if (needle == NULL) + { + WARN("No glyph for U+%.4lX in %s\n", UV, physDev->font.afm->FontName); + needle = physDev->font.afm->Metrics; + } + + return needle; +} + /*********************************************************************** * PSDRV_GetTextExtentPoint */ +#if 0 BOOL PSDRV_GetTextExtentPoint( DC *dc, LPCWSTR str, INT count, LPSIZE size ) { @@ -346,11 +391,30 @@ return TRUE; } +#endif +BOOL PSDRV_GetTextExtentPoint(DC *dc, LPCWSTR str, INT count, LPSIZE size) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + int i; + float width = 0.0; + + for (i = 0; i < count && str[i] != '\0'; ++i) + width += PSDRV_UVMetrics(str[i], physDev)->WX; + + width *= physDev->font.scale; + + size->cx = GDI_ROUND((FLOAT)width * dc->xformVport2World.eM11); + size->cy = GDI_ROUND((FLOAT)physDev->font.tm.tmHeight * + dc->xformVport2World.eM22); + + return TRUE; +} /*********************************************************************** * PSDRV_GetCharWidth */ +#if 0 BOOL PSDRV_GetCharWidth( DC *dc, UINT firstChar, UINT lastChar, LPINT buffer ) { @@ -365,7 +429,24 @@ return TRUE; } +#endif +BOOL PSDRV_GetCharWidth(DC *dc, UINT firstChar, UINT lastChar, LPINT buffer) +{ + PSDRV_PDEVICE *physDev = (PSDRV_PDEVICE *)dc->physDev; + UINT i; + + if (lastChar > 0xffff || firstChar > lastChar) + { + SetLastError(ERROR_INVALID_PARAMETER); + return FALSE; + } + + for (i = firstChar; i < lastChar; ++i) + *buffer++ = PSDRV_UVMetrics(i, physDev)->WX * physDev->font.scale; + + return TRUE; +} /*********************************************************************** * PSDRV_SetFont diff -urN ../wine-20010714cvs/dlls/wineps/ps.c ./dlls/wineps/ps.c --- ../wine-20010714cvs/dlls/wineps/ps.c Sun Jul 15 16:07:36 2001 +++ ./dlls/wineps/ps.c Sun Jul 15 16:25:12 2001 @@ -115,6 +115,9 @@ static char psshow[] = /* string */ "(%s) show\n"; +static const char psglyphshow[] = /* glyph name */ +"/%s glyphshow\n"; + static char pssetfont[] = /* fontname, xscale, yscale, ascent, escapement */ "/%s findfont\n" "[%d 0 0 %d 0 0]\n" @@ -634,6 +637,7 @@ return TRUE; } +#if 0 BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) { char *buf, *buf1; @@ -671,6 +675,32 @@ return TRUE; } +#endif + +BOOL PSDRV_WriteShow(DC *dc, LPCWSTR str, INT count) +{ + char buf[128]; + int i; + + for (i = 0; i < count; ++i) + { + LPCSTR name; + int l; + + name = PSDRV_UVMetrics(str[i], (PSDRV_PDEVICE *)dc->physDev)->N->sz; + l = snprintf(buf, sizeof(buf), psglyphshow, name); + + if (l < sizeof(psglyphshow) - 2 || l > sizeof(buf) - 1) + { + WARN("Unusable glyph name '%s' - ignoring\n", name); + continue; + } + + PSDRV_WriteSpool(dc, buf, l); + } + + return TRUE; +} BOOL PSDRV_WriteFill(DC *dc) { diff -urN ../wine-20010714cvs/dlls/wineps/psdrv.h ./dlls/wineps/psdrv.h --- ../wine-20010714cvs/dlls/wineps/psdrv.h Tue May 29 17:06:11 2001 +++ ./dlls/wineps/psdrv.h Sun Jul 15 16:11:36 2001 @@ -421,6 +421,7 @@ GLYPHNAME *PSDRV_GlyphName(LPCSTR szName); VOID PSDRV_IndexGlyphList(); BOOL PSDRV_GetTrueTypeMetrics(); +const AFMMETRICS *PSDRV_UVMetrics(LONG UV, const PSDRV_PDEVICE *physDev); #endif

1 0

Jump to page:

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