wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: Wine Start menu
by Ivan Leo Murray-Smith 16 Oct '03

16 Oct '03

>I dont know if the "Desktop" >option still exists in WINE but it would be nice to have ros-explorer >when running WINE in desktop mode under Linux. The I could just run all >of my Win32 apps from one place. Yes, this is possible, just set explorer.exe to desktop mode in your config file and run the ros explorer like any wine app.

1 0

System tree view
by BiGgUn 16 Oct '03

16 Oct '03

Hi Where is Windows explorer SysTreeView implemented in Wine ? TIA, Stephan

1 0

openssl-based win32 programs
by Geoff Thorpe 16 Oct '03

16 Oct '03

Hi all, I have just sent a post to the openssl list trying to solicit any developers of openssl-based win32 programs to try their programs under Wine. Eric Pouech helped me recently by fixing the one or two glitches in Wine that the openssl libs and utilities were stumbling on, and so openssl seems now to pose no problems for Wine. Anyhow, I just thought I'd post a link to this 'openssl-users' thread in case there's anyone else interested in this (in particular, if you think I've misrepresented anything about Wine or the process of testing win32 applications under it, feedback would be welcome); http://marc.theaimsgroup.com/?l=openssl-users&m=106626702426381&w=2 Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

1 0

Re: libs/unicode string folding
by Alexandre Julliard 15 Oct '03

15 Oct '03

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > +include/wine/unicode.h libs/unicode/fold.c > libs/unicode/Makefile.in libs/unicode/wine_unicode.def > Add A/W string folding functions I put the Unicode version in, but the Ascii one is wrong, you cannot hardcode Latin-1 codepage this way. FoldStringA should be implemented by converting to Unicode and calling FoldStringW. -- Alexandre Julliard julliard(a)winehq.com

1 0

Wine Start menu
by Robert van Herk 15 Oct '03

15 Oct '03

Hi all, As some of you might know I am working on a Wine Start menu, for Linux. I have heard different things on this list about the way Windows treats the start menu. Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory. From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory. So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu? Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here? Grtz, Robert

4 4

Re: "No docbook" changes
by Alexandre Julliard 15 Oct '03

15 Oct '03

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This caused rpm generation to fail because false returns 1. > > Changelog: > Change the command to true rather than false if docbook is not > installed. If docbook is not installed then generating the doc should definitely yield an error. You are free to ignore the error in the rpm generation, but the makefile should still report it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Todays CVS compile broken?
by Gerhard W. Gruber 15 Oct '03

15 Oct '03

I downloaded a fresh CVS version from WineHQ and when I tried to compile it I got the following errors: freetype.c: In function `WineEngCreateFontInstance': freetype.c:1254: `FT_ENCODING_MS_SYMBOL' undeclared (first use in this function) freetype.c:1254: (Each undeclared identifier is reported only once freetype.c:1254: for each function it appears in.) freetype.c:1257: `FT_ENCODING_UNICODE' undeclared (first use in this function) freetype.c:1261: `FT_ENCODING_APPLE_ROMAN' undeclared (first use in this function) make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/home/user/src/wine.2003-10-15/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/user/src/wine.2003-10-15/dlls' make: *** [dlls] Error 2 -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

3 3

Re: Wine Start menu
by Ivan Leo Murray-Smith 15 Oct '03

15 Oct '03

There already is an app that can do the menus, the ros explorer. If it was compiled as a winelib app, it would solve the menu problem, at least for who likes desktop mode (And the ros explorer makes wine look like a "real" emulator)

3 2

Re: Abort glyph rendering if everything is clipped
by Warren_Baird＠cimmetry.com 15 Oct '03

15 Oct '03

> That looks better yes; it's still a bit complex IMO, but I'm not sure > it's possible to do much better with that glyph index thing. Still I'm > wondering if you shouldn't do the IsRectEmpty check after the LPtoDP > and coordinates swap. It looks to me like LPtoDP is just doing a linear transform, so the area should be preserved - the rectangle should be empty after the transform if and only if it is empty before the transform. Or am I missing something? Is there another reason to move the IsRectEmpty check after the transform? Warren

2 1

Snoop Include/Excludwe
by Rein Klazes 15 Oct '03

15 Oct '03

Hi, The wine.conf man page says that in Snoop Include/Exclude specifiying <dllname>.* includes the whole dll. This does not work: you have to specify <dllname> without the ".*", at least that is the code. What should be corrected code or documentation? My guess it is the doc, here is the coorection. Changelog: In wine.conf man page correctly specify how to include/exclude the whole dll. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

configuring wine
by Alex Pasadyn 15 Oct '03

15 Oct '03

After taking a look at winesetuptk, I have some questions: I've been watching the IRC channel and I've seen a lot of people who install wine first (either from a binary package or from "make install") and then ask how to configure it. They want a single command they can run to simply get things to a reasonable state. While tools/wineinstall generally does this it's not quite what they are looking for. I think there are two separate problems that are being addressed, and it makes sense to have and document two stages of configuration. Step one doesn't ask too many questions (really just whether you want to use an existing "C" drive or not) and results in a "working" Wine (with all DLLs set to "builtin"). Step two would then use Wine itself to allow the user to customize things graphically. It seems worth it to me to split tools/wineinstall into two parts so that the configuration part can be easily run as a separate step (possibly with a Tk dialog later on?). This initial configuration _must_not_ depend on a working Wine. Further, a user might want to run it again later if their partitions change, etc. Does anyone object to this change? (The existing wineinstall could just call the next script after compiling and installing Wine.) Perhaps once winecfg is finished, it could be automatically launched after the initial configuration. As an alternative to this, we could have "make install" and the binary packages always create a system-wide fake C drive and install the default system-wide config file. Even though these are read-only, it's enough to run winecfg and notepad, and then the real C drive detection, etc could be moved into winecfg. This might be better as the user only has one program to run, and they can see that wine "works" right out of the box. It also has the benefit that every user would start from the same place at least once. One of the hardest things about helping people troubleshoot now is figuring out how they got to where they are. Finally, I thought at least one aspect of the interface for winesetuptk was more intuitive than winecfg. The winecfg has one tab where you specify whether you are changing global or application-specific settings, but winesetuptk repeats that concisely at the top of every page using a drop-down list and add/copy/rename/remove buttons. The way winesetuptk does it seems less likely to result in mistakes by users. Also, winesetuptk includes pictures of the different WineLook and windowing mode options, which is a nice touch. Basically, it'll take a fair amount of work to get winecfg up to the "niceness" level that winesetuptk currently has (not to mention actually saving the changes). Can we all send patches against the winecfg in CVS or does someone have a more up-to-date version? Alex

3 2

Re: rediff: wave device name patch
by Alexandre Julliard 15 Oct '03

15 Oct '03

Robert Reif <reif(a)earthlink.net> writes: > Adds support for wave driver name query to alsa and oss and wave tests. > Adds SetVolume implementation to alsa. You should use the standard Unicode functions like MultiByteToWideChar (probably with CP_UNIXCP) to convert the device names. -- Alexandre Julliard julliard(a)winehq.com

1 0

Mailslot test
by Mike McCormack 14 Oct '03

14 Oct '03

Hi, Just incase anybody is interested, here is a regression test for mailslots. There's not much point to include it into Wine until we support mailslots properly (which I'm working on). Mike /* * Mailslot regression test * * Copyright 2003 Mike McCormack */ #include <windows.h> #include <stdio.h> #define ok(cond,str) do{ if(!(cond)) printf("line %d: %s\n",__LINE__,str); }while (0) const char szmspath[] = "\\\\.\\mailslot\\wine_mailslot_test"; int main(int argc, char **argv) { HANDLE hSlot, hSlot2, hWriter, hWriter2; unsigned char buffer[16]; DWORD count, dwMax, dwNext, dwMsgCount, dwTimeout; // sanity check on GetMailslotInfo dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( !GetMailslotInfo( INVALID_HANDLE_VALUE, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo succeeded"); // open a mailslot that doesn't exist hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter == INVALID_HANDLE_VALUE, "non-existing mailslot"); // open a mailslot without the right name hSlot = CreateMailslot( "blah", 0, 0, NULL ); ok( hSlot == INVALID_HANDLE_VALUE , "Created mailslot with invalid name"); ok( GetLastError() == ERROR_INVALID_NAME, "error should be ERROR_INVALID_NAME"); // open a mailslot with a null name hSlot = CreateMailslot( NULL, 0, 0, NULL ); ok( hSlot == INVALID_HANDLE_VALUE , "Created mailslot with invalid name"); ok( GetLastError() == ERROR_PATH_NOT_FOUND, "error should be ERROR_PATH_NOT_FOUND"); // valid open, but with wacky parameters ... then check them hSlot = CreateMailslot( szmspath, -1, -1, NULL ); ok( hSlot != INVALID_HANDLE_VALUE , "mailslot with valid name failed"); dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( GetMailslotInfo( hSlot, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo failed"); ok( dwMax == -1, "dwMax incorrect"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); ok( dwTimeout == -1, "dwTimeout incorrect"); ok( GetMailslotInfo( hSlot, NULL, NULL, NULL, NULL ), "getmailslotinfo failed"); ok( CloseHandle(hSlot), "failed to close mailslot"); // now open it for real hSlot = CreateMailslot( szmspath, 0, 0, NULL ); ok( hSlot != INVALID_HANDLE_VALUE , "valid mailslot failed"); // try and read/write to it count = 0; memset(buffer, 0, sizeof buffer); ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); ok( !WriteFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot write"); // now try and openthe client, but with the wrong sharing mode hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter == INVALID_HANDLE_VALUE, "bad sharing mode"); ok( GetLastError() == ERROR_SHARING_VIOLATION, "error should be ERROR_SHARING_VIOLATION"); // now open the client with the correct sharing mode hWriter = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter != INVALID_HANDLE_VALUE, "existing mailslot"); // opening a client should make no difference to whether we can read or write the mailslot ok( !ReadFile( hSlot, buffer, sizeof buffer/2, &count, NULL), "slot read"); ok( !WriteFile( hSlot, buffer, sizeof buffer/2, &count, NULL), "slot write"); // we can't read from this client, but we should be able to write to it ok( !ReadFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can read client"); ok( WriteFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can't write client"); ok( !ReadFile( hWriter, buffer, sizeof buffer/2, &count, NULL), "can read client"); // seeing as there's something in the slot, we should be able to read it once ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); ok( count == (sizeof buffer/2), "short read" ); // but not again ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); // now try open another writer... should fail hWriter2 = CreateFile(szmspath, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "two writers"); // now try open another as a reader ... also fails hWriter2 = CreateFile(szmspath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "writer + reader"); // now try open another as a writer ... still fails hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "writer"); // now open another one hSlot2 = CreateMailslot( szmspath, 0, 0, NULL ); ok( hSlot2 == INVALID_HANDLE_VALUE , "opened two mailslots"); // close the client again ok( CloseHandle( hWriter ), "closing the client"); // now try reopen it with slightly different permissions ... shared writing hWriter = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter != INVALID_HANDLE_VALUE, "sharing writer"); // now try open another as a writer ... but don't share with the first ... fail hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 == INVALID_HANDLE_VALUE, "greedy writer succeeded"); // now try open another as a writer ... and share with the first hWriter2 = CreateFile(szmspath, GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL); ok( hWriter2 != INVALID_HANDLE_VALUE, "2nd sharing writer"); // check the mailslot info dwMax = dwNext = dwMsgCount = dwTimeout = 0; ok( GetMailslotInfo( hSlot, &dwMax, &dwNext, &dwMsgCount, &dwTimeout ), "getmailslotinfo failed"); ok( dwMax == 0, "dwMax incorrect"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); ok( dwTimeout == 0, "dwTimeout incorrect"); // check there's still no data ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "slot read"); // write two messages buffer[0] = 'a'; ok( WriteFile( hWriter, buffer, 1, &count, NULL), "1st write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 1, "dwMsgCount incorrect"); buffer[0] = 'b'; buffer[1] = 'c'; ok( WriteFile( hWriter2, buffer, 2, &count, NULL), "2nd write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 2, "dwMsgCount incorrect"); // write a 3rd message with zero size ok( WriteFile( hWriter2, buffer, 0, &count, NULL), "3rd write failed"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 1, "dwNext incorrect"); ok( dwMsgCount == 3, "dwMsgCount incorrect"); // then check that they come out with the correct order and size, then the slot is empty ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "1st slot read failed"); ok( count == 1, "failed to get 1st message"); ok( buffer[0] == 'a', "1st message wrong"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 2, "dwNext incorrect"); ok( dwMsgCount == 2, "dwMsgCount incorrect"); // read the second message ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "2nd slot read failed"); ok( count == 2, "failed to get 2nd message"); ok( ( buffer[0] == 'b' ) && ( buffer[1] == 'c' ), "2nd message wrong"); // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == 0, "dwNext incorrect"); ok( dwMsgCount == 1, "dwMsgCount incorrect"); // read the 3rd (zero length) message ok( ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "3rd slot read failed"); ok( count == 0, "failed to get 3rd message"); // now there should be no more messages // check the mailslot info dwNext = dwMsgCount = 0; ok( GetMailslotInfo( hSlot, NULL, &dwNext, &dwMsgCount, NULL ), "getmailslotinfo failed"); ok( dwNext == MAILSLOT_NO_MESSAGE, "dwNext incorrect"); ok( dwMsgCount == 0, "dwMsgCount incorrect"); // check that reads fail ok( !ReadFile( hSlot, buffer, sizeof buffer, &count, NULL), "3rd slot read succeeded"); // finally close the mailslot and its client ok( CloseHandle( hWriter2 ), "closing 2nd client"); ok( CloseHandle( hWriter ), "closing the client"); ok( CloseHandle( hSlot ), "closing the mailslot"); return 0; }

4 4

.def files in Debian packages
by Martin Troester 14 Oct '03

14 Oct '03

Hi, is there a reason that the for the Wine .dll.so libraries are not contained in the Wine Debian packages, especially libwine-dev? I mean, if I develop Winelib applications, I am going to need them anyway... Thanks for your help. Regards, Martin

2 1

attaching or inlining? what to do when you're stuck with a stupid mail client???
by Dave_Belanger＠cimmetry.com 14 Oct '03

14 Oct '03

Hi Dimi, I'm deeply sorry about that and I understand your frustrations for I have frustrations of my own using my mail client. The problem is that I have no other choice but to use Notes as a mail client for external emails at my company and Notes really screws up attachments and there's no way to configure it. Also, it wraps line longer than 70 characters, so inlining some of my patches will result in bogus patches. Then again, there's no way to configure it to disable line wrapping. And trust me, I've tried.... So what I'm gonna do in the future is inline patches that won't get line wrapped and attach the others the way I use too. Hopefully, most of them will be inlined. I apologize for the inconveniences. Dave "Dimitrie O. Paun" <dimi(a)intelliware.ca> on 10/08/2003 03:49:03 PM To: wine-devel(a)winehq.org cc: Dave Belanger/CSI@CSIDomain Subject: Re: patch for implementation of EMF driver SetPixel metarecord. On Wed, 8 Oct 2003 Dave_Belanger(a)cimmetry.com wrote: This patches are so hard to review. Not only are they not inlined, but they are attached as Application/OCTET-STREAM. This means I have to type about 8 keystrokes to open them in pine. Please, pretty please, try to inline them. If this doesn't wokr (have you tried?), at least attach them as text/plain. Thanks. -- Dimi. P.S. Inlining them is _far_ supperior to attachment. First, we can review them without any additional action. Second, we can simply press "Reply" and quote the code we want to comment on. This is very important.

7 16

HeapReAlloc status (take 3.B)
by Dimitrie O. Paun 14 Oct '03

14 Oct '03

We still have 72 HeapReAlloc() entries to validate: ./dlls/kernel/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./dlls/kernel/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./dlls/kernel/local16.c: ptr = HeapReAlloc( header->heap, ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, mem, size); ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), 0, ptr, size); ./dlls/netapi32/apibuf.c: *NewBuffer = HeapReAlloc(GetProcessHeap(), 0, OldBuffer, NewByteCount); ./dlls/ole32/ifs.c: pNewMemory = HeapReAlloc(GetProcessHeap(),0,pv,cb); ./dlls/ole32/ole16.c: ret = MapLS( HeapReAlloc( GetProcessHeap(), 0, MapSL(pv), cb ) ); ./dlls/rpcrt4/rpc_binding.c: LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(CHAR)); ./dlls/rpcrt4/rpc_binding.c: LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(WCHAR)); ./dlls/setupapi/virtcopy.c: vhstrlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, vhstrlist, ./dlls/setupapi/virtcopy.c: pvnlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, pvnlist, ./dlls/setupapi/parser.c: if ((new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, array, new_count * elem ))) ./dlls/setupapi/parser.c: if (!(section = HeapReAlloc( GetProcessHeap(), 0, section, size ))) return NULL; ./dlls/setupapi/parser.c: file->sections = HeapReAlloc( GetProcessHeap(), 0, file->sections, ./dlls/setupapi/parser.c: file->fields = HeapReAlloc( GetProcessHeap(), 0, file->fields, ./dlls/setupapi/parser.c: file->strings = HeapReAlloc( GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, file->strings, ./dlls/wineps/glyphlist.c: newGlyphList = (GLYPHNAME **) HeapReAlloc(PSDRV_Heap, 0, glyphList, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, len + sl + 1 ); ./dlls/wineps/type1.c: str->str = HeapReAlloc(GetProcessHeap(), 0, str->str, str->max_len); ./dlls/wineps/type1.c: t1->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyf_blocks = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/lolvldrv.c: HeapReAlloc(GetProcessHeap(), 0, (llTypes[type].lpMlds) ? llTypes[type].lpMlds - 1 : NULL, ./dlls/winmm/time.c: HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/mciavi/mmoutput.c: wma->lpAudioIndex = HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/wineoss/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(OSS_MSG)); ./dlls/winmm/wineoss/audio.c: This->notifies = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/winearts/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winealsa/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(ALSA_MSG)); ./dlls/winmm/winenas/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winejack/audio.c: wwo->sound_buffer = HeapReAlloc(GetProcessHeap(), 0, wwo->sound_buffer, wwo->buffer_size); ./dlls/winsock/async.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winspool/info.c: pent=HeapReAlloc(GetProcessHeap(),0,pent,strlen(pent)+strlen(buf)+2); ./dlls/winspool/info.c: LPWSTR *new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, printer_array, ./dlls/x11drv/xrender.c: glyphsetCache = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/x11drv/xrender.c: entry->realized = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->bitmaps = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->gis = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/clipboard.c: HeapReAlloc(GetProcessHeap(),0,val, total); ./graphics/painting.c: *PtsOut = HeapReAlloc( GetProcessHeap(), 0, *PtsOut, ./graphics/x11drv/xfont.c: !(buffer = HeapReAlloc( GetProcessHeap(), 0, buffer, *buf_size = len ))) ./graphics/x11drv/xfont.c: if( (newCache = (fontObject*)HeapReAlloc(GetProcessHeap(), 0, ./graphics/x11drv/palette.c: mapping = HeapReAlloc( GetProcessHeap(), 0, palPtr->mapping, ./objects/gdiobj.c: void *new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, ./objects/palette.c: int *newMap = (int*) HeapReAlloc(GetProcessHeap(), 0, ./objects/region.c: *firstrect = HeapReAlloc( GetProcessHeap(), 0, *firstrect, (2 * (sizeof(RECT)) * (reg->size))); ./objects/region.c: if (! (dst->rects = HeapReAlloc( GetProcessHeap(), 0, dst->rects, ./objects/region.c: newReg->rects = HeapReAlloc( GetProcessHeap(), 0, newReg->rects, ./objects/region.c: if (!(reg->rects = HeapReAlloc( GetProcessHeap(), 0, reg->rects, ./programs/regapi/regapi.c: lpsCurrentValue=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsCurrentValue,dwSize); ./programs/regapi/regapi.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regapi/regapi.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(), 0,stdInput,curSize+=STDIN_MAX_LEN); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(),0,stdInput,strlen(stdInput)+STDIN_MAX_LEN); ./programs/wineconsole/dialog.c: di->font = HeapReAlloc(GetProcessHeap(), 0, di->font, sizeof(*di->font) * (di->nFont + 1)); ./programs/wineconsole/wineconsole.c: data->cells = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, data->cells, ./programs/wineconsole/curses.c: PRIVATE(data)->line = HeapReAlloc(GetProcessHeap(), 0, PRIVATE(data)->line, ./programs/winhelp/hlp2sgml.c:void* WINAPI HeapReAlloc( HANDLE heap, DWORD flags, void* ptr, DWORD size) ./programs/winhelp/hlpfile.c: bi = HeapReAlloc(GetProcessHeap(), 0, bi, sizeof(*bi) + nc * sizeof(RGBQUAD)); ./programs/winhelp/hlpfile.c: hlpfile->bmps = HeapReAlloc(GetProcessHeap(), 0, hlpfile->bmps, ./programs/winhelp/hlpfile.c: hlpfile->windows = HeapReAlloc(GetProcessHeap(), 0, hlpfile->windows, ./programs/regedit/regproc.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regedit/regproc.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regedit/regproc.c: new_buffer = HeapReAlloc (GetProcessHeap(), 0, line, new_size); ./programs/regedit/regproc.c: *buffer = HeapReAlloc(GetProcessHeap(), 0, *buffer, ./programs/regedit/regproc.c: *val_buf = HeapReAlloc(GetProcessHeap(), 0, *val_buf, *val_size); -- Dimi.

1 0

non-HeapReAlloc() status (take 3.A)
by Dimitrie O. Paun 14 Oct '03

14 Oct '03

Only 33 non HeapReAlloc entries remain: ./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT))) { ./controls/edit.c: hloc32A_new = LocalReAlloc(es->hloc32A, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: hloc16_new = LOCAL_ReAlloc(hInstance, es->hloc16, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg16.c: *hmem = GlobalReAlloc16(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg16.c: lppd->hDevMode = GlobalReAlloc16(lppd->hDevMode, ./dlls/kernel/local16.c: hseg = GlobalReAlloc16( hseg, 0x10000, GMEM_FIXED ); ./dlls/kernel/local16.c:HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, WORD flags ) ./dlls/kernel/local16.c:HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) ./dlls/kernel/local16.c: return LOCAL_ReAlloc( CURRENT_DS, handle, size, flags ); ./dlls/kernel/local16.c:DWORD WINAPI Local32ReAlloc16( HANDLE heap, DWORD addr, INT16 type, ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/ntdll/heap.c:PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags, PVOID ptr, ULONG size ) ./dlls/ntdll/loadorder.c: env_list.order = RtlReAllocateHeap(GetProcessHeap(), 0, env_list.order, ./dlls/ntdll/relay.c: *dll = RtlReAllocateHeap(ntdll_get_process_heap(), ./dlls/ntdll/path.c: name = (WCHAR*)RtlReAllocateHeap(ntdll_get_process_heap(), 0, ./dlls/ole32/hglobalstream.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ifs.c: Malloc32.SpyedBlocks = (LPVOID*)LocalReAlloc((HLOCAL)Malloc32.SpyedBlocks, NewLength, GMEM_ZEROINIT); ./dlls/ole32/memlockbytes.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/memlockbytes16.c: This->supportHandle = GlobalReAlloc16(This->supportHandle, ./dlls/shell32/shell32_main.c: hargv=GlobalReAlloc(hargv, size, 0); ./dlls/shell32/shellole.c: addr = (LPVOID) LocalReAlloc((HANDLE) pv, cb, GMEM_ZEROINIT | GMEM_MOVEABLE); ./dlls/shlwapi/clist.c: lpTemp = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)pItem, ulSize, ./dlls/shlwapi/clist.c: lpIter = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ./dlls/shlwapi/clist.c: lpList = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ulNewSize, ./dlls/user/dde/misc.c: hData = GlobalReAlloc((HGLOBAL)hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD), ./objects/gdiobj.c: if ((new_handle = (HGDIOBJ)(ULONG_PTR)LOCAL_ReAlloc( GDI_HeapSel, h, size, LMEM_MOVEABLE ))) ./objects/metafile.c: return (HMETAFILE16)GlobalReAlloc16( hMeta, 0, -- Dimi.

1 0

{Heap,Global,Local,}ReAlloc status (take 2)
by Dimitrie O. Paun 14 Oct '03

14 Oct '03

Hi folks, Oleg has been doing a lot of good work, and we are now down to 73 HeapReAlloc and 73 non-HeapReAlloc entries to review. I'm still not sure how the comctl32.ReAlloc() should behave, any help in getting that resolved would be highly appreciated. Here is the update list: ./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT))) { ./controls/edit.c: hloc32A_new = LocalReAlloc(es->hloc32A, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: hloc16_new = LOCAL_ReAlloc(hInstance, es->hloc16, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./dlls/avifil32/avifile.c: This->idxFmtChanges = GlobalReAllocPtr(This->idxFmtChanges, This->nIdxFmtChanges * sizeof(AVIINDEXENTRY), GHND); ./dlls/avifil32/avifile.c: This->idxFrames = GlobalReAllocPtr(This->idxFrames, This->nIdxFrames * sizeof(AVIINDEXENTRY), GHND); ./dlls/avifil32/avifile.c: (LPDWORD)GlobalReAllocPtr(This->lpBuffer, max(size, This->sInfo.dwSuggestedBufferSize), GMEM_MOVEABLE); ./dlls/avifil32/api.c: pOptions->lpFormat = GlobalReAllocPtr(pOptions->lpFormat, size, GMEM_MOVEABLE); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/api.c: (lpBuffer = GlobalReAllocPtr(lpBuffer, cbBuffer *= 2, GPTR)) != NULL); ./dlls/avifil32/extrachunk.c: lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb + size + 2 * sizeof(DWORD), GHND); ./dlls/avifil32/extrachunk.c: lp = (LPDWORD)GlobalReAllocPtr(extra->lp, extra->cb + cb, GHND); ./dlls/avifil32/getframe.c: This->lpInFormat = GlobalReAllocPtr(This->lpInFormat, This->cbInBuffer, 0); ./dlls/avifil32/getframe.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpOutFormat, size, GMEM_MOVEABLE); ./dlls/avifil32/acmstream.c: This->acmStreamHdr.pbSrc = GlobalReAllocPtr(This->acmStreamHdr.pbSrc, ./dlls/avifil32/acmstream.c: This->acmStreamHdr.pbDst = GlobalReAllocPtr(This->acmStreamHdr.pbDst, ./dlls/avifil32/icmstream.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); ./dlls/avifil32/icmstream.c: (LPBITMAPINFOHEADER)GlobalReAllocPtr(This->lpbiPrev,size,GMEM_MOVEABLE); ./dlls/avifil32/editstream.c: GlobalReAllocPtr(This->pStreams, (This->nTableSize + 32) * sizeof(EditStreamTable), GMEM_SHARE|GHND); ./dlls/avifil32/editstream.c: pEdit->pStreams = GlobalReAllocPtr(pEdit->pStreams, This->nStreams * sizeof(EditStreamTable),GMEM_SHARE|GHND); ./dlls/comctl32/comctl32undoc.c:LPVOID WINAPI ReAlloc (LPVOID lpSrc, DWORD dwSize) ./dlls/comctl32/comctl32undoc.c: LPSTR ptr = ReAlloc (*lppDest, strlen (lpSrc) + 1); ./dlls/comctl32/comctl32undoc.c: LPWSTR ptr = ReAlloc (*lppDest, len * sizeof(WCHAR)); ./dlls/comctl32/comctl32undoc.c: LPWSTR ptr = ReAlloc (*lppDest, len*sizeof(WCHAR)); ./dlls/comctl32/comctl32undoc.c: lpTemp = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/comctl32undoc.c: lpTemp = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/comctl32undoc.c: lpDest = ReAlloc (hdsa->pData, nSize); ./dlls/comctl32/monthcal.c: infoPtr->monthdayState = ReAlloc(infoPtr->monthdayState, ./dlls/comctl32/propsheet.c: psInfo->proppage = (PropPageInfo*) ReAlloc(psInfo->proppage, ./dlls/comctl32/trackbar.c: infoPtr->tics=ReAlloc (infoPtr->tics, ./dlls/comctl32/trackbar.c: infoPtr->tics=ReAlloc( infoPtr->tics, ./dlls/comctl32/treeview.c: newText = (LPWSTR)ReAlloc(wineItem->pszText, buflen); ./dlls/comctl32/treeview.c: LPSTR newText = ReAlloc(wineItem->pszText, len); ./dlls/comctl32/treeview.c: LPSTR newText = ReAlloc(wineItem->pszText, len); ./dlls/comctl32/treeview.c: wineItem->pszText = ReAlloc(wineItem->pszText, ./dlls/comctl32/treeview.c: if (NULL == ReAlloc(editedItem->pszText, iLength + 1)) ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg16.c: *hmem = GlobalReAlloc16(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg16.c: lppd->hDevMode = GlobalReAlloc16(lppd->hDevMode, ./dlls/kernel/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./dlls/kernel/toolhelp.c: notifys=(struct notify*)HeapReAlloc( GetProcessHeap(), 0, notifys, ./dlls/kernel/local16.c: hseg = GlobalReAlloc16( hseg, 0x10000, GMEM_FIXED ); ./dlls/kernel/local16.c:HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, WORD flags ) ./dlls/kernel/local16.c:HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) ./dlls/kernel/local16.c: return LOCAL_ReAlloc( CURRENT_DS, handle, size, flags ); ./dlls/kernel/local16.c:DWORD WINAPI Local32ReAlloc16( HANDLE heap, DWORD addr, INT16 type, ./dlls/kernel/local16.c: ptr = HeapReAlloc( header->heap, ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/mpr/mpr_main.c:LPVOID WINAPI MPR_ReAlloc( LPVOID lpSrc, DWORD dwSize ) ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, mem, size); ./dlls/msvcrt/heap.c: return HeapReAlloc(GetProcessHeap(), 0, ptr, size); ./dlls/netapi32/apibuf.c: *NewBuffer = HeapReAlloc(GetProcessHeap(), 0, OldBuffer, NewByteCount); ./dlls/ntdll/heap.c: * RtlReAllocateHeap (NTDLL.@) ./dlls/ntdll/heap.c:PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags, PVOID ptr, ULONG size ) ./dlls/ntdll/loadorder.c: env_list.order = RtlReAllocateHeap(GetProcessHeap(), 0, env_list.order, ./dlls/ntdll/relay.c: *dll = RtlReAllocateHeap(ntdll_get_process_heap(), ./dlls/ntdll/path.c: name = (WCHAR*)RtlReAllocateHeap(ntdll_get_process_heap(), 0, ./dlls/ole32/hglobalstream.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ifs.c: Malloc32.SpyedBlocks = (LPVOID*)LocalReAlloc((HLOCAL)Malloc32.SpyedBlocks, NewLength, GMEM_ZEROINIT); ./dlls/ole32/ifs.c: pNewMemory = HeapReAlloc(GetProcessHeap(),0,pv,cb); ./dlls/ole32/memlockbytes.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ole16.c: ret = MapLS( HeapReAlloc( GetProcessHeap(), 0, MapSL(pv), cb ) ); ./dlls/ole32/memlockbytes16.c: This->supportHandle = GlobalReAlloc16(This->supportHandle, ./dlls/oleaut32/ole2disp.c:INT16 WINAPI SysReAllocString16(LPBSTR16 pbstr,LPCOLESTR16 oleStr) ./dlls/oleaut32/ole2disp.c:int WINAPI SysReAllocStringLen16(BSTR16 *old,const char *in,int len) ./dlls/oleaut32/oleaut.c:int WINAPI SysReAllocStringLen(BSTR* old, const OLECHAR* str, unsigned int len) ./dlls/oleaut32/oleaut.c: DWORD *ptr = HeapReAlloc(GetProcessHeap(),0,((DWORD*)*old)-1,newbytelen+sizeof(WCHAR)+sizeof(DWORD)); ./dlls/oleaut32/oleaut.c:INT WINAPI SysReAllocString(LPBSTR old,LPCOLESTR str) ./dlls/oleaut32/usrmarshal.c: SysReAllocStringLen(pstr, (OLECHAR*)&str->asData, str->clSize); ./dlls/rpcrt4/rpc_binding.c: LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(CHAR)); ./dlls/rpcrt4/rpc_binding.c: LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, (len+slen+2)*sizeof(WCHAR)); ./dlls/setupapi/virtcopy.c: vhstrlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, vhstrlist, ./dlls/setupapi/virtcopy.c: pvnlist = HeapReAlloc(heap, HEAP_ZERO_MEMORY, pvnlist, ./dlls/setupapi/parser.c: if ((new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, array, new_count * elem ))) ./dlls/setupapi/parser.c: if (!(section = HeapReAlloc( GetProcessHeap(), 0, section, size ))) return NULL; ./dlls/setupapi/parser.c: file->sections = HeapReAlloc( GetProcessHeap(), 0, file->sections, ./dlls/setupapi/parser.c: file->fields = HeapReAlloc( GetProcessHeap(), 0, file->fields, ./dlls/setupapi/parser.c: file->strings = HeapReAlloc( GetProcessHeap(), HEAP_REALLOC_IN_PLACE_ONLY, file->strings, ./dlls/shell32/shell32_main.c: hargv=GlobalReAlloc(hargv, size, 0); ./dlls/shell32/shellole.c: addr = (LPVOID) LocalReAlloc((HANDLE) pv, cb, GMEM_ZEROINIT | GMEM_MOVEABLE); ./dlls/shlwapi/clist.c: lpTemp = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)pItem, ulSize, ./dlls/shlwapi/clist.c: lpIter = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ./dlls/shlwapi/clist.c: lpList = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ulNewSize, ./dlls/user/dde/misc.c: hData = GlobalReAlloc((HGLOBAL)hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD), ./dlls/wineps/glyphlist.c: newGlyphList = (GLYPHNAME **) HeapReAlloc(PSDRV_Heap, 0, glyphList, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, ./dlls/wineps/ppd.c: buf = HeapReAlloc( PSDRV_Heap, 0, buf, len + sl + 1 ); ./dlls/wineps/type1.c: str->str = HeapReAlloc(GetProcessHeap(), 0, str->str, str->max_len); ./dlls/wineps/type1.c: t1->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyf_blocks = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/wineps/type42.c: t42->glyph_sent = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/lolvldrv.c: HeapReAlloc(GetProcessHeap(), 0, (llTypes[type].lpMlds) ? llTypes[type].lpMlds - 1 : NULL, ./dlls/winmm/time.c: HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/mciavi/mmoutput.c: wma->lpAudioIndex = HeapReAlloc(GetProcessHeap(), 0, ./dlls/winmm/wineoss/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(OSS_MSG)); ./dlls/winmm/wineoss/audio.c: This->notifies = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/winmm/winearts/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winealsa/audio.c: omr->messages = HeapReAlloc(GetProcessHeap(),0,omr->messages, omr->ring_buffer_size * sizeof(ALSA_MSG)); ./dlls/winmm/winenas/audio.c: mr->messages = HeapReAlloc(GetProcessHeap(),0,mr->messages, mr->ring_buffer_size * sizeof(RING_MSG)); ./dlls/winmm/winejack/audio.c: wwo->sound_buffer = HeapReAlloc(GetProcessHeap(), 0, wwo->sound_buffer, wwo->buffer_size); ./dlls/winsock/async.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winsock/socket.c: extrabuf=HeapReAlloc(GetProcessHeap(),0,extrabuf,ebufsize) ; ./dlls/winspool/info.c: pent=HeapReAlloc(GetProcessHeap(),0,pent,strlen(pent)+strlen(buf)+2); ./dlls/winspool/info.c: LPWSTR *new_array = HeapReAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, printer_array, ./dlls/x11drv/xrender.c: glyphsetCache = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ./dlls/x11drv/xrender.c: entry->realized = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->bitmaps = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/xrender.c: entry->gis = HeapReAlloc(GetProcessHeap(), ./dlls/x11drv/clipboard.c: HeapReAlloc(GetProcessHeap(),0,val, total); ./graphics/painting.c: *PtsOut = HeapReAlloc( GetProcessHeap(), 0, *PtsOut, ./graphics/x11drv/xfont.c: !(buffer = HeapReAlloc( GetProcessHeap(), 0, buffer, *buf_size = len ))) ./graphics/x11drv/xfont.c: if( (newCache = (fontObject*)HeapReAlloc(GetProcessHeap(), 0, ./graphics/x11drv/palette.c: mapping = HeapReAlloc( GetProcessHeap(), 0, palPtr->mapping, ./objects/gdiobj.c: if ((new_handle = (HGDIOBJ)(ULONG_PTR)LOCAL_ReAlloc( GDI_HeapSel, h, size, LMEM_MOVEABLE ))) ./objects/gdiobj.c: void *new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, size ); ./objects/metafile.c: mh = HeapReAlloc( GetProcessHeap(), 0, mh, ./objects/metafile.c: return (HMETAFILE16)GlobalReAlloc16( hMeta, 0, ./objects/palette.c: int *newMap = (int*) HeapReAlloc(GetProcessHeap(), 0, ./objects/region.c: *firstrect = HeapReAlloc( GetProcessHeap(), 0, *firstrect, (2 * (sizeof(RECT)) * (reg->size))); ./objects/region.c: if (! (dst->rects = HeapReAlloc( GetProcessHeap(), 0, dst->rects, ./objects/region.c: newReg->rects = HeapReAlloc( GetProcessHeap(), 0, newReg->rects, ./objects/region.c: if (!(reg->rects = HeapReAlloc( GetProcessHeap(), 0, reg->rects, ./programs/regapi/regapi.c: lpsCurrentValue=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsCurrentValue,dwSize); ./programs/regapi/regapi.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regapi/regapi.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(), 0,stdInput,curSize+=STDIN_MAX_LEN); ./programs/regapi/regapi.c: stdInput=HeapReAlloc(GetProcessHeap(),0,stdInput,strlen(stdInput)+STDIN_MAX_LEN); ./programs/wineconsole/dialog.c: di->font = HeapReAlloc(GetProcessHeap(), 0, di->font, sizeof(*di->font) * (di->nFont + 1)); ./programs/wineconsole/wineconsole.c: data->cells = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, data->cells, ./programs/wineconsole/curses.c: PRIVATE(data)->line = HeapReAlloc(GetProcessHeap(), 0, PRIVATE(data)->line, ./programs/winhelp/hlp2sgml.c:void* WINAPI HeapReAlloc( HANDLE heap, DWORD flags, void* ptr, DWORD size) ./programs/winhelp/hlpfile.c: bi = HeapReAlloc(GetProcessHeap(), 0, bi, sizeof(*bi) + nc * sizeof(RGBQUAD)); ./programs/winhelp/hlpfile.c: hlpfile->bmps = HeapReAlloc(GetProcessHeap(), 0, hlpfile->bmps, ./programs/winhelp/hlpfile.c: hlpfile->windows = HeapReAlloc(GetProcessHeap(), 0, hlpfile->windows, ./programs/regedit/regproc.c: lpsData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpsData,lLen); ./programs/regedit/regproc.c: lpbData=HeapReAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,lpbData,dwLen); ./programs/regedit/regproc.c: new_buffer = HeapReAlloc (GetProcessHeap(), 0, line, new_size); ./programs/regedit/regproc.c: *buffer = HeapReAlloc(GetProcessHeap(), 0, *buffer, ./programs/regedit/regproc.c: *val_buf = HeapReAlloc(GetProcessHeap(), 0, *val_buf, *val_size); -- Dimi.

3 2

Re: Fix some problems found while compiling and linking Wine under Cygwin
by Alexandre Julliard 14 Oct '03

14 Oct '03

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +++ wine/configure.ac Sun Oct 12 10:54:02 2003 > @@ -969,6 +969,7 @@ AC_CHECK_FUNCS(\ > popen \ > pread \ > pwrite \ > + res_init \ > rfork \ > select \ > sendmsg \ > @@ -1148,7 +1150,7 @@ dnl **** Check for types **** > > AC_C_CONST > AC_C_INLINE > -AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t]) > +AC_CHECK_TYPES([mode_t, off_t, pid_t, size_t, ssize_t, struct __res_state]) These checks won't work without including the proper headers first. > +++ wine/dlls/iphlpapi/ipstats.c Sun Oct 12 10:10:28 2003 > @@ -53,37 +53,37 @@ > #include "ifenum.h" > #include "ipstats.h" > > -#ifndef TCPS_ESTABLISHED > +#if !defined TCPS_ESTABLISHED && defined TCP_ESTABLISHED TCP_ESTABLISHED etc. values are an enum under Linux, you can't test them this way. -- Alexandre Julliard julliard(a)winehq.com

1 0

winehq download page
by Ivan Leo Murray-Smith 14 Oct '03

14 Oct '03

I sent this patch http://www.winehq.org/hypermail/wine-patches/2003/10/0064.html and can't think a reason in the world for it not to be applied, have I done something wrong or what?

4 3

Re: Wine Start menu
by Rolf Kalbermatter 13 Oct '03

13 Oct '03

Robert van Herk <robert(a)robertvanherk.nl> wrote: >As some of you might know I am working on a Wine Start menu, for Linux. > >I have heard different things on this list about the way Windows treats >the start menu. > >Some told me that it would be better to make a Windows (wine) client >that reads the actual start menu by querying a Wine dll, while others >told me that this is not neccesairy as all the links are contained in >the Start Menu directory. > > From looking at my Windows installation, I must agree that it seems >that all items in Programs are indeed in the Start Menu directory. Don't forget that the Start menu is a combination of the Start Menu of the "Current User" and the "All Users" (common) tree. SHGetFolderPath can give you the according pidls to those directories. Unfortunately shell32 does not export any functionality to enumerate those directories directly but the FileMenu_.... functions in shell32 take care about building that menu. One way might be to let those functions build the start menu and then enumerate that menu into an external format. >So, my question is: would it be enough to create just a Linux program >that synchronizes with this directory? Can anyone give me an example of >a lnk file that IS actually missing in a Start Menu directory, but is >there in his Program folder in the Windows start menu? > >Does anyone know how far people came at parsing the lnk files for Linux? >I read something about the .lnk format, but I don't really feel like >writing my own link file parser ;-). Does anybody know of parts of other >software that could be recycled here? You shouldn't need to. IShellLink should be all you need for retrieving information from a .lnk file although it seems currently broken somehow, according to some report a few days ago on wine-devel. But if you could reenumerate the Start Menu created by the shell32 FileMenu_ functions you might not really have to bother to much with this either. Rolf Kalbermatter

1 0

Re: configuring wine
by Ivan Leo Murray-Smith 13 Oct '03

13 Oct '03

It's true, winesetuptk is very usable (It's a wizard), and winecfg look more complicated than anything in windows. I did read that some very simple programs could run without a windows like filesystem. As winecfg is a winelib app, I suppose it may be possible to run it without a windows like filesystem, so wine could look for a registry (Winecfg works with a registry, not a config file), if it doesn't find it, it starts a wizard-like version of winecfg that allowsthe users to get wine ready to run, like winesetuptk does. > The way winesetuptk does it seems less likely to result in mistakes by users. That's very important for usability and it's why the first time one runs wine he should get a configuration wizard. The "Power user" winecfg (What is currently in the CVS) could be in the wine menu with the wine programs (How this menu is generated, with ros explorer or a specific linux/winelib app isn't really important) with the configuration wizard. This way, users just wanting to change the configuration can start the wizard again, and anybody wanting to tweak the configuration can use the "power user" version http://www.hostedscripts.com/scripts/antispam.html

1 0

Re: winesetuptk
by Ivan Leo Murray-Smith 13 Oct '03

13 Oct '03

> If an app installs msvcrt, use it before Wine's builtin one? That could theoreticly create legal problems, but it's OK for me. > I used the default values of documentation/samples/config. If those need > changes, it's best to do so there. I don't really care, but I personally prefer using builtin only (But that's a personal view) > Then those people use rpms or debs. And in that case, it's usually > already configured out of the box if the packager knows what he's doing. I (Following the example of codeweavers, at least until preview 4 that's the last I tried) use winesetuptk for packages. If you give a default config, you impose something that users may not want and may not know how to change. If you use winesetuptk, you give the user a choice of using a real or fake windows setup, and the user can also choose where to have it. The only difference is that codeweavers has a fancy pop up that asks you to run winesetuptk if it doesn't find a config file, and I'm not codeweavers, so I use the "By Alexandre" vanilla source (Otherwise it wouldn't be a official build anymore). Anyway, the config will go soon, so there isn't much point in discussing this.

1 0

RE: winnt.h file
by Steven Edwards 13 Oct '03

13 Oct '03

Hello Geoff, Comments are inline --- Geoff Peters <Geoff(a)logic.bm> wrote: > Steven - Thanks for the reply. I have 2 C files I am trying to port > to Solaris, one is done (compiles OK), the other one I am working on > has a dependency on wininet.h, along with it comes a huge raft of > other dependencies. I obtained most of these libraries from > http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/?cvs… The w32api package is only for developing Windows application using Mingw on Windows or cross-compiling Windows apps from a GNUtool chain. Winelib is a better solution for your problem. > There is one block of code that is dependent on this wininet.h > library - I am not a C developer (java!), so I'm kinda stumped as to > whether I should attempt to re write the offending piece of code > using a similar Solaris C API (I am assuming the wininet.h contains > most of the HTTP functions for windows), or simply try to match up > the correct libraries - again coming from Java I am having a hard > time understanding different libraries for different platforms to > perform the same functions. The winnt.h header file I am using is the > latest release you had posted on the above link - I just recently > tried to incorporate pieces of > http://cvs.winehq.com/cvsweb/~checkout~/wine/include/winnt.h?rev=1.172&cont… > which have a context defined for SPARC - which seems to be whats > missing from the redhat winnt.h Yes the structures and defines in winnt.h are Windows and WINE only. It will be nearly impossible to use them in a 100% native application. > In case you can offer any suggestions, I have attached a copy of the > C code I am attempting to port, the last function listed (int > call_cc_gateway) is the one that contains the references to wininet.h > > Haven't really looked at WINE, do you think it would help me out?? I think it could help alot. The first thing you may want to try and do is run your win32 application under WINE on a x86 linux box. If it works there then it should recompile as a Winelib application. The issue then becomes does Wine and Winelib work on Sparc. ATM I think the port is incompleate although we did have some people at Sun who were working on it and Wine does run under Solaris for x86. You can try and port your Win32 application if you can get a WINE to build for Solaris on Sparc. Another option would be to look at what functions Wines wininet.dll imports and see if you can develop a native implementation of wininet that sits on top of the Unix TCP/IP implementation rather than on Wine Winsock. We will try to help you as much as possible if you want to go the Winelib route on the Sparc as we really want to see the Solaris on Sparc port working. Thanks Steven > Geoff Peters, SCJP Phone : (441) 296-9640 > Applications Developer Fax : (441) 292-1509 > Logic Communications E-mail : geoff(a)logic.bm > 12 Par-La-Ville Road WWW : http://www.logic.bm > Hamilton, Bermuda HM JX > > > -----Original Message----- > From: Steven Edwards [mailto:steven_ed4153@yahoo.com] > Sent: Monday, October 13, 2003 11:37 AM > To: Geoff Peters; Steven_Ed4153(a)yahoo.com > Subject: Re: winnt.h file > > > Hello, > Are you trying to use Winelib to port your project to solaris? I can > try and help if you are taking this method. If you are using parts of > the w32api package to try and create a native application without > WINE > it may be a little harder. Can you send me your winnt.h header? > > Thanks > Steven > > > --- Geoff Peters <Geoff(a)logic.bm> wrote: > > Hi - Got your email from the cvs.sourceforge.net version info for > the > > winnt.h file. I have a question - wondering if you could help me or > > point me to someone that could - I am porting a win32 app to > Solaris, > > seem to be doing OK with the API's in the repository, however I am > > getting the following error on compilation using gcc on Solaris 8 > > (SPARC): > > > > In file included from /opt/portal/6.2/include/windef.h:246, > > from /opt/portal/6.2/include/windows.h:49, > > from call_tellan_cc_gateway.c:5: > > /opt/portal/6.2/include/winnt.h:1950: #error "undefined processor > > type" > > > > Obviously doesn't recognize the SPARC processor - any idea how I > > could work around this?? > > > > Thanks for your time, Geoff > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > > ATTACHMENT part 2 application/octet-stream name=call_tellan_cc_gateway.c __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

Re: winesetuptk
by Ivan Leo Murray-Smith 13 Oct '03

13 Oct '03

How can msvcrt possibly be native in a without windows setup? Anyway, if you want winver as win98, we might as well have winelook at win98 too. >Which can lead to the question, >what's the purpose of it if wineinstall can do it? wineinstall is a command line tool for installing wine from source code. Most people would say it's a "For geeks only" thing. You can start winesetuptk without knowing what a shell is, and you can set it up with a few clicks of the mouse, it's usually used by people using binary packages, you know, those people that only use computers as tools and don't know/care about source code and tweaking configurations, and that could never use wineinstall.

3 2

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