wine-devel

wine-devel@winehq.org

84463 discussions

Re: more misc fixes
by Alexandre Julliard 19 Jul '01

19 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Index: wine/include/wine/obj_base.h > =================================================================== > RCS file: /home/wine/wine/include/wine/obj_base.h,v > retrieving revision 1.40 > diff -u -u -r1.40 obj_base.h > --- wine/include/wine/obj_base.h 2001/05/07 18:15:40 1.40 > +++ wine/include/wine/obj_base.h 2001/07/19 14:50:28 > @@ -34,6 +34,8 @@ > #include "wtypes.h" > #include "guiddef.h" > > +#include "wine/windef16.h" This is wrong; Win32 header files must not include 16-bit ones. Also please avoid adding more 16-bit headers in include/wine, there are already too many of them. These headers (when they are really necessary) belong in their respective dll directory. And BTW your new lzexpand16.h is an example of a header file that is *not* necessary. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Lots of #defines OK?
by Patrik Stridvall 19 Jul '01

19 Jul '01

> I would like to get rid of the "hardcoded" offset into the glyph name > array and replace it with a macro ('GN_exclam', for example). > Each font > data file could then simply include a header that gets > regenerated when- > ever the glyphlist is changed -- eliminating the current > requirement to > regenerate all the font data. > > Anyone see any problems with this? (There are currently 1258 built-in > glyph names.) Not really, but as an alternative solution you could has a structure instead of an array like: typedef struct { GLYPHNAME A; GLYPHNAME AE; GLYPHNAME AEacute; GLYPHNAME AEsmall; /* ... */ } GLYPHNAMES; Perhaps this is better since it doesn't use the preprocessor. However I'm not sure if all C compilers supports 1258 structure members. Another possible problem is alignment on some platforms if you must be able for iterate over it and use it as and array. Of course you can simply have a seperate array of pointers like: GLYPHNAMES glyphnames = { /* ... */ }; GLYPHNAME *pGlyphnames[] = { &glyphnames.A; &glyphnames.AE; &glyphnames.AEacute; &glyphnames.AEsmall; /* ... */ };

2 1

Lots of #defines OK?
by Ian Pilcher 19 Jul '01

19 Jul '01

I'm giving some thought to cleaning up the data structures used by the PostScript driver. Any significant change here will require that the glyph list and font data be regenerated. This is not particularly difficult, but it would be easier if I could remove the dependency of the font data on the glyph name array. Each glyph's metrics include a pointer to its name, and all of the built-in glyph names are in a single array named PSDRV_AGLGlyphNames (in dlls/wineps/data/agl.c). So the metrics for a glyph look like this: { 33, 0x0021, 600, PSDRV_AGLGlyphNames + 907, { 236, -15, 364, 572 }, NULL /* exclam */ } I would like to get rid of the "hardcoded" offset into the glyph name array and replace it with a macro ('GN_exclam', for example). Each font data file could then simply include a header that gets regenerated when- ever the glyphlist is changed -- eliminating the current requirement to regenerate all the font data. Anyone see any problems with this? (There are currently 1258 built-in glyph names.) Thanks! -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

attempting to load mIRC32 5.91 using latest wine cvs
by mdew 19 Jul '01

19 Jul '01

mdew@storm:~$ /usr/local/bin/wine fake_windows/mIRC/mirc32.exe FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found fixme:console:SetConsoleCtrlHandler (0x546e60,1) - no error checking or testing yet FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/lib/libwine_tsx11.so: undefined symbol: XF86DGAGetViewPortSize Could not load graphics driver 'x11drv' err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still not found err:heap:HEAP_GetPtr Invalid heap 00000000! err:heap:HEAP_GetPtr Invalid heap 00000000! spews this message out many times (then quits)..., using the same wine config ..as always.. Using Debian Sid x86 (gcc-2.95.4-XFree86-4.0.3)

2 1

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

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