wine-devel

wine-devel@winehq.org

1 participants
84398 discussions

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

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